Hi Ted,
On Jun 22, 2012, at 4:11 PM, Ted Lemon wrote:
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.
If we split it into two options, that eliminates the future possibility of
supporting multiple URIs per client. So we will need to take this back to the
GEOPRIV WG to make sure folks are okay with foreclosing 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.
Okay, will add MUST reject language.
Alissa