Subject: [Geopriv] HELD guidance for IP address ID

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 7 Nov 2007 10:52:17 -0500

So, it sounds like there's some general consensus that people want usage
guidance for HELD, especially as it relates to VPNs and NATs, with IP
address as the ID.

Brian originally proposed the following text:
"Use of HELD is subject to the viability of the identifier used by the
LIS to
determine location.  This document describes the use of the IP address
of
the client as the identifier.  When a NAT, VPN or other forms of address
modification occur between the client and the server, the location
returned
may be inaccurate.  This is not always the case.  For example, a NAT
used in
a residential local area network is typically not a problem, because the
external IP address used on the WAN side of the NAT is in fact the right
identifier for all of the devices in the residence.  On the other hand,
if
there is a VPN between the client and the server, for example for a
teleworker, then the address seen by the server may not be the right
address
to identify the location of the client.  Where a VPN is deployed,
clients
often have the ability to bypass the VPN for a transaction like HELD."

I think this is a good start. I didn't like his suggested device
requirements that followed this text, so I propose the following
additional text. If you like the recommendations but want normative
language, feel free to modify.

To minimize the impact of VPNs that do not support split tunneling,
endpoints using IP address as the HELD identifier need to do their HELD
query prior to establishing a VPN tunnel.

Devices that can establish VPN connections for use by other devices
inside a LAN or other closed network should act as a HELD LIS for those
other devices. To accomplish this, such VPN devices that also act as
DHCP server will need to send their IP address or local domain name to
devices in response to a DHCP option requesting LIS server address
[reference to LIS discovery doc]. It may also be useful for such VPN
devices to act as a LIS for other location configuration options
[reference to DHCP options and LLDP-MED]. These VPN devices may support
HELD from a client perspective, as well. In this case, they will need to
do the HELD query prior to establishing a VPN tunnel. 

To minimize the likelihood of incorrect location being delivered to
endpoints accessing the LIS from a VPN connection or a NAT that serves a
large geographic area or multiple geographic locations (for example, a
NAT used by an enterprise to connect their private network to the
Internet), the LIS needs to be configurable to know which IP addresses
are served by such VPNs or NATs. The HELD LIS must not deliver location
to devices at these IP addresses.

LIS operators have a large role in ensuring the best possible
environment for HELD. The LIS operator needs to ensure that the LIS is
properly configured with IP addresses that serve NATs and VPNs. If it is
the intent of the LIS operator to serve devices behind a NAT that serves
a large geographic area or multiple geographic locations, then the LIS
operator needs to place the LIS to operate on the same side of the NAT
as the devices.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 7 Nov 2007 11:11:41 -0500

Barbara, 

> 
> To minimize the impact of VPNs that do not support split 
> tunneling, endpoints using IP address as the HELD identifier 
> need to do their HELD query prior to establishing a VPN tunnel.
> 

Even if the VPN soft client supports split tunneling (allowing traffic on
the local subnet as well as the tunnel), this does not guarantee that HELD
will work.  When an end host has more than one interface, in this case a
tunnel interface and local network interface, you must be ensure that the
routing table in the host sends the HELD request via the correct interface
otherwise the request will arrive at the LIS with an unknown source address
on the packet.  My experience has been that VPN tunnel establishment
modifies the host routing table such that the only traffic put out the local
network interface is traffic destined for that subnet (the default gateway
is on the tunnel).

-Marc-

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 7 Nov 2007 11:24:45 -0500

I've seen a number of VPNs that send Internet traffic across the local
network interface. But, I think that's beside the point. Would the
following rewording be better?

