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

Hi Ekr,

Eric Rescorla wrote:
> At Sun, 25 May 2008 19:19:58 +0300,
> Hannes Tschofenig wrote:
>   
>> Hi Ekr,
>>
>> Eric Rescorla wrote:
>>     
>>> $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 2008/05/24 15:03:19 ekr Exp $
>>>
>>> TECHNICAL
>>>
>>>
>>> S 4.2.
>>>    which a Location Recipient (LR) can use to retrieve LI.  A location
>>>    URI provided by a LIS can be assumed to be globally-addressable; that
>>>    is, anyone in possession of the URI can access the LIS.  However,
>>>    this does not in any way suggest that the LIS is bound to reveal the
>>>    location associated with the location URI.  This issue is deemed out
>>>
>>> I don't understand this point. anyone in possession of the URI can
>>> access the URI but the LIS isn't required to reveal it? Those
>>> seem kind of contradictory.
>>>
>>>   
>>>       
>> Compare this with a HTTP URL where you might know it but still there are 
>> access policies that control access.
>> Possession does not necessarily mean that you can always get the location.
>>     
>
> OK. That makes sense. Perhaps rewrite:
> "access the LIS and request the location associated with the URI. 
> However, this this does not imply that the LIS is bound to service
> the request. For instance, the LIS might reject the request for
> access control reasons."
>
>   
Sounds good.

>   
>>> 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.

>   
>>> S 5.1.
>>>    o  The HELD protocol must provide authentication, confidentiality and
>>>       protection against modification per Section 10.3.
>>>
>>> Are you talking about HELD, which doesn't seem to have these
>>> features, or about the transport protocol? Also, authentication
>>> for who? Based on what model?
>>>
>>>
>>>   
>>>       
>> The solution for HELD is to provide these capabilities as part of TLS.
>>     
>
> Perhaps this should be rewritten, then as:
>
> "The HELD protocol assumes that the underlying transport provides..."
>
>
>   
Yep, sounds good.

>> For the client to LIS interaction we are talking about server-side 
>> authentication and not client-side authentication.
>>
>> It would be important to spell this out.
>>     
>
> I agree.
>
>
>   
>>> S 6.5.
>>> I'm having trouble keeping straight two kinds of URIs:
>>>
>>> - URIs that a Device uses to get its own LI.
>>> - LbyR references that the LIS hands out.
>>>
>>> This text seems to imply that an LIS can hand out a helds:
>>> URI. Is that *also* the URI that a Device derferences?
>>>   
>>>       
>> The reference points to the device. What the Target uses this reference 
>> either for itself (if it wants to learn it's own location) or (more 
>> likely) it forwards that URI to someone else, for example to a PSAP.
>>     
>
> OK, but then what protocol is spoken over that URI? (see my 
> comments on S 8 below).
>
>
>   
The answer is:
http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-00.txt

>   
>>> S 6.5.1.
>>>
>>>    A "locationURI" SHOULD NOT contain any information that could be used
>>>    to identify the Device or Target.  Thus, it is RECOMMENDED that the
>>>    "locationURI" element contain a public address for the LIS and an
>>>    anonymous identifier, such as a local identifier or unlinked
>>>    pseudonym.
>>>
>>> 1. This seems like it should be clearer about what is desired.
>>>    In particular it's not just "identify" but also "link".
>>>    Also this needs to be clarified to indicate the implications
>>>    of idetntifiction by position.
>>>
>>> 2. Shouldn't this be MUST strength?
>>>
>>>
>>>   
>>>       
>> This is a MUST when possession of the reference also means access to the 
>> resource without any additional authorization policy being used by the 
>> LIS when access to location is being requested.
>>
>> This is a SHOULD when such policies are applied.
>>
>>
>> It might make sense to differentiate these two cases in the document.
>>     
>
> I would agree.
>
>
>   
>>> S 8.
>>> Does this say somewhere what "helds" actually means? I see the
>>> definitition of the URI, but it doesn't say what the 
>>> underlying transport is, as far as I can tell. Given
>>> a "helds:" URI, what am I supposed to do with it?
>>>
>>>
>>> S 9.
>>> OK and here's how I get confusied about the two types of URI,
>>> since this is an HTTP binding, but there's no corresponding
>>> URI.
>>>
>>>
>>>    The implementation of HTTP as a transport mechanism MUST implement
>>>    TLS as described in [RFC2818].
>>>
>>> Is this MUST implement or MUST use? Don't the next two sentences
>>> imply MUST use?
>>>
>>>
>>>    TLS provides message integrity and
>>>    privacy
>>>
>>> "privacy" -> "confidentiality"
>>>
>>>    between Device and LIS.  The LIS MUST use the server
>>>    authentication method described in [RFC2818]; the Device MUST fail a
>>>    request if server authentication fails, except in the event of an
>>>    emergency.
>>>
>>> This is incomplete, because 2818 assumes the presence of a URI to
>>> compare against. Where does that come from? 
>>>
>>> How is client authentication supposed to work here?
>>>
>>>
>>>   
>>>       
>> The client learns the URI using a discovery method, see
>> http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-lis-discovery/
>>
>> This URI is then used for comparison.
>>     
>
> This seems like it should be explicitly stated.
>
>
>   
>>> S 10.3.
>>>    o  The network SHOULD have mechanisms that protect against IP address
>>>       spoofing, such as those defined in [RFC3704].
>>>
>>> Is this WG really in a position to levy a SHOULD level requirement
>>> for network ingress filtering? Recall that this is really a global level
>>> technology. Or do you mean something else?
>>>   
>>>       
>> Being able to deal with IP address spoofing is a useful in certain 
>> environments.
>> Hence, saying that in a document is very useful.
>>     
>
> 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.

Ciao
Hannes

> -Ekr
>   

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf