Re: [Geopriv] Review of draft-ietf-geopriv-http-location-delivery-05.txt

["Mary Barnes" <[e-mail]>]

Hi Hannes,

Thanks for the review. Responses are embedded below [MB].

Mary. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Hannes Tschofenig
Sent: Saturday, March 29, 2008 10:58 AM
To: GEOPRIV
Subject: [Geopriv] Review of
draft-ietf-geopriv-http-location-delivery-05.txt

I have reviewed previous versions of the draft already.
The document looks good.

I only have a few minor questions.
 
** Figure


                     +---------------------------------------------+
                     | Access Network Provider                     |
                     |                                             |
                     |   +--------------------------------------+  |
                     |   | Location Information Server          |  |
                     |   |                                      |  |
                     |   |                                      |  |
                     |   |                                      |  |
                     |   |                                      |  |
                     |   +------|---------------------'---------+  |
                     +----------|---------------------'------------+
                                |                     '
                                |                     '
                               HELD                  APP
                                |                     '
     Rule Maker   - _     +-----------+         +-----------+
           o          - - | Device    |         | Location  |
          <U\             |           | - - - - | Recipient |
          / \       _ - - |           |   APP   |           |
         Target - -       +-----------+         +-----------+

                        Figure 1: Significant Roles



I would label the protocol exchange between the LR and the LIS
differently.
SIP Location Conveyance, as mentioned for the APP between the Device and
the LR, cannot be used between the LR and the LIS.

[MB] Good point. But, how should we label that interface (note that it
was unlabeled in the individual draft)? If we go back to RFC 3693, the
interface between the LS and the LR  is identified as a "notification
interface".  I'd prefer to just remove that interface since it's really
outside the scope of HELD and just add a note that only the interfaces
relevant to the Device, related to its use of the HELD protocol, are
shown. [/MB]

** VPN Usage

Some time ago I got the impression that we would put a more detailed 
description of VPN handling in another document. The text is fine but 
one could obviously describe details here and there.

[MB] I don't recall that we were going to add text elsewhere. The text
that's in there was what was discussed and agreed on the mailing list
and I don't recall that there was to be another document for VPN. I
thought that the idea was to add relevant text to this document rather
than putting something in another document. [/MB]


** HELD URI

Section 8 says:
"
query: As defined in RFC3986 [22]. This allows for additional 
information associated with the URIs such as a unique anonymous 
identifier for the Device associated with the target location.
"

I do not understand where this parameter comes from and why we need it.
Sorry if I missed some discussions.

[MB] Per RFC3986, 
 
   The query component contains non-hierarchical data that, along with
   data in the path component (Section 3.3), serves to identify a
   resource within the scope of the URI's scheme and naming authority
   (if any).  The query component is indicated by the first question
   mark ("?") character and terminated by a number sign ("#") character
   or by the end of the URI.

So, the intent was that field could be used for that random component
you mention below. Something
that's meaningless to anyone but the LIS that creates it. [/MB]


"
The following are examples of held:
   URIs:


     held://ls.example.com:49152/thisLocation?token=xyz987
     held://ls.example.com/THISLOCATION
     held://ls.example.com/THISlocation
     held://ls.example.com/civic
"

These aren't good examples given that we state in another place that the

URIs should contain a random component. Hence, in the typical case they 
will be random.

I don't understand the first URI example.

[MB] The first one is an error leftover from the original URI
definition. "token" should be "query" per comment above. I agree the
examples could use improvement, adding the random component, which was
the point of the token in the first one (i.e., something only
potentially meaningful to the LIS). [/MB]

Based on last IETF meeting I understood that we the URI scheme should be

helds: rather than held:.
[MB] That is correct. This document hasn't been updated since the
meeting because the WGLC spanned the meeting and ended on the 22nd of
March. I will make that change in the -06. [/MB]


*** Security - Return Routability



   Using IP return routability as an authenticator means that location
   information is vulnerable to exposure through IP address spoofing
   attacks.  A temporary spoofing of IP address could mean that a device
   could request a Location URI that would result in another Device's
   location.


[hannes] I would say that you should say "... could request a Location 
Object or a Location URI ....".

[MB] Yep - I'll make that change. [/MB]


   One or more of the following approaches are RECOMMENDED to
   limit this exposure:

   o  Location URIs SHOULD have a limited lifetime, as reflected by the
      value for the expires element in Section 6.5.2.
   o  The network SHOULD have mechanisms that protect against IP address
      spoofing, such as those defined in [9].
   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.

[hannes] Is a MUST more appropriate?

[MB] This goes back to our discussion at IETF-70 as to whether we can
mandate LIS behaviors. We can mandate how the LIS populates the protocol
elements (e.g., "MUST include expires attribute" per 6.5.2), but per the
discussion, we can't mandate how the LIS determines the value for the
attribute.  We also cannot mandate how a LIS Is configured, but we can
make recommendations, thus the SHOULD. [/MB]


Omit the summary for the security considerations section since it is 
fairly short anyway.

[MB] I'm totally neutral - I like the idea of a summary, but it could
lend itself to inconsistencies, so I am okay with removing it if others
do not object. [/MB]

** Security - TLS Authentication and Identity Check

I believe some of the recent LoST discussions apply here as well.
[MB] I have not been following the LoST discussions in detail, can you
point to the particular thread?  And, to which specific sections to your
concerns apply? I'll make some assumptions below based on the
context.[/MB]

There is obviously the case where the client is pre-configured with the 
IP address or FQDN of the LIS.
Then, the cert needs to contain this identifier.
[MB] So, are you suggesting that we add text about this point to section
10.1.1? [/MB]

A more interesting (and more likely) case is dynamic discovery of a LIS.

In this case the client learns the domain name and uses it as input to
the
U-NAPTR procedure. Then, a URI is determined and the LIS is contacted. 
Now, what information will be found in the cert?

Is it the input or the output of the U-NAPTR mechanism?
For this type of deployment scenario I could imagine that one puts the 
input to the U-NAPTR mechanism into the cert even though I believe it 
will not improve security given that the mechanism to obtain the domain 
name is
* either DHCP (which is insecure), or
* STUN, UPNP, etc. (which is insecure in this setup as well).

[MB] I believe your point relates to a point also made by Cullen:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05483.html
To which I responded:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05487.html
And then Richard responded with some new proposed text that I plan to
incorporate, which reduces the scope in section 10.1.1:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05490.html

If this is a different point, what specific text are you concerned
about?
[/MB]

I believe we need to discuss this issue.

Ciao
Hannes

_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv