RE: [Geopriv] Geopriv L7 LCP: New Requirement

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

OK - so I think the specific special case you're referring to is * User attaches to enterprise via a VPN tunnel (from arbitrary unknown location) * User utilizes enterprise's VoIP service which happens to be a carrier provided virtual PABX enterprise service * Carrier call-server performs an OBO based on the user's enterprise assigned, VPN tunnel end-point, IP@ * The LIS that the call-server makes the OBO to is also provided by the carrier and has no visibility into the enterprise network topology Is that the situation? You'll have to be clear if we're to be sure we're not talking at cross purposes. Again, I'm saying that the problem here is not specifically because an OBO was used. The problem is that the LIS being used is not adequate to the task. If the same subscriber did a LIS discovery over the VPN and found the same LIS and did a direct request for location by value or by reference, the LIS would come up with the same location as it did for the OBO. Saying that the device could have avoided the OBO by getting the location from an alternative LIS in its physical network is true, but it doesn't address the root cause which is the use of a LIS that cannot properly detect and determine the necessary granularity within the serving network in question. There are many ways for end-customers to extend their network in ways which are not transparent to the service provider. The "Pringle can scenario" could be the watchword for this. Digital cordless phones with one mile range in the POTS domain are the analog (no pun intended). Any carrier who offers a hosted VoIP service which includes a hosted LIS function needs to make it clear to the customer that their location capability is limited to attributing a single location to their subscribers. If the customer needs better granularity, then the customer needs to look at hosting their own LIS function. Ruling OBO out in all cases of a distributed enterprise is overly extreme. For example, an enterprise-hosted VoIP server with an enterprise hosted LIS can quite reliably provide OBO-based functionality because it can access the necessary internal network details. It can even do that when the enterprise is multi-site and the sites are interconnected via VPN tunnels. Again, in the specific case that you're referring to - where the user is connecting from an unknown location via a VPN - the LIS has to be able to detect and determine that location is unknown in this case. Cheers, Martin -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, 16 February 2007 3:16 AM To: Dawson, Martin; Winterbottom, James; 'Marc Linsner'; 'Stark, Barbara' Cc: 'GEOPRIV WG' Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement Actually no. With the single exception of a hardware VPN box that creates the tunnel before the endpoint even boots, you DON'T have the same problem. The problem occurs when the first time location is added is at emergency call time. If you do it at boot time, you are okay. You can even detect the problem (IP address at boot <> IP address at call time). The endpoint can often (but not always) bypass the tunnel to ask for location. A broadband carrier LIS can't determine if a device is attached virtually to its network, so it can't respond in a correct manner with OBO. The problems with OBO on large enterprise are too numerous to list. I think we can agree "Just don't do that" is the appropriate answer. Finally, if a carrier that implemented OBO also implemented, at the same time, a real LCP, and it checked for the presence of an LO before it added one, then we would get what we wanted. I fear they won't do this. Of course my liability issue would then rain upon them (the device could have reported the correct location, because it was upgraded, but the network didn't provide good location to the device, it insisted the network new better). That would be exactly the case in a teleworker to a small business via a VPN on the same carrier network if the phone implemented the LCPs. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, February 15, 2007 12:27 AM > To: Brian Rosen; Winterbottom, James; Marc Linsner; Stark, Barbara > Cc: GEOPRIV WG > Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement > > 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] ------------------------------------------------------------------------------------------------ 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, 15 Feb 2007 15:59:26 -0600

This archive was generated by hypermail 2.1.8 : Thu Feb 15 2007 - 16:59:21 EST