Subject: RE: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046...

From: "Kostur, Andre" <[email-masked]>
Date: Tue, 21 Oct 2003 13:32:50 -0700

> I've recently encountered a related issue w.r.t. the Pad 
> option.  Some 
> customers have been stating that it is incorrect for a DHCP relay to 
> simply insert Pad option bytes over the Relay option when returning a 
> reply to a client.  They say that since this results in Pad option 
> bytes *before* the End option, this is wrong and their client systems 
> do not accept the OFFERs they receive in this format.

This is actually wrong (the behaviour).  According to 3046, the device which
originally added the option 82 must _remove_ the option, not overwrite it
(section 2.2, RFC 3046).  This is further reinforced by RFC 3118 where it
talks about creating the hash on a DHCP message, and if option 82 is
present, it is to be calculated as if the option wasn't present (section 2,
RFC 3118).
 
> My understanding that a Pad option is simply to be skipped over in 
> option processing *wherever* it's encountered.  RFC2131 says:

Not entirely correct.  See RFC 3118.  DHCP Authentication will calculate the
hash with the pad options present.
 
> > the
> >    options in the 'options' field MUST be terminated by an 'end' 
> > option,
> >    and MAY contain one or more 'pad' options to fill the 
> options field.
> 
> and:
> 
> > The options in the 'sname' and 'file' fields (if in use as indicated
> >    by the 'options overload' option) MUST begin with the 
> first octet of
> >    the field, MUST be terminated by an 'end' option, and MUST be
> >    followed by 'pad' options to fill the remainder of the field.
> 
> (These being the only mentions of the Pad option).
> 
> However, RFC2132 says:
> 
> >    The pad option can be used to cause subsequent fields to align on
> >    word boundaries.

From a DHCP decoding standpoint, the pad option should effectively be
skipped.

In my opinion, both devices have a broken (or perhaps incomplete) DHCP
implementation: The relay because it is simply overwriting option 82, and
not removing it (I guess that could be dependant on the interpretation of
"remove"), and the client for not being able to process pad options.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Oct 2003 17:18:19 -0700

On Tuesday, October 21, 2003, at 01:32  PM, Kostur, Andre wrote:
> implementation: The relay because it is simply overwriting option 82, 
> and not removing it (I guess that could be dependant on the 
> interpretation of "remove"), and the client for not being able to 
> process pad options.

That's right.   However, the fact that the relay is potentially 
breaking the signature on the packet is a big bad nono that will 
completely prevent communication if we ever start signing DHCP packets. 
   The client bug, while definitely a bug, is something that's 
comparatively easy to work around, unless the relay agent does the 
wrong thing.   That is, if you find that your DHCP server is sending 
extra pads, it's easy to install a new version of the DHCP server.   
Installing new relay agents is hard, but installing new clients is 
beyond hard - by and large, it simply isn't possible.

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