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

From: [email-masked]
Date: Wed, 20 Apr 2005 09:29:56 -0400

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

---

From: Andrew Newton <[email-masked]>
Date: Wed, 20 Apr 2005 09:52:37 -0400

> equivalent to Last Call in IETF).

This is a very good question.

At the last GEOPRIV meeting at IETF 62, concerns were raised about how 
devices get location information and send up the protocol stack.  Since 
the IETF does not standardize all components of the stack, it would be 
either foolish or arrogant of us to define "an architecture" of how 
this is done.  Instead, we want to simply identify the different types 
of components in the network and the properties they should/must have 
in order to reliably accomplish the task of gathering location 
information from the network, placing it in a PIDF-LO document, and 
sending that information on its way through the appropriate 
application.

Our hope is to provide a clearer picture to network operators and 
implementors regarding the types of gear needed even if there are 
multiple types of gear to accomplish the same task.

Input regarding LLDP-MED is very much welcome and would be very useful.

> the list relatively recently.

Not a problem.  I hope I explained this in an understandable fashion.

> list, and waiting on AD action.

It was sent up to our AD right as he went on extended leave.  He's back 
now and clearing his queue, so this draft will be moving along shortly 
(as our AD is one of the best in the business).

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Apr 2005 09:53:43 -0400

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,   

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 

        To:        GEOPRIV WG <[email-masked]> 
        cc:         
        Subject:        [Geopriv] Announcement of Joint GEOPRIV/ECRIT
Interim Meeting

Proposed GEOPRIV Agenda:

Proposed ECRIT Agenda:

---

From: Ted Hardie <[email-masked]>
Date: Wed, 20 Apr 2005 10:47:47 -0700

>list, and waiting on AD action.

I'm awaiting a revision of this, as there was a last call comment by
Ralph Droms asking for clarification of whether the option could
be sent from server-to-host and host-to-server.  Here's an
excerpt of his comment:

>
>So, I think the draft needs to be extended with a section on whether the
>option can be sent from the server to the host, from the host to the server.
>Might also be good to be specific about whether the client can request the
>option and whether the server can send it unsolicited.

Here's Henning's reply:

>Ralph,
>
>thanks for your comments. I think your observation applies to both 
>this draft and RFC 3825 (on geo long/lat coordinates). I agree that 
>both directions are useful, although the direction from host to 
>server might necessitate the inclusion of the core privacy elements 
>into the object (distribution, retention).
>
>The draft assumes, probably without the appropriately clear wording, 
>beyond the introductory "End systems that obtain location 
>information via the mechanism" sentence, that this is server-to-host.

Because the draft is in a fairly late state, I had to approve an update
to make this clarification; I did so last Friday.
			regards,
				Ted Hardie