Subject: Re: [dhcwg] client pads all packets to 576 octets, can't add Option 82

From: "David W. Hankins" <[email-masked]>
Date: Tue, 9 Feb 2010 11:57:19 -0800

On Tue, Dec 15, 2009 at 10:48:25PM -0500, Chuck Anderson wrote:
> Yes, it is a "normal" packet with a 255 End Option, followed by 234 
> zeros (or however many zeros to make the total IP size 576).

I would say it's "unfortunate", but yes it is very common in many
client implementations.

There is also some confusion about how to measure '576'...as from
the ethernet header, ethernet payload, ip payload, udp payload, ...

So there are clients that pad to 576 UDP payload, and relays that
drop ("as an error") packets with longer than 576 ethernet payload.

But this is a different problem for another day.

> So are packet bigger than 576 IP+UDP+BOOTP bytes legal?

Yes.  In particular, relay agents have to be able to process
packets larger than 576 because it's possible clients might send
packets up to 576.  Relay agents probably should stick under MTU
size, however, as there are server implementations that ignore
UDP fragment reassembly.

However you cannot guarantee;

1) That a client will be able to receive a 576 octet packet.
2) That a relay agent on either side (client or server-facing)
   will be able to receive.
3) That a server will be able to receive.

So right now it is a dangerous game played between the client and
server relying on the client to indicate a "max message size" option
(57), and default to 576 octet "ethernet payload" otherwise.

The relay basically has no way to signal its intent, and probably
should be even more lenient than either of the other two speakers.

Except that they usually aren't. :(

> 3. remove the padding, then add the Option 82?

This is what ISC dhcrelay does.

Remove the padding, add option 82 on the END, place an END after
your option 82 for good measure, and no padding from there out (send a
packet precisely of length to include the END option).

Note (maybe comment this in your code) that this breaks DHCPv4 client
to server authentication because the client will have signed the packet
with the padding, but the server will receive a packet without padding,
remove option 82, and then perform the same algorithm (with a zeroed
hash field) to validate the packet.  The extra padding octets adjust
the hash conclusion, so they will no longer validate.

This implies clients really should not produce ridiculously padded
packets in the first place, and if they ever adopt authentication
they may want to fix that.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Feb 2010 10:55:17 -0500

> they may want to fix that.

Certainly they ought to fix that.   However, your relay agent still shouldn't be modifying the packet in transit other than as provided in the relay agent information option specification.   Removing padding is not appropriate.

Also, anticipating a DHCP server that can't handle a >576 byte packet is unreasonable. First of all, this clearly goes against the intent of the maximum message size option. Secondly, it's so easy to fix on the server that even if a server did have this bug, it would be very easy to fix.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 10 Feb 2010 14:59:26 -0800

On Wed, Feb 10, 2010 at 10:55:17AM -0500, Ted Lemon wrote:
> Certainly they ought to fix that.   However, your relay agent still
> shouldn't be modifying the packet in transit other than as provided in
> the relay agent information option specification.   Removing padding is
> not appropriate.

When I reviewed RFC 3046 at the time, I determined that omitting PAD
octets did not violate any normative language.

> Also, anticipating a DHCP server that can't handle a >576 byte packet is
> unreasonable. First of all, this clearly goes against the intent of the
> maximum message size option. Secondly, it's so easy to fix on the server
> that even if a server did have this bug, it would be very easy to fix.

Sure, but like I said you can't count on it.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Feb 2010 20:43:53 -0700

> Sure, but like I said you can't count on it.

Yes, you can.   I do not mean that there exists no broken implementation out there.   I mean that if you assume that there is no broken implementation out there, you will not suffer for that assumption.   The DHCP server market is not a particularly diverse one, and the existing implementations that are relevant to this discussion (i.e., are not in home gateways) all support RFC3046, and all support DHCP packets as large as the MTU.

> octets did not violate any normative language.

Here is the entire relevant text from RFC3046:

A DHCP relay agent adding a Relay Agent Information field SHALL add it as the last option (but before 'End Option' 255, if present) in the DHCP options field of any recognized BOOTP or DHCP packet forwarded from a client to a server.

I don't see anything in here that grants you permission to modify the payload.   It seems to me that it's pretty explicit as to what you're supposed to do: you're supposed to put option 82 right after the existing payload, and right before the End option.   It doesn't say anything about removing any options.

It's true that relay agent behavior in DHCP is rather underspecified, but the mere fact that you haven't been explicitly forbidden from modifying the packet in transit does not mean that doing so is acceptable.

It is true that in all likelihood what you are doing will cause no harm, because the clients you are talking about are not signing their packets, and the change you are making makes no semantic difference.   But I do not feel comfortable in letting your statement lie - it seems to set a bad precedent.

The fact that I am the author of the offending code doesn't make me any more comfortable with it at this late date - I no longer think removing the PAD options was the right thing to do.   It's very easy for me to imagine interoperability problems that might arise as a result of this.

> I don't see anything here worth responding to.

Then perhaps you shouldn't have responded.   My point is that the mere fact that no-one has complained about a particular idiosyncrasy of a particular implementation is not an indication that we should treat the idiosyncrasies of that implementation as a standard.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 16 Feb 2010 14:27:57 -0800

On Thu, Feb 11, 2010 at 08:43:53PM -0700, Ted Lemon wrote:
> Yes, you can.

...

> I do not mean that there exists no broken
> implementation out there.

As RFC 2131 does bother to mention 576 as a required minimum, and
because its language in that regard is (famously) vague and open to
many different interpretations, I could hardly describe any server (or
upstream relay agent) meeting the 576 octet minimum to be "broken."  I
do not know why you claim it to be so.

You should send packets up to MTU size, the RFC specifies that I
think, but you can't count on the server or upstream relay agent being
able to receive it.  You need to follow the RFC's direction and
include a configuration knob to reduce the maximum packet size.

Given that, you have to have a salient answer for the situation where
the packet size is reduced under where you can guarantee inclusion of
the agent option.

So, you can't count on it.

> I don't see anything in here that grants you permission to modify the
> payload.

It explicitly requires modification of the payload in order to add the
option.

>  It seems to me that it's pretty explicit as to what you're
> supposed to do: you're supposed to put option 82 right after the existing
> payload, and right before the End option.   It doesn't say anything about
> removing any options.

Unfortunately a single word, "add", is used to describe the entire
operation, a word which has a simple meaning but may be interpreted in
different ways.  It does not mean the same thing as "insert" for
example which may be interpreted differently.

The RFC requires the option be added with only two limitations; it
is the last option, it is before the END option.  Omitting padding
on either side of the END option conforms to these normative
requirements, and one of them is specified.  The other is equivalent.

> The fact that I am the author of the offending code doesn't make me
> any more comfortable with it at this late date - I no longer think
> removing the PAD options was the right thing to do.

That would be a fine sentiment if it were still 1998.

> Then perhaps you shouldn't have responded.

I generally like to give people the benefit of the doubt.  That is, if
you bothered to send the message you had, you probably were intending
to solicit a response I missed, rather than that your intent was
simply to stifle discussion.

Apparently that was a mistake on my part, I assure you I won't make it
again.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Feb 2010 19:24:21 -0700

> do not know why you claim it to be so.

I already explained why--there aren't any implementations out there of which I am aware that fail in this case, other than home gateways, which really don't matter for the situation we're talking about.

It was explicitly understood when we were working on the relay agent option that it was not only okay, but expected, that it would blow past the 576-byte limit.   And you can see that when you read the RFC, although we didn't make it explicit because we didn't realize that it would be necessary.

> It explicitly requires modification of the payload in order to add the

Where?

> That would be a fine sentiment if it were still 1998.

I'm having trouble parsing this.   Do you mean to say that you think that because I wrote this code in the ISC relay agent, which is almost never used in production, that this somehow set a precedent that others have followed?   If so, who?