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

["Gaurav Halwasia (ghalwasi)" <[e-mail]>]

Hi Curtis,

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

Thanks for the reply and infact I do have a use-case (which I will reply separately on this thread) and that's the reason I was exploring for this. Yes, I was indeed thinking about writing a short I.D for this but just thought to get some views on dhc/authors. So I will submit it soon. I do think this this proposed extension will further help the usability/deploy ability of Forcerenew as per  Nonce Authentication.

Thanks,
Gaurav
-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Wednesday, September 12, 2012 12:26 AM
To: Ted Lemon
Cc: Gaurav Halwasia (ghalwasi); [e-mail]
Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)


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