Subject: [dhcwg] RFC2563: Threat or Danger?

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Jan 2003 10:36:33 -0800

> 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

---

From: Robert Elz <[email-masked]>
Date: Sat, 25 Jan 2003 18:40:40 +0700

Date:        Fri, 24 Jan 2003 10:36:33 -0800
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

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

That's what 2653 says isn't it - or perhaps more accurately, 2653
assumes that if nothing is said, then not getting an address from
DHCP (the DHCP server ignores the DHCPDISCOVER) is implicitly telling
the client to go configure a LL address (if it wants to do that of
course).

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

Huh?   Everything here is voluntary - I (at the very least) do not
mean to imply coercion.   It is no different than assuming that clients
that are offered an address via DHCP will actually configure the address
they're offered, rather that some other address they pick that is on
the same network (using the subnet-mask from the DHCPOFFER to work that out).

If the client deliberately decides to ignore the advice, that's its
choice.   If the user has told it to do that, fine.   If the vendor has
implemented it to always do that, that's their choice, but they wouldn't
be able to claim conformance with 2563 obviously, and not with the LL
std if that ends up requiring 2563 be implemented (or something like 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.

I am pretty sure that I can make the ISC server generate 2563 responses
with no changes at all, but I haven't yet tested it.   To work "easily"
from the servers point of view, yes, that would require some modifications
I suspect.

  | - RFC2563 demands that the client operate in conflict with the wishes 
  | of the owner of the client.

No it doesn't.   It can't, nothing the IETF produces can require that.

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

Only if servers start supplying the option, right?   And your thesis above
was that none do or ever will.   So, how could this possibly cost anything
more than the implementation cost (like 50 lines of code, max).   On the
other hand, if servers do start supplying this option, because their operators
want them to, and then the servers are configured to generate the option,
and the option says "no LL addresses" when sent, and the clients ignore
that, don't you think that would generate support calls ?

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

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

Hmm - this doesn't follow, first you say that 2563 enables these attacks,
and then that they're already being carried out, without 2563.

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

If I were to be subject to such an attack, I'd much rather it was carried
out using 2563 than by handing me a bogus IP address.   That way at least
I could easily see what was happening, my system would tell me (you were
refused an IP address), rather than proceeding happily with an IP address
that looks to be just fine, but doesn't actually work.

So, if this is the threat, then bring on 2563, please!

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

It doesn't matter why they might choose to do this, if they do it now, and
can do it now, and will still be able to do it (in a different way) using
2563 (if clients implemented it) then nothing has really changed, except
2563 makes things more obvious (so if the "attacker"/ISP is trying to be
as nice as they can, while keeping down the load on their server, they'd
use 2653, if they're really trying to hide what they're doing, they'll
keep doing it the way they are now).

This is just another aspect of Keith's reply to Ralph's first message on
this general thread - the DoS potential of 2563 is really identical to the
DoS potential of DHCP without 2563.

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

Until it decides to try again, and assuming there is no other DHCP
server that actually offers an address.   The story continues...

  | With IPv4ll, in order to shut up a client, you 
  | have to be constantly listening for ARPs and defending IP addresses.

So?   You have to keep watching for DHCPDISCOVERS anyway, watching for
ARP is not really all that hard to do.
  
  | 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.

Huh?   You just have the client do a DHCPDISCOVER and watch what happens
next time.   If the attacker is being silent, then the client goes ahead
and gets its LL address after all this time - that's no different from an
ARP attack running for a short while, then going silent for a while in the
hopes of avoiding detection.

You're also assuming that the client is not recording the information
about who (mac & IP addr) of the node that sent the "shut down" DHCP
message.   Why would you assume that?   It seems like that would be the
obvious thing for a node to record for later analysis.

On the other hand, getting a reply to an ARP probe for an address is
"normal" - that's what is supposed to happen if you happen to pick an
address that is in use already.   There's no particular reason for a
client to believe it needs to remember anything about where that came
from, and without that, it can't tell that all the ARP responses seem
to be coming from the same place (even assuming that the ARP attacker
isn't just randomising its MAC source address).

Once again, the 2563 DoS attack is the one I'd much rather carried
out against me, it is the one that is much easier to detect and
analyse.

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

That's true for any attacker.

You have a hidden assumption here that a node wanting a LL address is
going to continue ARP'ing (probing) for one, forever, until it eventually
is received.   I kind of doubt that (and would like the implementors of
the current implementations, or those who know about them, to tell us if
they just continue forever, or if they give up after a while).

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

There's no reason that a client can't try again from time to time, after
either of these failures.   Explicit try again commands (from some user,
perhaps using one of the methods you mention, or something else) might,
be required for either of those methods.   I see nothing in 2563 that
says "never try again without detecting link state changes" or anything
like that.

In fact, anything of that nature would be very un-DHCP like - it is normal
for a DHCP client to re-validate (extend) its lease from time to time,
the only control DHCP has over this really is to send back timers that
control the max time the address is valid (and the suggested rebind time).

There's nothing in 2563 that mentions timers at all, there probably should
be.   One might assume that the lease validity timer of the yiaddr=0 is
intended to be the validity period of the "no autoconfigure", but there's
nothing in the doc that says that, nor is there anything anywhere that
prevents the client validating its address sooner (as soon as it likes).

I use your client Ted (the ISC client that is), and I quite often renew
leases very much sooner than the reply from the server would lead me to
otherwise do (for all kinds of reasons).

Nothing in your message suggests to me that 2563 should be deprecated,
nor that the LL doc shouldn't mandate its use in LL clients.

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 25 Jan 2003 20:28:15 +0700

Date:        Sat, 25 Jan 2003 18:40:40 +0700
    From:        Robert Elz <[email-masked]>
    Message-ID:  <[email-masked]>

  |   | DHCP cant' say "configure yourself an LL address."
  | 
  | That's what 2653 says isn't it

I meant 2563 (of course).

  |   | - It's voluntary, so it doesn't work - if you really want this, RFC2563 
  |   | isn't the way to get it.

And I missed your meaning there at first reading - you mean that clients
don't need to include the option, in which case the server won't include
it in its reply (it being one of the few "only supply when asked" options).

First, that's one thing I would change in the 2563 - there's no reason I
see for the server not to send the option any time it feels inclined.
There's no more reason this would cause a problem to a random client than
if the server should decide to supply the well known impress printer option.
Ignoring unknown/unwanted options is easy.

Second, even ignoring that, a client that intends to "play by the rules"
(assuming the rules and up as "don't configure yourself a LL address if
the DHCP server says not to, even if it hasn't given you an address" will
include the option in its DISCOVER (and REQUEST) packets, and so get the
response (assuming the server wants to send it).

Clients that have decided to take no notice, including clients implemented
before the LL staandard (or I-D of what it might be eventually) suggest
doing this will obviously not send the option, and if the server obeys
2563 as written now, won't get the "no LL option", and so will go ahead and
configure a LL address anyway.

Once again, I am not wanting to prohibit LL addresses because I think that
LL addresses will magically destroy my network.   I want the client to
not use one (in some cases where I decide) because I know that the client
will be better off with no address, than believing it has an address, which
will not then work (at all).   I want a way to tell the client that.  If
the client believes it knows better than I do (or is simply too old to
know anything at all) then so be it, it won't get the information that I
am trying to convey to it.

kre

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Jan 2003 10:11:45 -0800

> Ignoring unknown/unwanted options is easy.

The server is generating a bogus DHCPOFFER.   Sending this to a 
non-rfc2563-compliant client would have unpredictable results.
q

---

From: Robert Elz <[email-masked]>
Date: Sun, 26 Jan 2003 15:18:43 +0700

Date:        Sat, 25 Jan 2003 10:11:45 -0800
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | The server is generating a bogus DHCPOFFER.   Sending this to a 
  | non-rfc2563-compliant client would have unpredictable results.

If you mean, sending address 0, then yes, but that wasn't what I
meant in the text you quoted.

All I meant was that it would do no harm to include option 116 in
a DHCPOFFER, no more than any other option the server is configured
to send (that is, option 116 along with a normal IP address).

But even in the case where the server sends a full 2563 response,
with addr=0.0.0.0 and option 116, why would I care what the results
are in the client?   (Anything from crashing, to thinking it owns
address 0, to ...)

The only point of sending such a response is when it isn't intended to
work on the net in the first place, what happens to it (especially if
it has a poor dhcp client implementation with no sanity checking) shouldn't
bother anyone overly much.

kre