Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT InterimMeeting

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 20 Apr 2005 10:13:52 -0400

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: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Brian Rosen
>Sent: Wednesday, April 20, 2005 9:54 AM
>To: [email-masked]
>Cc: 'GEOPRIV WG'; [email-masked]
>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: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>[email-masked]
>Sent: Wednesday, April 20, 2005 9:30 AM
>To: Andrew Newton
>Cc: GEOPRIV WG; [email-masked]
>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 <[email-masked]>
>Sent by: [email-masked]
>13.04.05 16:34 
>        
>        To:        GEOPRIV WG <[email-masked]>
>        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
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/geopriv
>
>
>
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Apr 2005 10:47:21 -0400

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

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2005 10:14 AM
> To: Brian Rosen; [email-masked]
> 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:

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 20 Apr 2005 11:42:52 -0400

snip.........

> tunnels were established.

In the VPN case, the phone most likely is not the device that terminates the
tunnel; this is typically done via a separate box. If the phone were booted
after the tunnel was established, the phone would not have the capability of
contacting the domain with location knowledge.

-Marc-

snip............

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Apr 2005 11:58:13 -0400

Yeah, it's one of the larger limitations of the idea.  The devices that need
location don't have any knowledge of shenanigans happening underneath them,
and they don't have any way to find out.

The typical case works, because in the really, really, really common cases
of teleworkers, hotspot users, and the like, VPN tunnels are established by
software on computers, and not by boxes.  Having said that, there are lots
of IPsec boxes out there, and routers that have those features, and, ....

The folks pushing these ideas, when faced with this kind of problem, tend to
say "if there is a box screwing up the location mechanism, it's up to it to
fix the problem it creates".  They think it's perfectly reasonable for all
tunnel creation things to be aware of location infrastructure, and do the
right thing, whatever that means.  I must admit I don't believe we can do
that.

I may not have stated my own opinions on this issue clearly.
I don't think we can make an L7 mechanism work.  I like the idea in the
theoretic sense, but don't see how to make it work.

I observe that real devices really get IP address from DHCP, and that
mechanism can really be made to work in our favor.  The typical case is a
DSL modem with a home router.  The PCs get IP addresses from DHCP in the
router.  It can use whatever L2 mechanism it wants to get location from the
upstream provider, and then provide location to downstream PCs, phones and
the like via DHCP.  The uncommon case of a single device directly connected
to the DSL modem can be made to work because custom software is always
provided for that case, and can be provided with any L2 specific mechanism
needed to get location.  Push back on that idea is that there are a heck of
a lot of home routers out there, and updating their firmware is really hard.

I recognize the value of LLDP-MED, but I don't like having every phone,
every softclient/PC, etc having to implement LLDP-MED.  We may be stuck with
it, but it's not good.  Better to use DHCP to learn location, and have
something between the switches and the DHCP server to determine location.

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2005 11:43 AM
> To: 'Brian Rosen'; 'Michael Hammer (mhammer)'; [email-masked]
> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint
> GEOPRIV/ECRITInterimMeeting
> 
> snip.........
> 
> >