>>>>> $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 2008/05/24 15:03:19 ekr Exp $ >>>>> >>>>> S 4.3.1. >>>>> Devices that establish VPN connections for use by other devices >>>>> inside a LAN or other closed network could serve as a LIS, that >>>>> implements the HELD protocol, for those other Devices. Devices >>>>> within the closed network are not necessarily able to detect the >>>>> presence of the VPN and rely on the VPN device. To this end, a VPN >>>>> device should provide the address of the LIS server it provides, in >>>>> response to discovery queries, rather than passing such queries >>>>> through the VPN tunnel. >>>>> >>>>> How do you envision this happening? Isn't this going to require >>>>> changing every VPN protocol? I think some more text would be >>>>> appropriate here... >>>>> >>>>> >>>>> >>>> It requires location information to be obtained before the tunnel is setup. >>>> >>> OK, but I still don't understand how this is going to work. Say that >>> I'm on a local network with a DHCP server and the VPN server is a couple >>> of hops away. How does the VPN device "provide the address of the LIS >>> server" to me? >>> >>> >>> >> When you operate a network and you want this stuff to work then you have >> to consider this aspect. >> In the past a few folks have suggested to write a BCP about how >> different deployments may deal with this aspect but I believe it is far >> too early todo so for a BCP. > > The problem is that I'm not sure that this is an issue that can be solved > by the network operator. In the example I described, it sounds to > me like new protocol work may be required. The current document specifies the use of HELD as a protocol between an endpoint and its local network (i.e., as a location configuration protocol). In that sense, the use case you mention doesn't arise, or rather, the use case can be worked around by appropriate configuration of the LIS by the access network operator (to know how network segments are connected on the VPN). I think this issue merits more of an applicability statement than new protocol work. >>> Well, lots of protocols would benefit from not having IP address >>> spoofing, but again, you're making a levy on network operations >>> on a global scale, no? >>> >>> >> If you want to deal with certain attacks then you may want todo >> something about it. > > Sorry, I don't think I get what you're saying here. What the document is trying to say is that because HELD uses the requestor's IP address as a location identifier, if the LIS is trying to assure that location is actually only provided to the host that originates a request, then it must have assurance that the source IP address of the request is that of the originator, i.e., that the source address of the request has not been spoofed. If there is no requirement for that level of assurance, then there is no requirement for anti-spoofing. On the other hand, given that the LIS is notionally operated by the access network operator, this is actually a local requirement: If you, the network/LIS operator, require this degree of assurance then you MUST implement measures to prevent IP address spoofing. (Note, however, the conditionality.) --Richard _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf