RE: [Geopriv] HELD guidance for IP address ID

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Thu Nov 08 2007 - 21:45:40 EST

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:br@brianrosen.net] Sent: Friday, 9 November 2007 12:49 PM To: Dawson, Martin; 'Ted Hardie'; 'Marc Linsner'; 'Stark, Barbara'; geopriv@ietf.org Subject: RE: [Geopriv] HELD guidance for IP address ID 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 > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, November 08, 2007 8:23 PM > To: Ted Hardie; Marc Linsner; Stark, Barbara; geopriv@ietf.org > Subject: RE: [Geopriv] HELD guidance for IP address ID > > 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:hardie@qualcomm.com] > Sent: Friday, 9 November 2007 4:54 AM > To: Marc Linsner; 'Stark, Barbara'; geopriv@ietf.org > Subject: RE: [Geopriv] HELD guidance for IP address ID > > At 7:03 AM -0500 11/8/07, Marc Linsner wrote: > >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- > > 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 > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ------------------------------------------------------------------------ -- > ---------------------- > 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 > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------------------------------ 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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 8 Nov 2007 20:45:40 -0600

This archive was generated by hypermail 2.1.8 : Thu Nov 08 2007 - 21:45:57 EST