Subject: I-D ACTION:draft-schrijvp-dhcpv4-reconfigure-00.txt

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Tue, 12 Oct 1999 08:06:20 -0400 (EDT)

FYI; we'll have a chance to discuss this draft at the WG meeting in DC...

- Ralph

=====

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Dynamic host configuration : DHCP reconfigure 
                          extension
	Author(s)	: P. De Schrijver, Y. T'Joens 
	Filename	: draft-schrijvp-dhcpv4-reconfigure-00.txt
	Pages		: 5
	Date		: 08-Oct-99
	
This draft  defines  extensions  to  DHCP  [DHCP]  to  allow  dynamic
reconfiguration  of  a  single  host  with  a new IP address. This is
achieved by introducing  a  unicast  DHCP  FORCERENEW  message  which
forces the client to the RENEW state.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-schrijvp-dhcpv4-reconfigure-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-schrijvp-dhcpv4-reconfigure-00.txt".

A list of Internet-Drafts directories can be found in

http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-schrijvp-dhcpv4-reconfigure-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-schrijvp-dhcpv4-reconfigure-00.txt

<ftp://ftp.ietf.org/internet-drafts/draft-schrijvp-dhcpv4-reconfigure-00.txt>

---

From: Steve Gonczi <[email-masked]>
Date: Tue, 12 Oct 1999 13:24:22 -0400 (EDT)

Hello,

IMHO, the new option is long overdue, cheers! 

Comments:

1) The specific implementation chosen could be a bit simplified:
We could send an option to the client, which, upon receipt (if understood
and accepted), causes it to go directly into INIT state.

Why not? This is what we are ultimately trying to accomplish right? The
DHCPDISCOVER serves as "ack" for the message.

If we are concerned with the occasional need to give the client the same
address, we can do that in response to a DHCPDISCOVER as well. Should the
message work this way, it probably needs to be called FORCEINIT.

2) It would be also useful to introduce a new client option, to flag clients
who are capable of receiving FORCE(WHATEVER-YOU-END-UP-CALLING-IT) messages.
I would put it into the DHCPDISCOVER messages, and a compliant server should
track/flag such clients.

This is to avoid :
a)Generating unnecessary traffic while we are trying to send this to a
client who does not understand the option.
b)Possibly crashing a poorly implemented client who does not understand the
option. (The downside: we could crash a poorly implemented server, that does
not understand the new client option. ;-)

Good work!

sG

---

From: De Schrijver Peter <[email-masked]>
Date: Wed, 13 Oct 1999 10:10:32 -0400 (EDT)

Hello,

> message work this way, it probably needs to be called FORCEINIT.

We thought on this approach, but decided to have the client explicitly contact
the server, to have at least some protection against rogue RECONFIGURE messages.
I realize an attacker could of course also spoof the server replies...

> not understand the new client option. ;-)

That's indeed a good idea, also for possible future extensions.

> Good work!

Thanks.

Cheers,

Peter.

---

From: Steve Gonczi <[email-masked]>
Date: Wed, 13 Oct 1999 13:49:04 -0400 (EDT)

>> and accepted), causes it to go directly into INIT state.
--snip--

>I realize an attacker could of course also spoof the server replies...

Un-authenticated DHCP is not a secure protocol. 
It is arguable whether the extra bit of protection is worth the extra
message traffic.
IMHO it is not, others may disagree.

There is no way around making both server and client modifications for this
protocol. 
Given that, you could solve the rogue message problem via authenticated
DHCP, 
and choose the simpler solution.

sG

---

From: Richard Jones <[email-masked]>
Date: Wed, 13 Oct 1999 15:07:33 -0400 (EDT)

Like Steve, this draft looks like a good thing to me. It brings up a question
I've wondered about, and would ask anyone with more experience in the
dhc working group than me to comment on:

