Subject: AW: [dhcwg] ID's: DHCP Discovery Extensions

From: "Rentschler, Markus" <[email-masked]>
Date: Thu, 13 Nov 2003 16:02:57 +0100

----------------------------------------------------------------
Thus by default, any device on the network would be able to trigger a
DDoS attack on your DHCP infrastructure by sending a broadcast
DHCPNETSCAN (again, we're talking about the proposed _default_
configuration)?

[MR>]
This security hole is indeed the most painful aspect of the Discovery
Extensions.
Besides the proposed bandwith limitation, a possible solution could be: 
DHCP is at startup by default issuing DHCPDISCOVER. As long as the device
has no lease, broadcasted DHCPNETSCANs must not be answered. After the
device got its lease, only DHCPNETSCANs from the lease-granting server will
be answered OR only after some authentication took place (authentication
mechanism would have to be developed). 
But this would eliminate one of the advantages of the Discovery extensions:
No flooding mit DHCPDISCOVER messages at boot time and configuration under
complete control of the server.

What is your recommendation for the default settings from your point of view
?
So far the default settings where not that important to me. 
In our environments (very restricted access and a maximum of a few thousand
devices) I would just enable everything and be quite save as long as the
Admin doesn't make nonsense himself.
Maybe one should explicitly restrict the Discovery Extensions to such types
of networks?

----------------------------------------------------------------
In which case, why doesn't the admin simply
enable DHCP to begin with.  This would make DHCPCONFIGURE redundant (the
device will already have a lease, or will DISCOVER soon.  And accept
FORCERENEW (assuming RFC 3203 is implemented) ).

[MR>] 
I considered using the FORCERENEW instead of DHCPCONFIGURE in the beginning.
I came up to dislike the FORCERENEW mechanism for the following reasons:
It operates that way: The server who wants to initiate reconfiguration tells
the client to ask at the same server for a new configuration! A little bit
complicated, isn't it ? Especially for the server implementation when it
wants so supervise the whole reconfiguration process!  The FORCERENEW
mechanism leads to a seven (!) message exchange for the reconfiguration of a
single(!) client ! 
FORCERENEW -> DHCPREQUEST -> DHCPNAK -> DHCPDISCOVER -> DHCPOFFER ->
DHCPREQUEST -> DHCPACK
That produces a lot of superfluous network traffic. The straightforward way
would be that the server tells the client it's new configuration and gets an
ACK to be sure everything went ok. That's the way the
DHCPCONFIGURE/DHCPREPORT mechanism works which even provides additional
flexibility besides that.

And what happens when the server crashed and all the lease info is lost ?
No possibility to get any information about clients with FORCERENEW
With DHCPNETSCAN one could easily recover the leae database without the need
to boot up all the clients (which would be inacceptable anyway).

----------------------------------------------------------------
The draft still has additional state transitions to document.  For
example: upon receiving a DHCPNETSCAN in the BOUND state, the client
must transmit a DHCPREPORT and transition back to the BOUND state.  Upon
receiving a DHCPNETSCAN in the INIT-REBOOT state, do what?   How about
SELECTING?  The draft is proposing 3 new messages.  The draft needs to
document what is going to happen in _every_ state of the DHCP client
state machine when it receives any of the 3 messages (OK, 2 messages,
clients shouldn't be getting REPORTs).

[MR>]
OK, a state diagram with the extensions can be drawn. 
I thought this was unnecessary since the behaviour of the Discovery
Extensions is so simple, that IMHO a textual description is far better
understandable than a state diagram made of ASCII characters.

----------------------------------------------------------------
> > Another thought... what happens if the device sends the 
> RELEASE, then 
> > sends the REPORT, but the REPORT is lost?  (keep in mind 
> that this is all 
> > UDP... UDP packets may get dropped). 
> > 
>       [MR>]  Then the server will have to retransmit its DHCPCONFIGURE
> until it gets a DHCPREPORT from that device. 
>       Since this is done on layer 2, it is not important if the device
> accepted the initial DHCPCONFIGURE or still uses it's old or 
> no ip address at all. 
However, in the meantime there's a DHCP device out there that has an IP
address, which the DHCP server has no valid lease for.  This opens up
the possibility of duplicate IP address allocation.

[MR>] 
I don't agree on that.
The first IP that was RELEASEed is not longer in use, since the device
accepted the new ip setting.
The server has no valid lease on that new ip setting, but it knows that the
REPORT is outstanding 
and must of course not give that ip address to another client until its
recovery mechanism timed out. And additionally there is still the mechanism
that DHCP should check via an ARP request if an IP address is already in
use.

----------------------------------------------------------------
> > >       [MR>] 
> > >       Both should be possible: configuration AND reconfiguration, 
> > We already have a mechanism for reconfiguration.  Why 
> reinvent the wheel, 
> > which only adds additional overhead? 
> > 
>       [MR>]  Sure, but there is no mechanism for server-originated 
> CONfiguration. That's what the draft is all about. 
If the device is configured to use DHCP anyway, you only need to wait
until the device performs a DISCOVER.  

[MR>] 
What about the scenario that Lease Duration is infinite, the Server has
crashed and lost its lease information ? Or an additional server is plugged
onto a running network ? Or a network is going to be
reorganized/reconfigured/altered without booting all clients ?

----------------------------------------------------------------
> > one mildly malicious user can emit a NETSCAN once an hour and cause your
> > entire network of 200000 devices to DDoS your real DHCP server by 
> > hammering it with 200000 REPORTs, 
> > 
>       [MR>]  That is the only point that makes me some headache too. 
>       I would like to get some ideas how this potential 
> danger could be minimised. 
>       With normal DHCP we got a similar Problem at bootup, when every 
> client emits it DHCPDISCOVER messages. 

Granted, if your entire network is rebooting, the servers will undergo a
severe load.  However this would (hopefully) be a fairly rare event.
With this proposed draft, it even suggests initiating this load on a
periodic basis!

[MR>]
 I see there no real difference to what a management software does 
that is periodically PINGing its network to check if all agents are still
responding.

----------------------------------------------------------------
> > > > OK, what happens in the case: 
> > > > 1) Device A sends the RELEASE 
> > > > 2) Device B Discovers & Requests (since the IP is now 
> > > available, it was 
> > > > just released!) the now released IP 
> > > > 3) Device A REPORTs on that IP ? 
> > >       [MR>]  
> > >       The REPORT must of course use the new IP assigned with 
> > > DHCPCONFIGURE, since it is the REPORT's main job to tell the 
> > > rest of the network that a certain client has a certain 
> configuration.  
> > > So there should be no problem. 
> > There's a big problem.  There is now two devices with the 
> same IP address. 
> > 
> > 
>       [MR>] 
>       How do you get that idea ?? 
>       Device A has released the IP, since it got a DHCPCONFIGURE 
>       with new settings AND accepted them (Otherwise there would be no
> RELEASE). 
>       So only Device B has this IP. 

