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

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

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

> -----Original Message-----
> 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
> 
> 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:
> > "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
> 

_______________________________________________
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 21:45:45 -0400

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

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

Brian