Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Ted Lemon writes:
 
> On Sep 10, 2012, at 7:02 AM, "Gaurav Halwasia (ghalwasi)" <[e-mail]>
>  wrote:
>  
> > Is there any deliberate reason why we have not talked about and
> > included INFORM callflow. Well, I don’t think this is deliberate,
> > and In my opinion Forcerenew Nonce Authentication should be
> > applicable to the INFORM-ACK call flow as well. Including INFORM-ACK
> > is important. Appreciate if you can share your thoughts on this.
>  
> In general we don't expect DHCP servers to keep track of clients that
> do information requests—to do so would require a great deal more
> effort on the part of the DHCP server.  Consequently, there's no
> client record on which to store the nonce, and the DHCP server doesn't
> know to send the client a FORCERENEW.


With the exception of the massively bridged enterprise (a real bad
idea IMHO, but all too common due to IT ignorance) and the highly
centralized DHCP server with relays (also done in enterprise), there
is no need for more than a few hundred bits of state to keep track of.
Of course when the database is a flat file appended to (lease file),
its a little less efficient, but doable.

Regarding the centralization with excessive use of relays, rather than
centrralize control, delegating prefixes and therefor better
distributing DHCP server functionality would help.  Having a better
database than a flat file is also a real good idea IMHO, but that is
an implementation issue, not a protocol problem.

Transport equipment routinely keeps persistent state for tens of
thousands of SNC (usually in flash) so that a crash of the control
processor only affects new circuit setups.  Even this is not hard and
the problem for the DHCP server is a lot easier.

You'd need state for any DHCPINFORM requests with no lease as well as
those with a lease.

Maybe applicability to INFORM-ACK can be made optional (SHOULD).  It
would be really nice to get a FORCERENEW if the default routers list,
or static routes list, or DNS nameservers, or ... etc, are learned and
have changed but the addresses are configured.  In a way this isn't a
renew but rather a repeated request for parameters.

Right now AFAIK if the default router list changes or any parameter
but not the set of addresses, each client has to be manually be poked
to repeat the DHCP request.

So part of the question is "is this useful".  The answer is clearly
"yes".  The second part of the question is "is it hard to support".
Ted says yes, I say it shouldn't be but I'm not supporting any DHCP
server code.  Making it a SHOULD allows for software that doesn't do
Forcerenew Nonce Authentication on INFORM-ACK but also allows server
and client software to support it and use it if the other side
supports it.  A SHOULD also says "would be nice".

Note that RFC3203 already suggests that client who "obtained a network
address through some other means" but sent a DHCP INFORM resend that
INFORM if a FORCERENEW is received.  There is an absense of mention of
INFORM in RFC6704, and RFC6704 only says what should be done on an
"initial DHCP ACK".  RFC6704 doesn't explicitly say that
FORCERENEW_NONCE_CAPABLE can not be sent with INFORM but it does say
is "A DHCP client indicates DHCP Forcerenew Nonce Protocol capability
by including a FORCERENEW_NONCE_CAPABLE (145) option in DHCP Discover
and Request messages sent to the server."  It would not be such a big
deal to create a document that updates RFC6704 to indicate that
FORCERENEW_NONCE_CAPABLE could also be sent on DHCP INFORM for the
case in RFC3203 where a client "obtained a network address through
some other means".  Otherswise, those clients would need a configured
key while others could learn the key in a DHCPACK with
Auth-Proto=Forcerenew-Nonce.

This could be a very short document because it updates one sentence in
RFC6704 "3.1.1.  Forcerenew Nonce Protocol Capability Option" (cited
in paragraph above) and adds a reproduction of " Figure 2: Timeline
Diagram of Messages Exchanged between DHCP Client and Servers Using
the Forcerenew Nonce Authentication Protocol" that substitutes
DHCPINFORM for DHCPREQUEST or states "DHCPREQUEST or DHCPINFORM".

An implementation could decide to support RFC6704 but not to support
the update to RFC6704 in this new document.  Did Gaurav volunteer to
write it?

Curtis