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

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

Brian,

You describe the NENA phase i2 options, ESQK etc.  Your routing element, I assume is doing session routing.

The elements you detail are all (or would appear to be) application-layer entities and the signaling hops are likewise application-layer hops, not L2 hops (except for maybe the LIS-->EP). 

So, where is the L2 "dependency" coming from?

I understand that a network node that is immediately adjacent to the endpoint is most likely to know where the other end of the link terminates, but does that force the delivery protocol aspects of this to be a L2 issue?

Each of the myriad link types carry IP packets, no?  And IP packets can carry an application packet, no?  So, wouldn't the application-layer solution be the more general one?  I thought that was in line with IETF principles.

You are probably just laying out the options, not promoting a particular one.  I would be interested in seeing what the champions of one approach or another have to say.  (I did a search on LLDP-MED and drew a blank.)

Mike

>-----Original Message-----
>From: Brian Rosen [mailto:[email-masked]] 
>Sent: Wednesday, April 20, 2005 12:13 PM
>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
>
>
>> -----Original Message-----
>> From: Michael Hammer (mhammer) [mailto:[email-masked]]
>> Sent: Wednesday, April 20, 2005 12:00 PM
>> To: Brian Rosen; [email-masked]
>> Cc: GEOPRIV WG; [email-masked]
>> 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:[email-masked]]
>> >Sent: Wednesday, April 20, 2005 10:47 AM
>> >To: Michael Hammer (mhammer); [email-masked]
>> >Cc: 'GEOPRIV WG'; [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
>> >
>> >
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: Michael Hammer (mhammer) [mailto:[email-masked]]
>> >> Sent: Wednesday, April 20, 2005 10:14 AM
>> >> To: Brian Rosen; [email-masked]
>> >> Cc: GEOPRIV WG; [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:
>> >> 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 14:07:44 -0400

"Routing" in this context is session (SIP) routing, as you suspected.

The first hop (LIS to endpoint) is what we are discussing.
DHCP is not an L3+ protocol.  Neither is LLDP-MED.

The thread has discussed a number of problems with an L7 mechanism, but
laying them out:

1. You are subject to IP address spoofing (albeit you need to be able to get
the packets sent from the LIS to the IP address you are spoofing)

2. VPN or other tunnels may have been created before you run this protocol.
That will cause a failure; you need the location corresponding to the
original "outermost" IP address.

3. It is difficult to control the security (beyond IP spoofing) because you
don't have a generally good authentication mechanism.  This is a bare phone,
or equivalent, during its boot phase. 

There are probably others as well.  2) is the real problem.

Brian

> Sent: Wednesday, April 20, 2005 1:34 PM
> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
> InterimMeeting
> 
> Brian,
> 
> The elements you detail are all (or would appear to be) application-layer
> entities and the signaling hops are likewise application-layer hops, not
> L2 hops (except for maybe the LIS-->EP).
> 
> I understand that a network node that is immediately adjacent to the
> endpoint is most likely to know where the other end of the link
> terminates, but does that force the delivery protocol aspects of this to
> be a L2 issue?
> 
> Each of the myriad link types carry IP packets, no?  And IP packets can
> carry an application packet, no?  So, wouldn't the application-layer
> solution be the more general one?  I thought that was in line with IETF
> principles.
> 
> You are probably just laying out the options, not promoting a particular
> one.  I would be interested in seeing what the champions of one approach
> or another have to say.  (I did a search on LLDP-MED and drew a blank.)
> 
> Mike
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Apr 2005 14:15:38 -0400

One more little tidbit about 2)
The failure is really, really bad.  You can get a location which is wrong,
and there is no way to figure out that it happened.  You ask for location
inside the tunnel, and the local domain replies with what it thinks the
location is (typically that of the site where the tunnel terminates).  In
some environments, the location mechanism can figure out that you are coming
in on an IP address that is not known to be local, and at least fail better
than giving out the wrong location.  Wrong location is much worse that not
getting a location, or getting one, but knowing there was a problem.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Rosen
> Sent: Wednesday, April 20, 2005 2:08 PM
> To: 'Michael Hammer (mhammer)'; [email-masked]
> GEOPRIV/ECRITInterimMeeting
> 
> > You describe the NENA phase i2 options, ESQK etc.  Your routing element,
> I
> > assume is doing session routing.
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Apr 2005 15:47:35 -0400

There are at least two separate sets of issues that depend on the 
architecture, and it seems dangerous to conflate the two:

(First-person) I get my own location from a server. This makes address 
spoofing more difficult, with return routability. Drawback: If I'm 
behind a NAT, and the location server isn't, this works only if the IP 
address in the IP packet is used, not something in the query. VPNs 
should not be a big deal here.

