loophole with limiting leases per client

[HIBBS, BARR (PB)]

Brian--

thanks for the clarification.  My comments are in-line.

--Barr


> > This behavior permits a "roaming" client (i.e., one who moves from one
> > subnet to another -- imagine a laptop computer with an embedded NIC) to
> > be
> > offered a lease for multiple subnets (more or less simultaneously,
> > depending
> > on the remaining lease duration) which is the behavior suggested by
> > RFC2131.
> 
> Which I disagree with BTW.  When a roaming client moves from subnet A to
> subnet B, his lease on subnet A should be released and available for
> re-assignment according to the guidelines of assigning the oldest lease
> first.  The "one-lease-per-client" feature of version 3 achieves this. 
> This is not my problem however.
> 
--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?  It's only when the client returns to
the prior subnet that preserving the lease is important.  After all, the RFC
requires a server to offer the same address previously assigned to the
client if at all possible.  There are many people who feel as you do about
this behavior, but it is a requirement of the RFC.

[... stuff deleted ...]

> > I guess I don't see why you think this behavior is incorrect or
> > undesirable.
> 
> It is undesirable because one client can exhaust a pool of addresses by
> simply sending multiple requests with different client identifiers.  This
> can happen because the server will prefer to manage leases by client
> identifier if it is present in the DISCOVER/REQUEST messages.  A client
> that sends two REQUESTS with different client identifiers will be, as far
> as the server is concerned two clients.
> 
--so, do you think this is the result of a naive client or a deliberate
denial-of-service attack?  What are the dimensions of the problem?  Is it
merely an annoyance, or a genuine threat to the service levels your customer
has contracted to provide their users?

--Client identifiers were intended to be a stable (although, of course,
there is no real way to ensure this) way to provide subnet uniqueness of a
network host.  At least in my mind, 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
[here we use extra-cheap NICs and throw away any thought to be
malfunctioning rather than attempt repair because the labor cost makes
troubleshooting and repair far more costly than replacement, and with cheap
NICs the failure rate is significantly higher than with "good" ones.]

--What I think you are saying is that you've detected a vulnerability to
badly-implemented or malicious clients.  That wouldn't be the only weakness
in the protocol.  Trouble is, in some environments, supporting multiple
client identifiers could be a useful administrative tool.  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.

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

> Have you tested a client's ability to have two simultaneous leases on the
> same subnet by altering it's client identifier?  How about getting two
> leases by first not offering a client identifier, then requesting a second
> lease using a client identifier?
> 
--the first case was partially covered by moving a laptop between docking
stations equipped with NICs on the same subnet.  In that case, the client
hardware address was also different, which is not the same as your concern.
We have not tested the second case at all.


--Barr