To minimize the impact of VPNs, endpoints using IP address as the HELD
identifier need to do their HELD query prior to establishing a VPN
tunnel.

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2007 11:12 AM
To: Stark, Barbara; [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Barbara, 

> need to do their HELD query prior to establishing a VPN tunnel.

Even if the VPN soft client supports split tunneling (allowing traffic
on
the local subnet as well as the tunnel), this does not guarantee that
HELD
will work.  When an end host has more than one interface, in this case a
tunnel interface and local network interface, you must be ensure that
the
routing table in the host sends the HELD request via the correct
interface
otherwise the request will arrive at the LIS with an unknown source
address
on the packet.  My experience has been that VPN tunnel establishment
modifies the host routing table such that the only traffic put out the
local
network interface is traffic destined for that subnet (the default
gateway
is on the tunnel).

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 7 Nov 2007 17:01:31 -0600

Marc,

If you are trying to make out that the complexity is too high, I'd suggest that you need to base your arguments on experience.

In my experience, having written code for doing discovery, the network interface is a parameter that you need to find first.  Ensuring that the source IP is correct follows from that.

Using HELD in this fashion differs only from DHCP in that location needs to be retrieved from one interface only.  Barbara's suggested text ensures that there is only one place that location information can be successfully retrieved.

The DHCP process is performed for each interface, potentially yielding a 3825 object for each interface.  Perhaps similar text is appropriate for DHCP as well.  After all, poor network configuration there is equally dangerous.

Cheers,
Martin

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Thursday, 8 November 2007 3:25 AM
> To: Marc Linsner; [email-masked]

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: [email-masked]
Date: Wed, 7 Nov 2007 21:47:45 -0500

Hi, 

I have been trying to stay out of this now looong debate, but cannot any 
more...  It is just giving me too much gas. 

I side very strongly with the view of "simplicity is what will happen, no 
matter what we specify" in this.  Wording below aside (which i think is a 
good improvement BTW), a fundamental issue with anything at L7 remains 
that the application doing the location determination may well have 
absolutely no idea what interface is being used, even if it can know. 
There is no easy way to absolutely guarantee that it is not going across 
VPN unless the application itself comes up before VPN --  not a practical 
constraint, especially for soft client apps.  Yeah, clever programming can 
figure it out (as Martin points out)  ... but  WILL IT???    Always ???? 
Even then, there could still be other devices in path that implement VPN 
that are completely invisible to any application on the endpoint.   In the 
end, especially on soft client type apps, developers will always err in 
favour of doing what is easy, and miss the subtle points.   They will very 
often not even realize the subtle points exist.  Possibility that there is 
a VLAN will be missed.  Fire truck will roll to head office ... not where 
*I* currently am.  Hate when that happens .... 

We need to be use wording somewhat along these lines, but I think it needs 
to be written very strongly, and such that the query needs to be done 
before any application needing location can ask for it.  Don't know how to 
write that, short of OS-level requirement. 

-- Peter Blatherwick

