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

From: "Abbott, Nadine B." <[email-masked]>
Date: Wed, 20 Apr 2005 13:02:08 -0400

The "folks pushing this mechanism" are not using DHCP servers in their
networks to download configuration information. This constitutes a
significant portion of the access network providers in North America. That
is why they see a need to investigate an additional mechanism, e.g., ACS.
And the beyond-transition methods being discussed support download of
location to the endpoint, just not necessarily via DHCP.

On a different point, determination of location will be paid for by someone
(or it won't happen).  It's a matter of who and how. Out of scope for IETF
surely? 

Nadine

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
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
> >
> 

_______________________________________________
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: "Abbott, Nadine B." <[email-masked]>
Date: Wed, 20 Apr 2005 13:03:57 -0400

Mike,
You are right--it is being used in two different contexts.
Delivery of location to the endpoint and delivery of location to the PSAP.
We need different terms or we need to qualify the term when we use it (as
above).
Nadine

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Hammer (mhammer)
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

>From: Brian Rosen [mailto:[email-masked]]
>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
>
>
>
>
>
>> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim 
>> >Meeting
>> >
>> >
>> >Hi Andrew, lists,
>> >
>> >specified ways to pass equivalent data to the DHCP coordinate-based 
>> >LCI (RFC 3825) and civic location LCI 
>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).
>> >

---

From: "Abbott, Nadine B." <[email-masked]>
Date: Wed, 20 Apr 2005 15:09:18 -0400

Really need to change the name of this thread...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Wednesday, April 20, 2005 1:58 PM
To: [email-masked]
Cc: 'GEOPRIV WG'; [email-masked]; 'Michael Hammer (mhammer)'
Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
InterimMeeting

Peter

For some time, I have accepted the fact that we aren't going to be able to
have one mechanism.  I don't like it, but it seems inevitable.  You have to
admit that once you say "more than one" and your reasoning is "different
scenarios" you open the door to the next guy who gets to make the same
argument.  What are the phone vendors going to do?  You really, really don't
want a phone making one assumption and the network L2 vendors another.  The
scenarios where LLDP-MED works COULD, reasonably, use DHCP.  You might like
LLDP-MED for any number of reasons, but it's not the case that DHCP wouldn't
work.  The reverse is not true; there are many networks where there is no
switch that could reasonably implement LLDP-MED.  CableModem is an obvious
one.  At the moment, I'm rationalizing "home=DHCP, enterprise=LLDP-MED", but
I don't want a phone vendor assuming he is only serving one of those
markets.  You guys have made our life difficult, and I don't really think it
had to be, but its reality.

The appeal of the L7 mechanism was that we could have one.  Alas, I don't
see how to make it work.  Ethernet connected devices will probably need
LLDP-MED and DHCP.  That's my current message to phone vendors.

At the moment, all the DSL folks I talk to insist that they won't deploy a
DHCP mechanism or an LLDP-MED mechanism.  They want something else.  That's
the immediate impetuous for the L7 discussion.  If L7 mechanisms don't work,
and I don't think they do, then we either need a DSL L2 mechanism, or we
need them to buy my "home router uses DHCP to clients, and anything the want
to the DSL side" argument.  The DSL guys have some allies; basically boxes
in the middle of L2 that don't have a relationship with the DHCP box.  The
example is the WiFi management boxes.  They know which AP you are connected
to; some may even triangulate.  But those boxes don't run DHCP, and they
don't have an interface to them.  L7 works for them too; especially because
they can limit the domain to the subnet(s) their management boxes handle.
Maybe that's the angle to attack; define an interface to the DHCP server
that lets it get location so it can hand it out to the endpoints.  I've
tried to argue that they could implement LLDP-MED.  I got push back from one
of them, but the reasons don't make sense to me yet.

I've been working on this for some time.  The inclination of EVERY L2 player
is "we need a mechanism just for us".  That, clearly, won't work.  What I
tell them is "if you can control the specification of every end device that
directly or indirectly connects to your L2, then use anything you like, as
long as EVERY device that is connected to your L2 can get location.  If you
can't control endpoints like that, use DHCP (or LLDP-MED)".  3G is an
example of an L2 where they can control all the endpoints.  They have a way
to get location, and that's good enough for me.  

Brian

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

Seems a simple-minded question has sparked a flurry of debate ;-)    Some
thoughts, just to stir the pot some more... not that it appears to need
it... 

I do not at all see the purely L2 LLDP-MED approach and the call it L2.5
DHCP approach as being in conflict.  They are merely different ways suited
to different scenarios.   

I do not see implementing both LLDP-based and DHCP-based methods in a phone
as being a big deal, since in the end they both are simple, would deliver
the exact same data to the application above, and they start in a strict
order (LLDP always before DHCP).  The harder issue is really what would the
poor phone do if it received by both mechanisms, and the received data were
different -- it would need to pick one, or sort out the conflict itself
(yech!).   

Since LLDP (hence LLDP-MED) is strictly contained to a physical link, its
security is very contained.   

