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

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 10 Sep 2012 11:02:17 +0000

I was going through RFC6704 (Forcerenew Nonce Authentication) along with original Forcerenew spec RFC3203. If I look at the original spec, I see that we can send Forcerenew to a host who has actually not got it's IPV4 address through DHCP but instead it has got some of the config parameters through DHCP using DHCP INFORM message. So as per original Forcerenew spec, client can send INFORM message as a result of receiving Forcerenew message.

But latest spec on NONCE authentication (RFC6704), I figured out that we are only talking about including FORCERENEW_NONCE_CAPABLE option in DISCOVER/REQUEST messages. We are not actually talking about INFORM callflow.

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.

Thanks,

Gaurav

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Sep 2012 12:05:03 +0000

On Sep 10, 2012, at 7:02 AM, "Gaurav Halwasia (ghalwasi)" <[email-masked]>
 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.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Sep 2012 20:39:25 +0000

I didn't say that FORCERENEW for DHCPINFORM clients was hard.   I said it would impact performance.   We would go from DHCPINFORM being a lightweight read-only operation to a heavyweight read/write operation.   I guess we could forgo the sync-before-ack logic of stateful DHCP, but this would add a lot of complexity to a performance-critical code section.

So yeah, from an implementation point of view, I don't really like this idea.   It seems trivial until you think about the impact it has either on performance or on implementation complexity.   If there's strong demand for it with a clear use case, then I think that's fine.    I wasn't able to tease one out of your rather dense message—could you try to state your use case in a short paragraph or two?

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Sep 2012 14:56:12 -0400

In message <[email-masked]>
Ted Lemon writes:
 
> > 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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Sep 2012 17:32:05 -0400

In message <[email-masked]>
Ted Lemon writes:
 
> I didn't say that FORCERENEW for DHCPINFORM clients was hard.  I said
> it would impact performance.  We would go from DHCPINFORM being a
> lightweight read-only operation to a heavyweight read/write operation.
> I guess we could forgo the sync-before-ack logic of stateful DHCP, but
> this would add a lot of complexity to a performance-critical code
> section.
>  
> So yeah, from an implementation point of view, I don't really like
> this idea.  It seems trivial until you think about the impact it has
> either on performance or on implementation complexity.  If there's
> strong demand for it with a clear use case, then I think that's fine.
> I wasn't able to tease one out of your rather dense message—could you
> try to state your use case in a short paragraph or two?

Use cases include: list of default routers changes, list of static
routes changes, list of nameservers changes.  etc.  That was in the
email as examples.

There is no need to make INFORM r/w.  For example, the client change
the list of default routers.

All that is needed is to maintain a list of host for which an inform
was sent and the nonce used.  Then send a FORCERENEW is any config
changes.  Optioanlly also keep a list of parameters sent to avoid
sending a FORCERENEW is none of the requested and provided parameters
had changed.

The minimal change is add the DHCPINFORM client and nonce to the
leases database (if you can call appending to a flat file a database)
and also keep that mapping in RAM.

A certain DHCP server performance would be vastly improved if a flat
file was not used as the database for the leases.

Curtis

btw- I sent the prior message as [email-masked] and I'm subscribed
  to this list as [email-masked] so its in the moderator queue.
  My bad.  I'll cancel and resend shortly.

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Wed, 12 Sep 2012 01:26:50 +0000

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:[email-masked]] 
Sent: Wednesday, September 12, 2012 12:26 AM
To: Ted Lemon
Cc: Gaurav Halwasia (ghalwasi); [email-masked]
Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)

In message <[email-masked]>
Ted Lemon writes:
 
> > included INFORM callflow. Well, I don't think this is deliberate, 
> do information requests-to do so would require a great deal more 

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

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Wed, 12 Sep 2012 01:45:30 +0000

Hi Ted,

Thanks for your comments.

I am talking about a deployment where we do create *session* database for hosts either based upon DHCP packet (Discover) or the normal IP packet in case few of the hosts has not done DHCP but instead has just DONE DHCP INFORM to get the config parameters. So in this kind of deployment we do anyways maintain the session(or binding in terms of DHCP) database on the box. Having said that I don't think storing client information is a problem (at least in this deployment). The only extra thing which we would need to store is a 'nonce'. 
So I think it will be really useful to have nonce in INFORM-ACK callflow as it will also help in the usability of Forcerenew as per 6704.

Thanks,
Gaurav 

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, September 12, 2012 2:09 AM
To: <[email-masked]>
Cc: Gaurav Halwasia (ghalwasi); [email-masked]
Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)