"Stark, Barbara" <[email-masked]>
07.11.07 11:24
 
        To:     "Marc Linsner" <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: [Geopriv] HELD guidance for IP address ID

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2007 11:12 AM
To: Stark, Barbara; [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Barbara, 

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 7 Nov 2007 20:56:41 -0600

I wasn’t making a point about clever programming.  I was saying that it is almost an unavoidable consequence of developing working software.  That is, if it works at all, it’s highly likely that it works correctly as well.

Quibbles aside, I think we have consensus on putting the text in.

Cheers,

Martin

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, 8 November 2007 1:48 PM
To: Stark, Barbara
Cc: [email-masked]; Marc Linsner
Subject: RE: [Geopriv] HELD guidance for IP address ID

Hi, 

I have been trying to stay out of this now looong debate, but cannot any more...  It is just giving me too much gas.   

I side very strongly with the view of "simplicity is what will happen, no matter what we specify" in this.  Wording below aside (which i think is a good improvement BTW), a fundamental issue with anything at L7 remains that the application doing the location determination may well have absolutely no idea what interface is being used, even if it can know.  There is no easy way to absolutely guarantee that it is not going across VPN unless the application itself comes up before VPN --  not a practical constraint, especially for soft client apps.  Yeah, clever programming can figure it out (as Martin points out)  ... but  WILL IT???    Always ????   Even then, there could still be other devices in path that implement VPN that are completely invisible to any application on the endpoint.   In the end, especially on soft client type apps, developers will always err in favour of doing what is easy, and miss the subtle points.   They will very often not even realize the subtle points exist.  Possibility that there is a VLAN will be missed.  Fire truck will roll to head office ... not where *I* currently am.  Hate when that happens ....   

We need to be use wording somewhat along these lines, but I think it needs to be written very strongly, and such that the query needs to be done before any application needing location can ask for it.  Don't know how to write that, short of OS-level requirement.     

-- Peter Blatherwick 

07.11.07 11:24 

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2007 11:12 AM
To: Stark, Barbara; [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Barbara, 

-Marc-

---

From: "Tatham Oddie" <[email-masked]>
Date: Thu, 8 Nov 2007 14:11:52 +1100

Hi all,

Is it not also the LIS’s responsibility to not hand out information that it can’t reasonably believe to be accurate (ie. not issuing location information to known VPN clients)? If an LIS opts to not provide location data, the client should perform discovery on other interfaces. This way, the issue is mostly solved server-side, where knowledge of the VPN is mostly likely to exist.

I envision a process like:

1.       Discovery occurs on “default” interface (as per routing table)

2.       Query server – server responds “I don’t know where you are”

3.       Discovery occurs on next interface

4.       Etc

Is there a scenario where the information returned over the VPN would be useful at all (assuming no other data sources can be found)? This would mean that the first server would need to return the location data, as well as an “unsure” flag... That just makes things more complex and I can’t think of a benefit to it.

[ First post BTW – so please don’t shoot me down too much :) ]

Thanks,

Tatham Oddie

 <callto:+61414275989> call:+61414275989,  <callto:+61280113982> call:+61280113982,  <skype:tathamoddie?call> skype:tathamoddie,  <msnim:chat?contact=[email-masked]> msn:[email-masked],  <http://tatham.oddie.com.au/> tatham.oddie.com.au

From: Thomson, Martin [mailto:[email-masked]] 
Sent: Thursday, 8 November 2007 1:57 PM
To: [email-masked]; Stark, Barbara
Cc: [email-masked]; Marc Linsner
Subject: RE: [Geopriv] HELD guidance for IP address ID

Cheers,

Martin

  _____  

Hi, 

-- Peter Blatherwick 

07.11.07 11:24 

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2007 11:12 AM
To: Stark, Barbara; [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Barbara, 

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 7 Nov 2007 21:27:58 -0600

You are right, and this is the gist of Barbara’s text.  If the server knows (and it had better know) then it can say no.

There are scenarios where the server can determine the location of a host on the other end of a VPN, but that’s more an exception than a rule.  Most likely, Barbara’s recommendation that the VPN device act as a LIS is going to be needed.  The VPN device could use its own (non-VPN) connection to acquire the necessary location information.

I think that this is a good general rule – if a VPN is established, whatever establishes that VPN should go outside the tunnel to acquire location information and become a LIS for those who are trapped within.  If the VPN doesn’t capture all traffic, it’s not a problem.

From: Tatham Oddie [mailto:[email-masked]] 
Sent: Thursday, 8 November 2007 2:12 PM
To: Thomson, Martin; [email-masked]; 'Stark, Barbara'
Cc: [email-masked]; 'Marc Linsner'
Subject: RE: [Geopriv] HELD guidance for IP address ID

Hi all,

4.   Etc

 

Thanks,

Tatham Oddie

call:+61414275989 <callto:+61414275989> , call:+61280113982 <callto:+61280113982> , skype:tathamoddie <skype:tathamoddie?call> , msn:[email-masked] <msnim:chat?contact=[email-masked]> , tatham.oddie.com.au <http://tatham.oddie.com.au/> 

Cheers,

Martin

Hi, 

-- Peter Blatherwick 

07.11.07 11:24 

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, November 07, 2007 11:12 AM
To: Stark, Barbara; [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Barbara, 

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 8 Nov 2007 07:03:36 -0500

Barbara, 

> 
> To minimize the impact of VPNs, endpoints using IP address as 
> the HELD identifier need to do their HELD query prior to 
> establishing a VPN tunnel.

I agree with this.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 8 Nov 2007 07:03:36 -0500

Martin,

> 
> If you are trying to make out that the complexity is too 
> high, I'd suggest that you need to base your arguments on experience.
> 
> In my experience, having written code for doing discovery, 
> the network interface is a parameter that you need to find 
> first.  Ensuring that the source IP is correct follows from that.

You are making a leap of faith about developers that I am not prepared to
make.  What about text along the line of:

"When hosts deploy multiple interfaces, either physical, virtual, or a
combination, care needs to be taken to ensure the location request is sent
on the interface that corresponds with the discovery of the LIS.  This is
required as the LIS is utilizing the source IP address of the communication
as the identifier for location lookup."

-Marc-

---

From: Ted Hardie <[email-masked]>
Date: Thu, 8 Nov 2007 09:53:47 -0800

>> establishing a VPN tunnel.

So, I've been following this discussion silently, and I seen an emerging
consensus to recommend this.  But I don't really follow how this logic
doesn't apply to multi-interface situations in general.  On the laptop on which
I am typing, there are three potential non-VPN interfaces:  one wired,
one 802.11, and one EVDO.  The logic to me in selection seems to be
that someone presenting a query to a Location information server using
a particular interface should always use that interface's IP address if
the IP address is the HELD identifier.  (That is, I should use the IP assigned
by my EVDO provider, if I'm using the DO interface to query a LIS).   If
the LIS I reach across that interface doesn't understand that IP address,
it does not return a location (and that can happen when the configured
address of the LIS doesn't know anything about the interface I chose).

In a lot of cases, it seems to me a network can achieve this same effect
with VPN interfaces, simply by marking the pool of addresses associated
with VPN termination points as "unknown location" in the LIS configuration.
I think it would be good practice for it to do so in any case, as timing-related
configuration is always subject to oddity as interfaces come up and down.
That doesn't mean that the above isn't reasonable advice, but given the rest
of the data a LIS has to track, the VPN termination pool data doesn't seem
to be a big extra burden to maintain.

Have I missed the point here?
					Ted

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 8 Nov 2007 19:23:15 -0600

Hi Ted,

You're bang on. Any LIS that (is discoverable and) services HELD
requests from devices attached over a VPN needs to either be able to
provide location reliably for those devices or not actually provide
location. It should be noted that the process of location determination
will involve relating the IP address to some other physical network
parameters associated with that IP address and during that process it
should become evident that the device isn't on any physically measurable
part of the network.

Some VPN scenarios are perfectly reasonable. Two sites connected via a
branch to branch tunnel over the Internet are effectively a single
network. A LIS located at one of those sites can still query network
elements at the other site and determine location for the target IP
address. On the other hand a target device connecting from off-net using
a VPN should only be able to be traced back to the VPN server and the
LIS should recognize that as a situation where location cannot be
determined.

Cheers,
Martin

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Friday, 9 November 2007 4:54 AM
To: Marc Linsner; 'Stark, Barbara'; [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

So, I've been following this discussion silently, and I seen an emerging
consensus to recommend this.  But I don't really follow how this logic
doesn't apply to multi-interface situations in general.  On the laptop
on which
I am typing, there are three potential non-VPN interfaces:  one wired,
one 802.11, and one EVDO.  The logic to me in selection seems to be
that someone presenting a query to a Location information server using
a particular interface should always use that interface's IP address if
the IP address is the HELD identifier.  (That is, I should use the IP
assigned
by my EVDO provider, if I'm using the DO interface to query a LIS).   If
the LIS I reach across that interface doesn't understand that IP
address,
it does not return a location (and that can happen when the configured
address of the LIS doesn't know anything about the interface I chose).

In a lot of cases, it seems to me a network can achieve this same effect
with VPN interfaces, simply by marking the pool of addresses associated
with VPN termination points as "unknown location" in the LIS
configuration.
I think it would be good practice for it to do so in any case, as
timing-related
configuration is always subject to oddity as interfaces come up and
down.
That doesn't mean that the above isn't reasonable advice, but given the
rest
of the data a LIS has to track, the VPN termination pool data doesn't
seem
to be a big extra burden to maintain.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 8 Nov 2007 20:49:29 -0500

Indeed the text has to advise any VPN implementation to make sure that the
VPN IP addresses don't return locations from the LIS.  This is a necessary
step, but it's not sufficient.

I've used the following example before:
You have a small business.  You have a computer in your business and you
have a DSL connection.  Your buddy set you up a VPN tunnel from your home to
your business.  It happens that your home broadband provider is the same
provider as your business.

So, from the broadband provider's point of view, a HELD request from you
through the tunnel is a valid request from your business, and it will return
the location of your business.  You unfortunately are at home.

If your home system always manages to get location captured before the
tunnel is established, or can bypass the VPN, you can get the correct
location.  The problem with this scenario is that it fails really badly.
Failing with no location is bad, but failing with wrong location is very,
very bad.

How is anyone supposed to make this work right?  Let's list the players,
shall we?

The DSL provider
The VPN software vendor
The O/S vendor
The softclient vendor
Possibly your buddy
You, the small business owner

In this particular scenario, the broadband supplier can't help much.
Every VPN vendor needs to know to make sure the tunnel can be bypassed
Every O/S vendor (I'm assuming the O/S vendor is writing the HELD client)
has to know how to make the bypass work, and use that in the HELD client.  I
have no idea how to make "location before tunnel opens" work.  If a client
is mobile, you can't do that.
The softclient vendor has to use the O/S mechanism, or if he implements the
HELD client himself, has to do what the O/S vendor does.  He can't do the
"location before tunnel opens" trick.
Your buddy had better not screw up the configuration in any way that makes
the bypass not work
You are helpless.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Thursday, November 08, 2007 8:23 PM
> To: Ted Hardie; Marc Linsner; Stark, Barbara; [email-masked]

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 8 Nov 2007 20:45:40 -0600

That's a good one.

It's low-runner I think - a locked down tunnel in such a casual
situation. I'd look darkly at your buddy. Somebody who knows enough to
set up a VPN tunnel for you but doesn't know enough not to make it
split...

It also means that every bit-torrent client your kids run, every
Wikipedia page entry they edit, every hotmail account they use will be
attributed to your business' IP address.

Nevertheless, it's a valid scenario and the sort of one that I agree
could occur. As VPN products become more intelligent about recognizing
HELD messaging.this should become even more marginal.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 9 November 2007 12:49 PM
To: Dawson, Martin; 'Ted Hardie'; 'Marc Linsner'; 'Stark, Barbara';
[email-masked]

Indeed the text has to advise any VPN implementation to make sure that
the
VPN IP addresses don't return locations from the LIS.  This is a
necessary
step, but it's not sufficient.

have a DSL connection.  Your buddy set you up a VPN tunnel from your
home to

So, from the broadband provider's point of view, a HELD request from you
through the tunnel is a valid request from your business, and it will
return
the location of your business.  You unfortunately are at home.

If your home system always manages to get location captured before the
tunnel is established, or can bypass the VPN, you can get the correct
location.  The problem with this scenario is that it fails really badly.
Failing with no location is bad, but failing with wrong location is
very,
very bad.

The DSL provider
The VPN software vendor
The O/S vendor
The softclient vendor
Possibly your buddy

In this particular scenario, the broadband supplier can't help much.
Every VPN vendor needs to know to make sure the tunnel can be bypassed
Every O/S vendor (I'm assuming the O/S vendor is writing the HELD
client)
has to know how to make the bypass work, and use that in the HELD
client.  I
have no idea how to make "location before tunnel opens" work.  If a
client
is mobile, you can't do that.
The softclient vendor has to use the O/S mechanism, or if he implements
the
HELD client himself, has to do what the O/S vendor does.  He can't do
the
"location before tunnel opens" trick.
Your buddy had better not screw up the configuration in any way that
makes
the bypass not work
You are helpless.

Brian

> Have I missed the point here?
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------

---

From: [email-masked]
Date: Fri, 9 Nov 2007 15:44:29 -0500

Hi, 
Sorry, I just do not agree this is a "low-runner" scenario.  Details of 
Brian's example aside, the scenario is quite possible even in a relatively 
sophisticated business, and as Brian points out the resulting wrong 
location (as vs no location) is very very bad.  (To quote myself from 
earlier "... Fire truck will roll to head office ... not where *I* 
currently am.  Hate when that happens .... ".) 

We must remember here how many variables and potential players there are 
(Brian's list is a start; there are more).  And, real important, we also 
need to remember that especially for small businesses, the "IT dept" is 
probably either the biz owner themselves, or the poor sap who just happens 
to also know how to load ink into the printer ... or perhaps it is "buddy" 
 in Brian's example.  Also as Brian has re-enforced, working around this 
programmatically on the end device, especially in softclient type 
applications, is not all that straight forward.  Mistakes are quite easy 
to make on all fronts, by laziness, ignorance, or just plain goof-up.  And 
those mistakes will probably not even be visible until something bad 
happens. 

Whatever language we choose to highlight this issue, it had better be very 
prominent, and strongly worded.  I admit I have lost track of where this 
text was to go, but now am thinking it probably wants to go in both HELD 
and in phonebcp. 

-- Peter 

"Dawson, Martin" <[email-masked]>
08.11.07 21:45
 
        To:     "Brian Rosen" <[email-masked]>, "Ted Hardie" 
<[email-masked]>, "Marc Linsner" <[email-masked]>, "Stark, 
Barbara" <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: [Geopriv] HELD guidance for IP address ID

That's a good one.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 9 November 2007 12:49 PM
To: Dawson, Martin; 'Ted Hardie'; 'Marc Linsner'; 'Stark, Barbara';
[email-masked]

The DSL provider
The VPN software vendor
The O/S vendor
The softclient vendor
Possibly your buddy

Brian

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 15 Nov 2007 11:56:46 -0600

Hi all, 

I'm in the process of making changes to the HELD spec based on recent
discussions and nits that have been identified. My interpretation of
this thread is that there is consensus to add the following text to the
document in section 4, which discusses the use of the IP address to
identify the device as follows (last 3 sentences of the 2nd paragraph).
I will be re-arranging that text to accommodate this additional text
(moving those 3 sentences to the end of the section, so it doesn't
interrupt the flow of discussion of PIDF-LO) and I may slightly reword
that first sentence, if necessary, so it will flow better with the
existing text.
    
I know that the thread and debate did continue beyond that suggestion,
but I never saw another concrete text proposal. 

If folks see any issue, let me know ASAP and PLEASE include alternate
text that addresses your concerns.

Thanks,
Mary.

========================================================================
=================================

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 15 Nov 2007 13:09:42 -0500

Mary,
I thought Brian's text characterizing the problem was also appropriate,
as an introduction to why we were making these recommendations.

That was:
Use of HELD is subject to the viability of the identifier used by the
LIS to
often have the ability to bypass the VPN for a transaction like HELD. 

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 12:57 PM
To: [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Hi all, 

Thanks,
Mary.

*****

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 15 Nov 2007 12:37:54 -0600

Barbara,

Good point.  It seems that Brian's text would fit better in the Overview
and Scope (at the end of section 1). And, then we can have the start of
the paragraph in section 2 (Protocol Overview) read something like:

"As discussed in the overview in section 1, the source IP address of the
request message is used as the identifier for the device with the access
network.  To minimize the impact of VPNs, endpoints using IP address as
the HELD identifier need to do their HELD query prior to establishing a
VPN tunnel." 

And then the remaining paragraphs below. 

Mary.

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 12:10 PM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Mary,

That was:
Use of HELD is subject to the viability of the identifier used by the
LIS to determine location.  This document describes the use of the IP
address of the client as the identifier.  When a NAT, VPN or other forms
of address modification occur between the client and the server, the
location returned may be inaccurate.  This is not always the case.  For
example, a NAT used in a residential local area network is typically not
a problem, because the external IP address used on the WAN side of the
NAT is in fact the right identifier for all of the devices in the
residence.  On the other hand, if there is a VPN between the client and
the server, for example for a teleworker, then the address seen by the
server may not be the right address to identify the location of the
client.  Where a VPN is deployed, clients often have the ability to
bypass the VPN for a transaction like HELD. 

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Thursday, November 15, 2007 12:57 PM
To: [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Hi all, 

Thanks,
Mary.

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA625

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 15 Nov 2007 17:49:33 -0600

Hi Mary,

I think the prescription doesn't apply in the case of a branch-to-branch
VPN linking two sites. In that case, it effectively is a common LAN and
it's OK for the LIS to exist at just one site.

I actually think that the responsibility lays at the destination end the
most. The destination VPN server and LIS should make the appropriate
decisions as to whether the incoming requests can be realistically
served via this portal.

It's possible for the source end VPN to act as a LIS (or as a
proxy-LIS), and this may be the best solution in some topologies, but I
think that "should" is too strong a statement.

I certainly agree that the client should do discovery and utilize LIS on
the physical network interface before considering a software VPN link as
a general best practice.

With respect to the "large geographic area" part of the last paragraph,
it's OK as long as the granularity of location represented by that large
area is considered adequate for the users of the LIS. I think "large" is
intended to convey the scenario where that is not the case; it would be
good to make this explicit - e.g. "Where the granularity of the location
needs to be finer than that represented by location of the NAT function,
it is necessary to provide LIS functionality within the network behind
that NAT."

Cheers,
Martin

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, 16 November 2007 4:57 AM
To: [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Hi all, 

Thanks,
Mary.

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 16 Nov 2007 12:47:14 -0600

Martin,

I have a few comments embedded below [MB] and for the rest of the group,
the following is the new proposed text nicely divided into sections, as
suggested by Martin T, with one change  to address Martin D's comments
below:

========================================================================
===================================
4.1 Device Identifiers, NAT and VPNs

Use of HELD is subject to the viability of the identifier used by the
LIS to determine location.  As described in Section 3, this document
describes the use of the IP address of the Device as the identifier.
When NAT, a VPN or other forms of address modification occur between the
Device and the LIS, the location returned could be inaccurate.

This is not always the case.  For example, a NAT used in a residential
local area network is typically not a problem.  The external IP address
used on the WAN side of the NAT is an acceptable identifier for all of
the devices in the residence since the covered geographical area is
small.

On the other hand, if there is a VPN between the Device and the LIS, for
example for a teleworker, then the address seen by the LIS might not be
the right address to identify the location of the Device.

4.1.1 Devices and VPNs

To minimize the impact of VPNs, Devices SHOULD perform their HELD query
prior to establishing a VPN tunnel.  It is RECOMMENDED that discovery
[lis discovery] and an initial query are performed before establishing
the VPN.

Devices that establish VPN connections for use by other devices inside a
LAN or other closed network MAY act as a HELD LIS for those other
devices. Devices within the closed network are not necessarily able to
detect the presence of the VPN and are reliant on the VPN device.  To
this end, a VPN device SHOULD provide the address of the LIS server it
provides in response to discovery queries [reference to LIS discovery
doc].

It could also be useful for a VPN device to act as a LIS for other
location configuration options [reference to DHCP options and LLDP-MED;
3825; 802.1AB; informational ref].

VPN devices that act as a LIS MAY acquire their own location using HELD.

4.1.2 LIS Handling of NATs and VPNs

A LIS MUST NOT provide location information to a Device if it cannot
provide accurate information.  This applies where the Device uses a VPN
connection or is behind a NAT that serves a large geographic area or
multiple geographic locations (for example, a NAT used by an enterprise
to connect their private network to the Internet).  The LIS needs to be
configured to recognize identifiers that represent these conditions.

LIS operators have a large role in ensuring the best possible
environment for location determination.  The LIS operator needs to
ensure that the LIS is properly configured with identifiers that fall
within NATs and VPNs.  In order to serve a Device on a remote side of a
NAT or VPN a LIS needs to have a presence on the side of the NAT or VPN
nearest the Device.

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 5:50 PM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Hi Mary,

I think the prescription doesn't apply in the case of a branch-to-branch
VPN linking two sites. In that case, it effectively is a common LAN and
it's OK for the LIS to exist at just one site.
[MB] Is this concern specific to the text in the 2nd paragraph of 4.1.2.
above. And,   
are you suggesting adding something like this to the end of that second
paragraph or would it better belong somewhere else?:
"In the case of a branch-to-branch VPN linking two sites, a common LAN
is effectively formed, thus the LIS exists at just one site."
[/MB]

I actually think that the responsibility lays at the destination end the
most. The destination VPN server and LIS should make the appropriate
decisions as to whether the incoming requests can be realistically
served via this portal.
[MB] Is this not clear from the text in section 4.1.2 above?  If it
isn't, can you please propose explicit alternate text to what's already
proposed? [/MB]

It's possible for the source end VPN to act as a LIS (or as a
proxy-LIS), and this may be the best solution in some topologies, but I
think that "should" is too strong a statement.
[MB] Here, I believe you're referring to the second paragraph in 4.1.1
and your suggestion seems to be to change the should (which should have
been CAPS) to a MAY, which I've done in the text above.  [/MB]

With respect to the "large geographic area" part of the last paragraph,
it's OK as long as the granularity of location represented by that large
area is considered adequate for the users of the LIS. I think "large" is
intended to convey the scenario where that is not the case; it would be
good to make this explicit - e.g. "Where the granularity of the location
needs to be finer than that represented by location of the NAT function,
it is necessary to provide LIS functionality within the network behind
that NAT."
[MB] Isn't that what's already stated in the text in section 4.1.2? Or,
are you just suggesting we re-iterate what's already there and add your
suggested text to the end of that first paragraph? 

Cheers,
Martin

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Friday, 16 November 2007 4:57 AM
To: [email-masked]
Subject: RE: [Geopriv] HELD guidance for IP address ID

Hi all, 

Thanks,
Mary.

------------------------------------------------------------------------
------------------------
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender immediately
and delete the original.  Any unauthorized use of this email is
prohibited.
------------------------------------------------------------------------
------------------------
[mf2]