Subject: [dhcwg] RFC4361 adoption stumbling block.

From: "David W. Hankins" <[email-masked]>
Date: Tue, 26 Sep 2006 15:42:20 -0700

Below, I describe something that is unquestionably a bug - a bad
security glitch - and any such software should be discovered and rooted
out.  I do not mean to present this as a problem for the protocol, but
rather an operational issue (and there is no dhc-ops).

It's very hard to imagine RFC4361 being unsafe, considering its
simplicity.

But I have just had the opportunity to witness a "home network
appliance" containing a DHCP server which will reboot itself if
a "long" client identifier is provided (this was 25 bytes, partly
a hostname).

We haven't actually worked out how long a client identifier
it takes to...do whatever badness these things are doing
(sounds like a heap or stack overflow - very bad).

But I have to assume any value longer than 7 may produce unstable
results in appliances of either this or different manufacture.  That
is, that the behaviour of one kind of DHCP client in particular
(encoding a 7-byte hardware type and mac address string in the client
identifier) has become their expectation.  Design by sniffer: The rule
rather than the exception.

I have to imagine, speaking as a paranoid lunatic, there are going to
be other adoption pains along these lines (truncation at 7 bytes for
example...scary).

So that makes me question, as a client implementor, wether I should
send our customers headlong into this unknown forest (if I know
the DUID:IAID pairs we were to manufacture were to exceed 6 bytes in
length), or to make the adoption of RFC4361 user-optional.  A feature
you turn on rather than on-by-default.

I'm interested in other opinions.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email [email-masked].
-- 
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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Sep 2006 15:48:38 -0700

> you turn on rather than on-by-default.

Yes, you should definitely send your customers into this unexplored
territory, so that all of these boxes can be eliminated (updated) as
quickly as possible.   Frankly, the customer isn't going to know that
it's a DHCP problem - they're just going to see their gateway crashing
on a regular basis, and they're going to return it for repair, which is
precisely the outcome we want, since when enough of them go back, the
manufacturer will issue a firmware update.

What we shouldn't do is constrain protocols based on the least
conforming implementation.

BTW, one way to goose the process would be to get bugtraq involved.

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 27 Sep 2006 08:59:41 -0700

> manufacturer will issue a firmware update.

Part of me thinks very much like this, and probably wouldn't have said
anything if this were the only problem I could imagine (crashing other
people's servers).  I do have some small amount of reservation here,
speaking as someone whose experiments with SNMP on a production
backbone/coloco/ISP network caused several ethernet switches with less
than conforming SNMP subprocesses to reboot themselves.  Bug or not,
our operators were not very happy with that result.  It was less than
an ideal way to find out.

The rest of me is concerned that I haven't thought about the problem
hard enough (a common failing of mine) to dismiss it just yet.

If the person who created this bug were given a report that reveals
the problem, will they:

	1) Check bounds and assert an error on client-id's longer than
	   7 (ignoring their requests).
		o Note that this looks like a client bug (because other
		  clients work).

	2) Check bounds and truncate client-id's longer than 7.
		o Note that this is all but invisible, impossible to
		  detect so long as the first 7 bytes are unique to that
		  subnet (which is still pretty likely).
		o When/if this does manifest, it will look like a client
		  bug (because other clients work).

	3) Allow up to 255 octet client-id's.
		(multiple failure modes possible, but it doesn't seem
		 worth it to enumerate since we're not going to use
		 client-id's that large anyway)

	4) Allow variable, unlimited length client-id's according
	   to option fragmentation/multiple-options.

Would someone who committed this mistake be more prone to treat it
like an "oops I forgot to check bounds" bug, or a design flaw?

I'm fairly pessimistic in the answer to this question at the moment.

So I still question wether we know if other implementations have made
the same mistake...it may be that other implementations that have made
the first and second mistakes listed above are already out there, but
are much harder to detect.

And that leaves me undecided.

It also wouldn't necessarily be totally socially responsible to
send out code that triggers bugs like these knowing full well
someone else is going to bear the support burden.  Not without
knowing it is only going to affect a small scope, eg at least
consulting with others.