(Third-person) I ask for an address for an IP address. Address spoofing 
and VPN issues matter, possibly NAT issues (since the IP address I get 
may be a NAT address, given the typical circles of NAT hell in various 
networks.)

I think first-person is much more palatable than third-person.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 20 Apr 2005 15:58:53 -0400

The basic problem for the end system is

"Get the physically closest box that knows to tell me where I am"

The core requirement is zero client configuration.

L2 and DHCP mechanisms have the advantage that they usually are as close 
as you're going to get. You can make this indirect, i.e., have DHCP, PPP 
or L2 tell the client where to get its address.

L2 (LLDP-MED) has the advantage that the physical structure ensures that 
I get the correct answer, without doing mappings. Mappings are always 
subject to being out-of-date or ambiguous or not have the right 
lookup-key information (e.g., real MAC address, lost on its way through 
a router or MAC-spoofing bridge). (This is even true for DHCP, where the 
DHCP server may have to derive from switch port tracing where a device 
is, which is subject to a variety of failure modes.)

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 20 Apr 2005 16:18:55 -0400

I'm having some off line discussions that lead me to the following:

If you have a box that opens a VPN tunnel on the raw Internet connection
that feeds a LAN that has endpoints, and passes ALL LAN traffic through the
tunnel, you are hosed.  The box has to be location aware in some way.  This
is because there is no way, L2 or L7, that you can get a packet to anything
that knows about the location; the box is forcing everything through the
tunnel.  The box is physically between the uplink and the LAN, and you can't
go around it.  The box has to do something that lets you get at the right
LIS.

If the box supplies IP addresses (it's the DHCP server), then it only has to
relay the location option.

If the box doesn't supply addresses, it would have to run something that
either the client could access, or something the DHCP server would access.
We have no solutions.

L7 doesn't help; the box has to do something that would allow you to get to
the local LIS, with the boxe's public IP address.

Softclients are much easier, because the system can get location before the
tunnel is established.  Tunnels downstream of the local infrastructure are
problematic for L7, but not for L2.

This is bad news.  All the boxes have to change.  If we have to change all
the softclients for L7, is that a big enough reason to not use L7?

Hmmm.  I don't know enough about how the boxes work.  To make DHCP work with
the DHCP server in the corporate network, not in the box, the box has to
pass the DHCP packets; they aren't IP packets.  Does that mean it's always a
DHCP relay?  That would help.  The boxes have to change, but if they are
already doing DHCP relay, adding the location option would be the least
amount of work.

I keep hoping I've missed something here.

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2005 3:48 PM
> To: Brian Rosen
> Cc: 'Michael Hammer (mhammer)'; [email-masked]; 'GEOPRIV WG';
> [email-masked]
> Subject: Re: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
> InterimMeeting
>

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 20 Apr 2005 16:56:58 -0400

----note the subject change to reflect the topic------

In-line....

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henning Schulzrinne
> Sent: Wednesday, April 20, 2005 3:59 PM
> To: Michael Hammer (mhammer)
> Subject: Re: [Ecrit] RE: [Geopriv] Announcement of JointGEOPRIV/ECRIT
> InterimMeeting
> 
 
I'm not sure what you mean here.  Neither LLDP-MED nor RFC3825 depend on MAC
address to associate a location.  RFC3825 depends on the switch implementing
the RAIO, which should be pretty safe from ambiguous.  Certainly the wire
map database could be corrupted due to patch cable changes, etc., but this
would equally cause pain in either mechanism.

I think I'm missing something.

-Marc-

snip......

---

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

> I think I'm missing something.

Trying to be brief caused confusion. Let me try to be a bit more clear: 
   I see four levels of indirection, in increasing order:

(Direct) The wire or ether tells the client device where it is -> 
LLDP-MED, 802.11 beacons, BlueTooth beacons, etc. Little room for 
confusion. No need for addresses of any sort. Fewer privacy issues since 
the client never identifies itself in any traceable way.

(L2-interface/circuit) Server maps some circuit identifier to a 
location, based on a mapping (RAIO). No MAC address needed, but probably 
mainly applicable to broadband home networks rather than typical 
corporate networks.

(L2-MAC) The server obtains a MAC address from the client, and then uses 
various bridge-MIB tracing techniques to find out which port the client 
is connected to, by checking where the MAC address has been seen. This 
is subject to some failure scenarios and the problem I mentioned 
obliquely earlier.

(L3) The server gets an IP address and somehow knows the client location.

Note that I said "server" above - this could be a DHCP server, but 
doesn't have to be. Obviously, a DHCP server has the advantage that the 
client knows how to find it.

Also, I don't see the problem with DSL-specific mechanisms, as long as 
only DSL modems need to know this protocol and all of them implement it. 
They'd re-export this information via DHCP, for example, to their 
locally attached devices. Phones and PCs would not even know this 
mechanism existed.