>>>>> On Thu, 5 Feb 2004 17:40:44 -0800 (PST),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> My suggestion to the second point is that we should also ignore the
>> preferred lifetime if the valid lifetime is ignored due to the
>> two-hour rule.
> In my example of the incorrectly advertised prefix that the network admin
> wants to get rid of this actually makes it a bit harder.
> If the network admin advertised the prefix with valid=3 hours (decrementing
> in real time) and preferred=0 then if I've taken my laptop to
> a meeting for 1.5 hours when I come back the laptop will have
> StoredValidLifetime=7 days (whatever the original number was)
> StoredPreferredLifetime=1 day (whatever the original was)
> and receive packets with
> valid=1.5 hours
> preferred=0
> and as a result the lifetimes in the advertisement will be ignored and the
> (incorrect) prefix will remain preferred for a day.
> This is worse than being able to move the preferred lifetime to zero
> (thereby deprecating the prefix for future communication).
Hmm, good point. The above story can happen with the suggested
resolution and I agree that this is worse.
> I think following what is in the router advertisement should always be done
> (in order to give the network admin control) except in very specific cases.
> There is a specific case to ignore sudden drops in the valid lifetime
> but I haven't seen an equally strong argument for ignoring the preferred
> lifetime.
Okay, I reconsidered this issue.
(For reference, I've copied the options below I brought up before:)
1) update the preferred lifetime regardless of whether the valid
lifetime is accepted or not wrt the "two-hour" rule
2) update the preferred lifetime only when the valid lifetime is
accepted
If we take option 1, the preferred lifetime is always updated in non
DoS cases. In a DoS case, the preferred lifetime can be set to a very
short time (including 0). But this is not very harmful.
If we take option 2, the preferred lifetime can be accidentally kept
at a large value in non DoS cases, which is bad. In a DoS case, we
can avoid the DoS for the preferred lifetime *if the attack also
includes a too short valid lifetime*. The attack for the preferred
lifetime can still happen if it specifies a large value for the valid
lifetime.
So, I now think the correct option is 1. Unless someone makes a
different point, I'll revise the text accordingly.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
