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

From: Richard Johnson <[email-masked]>
Date: Tue, 21 Oct 2003 13:17:47 -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.

My understanding that a Pad option is simply to be skipped over in 
option processing *wherever* it's encountered.  RFC2131 says:

> 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.

/raj

On Tuesday, September 16, 2003, at 12:03 PM, Ted Lemon wrote:

> We have encountered in the field a relay agent that does something
> interesting.   RFC3046 says that the relay agent is supposed to insert 
> the
> Relay Agent Information option into the packet at the point where the 
> End
> option in the packet was found, or at the end of the options.   This 
> client
> ignores RFC3046 and stores the Relay Agent Information option _after_ 
> the
> packet's End option, followed by its own End option.
>
> Our first reaction was to think that the relay agent was just buggy, 
> but I
> went and looked at the RFCs and discovered a problem, which this relay 
> agent
> actually doesn't hit because of its weird way of storing the option.
>
> The problem is that what RFC3046 says about the End option is 
> ambiguous with
> respect to figuring out what the packet looked like when the RFC3118
> signature was computed.   Consider the following scenarios:
>
> 1. The packet has an End option after the last informative option (by 
> which I
> mean an option that conveys information, as opposed to an End or Pad 
> option).
>
> 2. The packet has no End option, and has some number of bytes of Pad 
> options
> after the last informative option.
>
> 3. The packet has no End option, and no Pad options after the last 
> informative
> option.
>
> It could be argued that (2) and (3) violate section 4.1 of RFC2131, 
> which says
> "The last option must always be the 'end' option."   However, people 
> have
> interpreted this in different ways - does this mean that the packet 
> MUST have
> an End option, or does it mean that if the packet has an End option, 
> it MUST
> be the last option in the packet?   What should the sending agent do 
> when it
> has exactly enough options to fill the option buffer, and no room for 
> an End
> option?   Does it send the End option, or not?
>
> So although cases (2) and (3) are technically out of spec, I would say 
> that we
> should account for them.   Even in case (1), it's not clear what to 
> do.   Is
> the End option included in the signature, or no?
>
> I think we need some language to explicitly say what relay agents 
> should do in
> all of these cases, and also what sending agents should do in these 
> cases.
>
> Comments?
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

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

---

From: "Kostur, Andre" <[email-masked]>
Date: Tue, 21 Oct 2003 18:09:28 -0700

Come to think of it... the relay is very broken, because technically
speaking it is adding a bunch of extra options that didn't exist in the
original packet.  Specifically a number of instances of option 0 :)  And the
only option that relays are allowed to add is option 82.

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Tuesday, October 21, 2003 5:18 PM
> To: Kostur, Andre
> Cc: [email-masked]; 'Richard Johnson'
> Subject: Re: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046...
> 
> 
> On Tuesday, October 21, 2003, at 01:32  PM, Kostur, Andre wrote:
> > 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.
> 
> 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.
> 
> 
>