Mike,
You are right--it is being used in two different contexts.
Delivery of location to the endpoint and delivery of location to the PSAP.
We need different terms or we need to qualify the term when we use it (as
above).
Nadine
-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of
Michael Hammer (mhammer)
Sent: Wednesday, April 20, 2005 12:00 PM
To: Brian Rosen; peter_blatherwick@mitel.com
Cc: GEOPRIV WG; ecrit@ietf.org
Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
InterimMeeting
I still get the feeling that "delivery" is being used in two different
contexts:
(1) (2)
Local node---?---->endpoint-----/many hops/----->PSAP
---------------------/many hops/----->
(2)
How can "delivery" be L2 dependent, when it must reach a PSAP many hops
away? Color me confused.
Mike
>-----Original Message-----
>From: Brian Rosen [mailto:br@brianrosen.net]
>Sent: Wednesday, April 20, 2005 10:47 AM
>To: Michael Hammer (mhammer); peter_blatherwick@mitel.com
>Cc: 'GEOPRIV WG'; ecrit@ietf.org
>Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint
>GEOPRIV/ECRIT InterimMeeting
>
>The idea is that, say, you are in your home, served by a DSL provider.
>The domain is then that of the DSL vendor. Your phone asks for its
>location from the server in the DSL domain. It would be given the
>location corresponding to the IP address of the request. Note that
>this would be pretty good for the requested case, even in the presence
>of a NATed local area network in your home. The phone would do this on
>boot, before any VPN tunnels were established.
>
>I get the idea that a single delivery mechanism is desirable.
>I'm skeptical we can do that because of the security issues.
>When you make the delivery mechanism L2 dependent, you can
>control the possible attacks to a finer grain than the L7 local domain.
>
>Please keep in mind that some of the folks wishing to use the
>L7 mechanism don't really want to just return location to the
>endpoint; they want to retain the location and give it out to
>authorized entities upon presentation of the IP address of the
>endpoint. That is a business decision. They can charge for
>such a service. I think the privacy implications of that are
>dicey, but the reality is that's the model that will probably
>be implemented if we do this.
>
>Brian
>
>
>
>
>
>> -----Original Message-----
>> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
>> Sent: Wednesday, April 20, 2005 10:14 AM
>> To: Brian Rosen; peter_blatherwick@mitel.com
>> Cc: GEOPRIV WG; ecrit@ietf.org
>> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint
>GEOPRIV/ECRIT
>> InterimMeeting
>>
>> Brian,
>>
>> Could you clarify the domain statement. Given nomadicity, it would
>> seem that location delivery would need to be cross-domain. The E911
>> PSAP will not always be the same domain as the roaming endpoint.
>>
>> My impression is that Location discovery is a L2 issue, tied to the
>> fact that L2 is supposed to be a single physical hop at most between
>> the end- user terminal and an adjacent location-determining network
>> node. (Of course those trying to make L2 protocols a
>replacement for
>> IP sort of screw this assumption up.)
>>
>> The location delivery mechanism is an application-layer or
>L7 service.
>> The argument there is that since multiple applications will need to
>> rely on location information, a general purpose delivery mechanism
>> will provide consistency and generality that is so often sought in
>> IETF work. Security can be built-in to the chosen delivery
>mechanism.
>> Note, that delivery could be a choice of an existing transfer
>> mechanism. This does not preclude other L7 protocols from
>defining a
>> place in their messages that could also carry location information.
>>
>> So, I believe:
>> Location discovery is local, with associated security being local,
>> Location delivery is global, with associated security being global.
>>
>> The real issues are making those happen.
>>
>> Mike
>>
>> >-----Original Message-----
>> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On
>> >Behalf Of Brian Rosen
>> >Sent: Wednesday, April 20, 2005 9:54 AM
>> >To: peter_blatherwick@mitel.com
>> >Cc: 'GEOPRIV WG'; ecrit@ietf.org
>> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
>> >InterimMeeting
>> >
>> >There turns out to be a large set of issues around this problem,
>> >which I fear is leading to Balkanization. There are two really
>> >important problems we need to solve.
>> >
>> >One fundamental problem is that every client needs to
>implement every
>> >possible LI transfer mechanism that its environment could provide.
>> >
>> >We have DHCP. You guys are working on LLDP-MED. The DSL
>> >guys reject both
>> >of these and want a something else. Every phone has to implement
>> >every protocol.
>> >
>> >There are some who have observed that the mechanisms at hand are L2
>> >specific. They claim as long as you have an L2 specific mechanism,
>> >you need one or more for each L2. To get out of that, they propose
>> >that we use an L7 mechanism (think some version of HTTP, although
>> >that might not fly). They would say, lets do that once,
>and every L2
>> >can use it. The problem is that you then have to deal with the
>> >security issues of an L7 mechanism, and in particular, you have to
>> >use IP address as the "key" for what location to return.
>If you can
>> >spoof IP address, you can get someone else's location.
>> >
>> >Those advocating L7 mechanisms claim that the mechanism
>would only be
>> >implemented within a domain, and the domain would have to take
>> >anti-spoofing steps. They note that the mechanism would need at
>> >least a complete round trip, and probably more than one, so
>spoofing
>> >requires the ability to
>> >intercept packets not addressed to the attacker. The
>> >returned data could
>> >be precisely a PIDF-LO.
>> >
>> >Then on top of that, we turn out to need some more security,
>> >especially for emergency calls. We need to prevent forged
>locations.
>> >That means we need to sign the PIDF-LO. If you get location via
>> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from that,
>> >how do we construct a signature from the entity that actually
>> >determined location?
>> >
>> >Brian
>> >
>> >
>> >________________________________________
>> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> >Behalf Of peter_blatherwick@mitel.com
>> >Sent: Wednesday, April 20, 2005 9:30 AM
>> >To: Andrew Newton
>> >Cc: GEOPRIV WG; ecrit@ietf.org
>> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim
>> >Meeting
>> >
>> >
>> >Hi Andrew, lists,
>> >
>> >I'd like to better understand the meaning of the following agenda
>> >items:
>> > "
>> > 2) Properties of network elements in transferring LI from layer 2
>> > upward to PIDF-LO.
>> > 3) Proposed enhancements to PIDF-LO to support #2.
>> > "
>> >
>> >Is there a summary of what these really mean, or examples
>of what the
>> >outcome could be in terms of protocol or layer interactions?
>> >
>> >Reason I'm asking is I am deeply involved in a layer 2
>approach which
>> >would be able to deliver location information to endpoints from the
>> >L2 LAN infrastructure they are connected to. The work is
>going on in
>> >TIA and is called Link Layer Discovery Protocol - Media Endpoint
>> >Discovery (LLDP-MED), which is an extension of IEEE
>802.1AB, specific
>> >to VoIP systems. In LLDP-MED, among several other things, we have
>> >specified ways to pass equivalent data to the DHCP coordinate-based
>> >LCI (RFC 3825) and civic location LCI
>> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I
>believe).
>> >We see this method of delivery as a non-competing
>alternative to the
>> >DHCP-based approach, with the same end result to the overall ECS
>> >system (the endpoint receives the exact same data), which has some
>> >advantages particularly in enterprise deployment scenarios. (The
>> >DHCP-based method has advantages in different scenarios.) I am
>> >Editor of thi s document, and it is now in ballot process in TIA
>> >(more or less equivalent to Last Call in IETF).
>> >
>> >Sorry, I expect I am suffering lack of context here, since I only
>> >joined the list relatively recently.
>> >
>> >BTW, what is the state of geopriv-dhcp-civil? Is it now past Last
>> >Call and in the RFC Editor's queue? It seemed to have been settled
>> >on the list, and waiting on AD action.
>> >
>> >-- Peter Blatherwick
>> >
>> >
>> >
>> >
>> >Andrew Newton <andy@hxr.us>
>> >Sent by: geopriv-bounces@ietf.org
>> >13.04.05 16:34
>> >
>> > To: GEOPRIV WG <geopriv@ietf.org>
>> > cc:
>> > Subject: [Geopriv] Announcement of Joint
>GEOPRIV/ECRIT
>> >Interim Meeting
>> >
>> >
>> >
>> >
>> >The GEOPRIV and ECRIT working groups will be holding a
>joint interim
>> >meeting.
>> >
>> > What: Interim GEOPRIV/ECRIT meeting
>> > When: 2005 May 16 08:30-17:30
>> > 2005 May 17 08:30-17:30
>> > 2005 May 18 08:30-17:30
>> > Where: Columbia University
>> > Dept. of Computer Science
>> > 450 Computer Science Bldg.
>> > 1214 Amsterdam Avenue (close to 120th St.)
>> > New York, NY 10027
>> >Directions: http://www.cs.columbia.edu/directions.html
>> > Also: WiFi provided.
>> > Teleconference to be provided.
>> > Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html
>> > Early bookings recommended.
>> >
>> >Proposed GEOPRIV Agenda:
>> > 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30
>> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the
>use of LI
>> >in HTTP/HTML for web browsing.
>> >2) Properties of network elements in transferring LI from layer 2
>> >upward to PIDF-LO.
>> >3) Proposed enhancements to PIDF-LO to support #2.
>> >
>> >Proposed ECRIT Agenda:
>> > 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30
>> >1) Emergency Call Routing Requirements
>> >2) Security and Threats Analysis
>> >
>> >_______________________________________________
>> >Geopriv mailing list
>> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >Ecrit mailing list
>> >Ecrit@ietf.org
>> >https://www1.ietf.org/mailman/listinfo/ecrit
>> >
>>
>
>
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 20 Apr 2005 13:03:57 -0400
This archive was generated by hypermail 2.1.8 : Wed Apr 20 2005 - 13:20:26 EDT