So yeah, from an implementation point of view, I don't really like this idea.   It seems trivial until you think about the impact it has either on performance or on implementation complexity.   If there's strong demand for it with a clear use case, then I think that's fine.    I wasn't able to tease one out of your rather dense message-could you try to state your use case in a short paragraph or two?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Sep 2012 02:52:42 +0000

> I am talking about a deployment where we do create *session* database for hosts either based upon DHCP packet (Discover) or the normal IP packet in case few of the hosts has not done DHCP but inste…

This is a heavy burden for the working group to take on for a small deployment.   Can you go into some detail about why this is the right way to solve the problem, and what bad things would happen if you didn't have FORCERENEW?

I'm sorry to be stubborn about this, but you're talking about a DHCPv4 protocol extension, and as you know from another draft that just went to the IESG, bandwidth is limited for the DHC working group—we've had presentation marathons at the last two IETFs, and I've had to chivvy presenters mercilessly just to avoid running over the generous time slots we've been given.   I feel really bad about doing that, and so I'm going to push back on proposals like this if I don't have a clear sense of their broad utility.   I say this sort of wearing my working group co-chair hat and sort of wearing my working group participant hat—as a participant, I don't see the broad utility in this proposal, and as a chair I see a lot of work in my future.   So please, give us a clear sales pitch for why we should feel good about taking on this work.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Sep 2012 02:56:54 +0000

Just to extend Ted's comments a bit - one issue is how long does the
server keep the information for the Inform only clients. When the
reconfigure-key is associated with a lease, we have a lease time; there is
no such item for Inform. This could be tied to
draft-halwasia-dhc-inform-refresh-time-opt (obviously it should be kept
longer than the refresh time), but that work might also reduce the need
for this -- at least it bounds the period where information may be stale.

While in theory having Reconfigure for Inform isn't a bad concept, it just
strikes me as overkill - do we really have a problem? Especially for IPv4
which we hope deprecate.

I'm also not sure how many clients do just Informs Š yes, there are lots
of clients that do send Informs but they've usually also done Discover/...

It is interesting that RFC 3315 accommodates Information-Request; not sure
why RFC 6704 didn't - I would guess because RFC 3318 didn't.

- Bernie

On 9/11/12 9:45 PM, "Gaurav Halwasia (ghalwasi)" <[email-masked]>
wrote:

>I am talking about a deployment where we do create *session* database for
>hosts either based upon DHCP packet (Discover) or the normal IP packet in
>case few of the hosts has not done DHCP but instead has just DONE DHCP
>INFORM to get the config parameters. So in this kind of deployment we do
>anyways maintain the session(or binding in terms of DHCP) database on the
>box. Having said that I don't think storing client information is a
>problem (at least in this deployment). The only extra thing which we
>would need to store is a 'nonce'.
>So I think it will be really useful to have nonce in INFORM-ACK callflow
>as it will also help in the usability of Forcerenew as per 6704.
>
>Thanks,
>Gaurav 
>
>I didn't say that FORCERENEW for DHCPINFORM clients was hard.   I said it
>would impact performance.   We would go from DHCPINFORM being a
>this would add a lot of complexity to a performance-critical code section.
>
>So yeah, from an implementation point of view, I don't really like this
>idea.   It seems trivial until you think about the impact it has either
>on performance or on implementation complexity.   If there's strong
>demand for it with a clear use case, then I think that's fine.    I
>wasn't able to tease one out of your rather dense message-could you try
>to state your use case in a short paragraph or two?
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Sep 2012 03:01:22 +0000

Ted Š I think you are spot on. We really have to prioritize and handle the
major issues and also focus on the future - IPv6 and getting there.
Marginal extensions to IPv4 should be very low priority (or even better
dropped).

- Bernie

On 9/11/12 10:52 PM, "Ted Lemon" <[email-masked]> wrote:

>> I am talking about a deployment where we do create *session* database
>>for hosts either based upon DHCP packet (Discover) or the normal IP
>>packet in case few of the hosts has not done DHCP but instead has just
>>DONE DHCP INFORM to get the config parameters. So in this kind of
>>deployment we do anyways maintain the session(or binding in terms of
>>DHCP) database on the box. Having said that I don't think storing client
>>information is a problem (at least in this deployment). The only extra
>>thing which we would need to store is a 'nonce'.
>
>This is a heavy burden for the working group to take on for a small
>deployment.   Can you go into some detail about why this is the right way
>to solve the problem, and what bad things would happen if you didn't have
>FORCERENEW?
>
>I'm sorry to be stubborn about this, but you're talking about a DHCPv4
>protocol extension, and as you know from another draft that just went to
>the IESG, bandwidth is limited for the DHC working group‹we've had
>presentation marathons at the last two IETFs, and I've had to chivvy
>presenters mercilessly just to avoid running over the generous time slots
>we've been given.   I feel really bad about doing that, and so I'm going
>to push back on proposals like this if I don't have a clear sense of
>their broad utility.   I say this sort of wearing my working group
>co-chair hat and sort of wearing my working group participant hat‹as a
>participant, I don't see the broad utility in this proposal, and as a
>chair I see a lot of work in my future.   So please, give us a clear
>sales pitch for why we should feel good about taking on this work.
>

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Wed, 12 Sep 2012 05:03:32 +0000

