Subject: [Geopriv] Review of draft-polk-geopriv-dhcp-lbyr-uri-option-02.txt

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 25 Nov 2007 12:06:10 +0100

I read through 
http://www.ietf.org/internet-drafts/draft-polk-geopriv-dhcp-lbyr-uri-option-02.txt

Here are a few comments:

-- Technical

The draft says:

   In enterprise networks, a URI can be assigned to individual Ethernet
   ports because each is assigned a unique circuit-ID that's used by
   the RAIO Option defined in RFC 3046 [RFC3046]; meaning whatever is
   attached to a particular port will get the same URI because that
   device is at a known location (where the cable attached to that port
   is terminated).

This is not possible since we have put in our requirements that the
URI has to contain a random component.

 This scenario applies to 802.11 Access Points (AP),
   in which the AP's location is what's fixed and known.  The same URI
   can be given to all devices attached to the same AP.

The same is true with this example. See comment above.

   This Option can be useful in WiMAX connected endpoints or IP
   cellular endpoints.  The Location URI Option can be configured as a
   client if it is a router, such as a residential home gateway, with
   the ability to communicate to downstream endpoints as a server.

I am not sure what this paragraph means.

* I don't have a strong opinion about UTF-8 vs. UTF-16 encoding. Sorry.

* Regarding Section 3.1 (architectural assumptions)

   o  Any user control (what Geopriv calls a 'rulemaker') for the
      parameters and profile options a Location-Object will have is out
      of scope of this document, by assumed to take place via something
      such as a web interface between the user and the LIS (direct or
      indirect).

This is not realistic since we cannot assume that the user will
use a Webpage to upload it's own policy rules. Furthermore, the ability
to upload policies in the style of the Geolocation Policy work
has been stopped even for HELD.

   o  Any user attempting to gain access to the information at this URI
      will be challenged by the LIS, not the DHCP server for
      credentials and permissions.

In our discussions we concluded that this may be the case in some 
deployments.
However, in general the possession of the URI is sufficient to resolve it.
We made this assumption since everything else is essentially not 
deployable.

There is, however, another assumption related to this aspect. In order 
for the
above statement to be true it is required that the LCP, Location 
Conveyance, and
the LDP protocol interaction is confidentiality protected.

With DHCP this is not the case since DHCP does not provide confidentiality
protection. This is a severe problem.

Hence, we would have to put at least a disclaimer there that link layer
security MUST be used in order to prevent other nodes in the same network
to learn the location URI.

Since deployments will probably not care about this aspect one could 
consider
this as a challenge. Possession of the URI would allow an adversary to track
movement even though the Target moved outside the range of the adversary or
where the adversary walked away.

* I assume that the document does not make any restrictions what is
behind the URI. That's OK but I would be explicit.

* Given that we have a requirements document for LbyR usage in the LCP
I would compare the work against the requirements.

* The text in Section 3.2 about "Harmful URIs" is good. I would also 
suggest to copy it
to the HELD document given that it is generic in nature.

-- Editorial

FROM:

For example, an endpoint can be a
Session Initiation Protocol (SIP) User Agent (i.e., a phone).

TO:

For example, an endpoint can be a
Session Initiation Protocol (SIP) User Agent (e.g., a phone).

 RFC 4119
   [RFC4119] has the <method> element, which indicates how the endpoint
   learned its location.  In this scenario, the <method> element
   indicates in the PIDF-LO the UA learned its location through DHCP,
   thus informing the call taker the UA is within a certain radius of
   the AP.

   APs that triangulate can also have a individual URI downloaded to
   each endpoint with this Option, for the endpoint to hand out
   whenever it is configured to.  The <method> element would give a
   different indication in such a case, one that states the location is
   a triangulation of the UA's specific location, and not that of the AP's.

The introduction talks about the method element although this is not 
irrelevant
for the purpose of this draft.

Ciao
Hannes

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv