At Sun, 25 May 2008 22:39:24 +0300, Hannes Tschofenig wrote: > > 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. 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 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 What's the status of that document? > > 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. -Ekr _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf