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

From: "Kostur, Andre" <[email-masked]>
Date: Tue, 4 Nov 2003 09:57:09 -0800

> > -----Ursprüngliche Nachricht-----
> > Von:	Kostur, Andre [SMTP:[email-masked]]
> > Gesendet am:	Dienstag, 4. November 2003 00:15
> > An:	'Rentschler, Markus'; [email-masked]
> > Betreff:	RE: [dhcwg] ID's: DHCP Discovery Extensions / Interface
> > Informati on Option
> > 
> 	.... 
> 
> > Regarding: DHCP Discovery Extensions 
> > 
> > - I think there's some overlap here.  What's different between a
> > DHCPCONFIGURE, and a DHCPRECONFIGURE (RFC 3203) 
> (Functionally speaking).
> > Both of them cause a device to acquire new configuration 
> information.
> 	[MR>]  
> 	To use DHCPFORCERENEW (DHCPRECONFIGURE), the client must already
> have a lease assigned!

True, the device must already have a DHCP state machine running.  But if
there's no state machine running, then the device is choosing to not use
DHCP!

> 	With the Discovery Extensions I try to overcome this. 
> 	It's in fact a different philosophy to "traditional" 
> DHCP, even a
> different protocol, that just uses the DHCP packet format and the DHCP
> infrastructure!! This point must be clearly understood.

So you're trying to say that this draft only pertains to unconfigured
devices?  And that DHCP servers should be extended to hold information about
devices that aren't performing DHCP (If it is performing DHCP, then the
server will learn about the device when it Discovers....)?  (Are we then
duplicating effort with other protocols/applications which deal with the
network discovery stuff such as SNMP workstations?)
 
> 	Right now there are some proprietary Discovery Protocols under
> development by some industry consortiums that go into that direction.
> 	But I don't want yet another proprietary packet format 
> and protocol
> infrastructure if I can easily adopt DHCP, which does familiar things
> anyway. Thats the background of my draft.

OK, but DHCP isn't a device discovery protocol (and IMHO, shouldn't be.  And
devices which are configured to be using DHCP will, at some point, broadcast
Discover, at which point the device will be "discovered").  And there is at
least one other "Discovery Protocol" mechanism that would work almost as
well (using existing protocols)... performing ICMP Echos to determine if
there is a device, followed by performing an SNMP Walk on the target device.
(Note that later on you mention a target environment of a factory floor, so
we wouldn't need to worry about firewalls getting in the way....)

> > - The DHCP Client behaviour talks about an "initially 
> granting server",
> > what if the device has not yet been granted a lease from any server?
> 	[MR>]  See my point above. In that case it is configuration, not
> reconfiguration! 
> 	Reconfiguration should be restricted to the initially granting
> server, but not configuration.

But then the draft is confusing.  The draft talks about an initially
granting server (thus the device already has a lease), and you're talking
about configuration (thus the device has no initially granting server)....

> > - I don't think this draft really takes into consideration 
> the scope of
> > where DHCP is used.  According to the draft, a DHCPNETSCAN may be
> > broadcast, and should be relayed onto all other subnets.  Thus if a
> > central DHCP server emits 1 of these messages, that will 
> result in it
> > being broadcast to _everything_ on an entire intranet.  And 
> what about
> > relays behind relays?  What about relays that aren't on the 
> same subnet as
> > the originating server?  And then there's the problem of potentially
> > hundreds of thousands of devices _all_ trying to DHCPREPORT 
> back to the
> > server within a 2 second timeframe!
> 	[MR>]  For this reason I propose to make this mechanism
> (Broadcasting over relays) configurable. Then it's entirely in the
> responsibility of the network administrator, if he wants to take the
> potential risk having his network flooded with broadcasts.I see the
> application of the discovery mechanism mainly in networks that run on
> factory floors, which are not publicly accessible and consist 
> of lets say a
> maximum of ten thousand devices.

Sure it's configurable.  But your draft sets it up in the default case that
"A broadcasted DHCPNETSCAN message SHOULD be broadcasted into a relay
agent's other subnets."  (Actually, I just noticed that by default the draft
wants all REPORTs to be broadcast too... so that one DHCPNETSCAN which is
sent across your network results in potentially everybody on your network
broadcasting back to you.... now there's an efficient DDoS attack on your
entire DHCP infrastructure!)