What (if any) are the differences in implication between a change in the protocol
that requires server implementors to alter server behavior, and a change that
requires client implementors to alter client behavior? If there are differences,
has this had an impact on the strategies for protocol changes (other than
requiring graceful handling of elements that don't deal with the changes)?

Regards,
Richard

Steve Gonczi wrote:

> There is no way around making both server and client modifications for
> this protocol.
> DHCP, and choose the simpler solution.
>
> sG

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Oct 1999 15:10:09 -0400 (EDT)

When you are thinking about this idea of a server-originating message
that causes a client to reconfigure, please think carefully about how
this affects the DHCP threat model.  This change makes a big
difference to the threat model.

With current DHCP, the threats are: a rogue server can feed a client
incorrect information, a rogue server can prevent a client from
acquiring or renewing a lease, and a rogue client can in various ways
cause a server that is doing dynamic address allocation to deplete its
address pool, preventing legitimate clients from getting addresses
from the server.

This means that the opportunities to deny service to a client occur at
relatively infrequent times in a normal configuration - when the
client first powers on, and whenever it renews.   Also, DoS attacks
against servers don't have any amplification - you just have one
attacker doing it, which is relatively easy to track down - the DoS
packets the server sees are actually coming from the attacker.

Now consider what happens if you add a server-sourced reconfiguration
packet, without DHCP authentication.  First of all, clients are
_always_ vulnerable to attack, not just at certain points.  If I want
to hijack a client's TCP connection, I can send it a reconfigure
message at a crucial time and *prevent* it from using its address.
This means I can hijack its TCP connections and, by cleverly blocking
its use of the DHCP protocol, prevent it from repudiating my
continuation of its TCP streams, because it won't be able to use its
IP address and probably won't even see the usurped stream coming back
from the server.

This changed window of opportunity has, IMHO, severe security
implications.   But let's forget about that for a moment.   What if we
just want to kill the DHCP server, so that we can do something
nefarious without it noticing?   What if we want to do this
indirectly, in such a way that packets originating from our machine
never hit the server?   No problem.   Sit around passively snooping
DHCP traffic for a while, and get a list of all the clients.   Then
send out messages to every client, all at once, telling them to
reconfigure.   Instantly, the DHCP server is under extreme load, all
of which is coming from *legitimate* clients!

I would argue that this reconfigure message changes the DHCP threat
model sufficiently that we should not just handwave about the security
implications.   If any draft like this is going to advance in the
working group, I think it has to *require* that conforming clients and
servers implement the DHCP authentication protocol or some similar
protocol.   The reconfigure message should also probably include a
requirement that a client stack receiving and executing a reconfigure
message should cleanly shut down all of its persistent connections
(essentially, TCP connections) before reconfiguring.

Comments?

			       _MelloN_

---

From: Steve Gonczi <[email-masked]>
Date: Wed, 13 Oct 1999 17:00:34 -0400 (EDT)

>If any draft like this is going to advance in the

>The reconfigure message should also probably include a

Yes, both of Ted's suggestions seem very reasonable. 

sG

---

From: Bernie Volz <[email-masked]>
Date: Wed, 13 Oct 1999 18:37:02 -0400 (EDT)

Ted/Steve:

I agree that this opens up significant threats.

There are some things that COULD be used to reduce the threat:

- Only allow these message to originate from a unicast address. That
way, you can't cause an entire subnet to reconfigure. You could even
require that this comes from the server that assigned the address,
but that does cause issues for the Failover protocol and may have
other problems. Even with this restriction, the failover issue can
be dealt with if you have both servers send the DHCPFOCE messages
to all the clients of interest (since the address was assigned by
one of these servers, it will happen). This does mean both servers
in the pair need to be up, but that's likely OK.

Yes, someone could always send a media-layer broadcast with a unicast
address as the destination IP address so that isn't that much more
secure.

However, most socket implementations don't tell you the destination
address, only the source on a recvfrom. So, this may have little value
and not be possible to implement. (Perhaps most DHCP Clients don't use
sockets?)

- The Client is, in the draft, asked to enter RENEW. This has 3
results:
	- NAK from server; go to INIT.
	- ACK from server; continue using address.
	- No response; keep trying or wait until T1/T2 times

This seems to me that it requires sending both a DHCPFORCE and
then hijacking the server.

Note also that the state change in the draft is like the T1 expires
time. So,the client can continue to use the address until it gets a NAK.

- To reduce the potential burden on the server, using unicast messages
means that the server can control the client rate. But, to avoid the
potential threat if DHCPFORCE was broadcast, have the clients wait a
random interval (say up to 60 seconds?) before renewing. This reduces
the burden on the server as it spreads out the load.

- And, build an anti-spoofing algorithm into the client. If the client
receives a DHCPFORCE and hears back from the server (either a NAK or
ACK), prevent it from processing any further DHCPFORCEs for a period of
time (say 5 minutes). This does mean you can't reconfigure more often
than once every 5 minute, but is that really needed?

Agreed that NONE of these eliminate the threat and the only solution is
to use some kind of authentication (DHCP authentication per the draft).
And, if authentication is used, some of the restrictions could be
dropped (such as not allowing 2 DHCPFORCEs within a period of time).

- Bernie Volz
  Process Software

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Oct 1999 09:31:32 -0400 (EDT)

> Only allow these message to originate from a unicast address. That
> way, you can't cause an entire subnet to reconfigure.

You mean don't allow a message to be sent to the broadcast address?
Okay, but I can still send flood the net with reconfigure messages and
create massive congestion.   WRT validating the source address as being
from the server, this is trivially forgeable, so it really makes no
difference.

> then hijacking the server.

Yes, but the timing is the difference.   Before, you had to wait for
the client to change state, and then attack.   Now you can attack when
it's convenient - for example, when you observe the client starting a
session that would be profitable to compromise.

> time. So,the client can continue to use the address until it gets a NAK.

Right, but it's sensitive to a NAK after receiving the DHCPFORCE,
whereas it was not sensitive to a NAK prior to receiving a DHCPFORCE,
so the situation is indeed different with DHCPFORCE than without.

> To reduce the potential burden on the server, using unicast messages
> means that the server can control the client rate.

No, it does not mean this.   It is still possible for an attacker to
cause all clients to reinitialize at once.

> But, to avoid the potential threat if DHCPFORCE was broadcast, have
> the clients wait a random interval (say up to 60 seconds?) before
> renewing. This reduces the burden on the server as it spreads out
> the load.

This is a good idea, and will help if implemented.

> And, build an anti-spoofing algorithm into the client. If the client

How does this help?

> to use some kind of authentication (DHCP authentication per the draft).

Right.   I do not believe we should advance the draft if it does not
*require* authentication.

			       _MelloN_