ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-geopriv-dhcp-lbyr-uri-option-15.txt> (Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)) to Proposed Standard

2012-06-01 10:16:03
There are still a few problems with this draft.   The first is that it uses a 
nonstandard and somewhat odd encoding to deliver the URI and Lifetime values.   
These should simply be delivered as separate options, leaving out the whole 
Luritype complication.    The argument might be raised that the Luritype field 
provides some sort of future-proofing, but this future-proofing can as easily 
be attained with another DHCP option code, so it's unnecessary.

Secondly, this text ought to be expanded:

 The choice of the Valid-For value is a policy decision for the 
 operator of the DHCP server.  Like location URIs themselves, it can 
 be statically configured on the DHCP server or provisioned 
 dynamically (via an out-of-band exchange with a Location Information
 Server) as requests for location URIs are received.

To:

The choice of the Valid-For value is a policy decision for the 
 operator of the DHCP server.  Like location URIs themselves, it can 
 be statically configured on the DHCP server or provisioned 
 dynamically (via an out-of-band exchange with a Location Information
 Server) as requests for location URIs are received.   DHCP server
 operators are advised not to configure a valid-for lifetime that is
 greater than half the minimum configured lifetime for DHCP leases,
 since this could result in stale configuration information on the
 DHCP client and potential loss of service.


Thirdly, this text is simply wrong, and indeed specifically contradicted by 
RFC3396:

   Per [RFC2131], subsequent LocationURI Options, which are 
   non-concatenated, overwrite the previous value.

I don't think this is a huge problem, but I think the text should say this:

It is not meaningful to configure multiple LocationURI options.   DHCPv4 
servers and clients conforming to RFC3396 will not permit this; DHCPv6 
servers and clients can be configured this way, but the behavior when so 
configured is undefined.   Therefore, DHCPv6 server operators are cautioned 
not to configure more than one such option.

Section 3.2 suggests that options shouldn't contain certain potentially harmful 
values, but this is a toothless restriction, since an attacker can simply 
ignore it.   In order for it to be effective, Section 3.2 should insist that 
DHCP clients reject forbidden URI formats.   Of course, this too is somewhat 
toothless, since any list of forbidden URI formats will necessarily fail to 
mention any future potentially harmful URIs that could arise.   It would be 
better to list which URIs _are_ permitted, and require the client to reject any 
URI that is not permitted.   The document is already set up to do this, but 
doesn't _actually_ do it, so fixing this should be quite easy.

Sorry for not catching all of this sooner—the previous review of the document 
was rudely interrupted by the Paris IETF meeting... :)

Aside from these objections, which I think are easy to address, I have no 
problem with the document proceeding.