> 	I also proposed in my draft to restrict broadcasting to certain
> relay interfaces, using the giaddr-field and/or the relay 
> agent information
> option. I think this would be very useful for security reasons and
> scalability (the server will be able to scan subnet for 
> subnet or interface
> for interface)
> 
> 
> > - DHCPREPORT says that option 61 is to be supplied.  There is no
> > requirement that a client _has_ a clientID.  It also says 
> that option 3 is
> > to be supplied too.  A device may not have a router defined.
> 	[MR>]  "The client MUST omit any parameters it cannot 
> provide." (see
> chapter 5). This should of course also be mentioned in chapter 3.3.

You may wish to reword that to something along the lines of "these options
are required to be sent by the client, all other options MAY (MUST?) be
included if the client has pertinent information".

> > - DHCPCONFIGURE is very disruptive to the network.  If all the
> > administrator changed was the client's DNS settings (for 
> example), this
> > draft requires the client to RELEASE it's existing lease, 
> and then assume
> > the new settings. 
> 	[MR>]  The Discovery Extensions rely heavily on the server. The
> people that implement and/or operate the server need to know 
> what they are
> doing. Of course can misuse of he server disrupt the network. 
> I can' t see
> any other strategy to prevent that than firing the admin if 
> he misuses the
> server under his control ;-)).
> 
> >  It's a little foggy as to what the DHCP server is going to 
> do when it
> > receives this RELEASE message.  
> 	[MR>]  Standard RFC2131 behaviour: The server has to check its
> internal lease database and relase that lease. 
> 	Sending a RELEASE is mainly for backward compatibility 
> with RFC 2131
> if there is a server on the network that doesn't support the discovery
> extensions.
> 
> > The draft also doesn't specify what order the RELEASE and 
> REPORT are to be
> > sent in.
> 	[MR>]  First RELEASE then REPORT.

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

?

> > - In section 3 you state: "To existing correct 
> implementations of BOOTP
> > relay agents these new message types SHOULD be 
> transparent."  This is
> > incorrect.  For DHCPNETSCAN (A server-to-client message), 
> the bootp relay
> > agent is supposed to broadcast that message on all connected subnets
> > (except the one it was received on).  This is not the 
> "normal" behaviour
> > of a relay agent.
> 	[MR>]  This describes the desired extended behaviour 
> defined in my
> draft. An existing relay agent that does not support the 
> discovery extension
> should never broadcast the DHCPNETSCAN packet. 
> 
> > In the abstact these are the stated goals: 
> >    - Discovery of clients in the network 
> >    - DHCP server redundancy 
> >    - Server-initiated configuration of clients 
> > 
> > DHCP server redundancy is already covered in the Failover draft.
> 	[MR>]  This is true. But server redundancy is not the 
> main purpose
> of the discovery extension. It's a nice "side-effect" and 
> IMHO much less

Not to sound nasty, but if this isn't a purpose of the discovery extension,
why is it stated as a goal of the draft?

> complicated than the failover protocol. But server redundancy 
> only works
> with clients that are able to broadcast DHCPREPORT messages. 
> It will not
> work with old BOOTP and DHCP clients, since they are unable 
> to tell other
> servers about their configuration.
> 
> >   Server-initiated configuration is covered in RFC 3203.  
> I'm not sure
> > that this draft can even do the Discovery of clients in the 
> network, as
> > any device which doesn't perform DHCP would be completely 
> invisible to
> > this scheme (as would any device which doesn't implement 
> this draft).
> 	[MR>]  For not beeing invisible, a device needs at least to be
> capable of BOOTP or DHCP, since they tell the server "Hey, 
> I'm here!".  For
> silent discovery, the clients of course need to be capable of 
> the Discovery
> Extensions.

Another general comment about the draft.  Offhand I think the DHCPCONFIGURE
message is superfluous when there exists RFC 3203.  I don't see anything
that that DHCPCONFIGURE does that DHCPRECONFIGURE can't do.  In the case of
an "unconfigured" client, there's nothing that needs to be done except wait
for the device to naturally Discover.  For an already configured device we
can send a FORCERENEW, and the device will immediately transition to the
Renewing state, causing it to perform a REQUEST/ACK sequence, at which point
the device can reconfigure itself based upon the data in the new ACK packet.

---

From: "Rentschler, Markus" <[email-masked]>
Date: Thu, 6 Nov 2003 14:41:25 +0100

> there's no state machine running, then the device is choosing to not use
	[MR>] 
	The device should be configurable in terms of DHCP on or off (as are
all devices I am aware of). 
	If the  Discovery Extensions are supported, the acceptance of
DHCPCONFIGURE should be configurable. Additionally initial sending of
DHCPDISCOVER should be configurable.

> >       It's in fact a different philosophy to "traditional" DHCP, even a 
> devices?  And that DHCP servers should be extended to hold information
> about devices that aren't performing DHCP (If it is performing DHCP, then
> the server will learn about the device when it Discovers....)?  
	[MR>]  
	Yes. The server will learn about devices through discovery: "Hey,
there is a device". 
	If the device is registered within the servers configuration
everything is fine. If it is not, the admin can be informed ("Hey Admin,
there is a unregistered device") or any other appropriate action taken.

> (Are we then duplicating effort with other protocols/applications which
> deal with the network discovery stuff such as SNMP workstations?)
	[MR>] 
	Yes and No. The Discovery Extensions allow both configuration AND
supervision of the network.
	It's up to the server, what it wants to use

> >       But I don't want yet another proprietary packet format and
> protocol 
> OK, but DHCP isn't a device discovery protocol (and IMHO, shouldn't be.
	[MR>]
	I think differently here... 
	Everybody how wants to use DHCP as ist is right now is free to use
it that way in the future and can disable the Discovery Extensions. They
won't get any disadvantage to what they have now. 
	Others who want to use it get a lot of functionality through it. 
	The Discover Extensions would be easy to implement. 
	No additional states in the client's state machine required. 
	I can see only advantages...:-)

	Designing a completely new protocol for device discovery would
create a lot of overhead in the client (memory in small clients !!), and it
would have to interact with DHCP anyway on the configuration level on both
the client and the server...

> And devices which are configured to be using DHCP will, at some point,
> broadcast Discover, at which point the device will be "discovered").  And
> there is at least one other "Discovery Protocol" mechanism that would work
> almost as well (using existing protocols)... performing ICMP Echos to
> determine if there is a device, followed by performing an SNMP Walk on the
> target device.  
	[MR>] 
	This allows only discovery of devices that already have their IP
addresses assigned and are reachable on the IP layer! If a device is
misconfigured and not reachable through IP, there is no SNMP walk...

	The Discovery Extensions would allow communication between server
and client on the Layer 2, prior to IP address allocation! Conmmunicate with
clients that are not reachable through IP is always possible!!

> > > - The DHCP Client behaviour talks about an "initially granting
> server", 
	[MR>] 
	Both should be possible: configuration AND reconfiguration, as the
server pleases...

> Sure it's configurable.  But your draft sets it up in the default case
> that "A broadcasted DHCPNETSCAN message SHOULD be broadcasted into a relay
> agent's other subnets."  (Actually, I just noticed that by default the
> draft wants all REPORTs to be broadcast too... so that one DHCPNETSCAN
> which is sent across your network results in potentially everybody on your
> network broadcasting back to you.... now there's an efficient DDoS attack
> on your entire DHCP infrastructure!)
	[MR>]  
	That's correct. That's why it should only be configurable and only
be used in closed networks that the administrator wants to tigthly control.
	The default value is on the server this case !! 
	Again: The operator of the server has the full responsibility of
what he is doing! Everything depends on the server implementation, that
gives the protocol its flexibility.

> > provide." (see chapter 5). This should of course also be mentioned in
> chapter 3.3. 
	[MR>]  Good suggestion.

	...... 
> 2) Device B Discovers & Requests (since the IP is now available, it was
> just released!) the now released 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.

> > main purpose of the discovery extension. It's a nice "side-effect"  
> Not to sound nasty, but if this isn't a purpose of the discovery
> extension, why is it stated as a goal of the draft? 
	[MR>] 
	I published the draft to show the possible potential of the
discovery extensions and to get some feedback on which of this possibilites
might be useful and which not. 
	A server implmentation may use the redundancy possibility or not.
It's up to the server. But I wouldn't restrict the protocol in a way that
usage of this possibility is not allowed. 
	The philosophy of the Discovery Extensions are: "The client provides
means that the server can use if he wishes." The client only reacts to
actions from the server. 

> Another general comment about the draft.  Offhand I think the
> DHCPCONFIGURE message is superfluous when there exists RFC 3203.  I don't
> see anything that that DHCPCONFIGURE does that DHCPRECONFIGURE can't do. 
> In the case of an "unconfigured" client, there's nothing that needs to be
> done except wait for the device to naturally Discover.  For an already
> configured device we can send a FORCERENEW, and the device will
> immediately transition to the Renewing state, causing it to perform a
> REQUEST/ACK sequence, at which point the device can reconfigure itself
> based upon the data in the new ACK packet.
	[MR>]  
	That's true. But there are the following limitations to the
mechanism in RFC 3203:

	--The client cannot get it's (new) configuration information to
other servers for redundancy (as it is possible with a broadcasted
DHCPREPORT).

	-- In the supervising case (the server sends a DHCPNETSCAN to see if
all its sheep are still in their right places in the network), using the
FROCERENEW mechanism would mean a four message exchange for every client!!
I don't like this very much since it produces a lot of unneccessary traffic.

	-- And again, there is no way to get informations about unconfigured
silent devices. 

	If FORCERENEW would also be able to set a "silent" device to the
INIT state, I would be happy with it 
	and DHCPCONFIGURE would indeed be superfluous (though I still
dislike the four message exchange, which is unneccessary when the server
starts communication). But unfortunately it doesn't.

	The Discovery Extensions are a different approach, please keep this
in mind. One shouldn't compare them too much to client-originated DHCP since
they follow different philosophies.

	Best Regards,
	             Markus

	-----Ursprüngliche Nachricht-----
	Von:	Kostur, Andre [SMTP:[email-masked]]
	Gesendet am:	Dienstag, 4. November 2003 18:57
	An:	'Rentschler, Markus'; [email-masked]
	Betreff:	RE: [dhcwg] ID's: DHCP Discovery Extensions 

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

---

From: "Kostur, Andre" <[email-masked]>
Date: Thu, 6 Nov 2003 09:03:09 -0800

> -----Original Message-----
> From: Rentschler, Markus [mailto:[email-masked]]
> Sent: Thursday, November 06, 2003 5:41 AM
> To: Kostur, Andre; [email-masked]
> Subject: AW: [dhcwg] ID's: DHCP Discovery Extensions
> 
> 
> 

Are you therefore saying that devices will have DHCPCONFIGURE disabled by
default?  As well as sending an initial DHCPDISCOVER?  (So by default the
client does _nothing_ on bootup?)

> there is a unregistered device") or any other appropriate 

So you're agreeing that if the device is performing standard DHCP anyway, we
already have the "discovery" feature?

> won't get any disadvantage to what they have now. 

Yes, they do.  They have the disadvantage of having to implement a more
complex state machine on the client side, as well as additional logic on the
server side.

> 	Others who want to use it get a lot of functionality 

So far I haven't seen a whole lot of additional functionality that isn't
already covered by other drafts and RFCs on the topic.

> 	The Discover Extensions would be easy to implement. 

Right now they are unimplementable in a standard way since the behaviour is
underspecified.

> 	No additional states in the client's state machine required. 

Not true.  There are a bunch more state transitions, and at least one more
state where the device has received a DHCPCONFIGURE causing it to transition
into a new State where the device emits a DHCPRELEASE and transitions into
another state where it emits a DHCPREPORT, where then it finally transitions
back into the Bound state.  Plus whatever state transitions and states would
be needed to express what the client is to do when it receives a NETSCAN in
each state.

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

> the client and the server...

It would only have to interact with DHCP in a rudimentary way.  All this
other protocol would need to do is cause the existing DHCP client to either
transition from the Bound to Renewing state, or possibly transition from any
state to the Init-Reboot state.  Leave the rest of the configuration up to
Standard DHCP.

> 	Both should be possible: configuration AND 

We already have a mechanism for reconfiguration.  Why reinvent the wheel,
which only adds additional overhead?

> be used in closed networks that the administrator wants to 

However your draft specifies that the default behaviour is to cause
broadcast storms across your entire network (and it even goes so far as to
suggest doing it periodically).  So, there's two possiblities here.  One is
that DHCPCONFIGURE is enabled on clients by default, thus only 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, or DHCPCONFIGURE is diabled on clients by default, and you need to
go and manually enable every client to support it (in which case why not
simply enable standard DHCP, and you get your discovery and reconfiguration
features anyway (assuming 3203 is implemented) )?

> gives the protocol its flexibility.

Famous last words.  Administrators will configure as little as possible to
get the service running.  They may not even see the "feature" of this
NETSCAN, so it will be left at its default values.  This server is then
deployed onto a broadband network with 200000 subscribers...... need I say
more?
 
> network that a certain client has a certain configuration.  

There's a big problem.  There is now two devices with the same IP address.

> means that the server can use if he wishes." The client only reacts to

Which is a fundamental change in the DHCP protocol.  Currently it's the
service that only reacts to actions from the clients (notwithstanding 3203).
 