Not necessarily true.  Device A gets a DHCPCONFIGURE to change it's DNS
settings.  Since Device A has a current lease, the draft says that it
needs to DHCPRELEASE it first.  Now the DHCP server has released the IP,
but the client is still using the IP.  Device B comes and does a
DISCOVER/REQUEST, receiving that IP.  Presto, duplicate IP.

[MR>]
Well, how long does Device A still have the old ip after DHCPRELEASE ?
0.001 seconds ?-)
The next operation in the code would of course be setting up the ip stack
with the new parameters.

----------------------------------------------------------------
> > Then it is a different protocol, and should be treated as such. 
> > 
>       [MR>]  It does the same (configuring the client with ip and some
other parameters), 
>       just in a slightly different way that offers some additional
opportunities for network administrators. 

So far, I don't see the advantage of using this particular scheme over
the already specified RFC 3203.  I think that 3203 has some elegance in
it that it reuses as much of the existing DHCP infrastructure as
possible. 

[MR>]
I agree that RFC 3203 has some elegance in terms of simple incorporation
into the DHCP client.
I think it was designed on this premise:
As much client-initiated behaviour as possible, even when the intention is
doing server-initiated reconfiguration. That's the reason why in the end we
come up with a seven message exchange for a simple reconfiguration that
could be done with two messages.
 
----------------------------------------------------------------
 Instead of the FORCERENEW attempting to do everything, it
only triggers the client to renew immediately, instead of waiting for
the full lease time. 

[MR>] RFC 3203 is an elegant solution for exactly that purpose, but beyond
that IMHO it reaches it's limitations very quickly.

----------------------------------------------------------------
 Results in the client doing a unicast RENEW, which
if all you're changing is the DNS settings, the client could easily only
change the DNS settings resulting in as little disruption to IP services
as possible (client implementation detail...).  And if you're chaging
the IP settings, the device would get a normal NAK to the request,
causing the client to perform all the normal DHCP behaviours associated
with the NAK.

[MR>] 
Sure, this mechanism works and is very easy to implement on clients, but on
what costs ?
Lots of messages get exchanged and the server has to incorporate a very
complicated state machine to supervise the reconfiguration process.

Do you know of any publicly available servers that support RFC 3203 ?

----------------------------------------------------------------
This draft seems to imply that a device _must_ have a DHCP state machine
running, even if the device isn't going to be using DHCP.
[MR] 
In this case the device IS going to use DHCP (Discovery Extensions), but not
sending initial DHCPDISCOVER messages.
This is simply to avoid flooding the network at boot time mit DHCPDISCOVER
messages and doing the configuration under the control of the Server.

If the device is already using DHCP, then this draft is redundant with
other,
already specified behaviours (Failover, RFC 3203, RFC 2131)  (Again, if
the device is already using DHCP, it will DISCOVER on it's own, or it
will have an established lease).

[MR>] 
Again, my scenario with the crashed server and the device/topology detection
possibility.
This is only solveable with the Discovery mechanism
(DHCPNETSCAN/DHCPREPORT).

The combination DHCPCONFIGURE/DHCPREPORT is IMHO a much better solution to
the server-initiated configuration problem than the RFC 3203 mechanism that
is IMHO more or less a workaround to the dogma of traditional DHCP that the
client must initate communication.

The redundancy mechanism is an additional goodie that the discovery
mechanism COULD provide. 
And I can think of a variety of other useful applications of the Discovery
Extensions, I just dont't want to name them here for not feeding potential
competitors too much.

I regard the Discovery Protocol as a powerful thing that offers a lot of
potential applications. 
And since it performs the same task than DHCP (Dynamic Host Configuration),
it is IMHO in the right place as a configurable extension to DHCP ,
especially since the DHCP packet format and infratructure (relay agents) can
be used for implementation with very little effort.

Im aware of it's cons (DDoS through DHCPNETSCAN) and recommend that it
should only be used in environments where such an attack is unlikely to
occur (networks with restricted access).

Regards,
        Markus

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