Subject: Restarting in INIT-REBOOT state

From: Ralph Droms <[email-masked]>
Date: Mon, 19 Apr 1999 22:19:46 -0400 (EDT)

There was some discussion at the last DHC WG meeting in Minneapolis about
whether a client should restart in INIT state or INIT-REBOOT state when it
has either RELEASEd its previous address or the lease on the address
expired while the client was down.  The original intent of RFC 2131 was
that a client should start in INIT state in both of those cases.  However,
as an optimization, a client might restart in INIT-REBOOT state and send an
initial DHCPREQUEST message in those cases as an optimization; in the case
that the client's previous address can be reassigned to the client, the
server can respond with a DHCPACK immediately rather than using the
four-message INIT state process.

The Apple OT 2.02 client restarts in INIT-REBOOT state after sending a
DHCPRELEASE during shutdown.  Are there other clients in use today that
restart in INIT-REBOOT state with an expired or RELEASEd address?

It seems to me that allowing clients to restart in INIT-REBOOT state with a
remembered but no longer leased address depends on servers responding with
a DHCPNAK if the address is, indeed, no longer valid; for example, if the
address has been reassigned to another client.  But, I read in a discussion
about the Apple OT 2.02 client that at least some servers, after receiving
a DHCPREQUEST for an expired address, remain silent rather than sending a
DHCPNAK.  If the servers don't send a DHCPNAK, the restarting client will
continue to use its RELEASEd or expired address.  Of course, if the address
has, indeed, been assigned to another client, there will be two clients
using the same IP address.

I'd like to hear about servers in use today - how do they respond to a
REQUEST for an expired or RELEASEd address?  Do they remain silent, always
reply with a DHCPNAK or reply with DHCPNAK/DHCPACK depending on whether the
REQUESTed address is still available?