> other servers for redundancy (as it is possible with a broadcasted

Not the client's reponsibility.  That is covered by the Failover draft.
 
> FROCERENEW mechanism would mean a four message exchange for 

Three message exchange, BTW: FORCERENEW->REQUEST->ACK

> 	-- And again, there is no way to get informations about 

If it's unconfigured, that's because it has failed a DHCP transaction (thus
the server has already heard from the device).  If it's silent, then it's
not doing DHCP at all anyway, so the NETSCAN will fall on deaf ears, and you
still won't get the REPORT.

> starts communication). But unfortunately it doesn't.

See above (3 message exchange, and a silent device isn't doing DHCP at all)

> they follow different philosophies.

Then it is a different protocol, and should be treated as such.

---

From: "Rentschler, Markus" <[email-masked]>
Date: Mon, 10 Nov 2003 19:19:21 +0100

[MR>] Comments inline...

> Gesendet am:	Donnerstag, 6. November 2003 18:03
> An:	'Rentschler, Markus'; Kostur, Andre; [email-masked]
	[MR>]  That wouldn't be useful. Of course at least one of the
mechanisms should be enabled. I suggest that by default both should be
enabled.

> state where the device has received a DHCPCONFIGURE causing it to
> transition into a new State where the device emits a DHCPRELEASE and
> transitions into another state where it emits a DHCPREPORT, where then it
> finally transitions back into the Bound state.  Plus whatever state
> transitions and states would be needed to express what the client is to do
> when it receives a NETSCAN in each state.
> 
	[MR>]  What you mean, could at most be described "transitional
states": An external event (DHCPNETSCAN, DHCPCONFIGURE) triggers immediate
actions (DHCPREPORT and internal things ). That are no stable states, whose
values are kept in some state variable. 
	Under a "state" i understand a stable state that waits for some
(external) event to change the state variable's value. 
	This is not the case with the Discovery Extensions.

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

> >       [MR>] 
> >       Both should be possible: configuration AND reconfiguration, 
	[MR>]  Sure, but there is no mechanism for server-originated
CONfiguration. That's what the draft is all about.

	[MR>]  
> suggest doing it periodically).  So, there's two possiblities here.  One
> is that DHCPCONFIGURE is enabled on clients by default, thus only 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.

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

> service that only reacts to actions from the clients (notwithstanding
	[MR>]  I would rather put it that way:  
	It is a fundamental EXTENSION to the DHCP protocol  :-)

	> network), using the 

	[MR>]  You're right, of course.

> >       The Discovery Extensions are a different approach, 
> > please keep this in mind. One shouldn't compare them too much to 
> > client-originated DHCP since they follow different philosophies. 
> 
	[MR>]  It does the same (configuring the client with ip and some
other parameters), 
	just in a slightly different way that offers some additional
opprtunities for network administrators.

	Regards,
	        Markus

---

From: "Kostur, Andre" <[email-masked]>
Date: Mon, 10 Nov 2003 10:51:24 -0800

> mechanisms should be enabled. I suggest that by default both should be

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)?

Oops.... reading the draft again... it actually specifies that DHCPCONFIGURE
SHOULD be disabled by default.  My oversight.  Which does mean that an
administrator would have to visit every device in order to enable
DHCPCONFIGURE.  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) ).

> 	This is not the case with the Discovery Extensions.

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

Offhand, I think there's still a state in there between sending a
DHCPRELEASE, and sending the DHCPREPORT.  I don't think you can have 1 state
transition sending two messages (at least there are no current state
transitions which emit 2 messages....)

> accepted the initial DHCPCONFIGURE or still uses it's old or 

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.

> 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.  Configuring a device to use DHCP to begin
with is beyond the scope of DHCP.

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

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

> > service that only reacts to actions from the clients 
> (notwithstanding
> > 3203).
> > 
> 	> FROCERENEW mechanism would mean a four message 
> exchange for every
> client!!    

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.  Instead
of the FORCERENEW attempting to do everything, it only triggers the client
to renew immediately, instead of waiting for the full lease time.  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.

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

---

From: "Kostur, Andre" <[email-masked]>
Date: Thu, 13 Nov 2003 09:32:36 -0800

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

So... in the absence of an authentication (of servers) mechanism (which
according to this draft, _isn't_ a requirement), both the discovery and
redundancy aspects of this draft are completely useless since devices won't
answer NETSCANs from anybody other than their lease-granting server?

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

Which would mean that devices which don't have a lease yet, cannot be
discovered by NETSCAN.
 
> What is your recommendation for the default settings from 
> your point of view

Recall that my opinion is that the Discovery Extensions shouldn't exist...
so my recommendation on what the default settings should be is fairly
obvious :)

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

Can you think of another DHCP option/behaviour which has a similar
restriction?

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

However, keep in mind that the last 6 messages are all already existing
messages and behaviours.  No new behaviours would need to be programmed into
DHCP Clients, Servers, or Relay Agents.  They are all very well defined and
implemented.  Particularly with regards to tearing down and reconfiguring
the IP stack.  Also keep in mind that network reconfiguration is (or should
be...) a fairly rare event.  Seven messages once in a blue moon is not an
issue.  (There's also another draft currently being discussed with could cut
it down to 5 messages).

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

Why is your lease info lost?  Either it's reloaded from stable storage, or
if the server goes up in flames, it's recovered from your failover partner.
(If your entire server room goes up in flames, then you've got bigger
problems than your clients rebooting).

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

You'd be surprised at how things can be misinterpreted. :)

> ----------------------------------------------------------------
> > accepted the initial DHCPCONFIGURE or still uses it's old or 
> > no ip address at all. 
> 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 

OK, so there's a bunch more logic and states on individual IPs that the
server must now maintain.

> the mechanism
> that DHCP should check via an ARP request if an IP address is 
> already in
> use.

ARP doesn't help if the device is on the other side of a router.... (and if
I recall correctly, the suggested method of detection for servers is ICMP
Echo.  ARP is suggested for _clients_ detecting duplicates).

> ----------------------------------------------------------------
> > > >       [MR>] 
> 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

Infinite lease.... two things.  One: your server admin shouldn't be using
infinite leases if the network configuration is going to change.  Two: RFC
3203.  A FORCERENEW would still cause the client to renew its lease
immediately.

> crashed and lost its lease information ? Or an additional 

Already addressed.  Either it's reloaded from stable storage, or recovered
from the failover partner.

> server is plugged
> onto a running network ? Or a network is going to be
> reorganized/reconfigured/altered without booting all clients ?

If you're reconfiguring the network, all of your clients are going to
effectively be rebooted anyway (from a networking perspective....).   And
3203 is still good for this....

> ----------------------------------------------------------------
> > > one mildly malicious user can emit a NETSCAN once an hour 
> and cause your
> >       I would like to get some ideas how this potential 
> > danger could be minimised. 
> 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.

PINGs are a lot more lightweight than a full DHCP exchange.  They also don't
involve broadcasting to everyone.

> ----------------------------------------------------------------
> > > > > 3) Device A REPORTs on that IP ? 
> > > >       [MR>]  
> 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 ?-)

That .001 is an eternity.   DHCP servers may have to deal with hundreds to
thousands of DHCP requests per second (in some environments).

> The next operation in the code would of course be setting up 
> the ip stack
> with the new parameters.

Right, but the DHCP server barely knows about this.  (If you have the
additional states in the DHCP server to remember that this IP is pending a
REPORT....).  Which leads to another (much less likely case):  What if a
device receives a CONFIGURE, emits the RELEASE, then keeps trying to REPORT
on the new IP, but the REPORTS keep getting lost?  That would result in a
client using an IP address that the server doesn't know about (the
configuration has timed out, thus the server is no longer holding aside the
IP).

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

And servers.... (and relays wouldn't need to be touched)

> I think it was designed on this premise:
> As much client-initiated behaviour as possible, even when the 
> intention is

Yep.  Much easier to change the server than the client (there's a lot fewer
servers out there than clients....)

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

However it's a seven message exchange where all of the implications are well
understood...
  
> ----------------------------------------------------------------
>  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.

Uh, _what_ complicated state machine?  Server sends a RECONFIGURE to client.
Server remembers that it has sent a RECONFIGURE to the client.  If the
client has not responded with a REQUEST, retry.  If a total timer has
expired, give up.  If a client responds with a REQUEST, note that the
RECONFIGURE has been answered, and do all the normal DHCP stuff.  That's a
pretty easy behaviour change.

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

3203 mandates the use of 3118.  There are no known implementations of 3118
on either a server or client.

> ----------------------------------------------------------------
> 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 device/topology detection in this case _only_ works if _every_ device
implements the Discovery Extensions.
 
> 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.

I don't think you've fully established that client-initiated communication
is that much of a problem.
 
> The redundancy mechanism is an additional goodie that the discovery
> mechanism COULD provide. 

Again, we already _have_ a redundancy mechanism.  DHCP Failover.

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

Problem is... that's not the only place that DHCP is being used.