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 sub-option?
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 doesn't _actually_ do it, so fixing this >> should be quite easy. > > In 3.3, I suggest replacing the following: > > "This section specifies which URI types are acceptable as a location > URI scheme (or type) for this DHCP Option:" > > with > > "URIs carried by this DHCP Option MUST have one of the following URI schemes:" That's just as toothless. Unless the client MUST reject these options, it MAY accept them.