- Ralph
- Ralph Droms
  Computer Science Department        (570) 577-1145 (o)
  Bucknell University                (570) 577-1822 (f)
  Lewisburg, PA 17837                [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Apr 1999 11:51:08 -0400 (EDT)

In order for the optimization you're talking about to work, a client
in INIT-REBOOT with a lease that's expired must not use that lease -
if it can't contact the server with a broadcast DHCPREQUEST, it has to
go back to INIT.   With that caveat, I think it works just fine.   The
ISC DHCP server will respond with a DHCPNAK if a client tries to get
an address that's already in use by some other client using a
DHCPREQUEST.

			       _MelloN_

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 21 Apr 1999 12:29:02 -0400 (EDT)

>four-message INIT state process.

	One of the reasons this came up was that
	I was interested in whether people actually implemented
	the original intent of RFC2131.  If they did (or someday
	could get their implementations compliant with the original
	intent), then the failover protocol could operate more
	effectively.  

	Today, the failover protocol assumes that a client has 
	been assigned an IP address and that there is time left 
	to run on the lease if it sees that client RENEW an IP 
	address, but doesn't make that same assumption for an 
	INIT-REBOOT.  Were the original intent of RFC 2131 implemented 
	by DHCP clients, then the failover protocol could *also* assume 
	that a client had been assigned an IP address and there there was 
	time left to run on the lease if it sees a client send in an 
	INIT-REBOOT for that IP address.  This would allow servers 
	implementing the protocol to provide increased availability in 
	cases where servers were going up and down and the communications 
	path between the servers was intermittent.

	However, my current belief is that, even given that we
	clarify the interpretation of RFC 2131 to the original
	intent (and not change it as an optimization, as it appears
	you are considering), we're going to have to assume that 
	clients don't do it the "intended" way for at least 
	some years to come.

>REQUESTed address is still available?

	Our server will always respond to an INIT-REBOOT if the address
	is managed by our server.  It will do the third thing you mentioned
	above -- if we find the address available, we'll give it to the
	client (DHCPACCK) despite the client not having sent in a DISCOVER, 
	or if it isn't available, we'll send a DHCPNAK.

---

From: "David Erdmann" <[email-masked]>
Date: Thu, 22 Apr 1999 13:16:14 -0400 (EDT)

> Ralph Droms posted:
> <snip>
> reply with a DHCPNAK or reply with DHCPNAK/DHCPACK depending on
> whether the REQUESTed address is still available?
>

Our DHCP server will send out an ACK if we are serving IP address
and we have a record of the client having previously had that address.

We will send out a NAK if:
 o  the IP requested is not on the subnets we serve
 o  the address requested is not the one we have previously
    associated with this client, but we have a record of the client.

We will send nothing if:
 o  we have no record of this client, as per the RFC:
    "...If the DHCP server has no record of this client, then it MUST
     remain silent, and MAY output a warning to the network
     administrator..."

I am a little curious about the following from Ralph's original post:
> If the servers don't send a DHCPNAK, the restarting client will

So are you implying that clients not receiving any NAKs will
continue to use their expired address?  (Sorry if I misinterpreted this.)

I agree with the follow-up from Ted Lemon:
>go back to INIT.

So if the client receives neither an ACK or NAK it should then go to
INIT state.

-Dave

Dave Erdmann
Nortel Networks, NetID Group
mailto:[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Apr 1999 13:23:19 -0400 (EDT)

> 	path between the servers was intermittent.

If you made this assumption, wouldn't you be setting yourself up for a
nasty denial-of-service attack when some client claimed it had the
address but really didn't?

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Apr 1999 13:25:14 -0400 (EDT)

> DHCP sort of runs on the "honor system" anyway, since anyone can use any IP 
> address at any time -- either a broken client, a malicious client, or any 
> user that just hard-codes an IP address into a machine.

Right, but in general the failover protocol seems not to make much use
of information stored on clients - rather, only what the server knows
is really trusted.   This represents a major change - you're deciding
to trust what the client knows.   All it would take would be a broken
real-time clock in a client somewhere to cause an IP address conflict
if you implement this, whereas if you don't, a bad RTC on a client
won't cause any problem.

			       _MelloN_

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 22 Apr 1999 13:24:18 -0400 (EDT)

Ted,

I'm not sure of the intent of your question.

Given that, the failover protocol assumes that anyone sending in a DHCPRENEW 
or DHCPREBINDING (which, remember are unicast from the IP address which the 
client is attempting to renew) is the legitimate owner of the IP address -- 
unless there is other information known to conflict with that assumption.    
And the ACK is unicast back to the IP address which was just renewed.

At present, the same assumption is *not* made about INIT-REBOOT, since I was 
unaware of the intent of the RFC, and I assumed that clients would send in 
an INIT-REBOOT whether or not they believed that they had time to run on 
their leases or not.  I was thrown off by the (completely appropriate) use 
of requested-address option to specify the IP address instead of the ciaddr, 
since I had internalized the use of ciaddr to mean "I own this address" and 
the use of the requested-address option to mean "I would like to own this 
address".  In this case, though, there is no choice but to use the 
requested-address option, since the IP address may well not be legal on this 
network (the discovery of which is the prinicipal reason for the INIT-REBOOT 
in the first place).

All that said, you can build quite a number of denial of service attacks 
with DHCP -- you can mimic lots of different clients and do real discovers 
and get offers and do requests and get acks.  You can also send in a renew 
to many servers today and get them to give you an address w/out going 
through all of the discover handshake, though this is harder since you 
actually have to be using the address to get the ack back (but maybe you 
don't care).  You can do the same thing to a failover server, and it will 
ack in pretty much the same way -- and if you can find two failover server 
that are partitioned, you can do renews to each of them with different IP 
addresses and the same client-id and thus construct a duplicate IP address 
scenario "by hand".

So, when (as you put it) "some client claims it has the address but
really doesn't", you may well open youself to attack -- but you are
already open to much easier attacks of exactly the same sort -- or
so they seem to me.

Perhaps if you want to pursue this, an example might help me understand
your specific concern.

Cheers -- Kim

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 22 Apr 1999 13:27:08 -0400 (EDT)

>> Kim said:
> Ted replied:
>is really trusted.   

	Kim responds:

	Actually, this isn't how I have conceptualized our approach,
	although you may well see it differently.

	First, let me state that I don't expect to change the failover 
	protocol to assume that a client that does an INIT-REBOOT has
	time left on their lease.  Someday I would like to, but that
	day is probably years in the future.

	That said, let me try to explain why I disagree with your 
	statement that "only what the server knows is really trusted
	in the failover protocol".  Certainly, if information that
	the server has and the client has conflict, the server
	will trust its own information.

	However, information stored on the client *is* trusted
	to some degree, and it is what makes the lazy update
	work.  Here is an example...

	Server A issues an ACK to client X for IP address i.j.k.l, 
	and then queues the binding update to server B (its secondary).  
	However, server A crashes prior to the binding update ever 
	getting sent to server B.  Now, server B knows nothing about 
	the fact that client X has IP address i.j.k.l.  Client X
	will try to renew from server A several times, and get no
	response, and ultimately will do a rebinding (broadcast),
	and server B will see it.  Now, server B will ACK the 
	rebinding from client X for IP address i.j.k.l, even though
	server B has absolutely *no* record of client X ever using
	IP address i.j.k.l.  However, server B has no conflicting
	information about some other client using IP address i.j.k.l,
	and so will assume that, since client X is using the IP
	address now (and clearly believes that it has time left to
	run on its lease, or it wouldn't be using it at all), that
	client X must have been given IP address i.j.k.l by the
	other server.

	As an aside, this is why one failover server cannot reallocate an
	IP address from one client to another client without interlocking
	with the other server (unless it is in partner-down state, where
	it has been assured that no other server is operating or can operate
	without resynchronizing with it).

	The example above is not the only situation in the failover 
	protocol where information stored on a client is used to allow
	the protocol to operate, but it is perhaps the simplest and
	the most likely situation to occur.

>This represents a major change - you're deciding

	Actually, in DHCP a bad RTC on a client (if it is bad in the
	"correct" way) can easily cause an IP address conflict with
	or without the failover protocol in operation.  DHCP as a 
	service depends on reasonably accurate RTC's in clients
	(and usually supports a grace period to allow for clocks that
	aren't too terribly accurate).  Any client with an RTC
	that doesn't run at all, or runs at some significant
	percentage less than accurate time (say 50% of real time),
	will cause an IP address conflict today without any
	interaction with the failover protocol.

	Cheers -- Kim

---

From: Rob Stevens <[email-masked]>
Date: Mon, 26 Apr 1999 09:35:46 -0400 (EDT)

It seems to me that the clear intent of the RFCs 
was the clients cannot start in INIT-REBOOT
when
	a) the lease has expired
	b) the lease was RELEASED

It may very well be that this would save 2 packet
exchanges in the case where servers have not
re-allocated the address; but it will create 2 more
packets (REQUEST; NAK; DISCOVER; OFFER; etc)
when the servers have re-allocated the address.
The gain in efficiency is thus diminished.

I would like to make this a MUST NOT
(ie if either of the two conditions holds, client MUST NOT start in
INIT_REBOOT).
Nonetheless we support such clients and don't pedantically NAK if no
other ill-effect would occur:

a) If the client is on a subnet not served - remain silent
    (perhaps should NAK if IP address inconsistent with net,
      but if subnet not served, the server may not have the
     proper masking/logical net configuration available)
b) If the IP address is bound to another client: NAK
c) If the client is already bound to a different IP address: NAK
d) If the IP address is not one adminstered by he server: remain silent
e) If the IP address is still bound to the client (whether expired or no)
    ACK (and update lease expiration to new value).

