loophole with limiting leases per client

[Brian J. Murrell]

from the quill of "HIBBS, BARR (PB)" <RBHIBBS at msg.pacbell.com> on scroll
<21839C593E75D211BF7800805FCCD026EAADE3 at msgsrv03.srv.PacBell.COM>
> 
> thanks for the clarification.

You are welcome.

> My comments are in-line.

So are mine.  :-)

> --I'll acknowledge your disagreement, even though I like the way the
> RFC
> behavior works.  If a server releases an existing lease when a client
> moves
> from one subnet to another, so what?

Well then it is available for reassignment should an address crisis
arise on that subnet.  The host is no longer there, and no longer has a
use for that address, why should he have that previously used address
"reserved" for him at the expense of others participating on that
subnet?  If that is really what is desired, then a fixed address should
be assigned, or oversubscription should not be permitted.

> It's only when the client returns to
> the prior subnet that preserving the lease is important.

And it will be reserved for as long as it possibly can be, but not at
the expense of a denial service to others.

> After all, the RFC
> requires a server to offer the same address previously assigned to the
> client if at all possible.

Agreed.  Don't get me wrong.  I like this feature, I just don't think
preserving the address should be done at the expense of other users.  If
 absolute guarantee of addresses is required then the system manager
should assign a fixed address, or be sure he has not underprivisioned
his pools.  This is all moot however, as it is not my issue.  :-)

> There are many people who feel as you do about
> this behavior, but it is a requirement of the RFC.

I don't disagree with the RFC.  I think the server should try as hard as
it can to preserve the client->IP address mapping, just not when others
need the address and the client is no longer using it.

> --so, do you think this is the result of a naive client or a
> deliberate
> denial-of-service attack?

Neither.  It could be naive users screwing around with their DHCP client
(where they have control, as in the ISC dhclient), or it could be
customers trying to circumvent contracted service levels (i.e. number of
provided addresses), or most likely it could be alternate O/S's on a
single machine.  This latter issue is not really a problem as address
recycling will take care of it, but it would be nice to offer the same
address to a client no matter what O/S it is running.

> What are the dimensions of the problem?

Pure speculation (and CYA) right now.

> Is it
> merely an annoyance, or a genuine threat to the service levels your
> customer
> has contracted to provide their users?

It is an annoyance right now, but there will be a matter of culpability
should somebody decide to excercise this weakness.  If I can prevent
that I would like to.

> --Client identifiers were intended to be a stable 
[ snip ]
> I would expect that if a client were
> able to specify one's own client identifier (again, for example,
> "brians_pc") that it would remain stable while the NIC would be less
> so
[snip]

Agreed, in general.  But I would have to disagree with this for the same
reasons as disagreeing with using the "hostname" to assign leases.  If
it is something the user of a client can screw with and adjust, it is
going to be no end of troubles, the most obvious being two "brian"s
arguing over who gets to use "brians_pc".

> --What I think you are saying is that you've detected a vulnerability
> to
> badly-implemented or malicious clients.

Bingo!

> That wouldn't be the only weakness
> in the protocol.

Certinly not!  My next proposition is going to be a switch to ignore a
client's DECLINE.  If a client does not like an address given to it, the
owner of the client can take it up with the system manager.  The
assumption being of course that the server assumes it can reach any
client "assuming" (read: stealing) an address on the network.

We are always watching one client or another run a pool of addresses
into abanonment.  It is nice that the version 3 server seems to recover
them gracefully once the whole pool goes into abandoment, but I would
like to avoid that "transition into and out of abandoment" if I can.  A
good example of a client that will run a pool is the ISC dhclient.  I
only just discovered the other day that if the dhclient-script is
missing, the client declines the offer made to it, and does another
discover.  ~sigh~  I need to fix this.  If the client has a problem with
the script not being there, it should not even do the DISCOVER.

> Trouble is, in some environments, supporting multiple
> client identifiers could be a useful administrative tool.

I don't disagree which is why I proposed a "switch" instead of removing
the current functionality.

> I've heard of
> administrators compensating for the current lack of user class
> identifier
> support (because the I-D is still under discussion) by changing the
> client
> identifier (for example, "NT63IDDZ100636-153-OSS" to
> "NT63IDDZ100636-153-EXE") to encode user class information, then
> forming the
> response according to the differences in client identifier.

Which he still could do if he does not turn my new switch "on".

> --Explained this way, I can see an issue in some cases:  perhaps the
> "one-lease-per-client" option should be applied here as well, to
> permit the
> different points of view about multiple leases to co-exist.

Perhaps.  I wonder if tying "one-lease-per-client" to
one-lease-per-hardware-addresses would make anybody upset.

b.


--
Brian J. Murrell                              InterLinx Support Services, Inc.
North Vancouver, B.C.                                             604 983 UNIX
        Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD