Subject: [Geopriv] Use of IP address as an identifier in draft-ietf-geopriv-http-location-delivery

From: "Brian Rosen" <[email-masked]>
Date: Wed, 31 Oct 2007 08:50:39 -0400

In the long set of discussions that have lead to HELD, one of the biggest
concerns a few of us have had is the problem than an IP address may not be a
good identifier for determining the location of the client.  There is a
draft that describes alternate identifiers.  However, there is no discussion
in the present draft of the base protocol on these issues.  

I would like to propose that we add text something like:

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.

HELD Clients MUST NOT send HELD requests where IP address is the identifier
and a VPN, NAT or other IP address modification exists between the client
and the server which could produce incorrect location.  HELD MUST NOT be
deployed in networks where the client cannot comply reasonably reliably with
that requirement.

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

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 31 Oct 2007 09:08:07 -0400

How is a client supposed to know whether a "VPN, NAT or other IP address
modification exists between the client and the server which could
produce incorrect location"? One of the best uses of HELD is the case
where there is a NAT (and the box with the NAT is location unaware). For
landline broadband services, this NAT exists, but doesn't produce an
incorrect location. So this NAT is ok. How can you distinguish between a
NAT that produces an incorrect location, vs. one that produces a correct
location?

The VPN could be originated out of the router, and not the client. How
would the client know this VPN even exists?

Unless you can tell me the logic to use to implement this proposed
requirement, I can't support it.
Barbara

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, October 31, 2007 8:51 AM
To: [email-masked]
Subject: [Geopriv] Use of IP address as an identifier
indraft-ietf-geopriv-http-location-delivery

In the long set of discussions that have lead to HELD, one of the
biggest
concerns a few of us have had is the problem than an IP address may not
be a
good identifier for determining the location of the client.  There is a
draft that describes alternate identifiers.  However, there is no
discussion
in the present draft of the base protocol on these issues.  

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.

HELD Clients MUST NOT send HELD requests where IP address is the
identifier
and a VPN, NAT or other IP address modification exists between the
client
and the server which could produce incorrect location.  HELD MUST NOT be
deployed in networks where the client cannot comply reasonably reliably
with
that requirement.

*****

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. GA623

---

From: Richard Barnes <[email-masked]>
Date: Wed, 31 Oct 2007 10:22:53 -0400

Right, I think what's needed is more a caveat that HELD provides the 
location of the source IP address in the IP header of the request -- 
whatever that may be.

--Richard