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

"Mary Barnes" <mary.barnes@nortel.com> Thu, 29 May 2008 15:24 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 38E5D28C139; Thu, 29 May 2008 08:24:16 -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 CAD593A6B5F; Thu, 29 May 2008 05:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 YlsHxw-dZ0H5; Thu, 29 May 2008 05:54:19 -0700 (PDT)
Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id D03B13A69AD; Thu, 29 May 2008 05:54:18 -0700 (PDT)
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4TCs1Q02472; Thu, 29 May 2008 12:54:01 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Review of draft-ietf-geopriv-http-location-delivery-07
Date: Thu, 29 May 2008 07:51:02 -0500
Message-ID: <F66D7286825402429571678A16C2F5EE03ADF950@zrc2hxm1.corp.nortel.com>
In-Reply-To: <20080525020040.4DE5A5081A@romeo.rtfm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-geopriv-http-location-delivery-07
Thread-Index: Aci+CmIe+nvI4eraTH+eZmvqEJuS4ACV1crA
References: <20080525020040.4DE5A5081A@romeo.rtfm.com>
From: "Mary Barnes" <mary.barnes@nortel.com>
To: "Eric Rescorla" <ekr@networkresonance.com>, <secdir@mit.edu>, <draft-ietf-geopriv-http-location-delivery@tools.ietf.org>
X-Mailman-Approved-At: Thu, 29 May 2008 08:24:14 -0700
Cc: geopriv@ietf.org, ietf@ietf.org, iesg@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

Hi Eric,

Thanks for you review and comments.  My responses are embedded below
[MB]. 

Mary. 

-----Original Message-----
From: Eric Rescorla [mailto:ekr@networkresonance.com] 
Sent: Saturday, May 24, 2008 9:01 PM
To: secdir@mit.edu;
draft-ietf-geopriv-http-location-delivery@tools.ietf.org
Cc: ietf@ietf.org; iesg@ietf.org
Subject: Review of draft-ietf-geopriv-http-location-delivery-07

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

[MB] Your comment is similar to a point made by Ben Campbell's gen-art
review.
The text is unclear, in particular the "However," clause.  The changes
agreed as a result of the gen-art thread 
http://www.ietf.org/mail-archive/web/gen-art/current/msg02995.html
are reflected below (also incorporating another issue Ben raised, as
well, by adding a new paragraph to that section):

NEW:
   However, this does not in any way suggest that the LIS 
   indiscriminately reveals the location associated with the location
URI.
   The specific requirements associated with the dereference of the 
   location are specified in [I-D.ietf-geopriv-lbyr-requirements]. 
   The location dereference protocol details are out of scope of 
   this document and are specified in 
   [I-D.winterbottom-geopriv-location-deref]. 

   It should also be noted that while the lybr requirements document
   specifies a requirement that a client SHOULD be able to cancel
   location references, the protocol specified in this document
   does not provide that functionality. The mechanism to
   provide this support in the protocol requires explicit management
   of Target state on the LIS. It is anticipated that extensions to HELD
   may support that requirement. 

Does the revised text help to alleviate your concern?

[/MB]


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

[MB] Ben also had concerns with the intent of this text and we went back
and forth several times, with the conclusion of the thread 
http://www.ietf.org/mail-archive/web/gen-art/current/msg03003.html
being to add the following statement to the end of that paragraph to
clarify what happens if the VPN does not serve as a LIS on behalf of the
other devices:
   Otherwise, the other devices would be totally unaware that they 
   could receive inaccurate location information.

However, based on the subsequent discussion on this point, we likely
need to add more text to highlight that this isn't general functionality
we're talking about for all VPNs. This is for a specific configuration
where devices might be unaware that they're using a VPN. In this case,
when those devices try to discovery a LIS, the VPN is recommended to not
tunnel those requests but to serve as the LIS on behalf of those devices
(to ensure the devices receive accurate locations).   So, for your DHCP
example (in a subsequent thread) this configuration doesn't apply.
Also, we previously had more text in here about DHCP, but removed it
because it didn't seem necessary (and was confusing even within the WG).
But, maybe adding that text back in  might help. Here's the old text
from the -05 (this was a discussion point at IETF-71):
   It could also be useful for a VPN device to serve as a LIS for other
   location configuration options such as Dynamic Host Configuration
   Protocol (DHCP)[23] or Link Layer Discovery Protocol - Media Endpoint
   Discovery (LLDP-MED) [27].  VPN devices that serve as a LIS may
   acquire their own location using HELD.
[/MB]

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?

[MB] Per your subsequent response to Hannes on this point, I will change
that bullet to read:
    o  The HELD protocol REQUIRES that the underlying transport provide
authentication, confidentiality and
       protection against modification per Section 10.3.

[/MB]


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?

[MB] Yes, the helds: URI that a device receives in a locationResponse is
the URI that a device would dereference. But, it's important to note
that the LIS does not have to return a helds: URI - other URIs may also
be used per the text in section 6.5. [/MB]


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?

[MB] This isn't a MUST strength because we had WG discussion/consensus
that we can't mandate LIS behavior. We can make recommendations, but a
LIS may not necessarily follow them.  I'm not entirely clear on your
first point as far as "identification by position".  [/MB]

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?
[MB] I will add something like the following to section 8. Also, we have
discussion on the WG mailing list and we will be adding the basic held:
URI schema, as well:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05567.html
OLD: 
   This section defines the schema for a helds: URI.
NEW:
   This section defines the schema for a helds: URI for TLS connections.

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.
[MB] The thread above relates to this point and your next.
On this specific point, we will be defining a held: URI along with the 
helds: URI.  [/MB]


   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?

[MB] Per the thread above, that text does need some clarification for
consistency. It should be
     MUST "implement" and not MUST "use", so I would propose the
following change:
OLD:
   The implementation of HTTP as a transport mechanism MUST implement
   TLS as described in [RFC2818].  TLS provides message integrity and
   privacy 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.
NEW:
   The implementation of HTTP as a transport mechanism MUST implement
   TLS as described in [RFC2818].  TLS provides message integrity and
   privacy between Device and LIS.  The LIS MUST implement the server
   authentication method described in [RFC2818]. When TLS is used, 
   the Device SHOULD fail a request if server authentication fails, 
   except in the event of an emergency.

Does that address your concerns?
[/MB]


   TLS provides message integrity and
   privacy

"privacy" -> "confidentiality"

[MB] Yep. [/MB]

   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?

[MB] Per Hannes response, the device (client) gets the URI of the LIS
(server) using LIS discovery procedures. Thus, the client can use this
URI for comparison.  So, I would suggest one more slight change to the
paragraph above:
NEW:
   The implementation of HTTP as a transport mechanism MUST implement
   TLS as described in [RFC2818].  TLS provides message integrity and
   privacy between Device and LIS.  The LIS MUST implement the server
   authentication method described in [RFC2818]. The device uses the URI
   obtained during LIS discovery to authenticate the server.  When TLS
is used, 
   the Device SHOULD fail a request if server authentication fails, 
   except in the event of an emergency.
[/MB]


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?

[MB] Per Richard's response on this thread, the IP address spoofing
recommendation is due to HELD using the devices IP address as the
identifier for the device. In this case it is important to have a
recommendation for IP address spoofing. I think the paragraph prior to
those bullets appropriately qualifies the context of that
recommendation. 
[/MB]


   o  The LIS and network SHOULD be configured so that the LIS is made
      aware of Device movement within the network and addressing
      changes.  If the LIS detects a change in the network that results
      in it no longer being able to determine the location of the
      Device, then all location URIs for that Device SHOULD be
      invalidated.

This probably needs some more detail about how it's going to work.

[MB] As Hannes responded, the specifics are very network/configuration
dependent. However, I do think that we "should" explain what happens as
an alternative to the SHOULD case by adding something like the following
to the end of that bullet:
   Thus, subsequent dereferences SHOULD fail.  If the LIS does not
invalidate the location URIs, the device can 
   receive inaccurate location information.
[/MB]


   When there are further mechanisms available to authenticate ownership
   of the IP address, the LIS SHOULD use them to authenticate that the
   client is the owner of the target IP address.  For example, in a TLS
   transaction, the client could present a certificate with a public key
   bound to an IPv6 Cryptographically Generated Address, and the LIS
   could verify this binding.

Not that I think that any situation in which the client has an IP
level cert is particularly likely, but this one seems particularly
unlikely.

[MB] I like Hannes' suggestion to just remove this text. Does anyone in
the WG have a concern about that?
[Note: I will also post a note separately to the WG to ensure that they
see this ?]
[/MB]



    

EDITORIAL


[MB] I will fix all of these. Thanks. [/MB]

Abstract:
   independent of session-layer.  This document describes the use of
   Hypertext Transfer Protocol (HTTP) as a transport for the protocol.

This should be HyperText

Also, isn't this using HTTPS, not HTTP.


S 1.
   information.  The LIS service applies to access networks employing

This is the first reference to LIS. Please expand.


   [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which the
   Device might rely on its access network to provide location

"the" -> "a"


   capable of MIME transport.  This document describes the use of
   Hypertext Transfer Protocol (HTTP) as a transport for the protocol.

See comments about abstract.




S 4.3.
I would move this to precede 4.1 and 4.2, since it's orthogonal
to the value/reference distinction.


S 5.1.
   o  The HELD protocol is a request, response protocol, thus the

I would write request/response.


S 6.6.
   schema Section 7 for a location response message due to XML schema

"schema Section 7" -> "schema in Section 7"





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