> conforming implementation.

If you're talking about making this a protocol problem, I agree.
There is no reason to go back to drawing boards.

But this does present an operational problem, in how we deploy
as-is, and least conforming implementations will always be a
constraint to deployment.  That's reality.

I possibly should have sent my query to the general ops area, but I
wanted to reach 'dhcp people' specifically, so I hope this is
forgiven.

> BTW, one way to goose the process would be to get bugtraq involved.

Have no fear.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 Sep 2006 10:29:35 -0700

> an ideal way to find out.

Yup, that sucks.   We've also had nonconforming network switches that
did proxy ARP on IP addresses whose leases had expired.   Bad
implementations are a real problem.

What you need to ask yourself is what you're really trying to do.   If
you're producing a reference implementation, then you don't really have
any choice.   You have to do the thing that breaks the hardware.
There's no way to tell in advance that the hardware is broken; the only
way to fix this is to fix the broken hardware.   This is not a problem
that's new to RFC4361 - it's always been the case that a client
identifier can be up to 255 bytes, so a DHCP server that crashes when a
client identifier is longer than 7 bytes doesn't even conform with
RFC2131, to say nothing of the fact that if you have a device with a
memory smash like this running on your network, your network is
vulnerable to attack.

> 		o Note that this looks like a client bug (because other

This isn't an unlikely scenario.   However, it's not true that it will
look like a client bug - if the DHCP server doesn't respond to
legitimate client requests, it looks like the server is broken.

> 		  bug (because other clients work).

Actually, the RFC4361 client will probably work too.   I'm guessing the
device you're talking about is a SOHO router.   This is certainly the
device that's most likely to have a bad server implementation on it.
On a network with such a device, in the scenario you're describing,
where RFC4361 clients are rare, this client will have a unique
identifier on the network.   So it'll get an IP address.

> 	   to option fragmentation/multiple-options.

If they do either of these things, we don't have a problem.

> I'm fairly pessimistic in the answer to this question at the moment.

Justifiably so.  But we've been dealing with this kind of lossage all
along.   As long as I've been involved with the workings of the ISC DHCP
client, there have been situations where it simply doesn't work because
the server is broken, but the Microsoft client does.   Why?   Because
people only ever test with the Microsoft client.   And the Microsoft
client is implemented in a paranoid fashion - it does all kinds of
things to work around broken DHCP server implementations, including
proxy arping if the IP address of the router isn't on the local subnet
(I ran into this at a Holiday Inn Express in Santa Fe last week).

So you really can't win here.   You can try, but there are going to be
situations where some broken DHCP server makes your client look bad, and
you just have to deal with that.   This is actually a really good
scenario for you, because you're *crashing* the DHCP server, so the
operator is likely to notice and fix the problem, where in the case of
the Holiday Inn Express, the _only_ reason why I was able to get it
working was because I was a DHCP geek; there was no hope of a non-geek
Linux user getting their network connection working, and there was no
hope that calling the provider and complaining would fix the problem.

> And that leaves me undecided.

Are you a reference implementation vendor, or an embedded DHCP client
vendor?

> knowing it is only going to affect a small scope, eg at least

Yes, it is totally responsible.   It is the kindest thing you can do.
Don't doubt it.   One of the functions Linux DHCP clients perform in the
world is garbage collection - they detect broken servers.   The more
pervasive Linux clients are, the less pervasive bad DHCP servers will
be.   This isn't a case of being conservative with what you send and
liberal with what you accept: the DHCP server you are talking about is
pathologically broken, and you are doing the operator of the network on
which it runs, and indeed the vendor of the product, a favor if you
cause them pain so that they fix it.

---

From: "todd glassey" <[email-masked]>
Date: Wed, 27 Sep 2006 10:33:32 -0700

The problem is that the IETF's licensing model is what created this
nightmare. If the IETF mandated that anyone using its protocols maintain
their compliance to 'full and current' standards then this would not be an
issue per se.

Todd Glassey