Subject: Re: Last Call: <draft-ietf-intarea-shared-addressing-issues-02.txt> (Issues with IP Address Sharing) to Informational RFC

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 15 Feb 2011 12:05:41 -0500

One late comment on this: Section 7 discusses the impact of address sharing on geolocation and geo-proximity use cases.  (Nit: common usage is "geolocation", not "geo-location")  This section does a good job of describing the impact of address sharing on the common case where an IP address is used as a key into a generic "IP geo" database.

However, there are several emerging systems that provide much more than these generic databases.  Typically, these systems tap into network management infrastructure to map an IP address to the physical resource to which it is assigned, using things like RADIUS databases and DHCP lease tables. This is an important use case, for example, for ECRIT emergency services [draft-ietf-ecrit-framework] using the HELD location protocol [RFC5985].  (Also an issue that Law Enforcement agencies have been known to care deeply about.)

It would be good for this draft to comment on the impact of address sharing for these high-precision IP-geo systems. Suggested text for after the first paragraph of Section 7:
"
IP addresses are also used as input to higher-fidelity geolocation services that resolve an IP address to a physical location using information from the network infrastructure.  Current systems rely on resources such as RADIUS databases and DHCP lease tables.  The use of address sharing will prevent these systems from resolving the location of a host based on IP address alone.  It will be necessary for users of such systems to provide more information (e.g., TCP or UDP port numbers [I-D.ietf-geopriv-held-identity-extensions]), and for the systems to use this information to query additional network resources (e.g., NAT-PT binding tables).  Since these new data elements tend to be more ephemeral than those currently used for geolocation, their use by geolocation systems may require them to be cached  for some period of time.
" 

On Jan 18, 2011, at 10:04 AM, The IESG wrote:

> 
> The IESG has received a request from the Internet Area Working Group WG
> (intarea) to consider the following document:
> - 'Issues with IP Address Sharing'
>  <draft-ietf-intarea-shared-addressing-issues-02.txt> as an
> Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2011-02-01. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Feb 2011 16:41:33 +0900

Richard L. Barnes wrote:

> However, there are several emerging systems that provide much
> more than these generic databases.  Typically, these systems
> tap into network management infrastructure to map an IP
> address to the physical resource to which it is assigned,
> using things like RADIUS databases and DHCP lease tables.

As you are assuming physical identity of DHCP clients are known
reliably (I don't know how it can be done), it is a lot easier
for DHCP servers to assign static IP addresses to the clients
based on the physical identity information than assigning random
addresses and map them later through complicated database look up.

> This is an important use case, for example, for ECRIT
> emergency services [draft-ietf-ecrit-framework]

Is it a use case in the real world?

> IP addresses are also used as input to higher-fidelity
> geolocation services that resolve an IP address to
> a physical location using information from the network
> infrastructure.

AFAIK, IP addresses can not be used for high fidelity geo-location,
though some copyright-wraiths are hoping so.

						Masataka Ohta

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 16 Feb 2011 08:36:12 -0500

> addresses and map them later through complicated database look up.

As an example, consider a system we built for the IETF meeting network a few years ago.  The server queried a series of tables inside of NetDisco to map an IP address to the WiFi AP that it was connected to:
IP address --> MAC address --> Connected AP
Since the locations of the APs are known, this gives you the location of the endpoint to within a few tens of meters (empirically, within the IETF network).

> Is it a use case in the real world?

The US FCC thinks so:
<http://edocket.access.gpo.gov/2011/pdf/2011-565.pdf>

--Richard

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Feb 2011 23:22:50 +0900

Richard L. Barnes wrote:

> As an example, consider a system we built for the IETF meeting
> network a few years ago.  The server queried a series of
> tables inside of NetDisco to map an IP address to the WiFi AP
> that it was connected to:

As the MAC addresses are NOT reliable, it is a lot more straight
forward to directly map between IP addresses and APs.

> Since the locations of the APs are known, this gives you the
> location of the endpoint to within a few tens of meters
> (empirically, within the IETF network).

Directional antenna makes it imprecise.

> <http://edocket.access.gpo.gov/2011/pdf/2011-565.pdf>

Could you quote the relevant part of the lengthy document?

						Masataka Ohta

---

From: Scott W Brim <[email-masked]>
Date: Wed, 16 Feb 2011 09:28:02 -0500

> forward to directly map between IP addresses and APs.

In the (excellent!) experiment, you associated yourself with one or more MAC
addresses.  Your IP address is more likely to change than your MAC.

> Directional antenna makes it imprecise.

In the (truly excellent) experiment, the goal was to find out which room
someone was in so you could find them.

swb

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 17 Feb 2011 05:41:13 +0900

> addresses.  Your IP address is more likely to change than your MAC.

I can't see the point of insisting on MAC. If MAC is so good, use it,
not IP, for geo-location.

> someone was in so you could find them.

Are there any other hidden assumptions of the experiment?

							Masataka Ohta

PS

I acknowledge there is no real world use cases.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 16 Feb 2011 17:25:11 -0500

Hey Scott,

Thanks for all the "excellent"s.  Hopefully some of them are deserved :)

Couple of clarifications:

> In the (excellent!) experiment, you associated yourself with one or more MAC addresses.  Your IP address is more likely to change than your MAC.

You're actually both right, but neither fact really matters to the experiment.  The goal was to locate "the thing with that IP", and the network is authoritative for which MAC address goes with that IP -- even if the MAC address is bogus and even if the MAC address changes.  In the end, all you really care about is that the thing that is assigned a given IP address is connected to a given access point, which bounds its location.   

> In the (truly excellent) experiment, the goal was to find out which room someone was in so you could find them.   

Even with a directional antenna that's throwing WiFi out for a couple of kilometers, you're still doing a lot better than the generic IP-geo service mentioned in the draft.  And part of the point of discussing ISP-based systems is that the ISP knows how the APs are laid out and configured -- so even if there were directional antennas, the location system could account for them.

In reality, we just did the easy thing.  If we had gotten into signal measurements, we probably could have done much better.  I understand that there are even companies that make products for these sorts of things :)
<http://www.cisco.com/en/US/prod/collateral/wireless/ps5755/ps6301/ps6386/prod_qas0900aecd8029371a.html>

In any case, the broad point is that if you know something about the infrastructure, you can create a better location service, and that such services are being created.  I was just suggesting that it could be helpful for the shared-addressing-issues draft to mention the impact on these systems. 

--Richard