Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT

On Nov 9, 2004, at 5:34 PM, Bernie Volz wrote:
> Today, without this option, there is no value. So, it is up to the 
> client to
> decide when it will refresh this information.

Right.   That's why we need this draft.   The protocol is slightly 
broken without this draft.

> With the introduction of the lifetime option, I still think it is up to
> clients to decide what values they'll accept and when they'll refresh.

Right.   And I am suggesting that we give client implementations a 
recommendation as to what the maximum value for this trigger is that 
they should use.   Actually, I guess I'm suggesting that we give the 
clients a requirement, but I'd be okay with making it a recommendation, 
like "clients SHOULD use a value of 1 day if the value is greater than 
one day."

> So, while we COULD have an upper bound, I don't see that this is that
> critical.

I didn't say it was critical.   However, I think it is useful.

> Note that the opposite argument for not needing a lower bound could 
> also be
> made, but I think there's much more value in that since we don't want 
> it
> easy to cause a DoS attack because based on the above language, a 
> client
> WOULD refresh its information.

A lower value doesn't help you to do a DoS attack, because there is no 
amplification (well, unless your client is broken and retransmits 
continuously if it gets a value of zero, but we could fix that by 
setting the minimum value to 1, or 15, and pointing out why it's 
important to enforce this limit).   However, I think it was Ralph who 
pointed out that this is not a good idea, because unlike a DNS TTL 
which simply causes data to be discarded, this causes a packet to be 
transmitted.   So I'm not arguing for a lower minimum value anymore.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg