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

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 May 2008 19:00:40 -0700

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

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

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?

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?

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?

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?

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?

   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.

   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.

EDITORIAL
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 25 May 2008 19:19:58 +0300

Hi Ekr,

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

> changing every VPN protocol? I think some more text would be 
It requires location information to be obtained before the tunnel is setup.

> for who? Based on what model?
The solution for HELD is to provide these capabilities as part of TLS.

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.

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

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

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

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

> This probably needs some more detail about how it's going to work.
This depends on the type of network.

Very hard to describe this in general.

I doubt it is useful to go into a lot of descriptions.

> level cert is particularly likely, but this one seems particularly
This paragraph is certainly forward looking. I wouldn't feel sad to 
remove it.

> "schema Section 7" -> "schema in Section 7"
Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 May 2008 11:29:44 -0700

At Sun, 25 May 2008 19:19:58 +0300,
> 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."

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

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

> It would be important to spell this out.

I agree.

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

> It might make sense to differentiate these two cases in the document.

I would agree.

> This URI is then used for comparison.

This seems like it should be explicitly stated.

> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 25 May 2008 22:39:24 +0300

Hi Ekr,

> the request. For instance, the LIS might reject the request for
Sounds good.

> of hops away. How does the VPN device "provide the address of the LIS
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 HELD protocol assumes that the underlying transport provides..."
Yep, sounds good.

> OK, but then what protocol is spoken over that URI? (see my 
The answer is:
http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-00.txt

> spoofing, but again, you're making a levy on network operations
If you want to deal with certain attacks then you may want todo 
something about it.

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 May 2008 15:54:16 -0700

At Sun, 25 May 2008 22:39:24 +0300,
> 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.

> http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-00.txt

What's the status of that document?

> If you want to deal with certain attacks then you may want todo 

Sorry, I don't think I get what you're saying here.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 May 2008 16:46:46 -0700

At Sun, 25 May 2008 15:54:16 -0700,
> What's the status of that document?

Oh, and doesn't this need to be a normative ref, then?

-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Sun, 25 May 2008 20:49:47 -0400

> me like new protocol work may be required.

The current document specifies the use of HELD as a protocol between an 
endpoint and its local network (i.e., as a location configuration 
protocol).  In that sense, the use case you mention doesn't arise, or 
rather, the use case can be worked around by appropriate configuration 
of the LIS by the access network operator (to know how network segments 
are connected on the VPN).  I think this issue merits more of an 
applicability statement than new protocol work.

> Sorry, I don't think I get what you're saying here.

What the document is trying to say is that because HELD uses the 
requestor's IP address as a location identifier, if the LIS is trying to 
assure that location is actually only provided to the host that 
originates a request, then it must have assurance that the source IP 
address of the request is that of the originator, i.e., that the source 
address of the request has not been spoofed.  If there is no requirement 
for that level of assurance, then there is no requirement for anti-spoofing.

On the other hand, given that the LIS is notionally operated by the 
access network operator, this is actually a local requirement: If you, 
the network/LIS operator, require this degree of assurance then you MUST 
implement measures to prevent IP address spoofing.  (Note, however, the 
conditionality.)

--Richard

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 26 May 2008 10:27:08 +0300

>What the document is trying to say is that because HELD uses 
>the requestor's IP address as a location identifier, if the 
>LIS is trying to assure that location is actually only 
>provided to the host that originates a request, then it must 
>have assurance that the source IP address of the request is 
>that of the originator, i.e., that the source address of the 
>request has not been spoofed.  If there is no requirement for 
>that level of assurance, then there is no requirement for 
>anti-spoofing.
>
>On the other hand, given that the LIS is notionally operated 
>by the access network operator, this is actually a local 
>requirement: If you, the network/LIS operator, require this 
>degree of assurance then you MUST implement measures to 
>prevent IP address spoofing.  (Note, however, the
>conditionality.)
>
>--Richard

I think it is also important to mention that IP address spoofing itself
is not sufficient. As an adversary you also need to see the response in
order to actually see the provided location information.

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 May 2008 06:33:39 -0700

At Mon, 26 May 2008 10:17:19 +0300,
Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> 
> Hi Ekr, 
> 
> ~snip~
> 
> >> >   
> >> When you operate a network and you want this stuff to work then you 
> >> have to consider this aspect.
> >> 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.
> 
> So far, there was nobody who believed that new protocol work would be
> required. 

Then I think this document needs some editorial work to 
explain this, since as it is, it certainly gave me
that impression.

> At the last meeting the group agreed that this document should become a
> WG item. 
> I believe my co-author has submitted the document but it got stuck
> somewhere. 
> 
> Thanks for reminding me to ping my co-authors again. 

As noted above, based on my understanding of what you have said,
this needs to be a normative ref.

-Ekr

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 26 May 2008 10:17:19 +0300

Hi Ekr, 

~snip~

>Sorry, I don't think I get what you're saying here.

Let me give you an example from the emergency services space where this
work could be  helpful. 

If the network operator wants to make location information available to
the end host then they have various protocol choices. However, there is
more beyond just using protocols we develop in the IETF, the IEEE or
some other SDOs develop. You need to give the Location Server a way to
perform location determination, i.e., it gets some identifier as input
and then it needs to determine the physical location of that node. 
In some environment that's simpler than in others and it also depends on
the quality of the location you would like to get back. 

Regardless of what identifier you pick for the lookup (let it be a MAC
address, IP address, etc.) you may want to think about cases where an
adversary uses an identifier of someone else. This would potentially
allow him to learn location of someone other than his own location. 

In certain networks this might indeed be possible, for a more detailed
discussion see
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-07.txt

As a network operator you might want to evaluate whether your network
infrastructure is vulnerable to such an attack and to take the
corresponding steps to mitigate them. 

Ciao
Hannes

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 29 May 2008 07:51:02 -0500

Hi Eric,

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

Mary. 

-----Original Message-----
From: Eric Rescorla [mailto:[email-masked]] 
Sent: Saturday, May 24, 2008 9:01 PM
To: [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
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.

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.

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.

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.

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

[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]

[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]

[MB] Yep. [/MB]

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

[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]

[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]

[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:

This should be HyperText

S 1.

"the" -> "a"

S 4.3.

S 5.1.

S 6.6.