RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures)

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

I'd also add that I don't think the OMA protocols (or the 3GPP) ones, for that matter, are a big problem. You have to understand the context in which they are used - which is well-established cellular networks and their associated location services infrastructure. The cellular industry has been doing location determination, acquisition, and conveyance for years and they've invested mightily in it. Clearly they are not going to fall about the place and modify all their existing architectures, protocols, and implementations just because the IETF now has something to say on the topic. This does not become a problem as long as that entire existing infrastructure is used within the walled garden of the cellular context - with the associated tight coupling between the access operators, their access roaming partners, and the voice and other cellular location service providers. It only becomes a problem once these networks bump up against the Internet. For example, the subscriber just wants to use the cellular network for broadband wireless Internet access but, perhaps, uses Skype. In this case, the client would like to treat it like any other Internet access network - discover a LIS, get a PIDF-LO and away it goes. Going specifically into control-plane mobile originated location request mode via a UMTS RNC and then converting the WGS-84 shape returned into a PIDF-LO before using it with the generic Internet application (Skype) doesn't quite achieve the desired level of transparency. The solution for cellular broadband providers, if they want to be regarded as equal to the majority of other Internet access providers, is to provide a LIS in their access. Unlike DSL and the other providers, these operators don't have to start from scratch. They already have a huge start in terms of implemented location infrastructure. All they have to do is invoke that legacy from their LIS. The LIS will invoke SUPL and/or control-plane location. The established protocols such as MLP, MAP, BSSAP-LE, IS-801, RRLP, ULP (SUPL), and PCAP will come into play. The LIS provides the bridge between the Internet model and the legacy cellular model. It does the conversion between location presentation forms; it supports things such as signing, assertion, and location reference management. It just doesn't need to implement any new location generation functions because it rides on what already exists. The industry can only start from where it is; trying to wind the clock back to the year dot and have everyone start again is not a practical way forward. Cheers, Martin -----Original Message----- From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] Sent: Friday, 16 February 2007 10:56 AM To: Brian Rosen Cc: geopriv@ietf.org Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) While my email was flippant (and I couldn't pretend otherwise), you need to realize that what you ask is a big task. I believe that the correct approach is to address the GEOPRIV-defined location object, the PIDF-LO. This addresses that class of protocols known as GEOPRIV using-protocols. If I was starting today, I would have trouble finding a reason to use anything other than PIDF-LO. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, 16 February 2007 3:04 AM > To: Thomson, Martin > Cc: geopriv@ietf.org > Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF- > LOdigitalsignatures) > > I really don't know what to do about the OMA protocols; it's a big > problem. > > We can probably work with TIA and we certainly can work with the DHCP > stuff > to agree on a signature mechanism. I would prefer you approach this in a > spirit other than "I've solved the problem for PIDF-LO, the rest of you > can > just change to make my solution work with your protocol". > > Nevertheless, we might want to ask, with a couple of years of further work > on location protocols behind us, if in fact allowing a PIDF-LO through > DHCP > is a good idea. > > John S/Marc: if you were starting today, what would you say? > > Brian > > > -----Original Message----- > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > Sent: Thursday, February 15, 2007 12:23 AM > > To: Brian Rosen > > Cc: geopriv@ietf.org > > Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF- > > LOdigitalsignatures) > > > > I'm sorry. I seem to have misplaced my magic wand. > > > > I can recommend a solution for DHCP - since a new option is required to > > carry the signature, let's just make that option carry a PIDF-LO. It's > > less fussy that way and we avoid any concerns about the format. > > > > As for the others, they aren't IETF protocols, but I'm sure it wont be > too > > hard to convince the other SDOs to change: > > > > LLDP-MED already has an option to carry a PIDF-LO, so no problem there. > > Just deprecate the RFC3825 format. > > > > SUPL uses 3GPP GAD, so you'd be better off talking to 3GPP. Perhaps we > > can also come to some arrangement with 3GPP so that we can squeeze a > > signature into a few protocols. After all 23.271 specifies mobile- > > originated location requests. That's a minor change to... (lemme > see)... > > MAP, RRC, RRLP, BSSMAP-LE, and PCAP spring to mind. > > > > As for SUPL - you probably want to get MLP as well, but that's XML so > > maybe there is something we can do (I'll let you talk OMA into > changing). > > > > Oh yeah, and OMA want to include civic addresses - we can give them > those > > for free while we're at it. > > > > Enjoy, > > Martin > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, 15 February 2007 3:37 PM > > > To: Thomson, Martin; Dawson, Martin; 'Henning Schulzrinne' > > > Cc: geopriv@ietf.org > > > Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF- > > > LOdigitalsignatures) > > > > > > As long as it works with L7 LCP, DHCP and LLDP-MED and maybe SUPL, > > great. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > > Sent: Wednesday, February 14, 2007 11:34 PM > > > > To: Brian Rosen; Dawson, Martin; Henning Schulzrinne > > > > Cc: geopriv@ietf.org > > > > Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF- > > > > LOdigitalsignatures) > > > > > > > > I'm pleased. It seems that we are making progress towards a > solution. > > > > > > > > I have been working for a while on a draft that outlines, in more > > > detail, > > > > the "why" and "how" of applying digital signatures to location > > objects. > > > > It is based largely on section 8 of l7-lcp-ps rather than my old > > draft. > > > > After a few weeks, it's largely complete - it just needs the > > trimmings: > > > > schema, examples, IANA, some final touches, reorganization and a > harsh > > > > edit. I'll publish before the -00 deadline as a discussion piece. > > > > > > > > Regards, > > > > Martin > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, 15 February 2007 3:21 PM > > > > > To: Dawson, Martin; 'Henning Schulzrinne' > > > > > Cc: geopriv@ietf.org > > > > > Subject: RE: [Geopriv]WGLCondraft-ietf-geopriv-l7-lcp-ps-00(PIDF- > > > > > LOdigitalsignatures) > > > > > > > > > > We think the cert problem is tractable. > > > > > > > > > > The local PSAP, for example, can deal with its local access > network > > > > > providers. The PSAP can sign the certs of the local providers. > > There > > > > are > > > > > not very many of them, and they are all local (at least in the > sense > > > > that > > > > > there are local people, and local equipment). > > > > > > > > > > Then the PSAP can check the certs. > > > > > > > > > > We actually think we can have a real PKI for PSAPs, but just doing > > > local > > > > > certification is feasible. > > > > > > > > > > Enterprise is a little more difficult, just because of the > numbers. > > I > > > > > think > > > > > we can handle that too, because we have a set of issues to deal > with > > > > that > > > > > involves enterprises, and we can get the cert in the mix. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > > Sent: Wednesday, February 14, 2007 4:44 PM > > > > > > To: Henning Schulzrinne > > > > > > Cc: geopriv@ietf.org > > > > > > Subject: RE: [Geopriv] WGLCondraft-ietf-geopriv-l7-lcp-ps- > 00(PIDF- > > > > > > LOdigitalsignatures) > > > > > > > > > > > > Yes, I think the broader Internet issue of cert security etc. > > needs > > > to > > > > > > be solved in the broader context. Location needs to ride on > > whatever > > > > the > > > > > > best state of the art is. > > > > > > > > > > > > I actually just think of the identity as a unique random number > > that > > > > the > > > > > > LIS generates. That, coupled, with the LIS identity makes for a > > > > globally > > > > > > unique identity that the location recipient can be comfortable > > with > > > > > > using to applying policy against without any user or network > > > specific > > > > > > information having had to be conveyed. > > > > > > > > > > > > Cheers, > > > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > > Sent: Thursday, 15 February 2007 8:37 AM > > > > > > To: Dawson, Martin > > > > > > Cc: jerome.grenier@bell.ca; geopriv@ietf.org > > > > > > Subject: Re: [Geopriv] WGLC > > > > > > ondraft-ietf-geopriv-l7-lcp-ps-00(PIDF-LOdigitalsignatures) > > > > > > > > > > > > I think we're in general agreement. I'm not sure what you mean > > > > > > precisely by "access network identify", but this doesn't have to > > be > > > a > > > > > > NAS identity, say. It could just as well be a (public) IP > address > > or > > > > > > any other token, so that it works for non-authenticated users, > as > > > > > > long as these cannot spoof a large number of network addresses > or > > > > > > similar. In some cases, a combination of a physical network port > > and > > > > > > identity may well be appropriate. If the PSAP gets 100 calls > from > > > > > > "socket 17 at columbia.edu" or "AP 42 at the Anytown Starbucks", > > > even > > > > > > if they all have different MAC addresses, something is likely > > fishy. > > > > > > > > > > > > The remaining hard problem of not having trustworthy certifiers > > > > > > remains and could make any such mechanisms moot. (Although > today's > > > > > > email-return-routability CA mechanism makes it expensive to get > > > > > > dozens of certs, although fishers seem to pay for those with > > stolen > > > > > > credit card numbers...) > > > > > > > > > > > > On Feb 14, 2007, at 4:27 PM, Dawson, Martin wrote: > > > > > > > > > > > > > This is true, I agree. > > > > > > > > > > > > > > I think what we want to do is to make it as difficult as > > possible > > > > > > > to do that more than once for a given client identity in the > > > > > > > network. This, as nearly as possible, would make it the > > equivalent > > > > > > > of Trudy setting her phone to forward to 911. Eve could only > > make > > > > > > > one call at a time through it. Trudy could have two phones and > > > etc. > > > > > > > but, really, Eve is constrained to requiring her partner to > have > > > > > > > the equivalent amount of "presence" in the network as she is > > > > > > > attempting to use. > > > > > > > > > > > > > >> From a PSAP perspective, it is a concern that each call is a, > > > > > > >> presumably, bogus one but they are not particularly concerned > > as > > > > > > >> to whether it is Eve that is effectively dialling them rather > > > than > > > > > > >> Trudy. > > > > > > > > > > > > > > So - the important thing is for the PIDF-LO to be associated > > with > > > a > > > > > > > single apparent identity in the access network so that > > appropriate > > > > > > > policy can be applied against getting two calls arriving with > > this > > > > > > > identity. Note that this "identity" is the anonymous > appearance > > of > > > > > > > a particular IP host in the network and nothing to do with > > > > > > > conveying an individual's real world identity or voice service > > > > > > > subscriber identity. The latter is not the access network's > job. > > > > > > > Requirement 3 is about providing a mechanism for the access > > > network > > > > > > > to convey this "access network identity" as part of the > location > > > > > > > information. > > > > > > > > > > > > > > Cheers, > > > > > > > Martin > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------- > -- > > -- > > > -- > > > > -- > > > > > -- > > > > > > ---------------------- > > > > > > 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 > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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] > ------------------------------------------------------------------------ ------------------------ 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 19:26:57 -0600

This archive was generated by hypermail 2.1.8 : Thu Feb 15 2007 - 20:26:33 EST