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

Eric Rescorla <ekr@networkresonance.com> Sun, 25 May 2008 18:32 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBC73A68B9; Sun, 25 May 2008 11:32:28 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933943A69F6; Sun, 25 May 2008 11:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.651
X-Spam-Level:
X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw2CZNw7lXsr; Sun, 25 May 2008 11:29:48 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 7BFD83A6778; Sun, 25 May 2008 11:29:47 -0700 (PDT)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.rtfm.com (Postfix) with ESMTP id DF50C2A74DA; Sun, 25 May 2008 11:29:46 -0700 (PDT)
Date: Sun, 25 May 2008 11:29:44 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07
In-Reply-To: <483991AE.9060906@gmx.net>
References: <20080525020040.4DE5A5081A@romeo.rtfm.com> <483991AE.9060906@gmx.net>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080525182946.DF50C2A74DA@kilo.rtfm.com>
Cc: GEOPRIV <geopriv@ietf.org>, secdir@mit.edu, draft-ietf-geopriv-http-location-delivery@tools.ietf.org, iesg@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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


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



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


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



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

-Ekr

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