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
Ted Lemon <mellon <at> fugue.com>
2012-06-22 20:11:28 GMT
On Jun 22, 2012, at 3:59 PM, Alissa Cooper wrote:
> My understanding is that the option is encoded this way both for extensibility and because the Valid-For
parameter is solely a property of the URI. Surely this is not the only instance of a DHCP option with a
What's in the draft is not suboptions—it's a whole special format requiring new code on all servers that
implement it. Suboptions don't exist in DHCPv6—just encapsulations of regular options, which I don't
think make sense here either.
> It may have been before I was paying attention, but I get the impression that related ground has already
been trod in DHC, given that it also came up in GEOPRIV. http://www.ietf.org/mail-archive/web/geopriv/current/msg08451.html
When the topic of suboptions first came up, it was because I proposed them as an alternative to a complicated
internal option structure with lots of special code required in the server to implement. But given that
only one Location URI option is allowed, there's no need for suboptions.
> I'm not sure the additional text is necessary given that there is an entire paragraph explaining
considerations for servers in setting the Valid-For value. Furthermore, I don't see how "potential loss
of service" is possible. We're talking about a URI with an expiration. When it expires, location
recipients will no longer have access to the client's location, but it otherwise doesn't affect
recipients' ability to use any "service" whatsoever.
You're right—don't know how I missed that.
>> 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