Subject: [Ecrit] RE: [Geopriv] UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery

From: "Marc Linsner" <[email-masked]>
Date: Tue, 6 Nov 2007 09:38:03 -0500

Martin,

In the case of software VPN, if you read #2, I'm trying to explain that
location configuration needs to happen prior to tunnel establishment.  There
are too many variables involved to depend on LIS/location discovery working
properly during/after tunnel establishment (end host route tables, subnet
restrictions, etc.).

In the case of hardware VPN, if you read #3 & #4, I'm trying to explain
that, in most cases, the hardware VPN device offers network configuration to
the end host and typically the end host has no visibility to the home
network/home router, therefore could not utilizes services of the home or
local SP network.

-Marc-

> -----Original Message-----
> From: Dawson, Martin [mailto:[email-masked]] 
> Sent: Tuesday, November 06, 2007 9:21 AM
> To: Marc Linsner; [email-masked]
> Subject: RE: [Geopriv] UseofIPaddressasanidentifier 
> indraft-ietf-geopriv-http-location-delivery
> 
> I'm trying to understand - given the same constraints in 
> terms of how they are used - what the difference between DHCP 
> and HELD is supposed to be in these use cases...
> 
> Cheers,
> Martin
> 
> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, 7 November 2007 1:13 AM
> To: Dawson, Martin; 'ECRIT'
> Subject: RE: [Geopriv] UseofIPaddressasanidentifier 
> indraft-ietf-geopriv-http-location-delivery
> 
> Martin,
> 
> > 
> > Could you elaborate, specifically, on what the "hardware" 
> VPN issue is 
> > that you're describing? What are the network elements 
> involved, where 
> > is the signalling going, and where does the problem arise?
> > 
> 
> I am not sure what you are asking.  As this thread mutated, 
> James proposed the cautions suggested for inclusion in the 
> HELD draft surrounding NATs & VPNs were not related to HELD, 
> but to service discovery.  James also suggested that "A 
> simple HELD-based LIS/relay-service added to a home router" 
> could solve part/all of the issue.  I was attempting to 
> explain service discovery and how these claims worked with 
> each VPN use case.
> 
> -Marc-   
> 
> 
> 
> > James,
> > 
> > In-line.... 
> > 
> > > Perhaps I am missing something here, but it seems to me
> > that this not
> > > a HELD problem so much as a service discovery problem,
> > which from what
> > > I am lead to believe can be just as problematic with DHCP
> > when it is
> > > run over VPNs. Consequently unless we are going to address
> > that issue
> > > too, I think that AGAIN singling HELD out to address a
> > generic problem
> > > is totally inappropriate.
> > 
> > 1) I don't understand your service discovery statement.  
> DHCP server 
> > discovery is under strict control of the broadcast domain 
> > administration.
> > The end host does not participate in this process.
> > 
> > 2) In the case of a software VPN client, it is assumed the end host 
> > receives configuration information prior to establishment of the 
> > tunnel.  It has been stated many times the end host must 
> utilize the 
> > location received during the first step, prior to tunnel 
> > establishment.  It would also be prudent that location 
> information not 
> > be passed during tunnel establishment.
> > 
> > 3) In the case of a hardware VPN it is typical that the 
> remote device 
> > co-located with the end host provides network 
> configuration.  Location 
> > can be included at that time.
> > 
> > 
> > > 
> > > A simple HELD-based LIS/relay-service added to a home router will 
> > > avoid the issues that have been described by Brian to the
> > same degree
> > > that they are avoided by DHCP. This is very easy to do 
> and we have 
> > > made this work in OpenWRT running on a linksys home-router.
> > 
> > 4) This would not work in the typical hardware VPN environment.
> > 
> > 5) I assume you are not suggesting home users to run OpenWRT..?
> > 
> > I am not keen to start describing these
> > > kinds of solutions in the base HELD specification, a BCP is more 
> > > appropriate, though a mention of care would seem reasonable.
> > 
> > 6) As I stated in another email, in my experience, the IESG 
> will want 
> > applicability included in the base draft, but I'm continually 
> > surprised by the IESG... :^)
> > 
> > 
> > -Marc-
> > 
> > 
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> > 
> > --------------------------------------------------------------
> > ----------------------------------
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender 
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.
> > --------------------------------------------------------------
> > ----------------------------------
> > [mf2]
> > 
> 
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may 
> contain privileged, proprietary, or otherwise private information.  
> If you have received it in error, please notify the sender 
> immediately and delete the original.  Any unauthorized use of 
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
> 

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 6 Nov 2007 08:50:03 -0600

Below.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 7 November 2007 1:38 AM
To: Dawson, Martin; [email-masked]
Cc: 'ECRIT'
Subject: RE: [Geopriv] UseofIPaddressasanidentifier

Martin,

In the case of software VPN, if you read #2, I'm trying to explain that
location configuration needs to happen prior to tunnel establishment.
There
are too many variables involved to depend on LIS/location discovery
working
properly during/after tunnel establishment (end host route tables,
subnet
restrictions, etc.).
[[MCD]] Right - which is the same constraint as applies to using DHCP...

In the case of hardware VPN, if you read #3 & #4, I'm trying to explain
that, in most cases, the hardware VPN device offers network
configuration to
the end host and typically the end host has no visibility to the home
network/home router, therefore could not utilizes services of the home
or
local SP network.

[[MCD]] This is the one I'm asking you to explain... let's start with
the target/user device in the home network... where is this hardware VPN
device?
-Marc-

> > and delete the original.  Any unauthorized use of this email is 

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 6 Nov 2007 10:24:13 -0500

Martin,

In-line...
> 
> In the case of software VPN, if you read #2, I'm trying to 
> explain that location configuration needs to happen prior to 
> tunnel establishment.
> There
> are too many variables involved to depend on LIS/location 
> discovery working properly during/after tunnel establishment 
> (end host route tables, subnet restrictions, etc.).

Not exactly the same.  End host invocation of DHCP is predictable and
therefore solutions are predictable.  End host invocation of HELD is not
predictable nor controllable.

> 
> In the case of hardware VPN, if you read #3 & #4, I'm trying 
> to explain that, in most cases, the hardware VPN device 
> offers network configuration to the end host and typically 
> the end host has no visibility to the home network/home 
> router, therefore could not utilizes services of the home or 
> local SP network.
> 
> [[MCD]] This is the one I'm asking you to explain... let's 
> start with the target/user device in the home network... 
> where is this hardware VPN device?

You actually need me to answer this?

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 6 Nov 2007 09:42:01 -0600

ditto

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 7 November 2007 2:24 AM
To: Dawson, Martin; [email-masked]
Cc: 'ECRIT'
Subject: RE: [Geopriv] UseofIPaddressasanidentifier

Martin,

In-line...

Not exactly the same.  End host invocation of DHCP is predictable and
therefore solutions are predictable.  End host invocation of HELD is not
predictable nor controllable.
[[MCD]] Seems a matter of degree - DHCP requests could be sent broadcast
or unicast; it's not totally predictable.

You actually need me to answer this?
[[MCD]] I don't know that I need it; but I'd appreciate it. Is that it a
problem?

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 6 Nov 2007 12:42:23 -0500

Martin, 

> > 
> > In the case of software VPN, if you read #2, I'm trying to explain 
> > that location configuration needs to happen prior to tunnel 
> > establishment.
> > There
> > working properly during/after tunnel establishment (end host route 
> > tables, subnet restrictions, etc.).
> Not exactly the same.  End host invocation of DHCP is 
> predictable and therefore solutions are predictable.  End 
> host invocation of HELD is not predictable nor controllable.
> [[MCD]] Seems a matter of degree - DHCP requests could be 
> sent broadcast or unicast; it's not totally predictable.

