Subject: Re: [dhcwg] Lifetime option (draft-ietf-dhc-lifetime-00.txt)

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Jul 2004 10:36:18 -0400

Personally, I think that if one is trying to contact a DHC server, and
none respond, there should be a generic algorithm used for
retries. I.e., the case for this option should not be any different
(for say) the case where one first boots, and no DHC server responds,
or when one fails to renew an address after an address expires.

I.e., isn't there already a generic retranmission with backoff and
some upper limit? Why not just do the same? Is there a need for
multiple different algorithms?

Thomas

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Stig Venaas <[email-masked]>
Date: Tue, 6 Jul 2004 15:07:17 +0200

> multiple different algorithms?

You're right. I've looked more carefully at RFC 3315, and the obvious
thing is to follow the same rules. It specifies how a client should
send messages (including backoff) and we're after all not changing the
DHCP protocol.

I suggest the following text for the next version:

   Before making the request it MUST wait for a random amount of time
   between 0 and INF_MAX_DELAY.  INF_MAX_DELAY is defined in [RFC 3315].

   Then it can make the DHCP request to update the configuration.  The
   message MUST be created and transmitted according to [RFC 3315].  E.g.
   for an Information-request message it must be done according to the
   rules for creation and transmission of Information-request messages in
   section 18.1.5 of [RFC 3315].

Any other comments on the draft are welcome. I'm hoping the next version
may be the final one, I don't think there's much more that can be said
about this simple option...

Stig

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Jun 2004 08:37:38 -0700

On Jun 29, 2004, at 4:14 AM, Stig Venaas wrote:
> I think it might be better to retry. The retry interval could be a
> function of the lifetime. The reason I didn't in the current version,
> is that I was worried what would happen if someone sent a forged reply
> with say a lifetime of 1s.
>
> What do you think? Should there be some retry? What should the
> function be?

I think it's reasonable to retry.   I don't think that forgetting the 
lifetime if one is not heard in a subsequent reply is a good idea, 
because it's likely to lead clients into a stagnant state where they 
never recheck.   You can do a perfectly good DoS attack that way as 
well.   I think it would be fair to say that a lifetime of zero should 
be discarded, and perhaps the previous lifetime, if any, should be 
retained in that case.   As for what happens if the client gets a 
lifetime of 1s, I don't know.   You could add a really hairy protocol 
for managing timeouts, but I'm not sure it's worth it.   For example, 
you could say that if we had a lifetime of n, then if we subsequently 
get a lifetime that is less than n/2, we will ignore it.   Or we will 
use a lifetime of n/2.   But of course then you have to go down the 
path of considering all the possible legitimate reasons why the 
lifetime might drop precipitously, and make sure that if the prefix 
changes you forget the old lifetime, and like that, and I think it just 
gets too hairy.  I think creating a situation where you get significant 
amplification from a DoS attack based on short lifetimes would be 
pretty challenging.