Hi Ted, Bernie,

Thanks for your thoughts. I think nobody can deny (including me) at this point of time that our focus should be on IPv6 and we should be willing to drop any minor DHCPv4 nits. I am with you on this. 

> It is interesting that RFC 3315 accommodates Information-Request; not sure why RFC 6704 didn't - I would guess because RFC 3318 didn't.

Are you sure you are referring to the correct spec. (3318.?) In case you meant RFC3203, I wanted to clarify that original Forcerenew spec indeed accommodates DHCP INFORM triggered by Forcerenew as RFC 3315 accommodates Information-Request. So i was surprised to find no reference of INFORM in 6704. This is want I wanted to clarify.  I am not particularly stressing to take this work right now but  still finding it little confusing to find that as per current standards we are saying that we can use Forcerenew Nonce Authentication for RENEW triggered by FORCERENEW but we still have to use original DHCP authentication for INFORM triggered by FORCERENEW.

Anyways thanks for your clarifications.

Thanks,
Gaurav
-----Original Message-----
From: Bernie Volz (volz) 
Sent: Wednesday, September 12, 2012 8:27 AM
To: Gaurav Halwasia (ghalwasi); Ted Lemon; <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)

Just to extend Ted's comments a bit - one issue is how long does the server keep the information for the Inform only clients. When the reconfigure-key is associated with a lease, we have a lease time; there is no such item for Inform. This could be tied to draft-halwasia-dhc-inform-refresh-time-opt (obviously it should be kept longer than the refresh time), but that work might also reduce the need for this -- at least it bounds the period where information may be stale.

While in theory having Reconfigure for Inform isn't a bad concept, it just strikes me as overkill - do we really have a problem? Especially for IPv4 which we hope deprecate.

I'm also not sure how many clients do just Informs Š yes, there are lots of clients that do send Informs but they've usually also done Discover/...

It is interesting that RFC 3315 accommodates Information-Request; not sure why RFC 6704 didn't - I would guess because RFC 3318 didn't.

- Bernie

On 9/11/12 9:45 PM, "Gaurav Halwasia (ghalwasi)" <[email-masked]>
wrote:

>DHCP) database on the box. Having said that I don't think storing 
>client information is a problem (at least in this deployment). The only 
>extra thing which we would need to store is a 'nonce'.
>So I think it will be really useful to have nonce in INFORM-ACK 
>callflow as it will also help in the usability of Forcerenew as per 6704.
>
>Thanks,
>Gaurav
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Sep 2012 11:28:10 +0000

3318 --> 3118. Sorry for typo.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Sep 2012 12:33:48 +0000

> Are you sure you are referring to the correct spec. (3318.?) In case you meant RFC3203, I wanted to clarify that original Forcerenew spec indeed accommodates DHCP INFORM triggered by Forcerenew as…

Okay, now I understand why you raised this now.   I still think it's not work we ought to take on right now, but it makes more sense now.

BTW, having given you a bit of a hard time about proposing new work for the working group, I would like to commend you for raising this on the mailing list between meetings.   Now is a really good time to be proposing new work, so that we can discuss it and decide whether it needs a presentation at the next IETF.   I hope others will follow your example, and that my reaction won't discourage this.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Sep 2012 23:13:20 -0400

In message <[email-masked]>
"Bernie Volz (volz)" writes:
>  
> Ted - I think you are spot on. We really have to prioritize and
> handle the major issues and also focus on the future - IPv6 and
> getting there.  Marginal extensions to IPv4 should be very low
> priority (or even better dropped).
>  
> - Bernie

Bernie,

FORCERENEW and Forcerenew Nonce Authentication apply to IPv6 as well
as IPv4.

A short draft saying the RFC6704 also applies to INFORM would not be a
big distraction.  A statement could even be short enough to be an
errata if we were willing to change RFC6704 with an errata (though I
don't suggest we do this as an errata).

Curtis

> >the IESG, bandwidth is limited for the DHC working group - we've had
> >co-chair hat and sort of wearing my working group participant hat - as a