Your comment makes no sense, besides broadcast vs. unicast being irrelavent
to this discussion, there is no mechanism to advise an end host of the
available DHCP servers prior to the initial end host DHC discover packet.
The handling of the discovery packets is under total control of the
broadcast domain administration.

It is very predictable when an end host invokes DHCP.  It is very
predictable what DHCP server an end host communicates with.  Hence, the
response from the DHCP server is totally controllable.

> 
> 
> > 
> > In the case of hardware VPN, if you read #3 & #4, I'm trying to 
> > explain that, in most cases, the hardware VPN device offers network 
> > configuration to the end host and typically the end host has no 
> > visibility to the home network/home router, therefore could not 
> > utilizes services of the home or local SP network.
> > 
> start with 
> > the target/user device in the home network...
> [[MCD]] I don't know that I need it; but I'd appreciate it. 
> Is that it a problem?

The use case is a hardware VPN device in the home network, so the hardware
VPN device connects to the home network and the end host connects to the VPN
device.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 7 Nov 2007 21:07:13 -0600

Hi Marc,

I'll elaborate... let's use the example of some application wanting to
use 3825 on a Windows OS where a software VPN is also installed.

My point is actually that you can't assume anything about where the
software VPN virtual network adaptor inserts itself in the Windows
kernel (including whether it does or doesn't).

We can certainly know that Windows will hijack (i.e. "take
responsibility for") the initial DHCP broadcast associated with the
physical NIC connection initialization. There's no opportunity to ask
for option 123 at that stage. Anybody who wants to take advantage of a
3825-enabled server at the moment (and possibly for all time) will need
to implement a subsequent DHCP request. This will almost certainly
involve the construction of a unicast request - something like the
following:

byte privateoption =
Convert.ToByte(Configuration.GetValue("dhcpprivateoption"));

 request.AddOption(55, new byte[1] { 123 });

 DHCPPacket packet = DHCPClient.Request(info, dhcpserver, request);

So - what will the software VPN do with that? I think the answer is that
we don't know - it will depend on the implementation. Nevertheless, I
think it's clearly possible that it will result in the unicast being
pushed down the VPN tunnel. I don't see any difference between this and
the scenario of a HELD request being pushed down the VPN tunnel. Hence,
I don't think there's any basis for suggesting that, in a software VPN
scenario, DHCP is guaranteed to be functional or that it is exempt from
documenting such issues any more than HELD is.

You could argue that the OS is responsible for asking for option 123 at
NIC initialization time. I could similarly argue that the OS be
responsible for doing the HELD query at the same time. It is all a
matter of degree and there are a lot of assumptions about DHCP which I
think are spurious.

With respect to the hardware VPN - again - a hardware VPN could be
configured badly such that it routes the local LIS requests down the
tunnel. It could do the same thing with a DHCP unicast - if the CHADDR
is outside the subnet. The DHCP server *could* be inside the broadcast
domain but, then, so could a LIS. As long as you stick to the same rules
for each model, the qualitative nature of the risks isn't any different.

Note - I'm not arguing that it's not useful to have such caveats spelt
out whatever the acquisition protocol in question is. However, I think
too much is made of the difference between HELD and DHCP and the need
for good advice in either case.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 7 November 2007 4:42 AM
To: Dawson, Martin; [email-masked]
Cc: 'ECRIT'
Subject: RE: [Geopriv]UseofIPaddressasanidentifier

Martin, 

> sent broadcast or unicast; it's not totally predictable.

Your comment makes no sense, besides broadcast vs. unicast being
irrelavent
to this discussion, there is no mechanism to advise an end host of the
available DHCP servers prior to the initial end host DHC discover
packet.
The handling of the discovery packets is under total control of the
broadcast domain administration.

> [[MCD]] I don't know that I need it; but I'd appreciate it. 

The use case is a hardware VPN device in the home network, so the
hardware
VPN device connects to the home network and the end host connects to the
VPN
device.

-Marc-