Re: [secdir] Review of draft-ietf-geopriv-http-location-delivery-07

[Richard Barnes <[e-mail]>]

>>>>> $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
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf