RE: [Geopriv] Geopriv L7 LCP: New Requirement

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Thu Feb 15 2007 - 00:26:59 EST

The VPN corner case isn't OBO-specific. Any acquisition protocol working over layer 3+ has this issue. The issue is that the LIS may think that the device is actually inside the physical network rather than just joining it virtually. The fear that you're raising is that it may incorrectly associate a location with that device. The solution is that the LIS must be able to detect that the device with the presented IP@ is actually coming through a VPN tunnel. A LIS should respond that it can't provide a location in this case (and that's regardless of whether the request came directly from the device or by OBO). Ultimately it would be preferable that the location client on devices are designed to only discover a LIS via the physical network connections - however it would be na´ve for a LIS implementation to assume this safeguard was in place. Similarly, any NAT situation where the device is on the opposite side of the NAT from the LIS will result in a single location being associated with the outgoing IP@ of that NAT. For homes and small businesses this is OK. For really large businesses, where the granularity of the location information on the user side of the NAT is relevant, there should be a LIS on the user side. This consideration, also, is independent of whether either LIS is queried OBO or direct. Finally, I think OBO is an excellent incremental feature. It's not the network upgrade that's being deferred as you suggest. It's the end-devices that need updating. A LIS should be able to accept both OBO requests, from authorized clients, and device-direct requests from within its area of coverage. A call server that knows how to do an OBO, should also be able to cope with getting an LO or location reference in the call signalling as well. Cheers, Martin -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Thursday, 15 February 2007 3:34 PM To: Dawson, Martin; Winterbottom, James; 'Marc Linsner'; 'Stark, Barbara' Cc: 'GEOPRIV WG' Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement The attraction of OBO is the ability to provide accurate location before we upgrade the endpoints. I really, truly hope that it would not be used as an excuse to not upgrade the networks. The downside of OBO is that there are commonly occurring circumstances that result in WRONG location. Not just no location, wrong location, and no one knows it until they respond. VPN NATed IP addresses that appear to be good is an example (such as a teleworker to a mediums sized enterprise that are on the same carrier's network). In some countries, that may be a fatal problem: it's not failure or mistake or something like that, you know for sure that some number of cases will fail bad. The liability of that is probably too much to handle unless the government specifically exempts the carriers from the liability. The IETF won't like this kind of problem when the solution is relatively straightforward (upgrade to new protocols). If OBO was relatively foolproof, or failed "safe" (no location), it's probably a worthwhile tradeoff. If the use case is "greater good", it's probably a win. However, that is probably not the case. Oh, and James, the endpoint/user is NOT asking it's carrier to do this. As we usually understand it, it's not subject to any kind of user control or sanction, it's something the carrier does to get things like emergency call to work better. I shudder to think of the privacy implications of doing it in some other circumstances. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, February 14, 2007 6:21 PM > To: Winterbottom, James; Marc Linsner; Stark, Barbara > Cc: GEOPRIV WG > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > Just in case James is interpreting your comments too specifically, Marc, > I'll respond from the general perspective. > > "On-behalf-of", as I think we all understand, means that an entity other > than the target device is querying the LIS for the target location. This > means the LIS is explicitly identifying the target by some identifier > (including IP@ as a possibility) as opposed to using the source IP@ of > the requestor to identify the target. > > A key scenario for this is where the target device does not have native > location capability itself (e.g. a legacy regular phone form factor VoIP > handset that can't speak an acquisition protocol). The applicability of > this scenario is really limited to the situation where the entity that > controls the application also controls the access network. This may be > because it's one entity that owns the whole plot or because an > independent trust relationship exists between multiple entities who, > between them, own the whole plot. An example is an enterprise switched > Ethernet network with an IP PABX, legacy VoIP handsets, and their own > LIS. Another example is a DSL provider that provides an on-net VoIP > service (not nomadic to third party access) for their DSL providers. As > such, none of these are really pure Internet services model scenarios. > In both these cases, it is reasonable and secure - and should be > uncontentious - that the call servers can query the LIS on-behalf-of the > legacy devices. > > Barbara was highlighting that regulators, who are often unsympathetic, > will require DSL/VoIP provider as mentioned in the above scenario to > provide full location capability according E911 requirements. They won't > care if there is a problem with getting updates into an existing > population of clients. For this carrier, the OBO mechanism is both > technically possible and reliably implementable. Since an OBO type > request requires strong trust coupling between the requestor and the LIS > - which would involve the use of authentication/authorizatin mechanisms, > trusted networks and the like, it's not really a generic Internet use > case. However, it's still are real one for the acquisition protocol to > accommodate. > > Cheers, > Martin > > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Thursday, 15 February 2007 9:58 AM > To: Marc Linsner; Stark, Barbara > Cc: GEOPRIV WG > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > Marc, > > Your statements demonstrate a clear misinterpretation of the problem in > so far as the way in which Barbara, Guy, Otmar and others are trying to > stating it. > > A user is asking the ISP, "Where am I?" > He has the right do this, doesn't he? > > Has he granted the ISP permission therefore to have his location? > Of course he has, because he is expecting the ISP to know. > > The ISP doesn't know where the user is, but the ISP does know who to > ask. > The thing the ISP is going to ask does know where the User is, but > doesn't call the user by that name. This is fact, and it is NOT OBO as > has been described with relation to a proxy requesting location > on-behalf-of an end-point that is not location capable. It is describing > how a location request can be proxied to a node that actually knows > where location is. Indeed, the LIS to LIS mechanisms is no more OBO than > the DHCP server requesting location from a wiremap database because a > DHCP client has requested one of the location options. > > The LIS to LIS requirement is similar to other relay concepts that the > IETF readily endorses when they are proposed. This is NO DIFFERENT to > the DHCP relay concept on which a number of existing proposals are > heavily dependent. > > In fact, DHCP relay is a very analogy, since the relay agent essentially > uses the same protocol but adds additional identifiers to provide the > DHCP server with additional information. > > Cheers > James > > > > > > > > > > > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Thursday, 15 February 2007 9:34 AM > > To: 'Stark, Barbara' > > Cc: 'GEOPRIV WG' > > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > > > Barbara, > > > > > > > > Furthermore, people have expressed the belief in other venues (other > > > than the IETF) that legislative and/or regulatory bodies in some > > > countries may require true "On Behalf Of" > > > querying by a VPC (VoIP Position Center), when an emergency call > > > arrives without a location. It's believed that this could make for a > > > smoother transition from non-location-capable to location-capable > > > devices. That should be the job of that national entity to legislate > > > this (or not), and not of the IETF to simply prevent it (by refusing > > > to allow a protocol to support this function). Furthermore, it > should > > > be the job of these same national legislative/regulatory bodies to > > > determine and police privacy > > > laws/regulations, and not the IETF. > > > > > > > 1) The IETF is very interested in maintaining the current Internet > > architecture as these attributes directly contribute to the Internet's > > success. The attributes I'm referring to include the separation of > > application from the network. Of particular concern to your proposal > is > > to > > create an application that requires low layer information from the far > > side > > of the Internet as implementation experience tells us that limits are > > created when doing such. It appears some accept these limitations, it > > appears some aspire for these limitations. > > > > 2) The GeoPriv work group is charged with protecting the privacy and > > security of an Internet user's location information. When highly > > sensitive > > information is passed around 'On Behalf Of', it raises large concerns > to > > the > > GeoPriv community. > > > > 3) Regulators will make rules, regulators are not capable of inventing > > technology. Regulators will do what they do regardless of what the > IETF > > does. > > > > _______________________________________________ > > 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 ------------------------------------------------------------------------------------------------ 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 Wed, 14 Feb 2007 23:26:59 -0600

This archive was generated by hypermail 2.1.8 : Thu Feb 15 2007 - 00:26:25 EST