IEEE 802.1X is applied to that same link before LLDP gets to run (or before
DHCP for that matter), so at least the endpoint can be well authenticated
before hand.  Also, it intuitively makes sense at least in my fuzzy brain,
that the X509 certs which could be part of the 802.1X authentication
exchange (if EAP-TLS is used) could also be useful in the upward
authentication process.  (If I have messed up the acronyms, please do not
jump down my throat .. hopefully close enough.) 

It would indeed be unfortunate to add a third approach ... or a forth ....  
I am not familiar with whatever the DSL approach would be, but do not
off-hand see why a DHCP relay approach would not work there.  Anything
written up to look at on it? 

Peter 

"Brian Rosen" <[email-masked]> 
20.04.05 10:47 
        
        To:        "'Michael Hammer (mhammer)'" <[email-masked]>,
<[email-masked]> 
        cc:        "'GEOPRIV WG'" <[email-masked]>, <[email-masked]> 
        Subject:        RE: [Ecrit] RE: [Geopriv] Announcement of Joint
GEOPRIV/ECRIT InterimMeeting

Brian

> >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. 
> >
> >requires the ability to intercept packets not addressed to the 
> >attacker.   The returned data could
> >be precisely a PIDF-LO.
> >

---

From: "Abbott, Nadine B." <[email-masked]>
Date: Wed, 20 Apr 2005 15:22:55 -0400

Brian,

Not clear to me why #2 is any more of a problem for an application query
method, than the DHCP method.

You have to have internet access before you can create the VPN (at least on
my software)--since we are talking about VPNs, I assume that we are talking
about softphones.
If you have internet access, an application can perform a query to an LIS
and get its location as soon as it gets its configuration information (by
whatever mechanism).
This can happen BEFORE you create the VPN (certainly what is assumed by the
DHCP download mechanism).
Then the endpoint has its location information and can provide it when it
starts its VoIP application. 

Nadine  

-----Original Message-----
Brian Rosen
Sent: Wednesday, April 20, 2005 2:08 PM

"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
> 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
> 
> >Sent: Wednesday, April 20, 2005 12:13 PM
> >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
> >
> >
> >> How can "delivery" be L2 dependent, when it must reach a PSAP many 
> >> hops away? Color me confused.
> >>
> >> Mike
> >>
> >>
> >> >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.  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
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >> seem that location delivery would need to be cross-domain.  The 
> >> >> E911 PSAP will not always be the same domain as the
> >roaming endpoint.
> >> >>
> >> >> 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
> >> >> >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.
> >> >> >
> >> >> >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
> >> >> >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
> >> >> >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]
> >> >> >  2) Properties of network elements in transferring LI
> >from layer
> >> >> >2
> >> >> > upward to PIDF-LO.
> >> >> >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
> >> >> >DHCP-based approach, with the same end result to the overall 
> >> >> >ECS system (the endpoint receives the exact same data),
> >which has some
> >> >> >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).
> >> >> >
> >> >> >Call and in the RFC Editor's queue?  It seemed to have been 
> >> >> >settled on the list, and waiting on AD action.
> >> >> >
> >> >> >-- Peter Blatherwick
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >[email-masked] https://www1.ietf.org/mailman/listinfo/ecrit
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>

---

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

Thanks for the clarification, allow me to stew on this one a bit.
 
Cheers
James

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, 21 April 2005 11:46 AM
To: Winterbottom, James [WOLL:5500:EXCH]; 'Henning Schulzrinne'
Cc: 'GEOPRIV WG'; [email-masked]
Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
InterimMeeting

The box can run the protocol, be it layer 2 or 7 any time; it has access to
the uplink.

A downstream endpoint can't do that.  It can't get location before the
tunnel is created because the box doesn't pass traffic until the tunnel is
created.

The problem we're discussing is something like an IPsec appliance; a box
physically between the uplink and the local LAN that creates the tunnel when
it initializes and doesn't allow any traffic other than that which goes
through the tunnel.  There are variations on such boxes; you can configure
some of them to allow access outside the tunnel for some things.  Most of
them, I'm told, are DHCP relays at least.

Brian

  _____  

From: James Winterbottom [mailto:[email-masked]] 
Sent: Wednesday, April 20, 2005 9:34 PM
To: Brian Rosen; 'Henning Schulzrinne'
Cc: 'GEOPRIV WG'; [email-masked]
Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
InterimMeeting

I think that you are missing something here. 
You are making the assumption that L7 is only used to retrieve location
after the VPN tunnel has been established, I fail to see why this has to be
the case. It could just as easily be retrieved from the local network prior
to the tunnel being established and so this presents no more difficulty for
VPNs and softclients than a layer 2 delivered solution.

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Brian Rosen 
Sent: Thursday, 21 April 2005 6:19 AM 
To: 'Henning Schulzrinne' 
Cc: 'GEOPRIV WG'; [email-masked] 
Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
InterimMeeting 

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]
<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 
> 
> 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. 
> 
> Brian Rosen wrote: 
> > 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 
> > 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, 

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