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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf