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

From: Dawson, Martin ^lt;Martin.Dawson@andrew.com>
Date: Wed Nov 07 2007 - 22:07:13 EST

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:mlinsner@cisco.com] Sent: Wednesday, 7 November 2007 4:42 AM To: Dawson, Martin; geopriv@ietf.org Cc: 'ECRIT' Subject: RE: [Geopriv]UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery 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... > > 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. > > > > [[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? > [[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- ------------------------------------------------------------------------------------------------ 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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 7 Nov 2007 21:07:13 -0600

This archive was generated by hypermail 2.1.8 : Wed Nov 07 2007 - 22:07:22 EST