Rob

---

From: David Babbitt <[email-masked]>
Date: Mon, 26 Apr 1999 13:55:14 -0400 (EDT)

> d) If the IP address is not one adminstered by the server: remain silent

Our server (AIX) is about identical to this behavior.

I'd like to raise another question about steps (a) and (d) here.
I contend that the server should remain silent in both of these
cases because it can't be positive that it's the only server on
the network or the only server servicing the subnet in question.
More specifically, in (a), I wouldn't want the server to NAK
when it thinks that the subnet doesn't match the address if
there exists another server on the network that is configured for
multiple subnets on that physical network.

The reason I bring this is up is to find out about the behavior
of other vendors' DHCP clients.

I've had to argue the behavior of my server concerning the above
with customers after they realized that some clients will continue
to use their previous lease when neither an ACK nor a NAK is received
in the INIT-REBOOT state.  E.g., a laptop moves from one subnet to another,
the new subnet isn't controlled by the old server, and therefore
the client falls into scenario (a), gets no response, but continues
with the old address ...

Thanks,

David

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Apr 1999 17:53:03 -0400 (EDT)

> multiple subnets on that physical network.

This seems correct to me too.

> the client falls into scenario (a), gets no response, but continues

This shouldn't happen if there's a DHCP server on the new net.

In (d), the server SHOULD NAK if the IP address is on the wrong
network, even if it doesn't have any record of the IP address.  This
is how version 2.0 of the ISC DHCP server behaves by default.  In
version 3, because so many people are setting up DHCP servers at home
connected to cable modem services, I've set the default so that it
won't NAK unless it has a record of the address, but in any real
production environment this is incorrect - the server administrator
should configure it with correct knowledge of the network, and it
should always NAK requests for IP addresses that aren't valid for the
network they originated on.

			       _MelloN_