Subject: [Ecrit] RE: L2 vs. L7 Location Discover

From: "James Winterbottom" <[email-masked]>
Date: Thu, 21 Apr 2005 11:22:02 +1000

Hi Marc,
 
Please see comments in line.

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, 21 April 2005 9:30 AM
To: Winterbottom, James [WOLL:5500:EXCH]
Cc: 'GEOPRIV WG'; [email-masked]
Subject: L2 vs. L7 Location Discover

------note the subject change - it's an attempt to more accurately reflect
the topic------

James,

1) Are not complex shape definitions associated with TOA technology which is
associated with wireless?  I don't remember anyone advocating the use of
RFC3825 nor LLDP-MED for a complete wireless solution.  If fact, I know that
RFC3825 recommends using a yet-to-be-determined more exotic method for
passing location information to a wireless client. 

[ajw] Would you not agree that a single approach to location delivery is
more desirable than one per access technology? 

2) In the case of signing the pidf-lo, who is going to sign it when the data
is user derived (either user keyed or on-board gps)? 

[ajw] Please read the HELD draft, it goes into a great deal of explanation
on how this is possible. While there maybe other problems in HELD, this one
is quite well addressed I believe.

3) There seems to be consensus that L1/L2 will, in all but user derived
mechanisms, be involved in location determination at some level.  Is it the
case that you are advocating that the L1/L2 infrastructure build and sign a
pidf-lo and forward to either the client or a L7 service somewhere in the
network? 

[ajw] ABSOLUTELY, this has always been my advocation. Location determination
is clearly layer 1 and layer 2, location delivery is not. I believe that it
is better to provide to the client the object that it plans to use, not
something that it needs to munge in order to be able to use. 

Just attempting to understand.......

-Marc-

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
James Winterbottom
Sent: Wednesday, April 20, 2005 5:55 PM
To: Brian Rosen; [email-masked]
Cc: 'GEOPRIV WG'; [email-masked]
Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
InterimMeeting

I think that there is one other argument that also lends itself to the
returning of the PIDF-LO rather than a layer 2 alternative, and that is that
the contents of PIDF-LO are very likely to change, largely with things being
added to them. To support these changes in PIDF-LO is relatively easy,
because XML is by its very nature extensible. It would be difficult, and I
would argue completely undesirable to have to change myriad of layer 2
protocols to support a new attribute that has been added to PIDF-LO. Case in
point is the provided-by parameter that is already there, another example
would be complex shape definitions, and also the signatures that Brian
describes below.

The problems that I see with the current layer 2 implementation are also
that they are essentially clones of one another with regards to what
information is conveyed, so if it is insufficient in one, or plain simply
wrong (and I am not saying that it is wrong), then the task to fix it is
large.

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Brian Rosen 
Sent: Wednesday, 20 April 2005 11:54 PM 
To: [email-masked] 
Cc: 'GEOPRIV WG'; [email-masked]; 'Andrew Newton' 
Subject: RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting 

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]
<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
<http://www.cs.columbia.edu/directions.html>  
      Also: WiFi provided. 
            Teleconference to be provided. 
     Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html
<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
<https://www1.ietf.org/mailman/listinfo/geopriv>  

_______________________________________________ 
Geopriv mailing list 
[email-masked] 
https://www1.ietf.org/mailman/listinfo/geopriv
<https://www1.ietf.org/mailman/listinfo/geopriv>  

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

---

From: "James Winterbottom" <[email-masked]>
Date: Thu, 21 Apr 2005 11:16:49 +1000

Hi Marc,
 
I am recommending, I think, that we introduce one mechanism now, that tells
us how to get a location.
I can think of several things and ways to do this, include one time URLs. If
this is done right, that is it is a pointer to a location object, then the
location can change and evolve, without us needing to change the underlying
layer 2 mechanism to transport it. I am not saying that changes to L2
protocols are not required to make the initial support possible, what I am
saying is that an evolution of those changes to support new location types
will not be required.
 
Cheers
James

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, 21 April 2005 9:30 AM
To: Winterbottom, James [WOLL:5500:EXCH]
Cc: 'GEOPRIV WG'; [email-masked]
Subject: L2 vs. L7 Location Discover

.....subject changed to more accurately reflect topic.......

James,

Since an argument for L7 location discovery architecture is no changes
needed to the myriad of L2 mechanisms, what are you proposing to use for a
key?

-Marc-

 

Hmmmm!!! 

I am not sure that I agree your statement that the key passed to external
would be the IP address of the client. It could be, but I would most
certainly not advocate that. 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Brian Rosen 
Sent: Thursday, 21 April 2005 2:13 AM 
To: 'Michael Hammer (mhammer)'; [email-masked] 
Cc: 'GEOPRIV WG'; [email-masked] 
Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
InterimMeeting 

The basic picture is: 

LIS ---> endpoint ---> routing element ---> psap 

The LIS knows where the endpoint is. 
The endpoint gets location from the LIS 
The endpoint includes location on the emergency call 
The routing element uses location to route the call to the right PSAP The
PSAP gets the call, and the location. 

The discussion is, how does the endpoint get location from the LIS? DHCP is
one answer.  LLDP-MED is another.  A proposed L7 mechanism is another.

To be sure, there are folks who want to make the picture: 

LIS --> endpoint --> routing element ---> psap 
 ^                        |                 | 
 |                        |                 | 
 +------------------------+                 | 
 |                                          | 
 +------------------------------------------+ 

The LIS gives the endpoint a "key" 
The endpoint includes the key in the emergency call 
The routing element gets the key and exchanges it for location at the LIS
The psap gets the key and exchanges it for location at the LIS

The key could be an IP address. 

Brian 

> From: Michael Hammer (mhammer) [mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, April 20, 2005 12:00 PM 
> 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 
> 
> 
> >From: Brian Rosen [mailto:[email-masked] <mailto:[email-masked]> ] 
> >Sent: Wednesday, April 20, 2005 10:47 AM 
> >To: Michael Hammer (mhammer); [email-masked] 
> >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 
> > 
> > 
> > 
> > 
> > 
> >> From: Michael Hammer (mhammer) [mailto:[email-masked]
<mailto:[email-masked]> ] 
> >> Sent: Wednesday, April 20, 2005 10:14 AM 
> >> 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 
> >> 
> >> >From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On 
> >> >Behalf Of Brian Rosen 
> >> >Sent: Wednesday, April 20, 2005 9:54 AM 
> >> >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. 
> >> > 
> >> >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. 
> >> > 
> >> >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 
> >> >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 
> >> > 
> >> > 
<mailto:[email-masked]> ] 
> >> >On Behalf Of [email-masked] 
> >> >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 
> >> > 
> >> > 
> >> > 
> >> > 
> >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the 
> >use of LI 
> >> >in HTTP/HTML for web browsing. 
> >> >[email-masked] https://www1.ietf.org/mailman/listinfo/geopriv
> >> >[email-masked] https://www1.ietf.org/mailman/listinfo/ecrit
<https://www1.ietf.org/mailman/listinfo/ecrit>  

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