Subject: Re: [dhcwg] dhcwg Digest, Vol 67, Issue 18

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

On Thu, Nov 19, 2009 at 11:52:16PM -0500, Ted Lemon wrote:
> On Nov 19, 2009, at 7:43 PM, David W. Hankins wrote:
> > But even then if the client sent a series of PAD bytes at the end of
> > their 576 octet packet, the DHCPv4 server may not necessarily know
> > this, and the validation will fail (when the agent options are
> > inserted, they will fill the padded space, when they are removed, the
> > pad space is gone).  This happens whether the relay agent is
> > authenticating or not.
> 
> Are you sure about this?  It's my understanding that the RFC requires
> you to leave all the options there except the END option, which is
> replaced upon removal of the relay agent options.

PAD options have no length.  So when the server removes a relay agent
info option that was placed on the END Option, over-writing PAD
options, they are lost.

For this reason, a relay agent may as well over-write PAD options that
are placed on the packet before the end option, and the ISC dhcrelay
you wrote does this (although it had a bug wherein it would remove
only the last PAD octet, which still breaks validation, and manages to
not save a lot of space).

So yes, I'm pretty sure about this, and I think I can say there is
running code.

-- 
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: "David W. Hankins" <[email-masked]>
Date: Tue, 9 Feb 2010 12:38:27 -0800

On Fri, Nov 20, 2009 at 08:34:54AM -0800, Stephen Jacob wrote:
> In the approach suggested where the second relay agent would add a
> sub-option to the existing relay-agent-information option, I don't
> think there is any need to limit how many relays can add their
> options and I don't think that further complicates the algorithm
> for adding or checking a signature beyond what you're talking about
> already.

We do need a limit, one that realistically won't be reached; there
are internal limits to the size of sub-options because it isn't well
defined that sub-options can exceed 255 octets in length, but more
generally we don't want to create a scenario where a server can get
captured processing nested values (sent by a ne'er-do-well).

In our case "1" is a pretty good limit because beyond 1, you need to
preserve bootp header fields (giaddr for example), and it allows for
one "l2" relay agent and one "l3" relay agent to both send options
that can be rewound.  If there's a use case for more than that, then
we can do that, but it gets much more involved.

I'm a fan of "simply 1".

Even DHCPv6 nested relays provides a sane default limit so servers
don't get over-abused, unless I'm not remembering right.

> It's kind of nasty not least because it's sort of inside-out versus
> the way DHCPv6 does it, but as I understand it the idea was that a
> new sub-option (I've arbitrarily picked the name
> 'next-relay-information' to represent it below) something like:

Yes, it's kind of backwards-think.

---

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

> So yes, I'm pretty sure about this, and I think I can say there is

The reason the isc dhcrelay program is so broken is that rounded to the nearest hundred users, it has zero users.   The fact that there is running code doesn't mean that the code is correct.   Otherwise, we'd still be using BIND 4.3!

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 10 Feb 2010 15:01:45 -0800

On Wed, Feb 10, 2010 at 10:56:39AM -0500, Ted Lemon wrote:
> The reason the isc dhcrelay program is so broken is that rounded to the
> nearest hundred users, it has zero users.   The fact that there is running
> code doesn't mean that the code is correct.   Otherwise, we'd still be
> using BIND 4.3!

I don't see anything here worth responding to.

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