Subject: RE: [dhcwg] RFC2563: Threat or Danger?

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 24 Jan 2003 14:30:09 -0600

Ted:

This is great analysis and response. Perhaps you and Ralph should update
draft-droms-rfc2563-deprecate-00.txt to include this information.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, January 24, 2003 1:37 PM
To: Robert Elz
Cc: Ralph Droms; [email-masked]; [email-masked]
Subject: [dhcwg] RFC2563: Threat or Danger?

> I know that if
> I was writing a client, and I got an offer which said "no addresses 
> for you"
> and another that said "here's an address you can use" (or even 
> "configure
> yourself a LL address") then I know which offer would be the one I'd be

DHCP cant' say "configure yourself an LL address."

I've got a couple of problems with what you've said, and agree with 
other things you've said.   The DoS problem is definitely not the only 
reason to deprecate RFC2563, and I will give some other reasons to 
deprecate it.   I will also point out some reasons why the DoS attack 
enabled by RFC2563 is easier to do than the a direct IPv4ll DoS attack. 
   Finally, I will point out why the RFC2563 DoS is a more difficult 
attack from which to recover.

1. Non-DoS reasons to deprecate RFC2563.

- It's voluntary, so it doesn't work - if you really want this, RFC2563 
isn't the way to get it.
- It requires a change to the DHCP protocol state machine - a response 
is generated by the server according to RFC2563 in a case where no 
response would be generated according to RFC2131.   This requires 
significant changes to clients and servers, which I think is one reason 
why nobody has implemented RFC2563 to date.
- Customers are not asking for it, and nobody has implemented it, even 
though the theoretical need for such a mechanism after almost five 
years of deployment.
- RFC2563 demands that the client operate in conflict with the wishes 
of the owner of the client.   So it is difficult for a client vendor 
(e.g., Microsoft or Apple) to justify implementing RFC2563 - it is 
likely to cost them business, or generate support calls that will cost 
them money.   I think this is the main reason RFC2563 has not been 
implemented.

2. RFC2563 enables off-network attacks

Having said that, I think you underestimate the value of the DoS attack 
that RFC2563 enables.   RFC2563 enables off-network DoS attacks, 
whereas without RFC2563 the only possible attacks require that the 
attacker be attached to the network.   There are two kinds of 
off-network attacks that it enables:

- Speculative attacks, where you guess the MAC address and transaction 
ID of a device and send it DHCP packets in the hopes that it will be in 
the right state to be disabled by these attacks.
- Relay agent-based attacks, where you listen to the relay agent and 
supply a bogus response that shuts off IPv4ll.

This second attack is quite significant, as some folks have mentioned, 
because we know of ISPs who perform this kind of attack on their 
customers already.   Currently they do it by providing bogus IP 
addresses rather than by using the RFC2563 mechanism, but if RFC2563 
were widely implemented by clients, we have reason to suspect that it 
would be used to attack and disable legitimate networks.

One reason why ISPs may perform this attack is because when you don't 
respond to a DHCP client, it keeps asking, and never shuts up.   If you 
can send it a "shut up" response, you eliminate all these clients.   So 
if we give ISPs rfc2563, that is, if it becomes widely implemented, it 
will be used to shut up clients.   The effect of this will be to break 
networks that ought to work.   So in fact the DoS argument against 
RFC2563

3. It is harder to identify and eliminate an RFC2563 attacker

Another problem with RFC2563 is that it's easy to use it to deny 
service.   A client pipes up with a DHCPDISCOVER.   You tell it to shut 
up.   End of story.   With IPv4ll, in order to shut up a client, you 
have to be constantly listening for ARPs and defending IP addresses.   
So a DoS attack of this kind would be very easy to track down.   By 
contrast, an RFC2563 attacker can attack at an opportune moment, 
disable one or more clients, and then go silent for an extended period 
of time, so there's no easy way to track it down.

4. No automatic recovery from an RFC2563 DoS attack.

Once you have identified an attacker that is using the 
defend-all-addresses attack, you can unplug  attacker from the network, 
and the network immediately starts working again.   In comparison, the 
RFC2563 DoS requires you to physically manipulate every computer on the 
network - you either have to power cycle them, or if they can detect 
link state transitions, disconnect and reconnect each device from the 
network.   This is because once the client has been told to shut up, it 
shuts up, so there's no automatic recovery mechanism.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg