$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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf