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

3318 --> 3118. Sorry for typo.

- Bernie

On Sep 12, 2012, at 1:03 AM, "Gaurav Halwasia (ghalwasi)" <ghalwasi@cisco.com> wrote:

> 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; <curtis@occnc.com>
> Cc: dhcwg@ietf.org
> 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)" <ghalwasi@cisco.com>
> wrote:
> 
>> 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:Ted.Lemon@nominum.com]
>> Sent: Wednesday, September 12, 2012 2:09 AM
>> To: <curtis@occnc.com>
>> Cc: Gaurav Halwasia (ghalwasi); dhcwg@ietf.org
>> Subject: Re: [dhcwg] Reg RFC6704 (Forcerenew Nonce Authentication)
>> 
>> 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?
>> 
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 