Subject: RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim Meeting

From: "James Winterbottom" <[email-masked]>
Date: Thu, 21 Apr 2005 07:55:28 +1000

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]] 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]] 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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Apr 2005 19:17:09 -0400

James Winterbottom wrote:
> 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 

This is bogus. We have essentially two layer-2 mechanisms that inherit 
the same name space. Registering and defining a new XML tag is no easier 
(or no more difficult) than registering a new DHCP numeric tag. Just 
because it's XML doesn't mean that magically all applications understand it.

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 20 Apr 2005 19:30:29 -0400

------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.

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)?

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?

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

-----Original Message----- 

Brian 

Hi Andrew, lists,   

-- Peter Blatherwick 

Proposed GEOPRIV Agenda: 

Proposed ECRIT Agenda: