[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(usagi-users 00689) Re: Updating address lifetime (again)
- To: <usagi-users@xxxxxxxxxxxxxx>
- Subject: (usagi-users 00689) Re: Updating address lifetime (again)
- From: Pekka Savola <pekkas@xxxxxxxxxx>
- Date: Mon, 20 Aug 2001 10:46:36 +0300 (EEST)
- In-reply-to: <Pine.SOL.4.30.0108171127070.1557-100000@kiuru.cs.tut.fi>
- Reply-to: usagi-users@xxxxxxxxxxxxxx
On Mon, 20 Aug 2001, Alakoski Teemu wrote:
> I didn't get any answers last time, so I'll try once more. There was also
> a little mistake with lifetimes:
>
> If I specify a valid lifetime of 7300 seconds or more on router, address
> lifetimes on hosts is updated nicely every time new RA arrives.
>
> But if valid lifetime is 7200 seconds or less, lifetimes on hosts just
> decrease towards zero. Finally when zero (preferred lifetime) is reached,
> new lifetimes are updated from incoming RA. But again RAs are not accepted
> until preferred lifetime is zero and so on...
>
> I didn't test what is the exact time when behaviour change. But it is
> between 7300 and 7200 seconds.
>
> This happends at least with usagi-20010806-linux24 and with
> linux24-2.4.9-usagi-20010817.patch.
This _might_ be a bug in "TWO_HOURS" rule, see
addrconf.c:addrconf_prefix_rcv. Also see RFC2462 5.5.3. e). (this has
been updated slightly by so-called "Jim Bound rule" afterwards)
I don't spot it right out though; this:
--8<--
if (!update_lft) {
if (valid_lft > TWO_HOURS ||
valid_lft > ifp->valid_lft) {
update_lft = 1;
--8<--
_seems_ to be proper. If you advertise 7200 seconds, and valid lifetime
drops below that, it should be updated. But if you advertised e.g. 600
seconds, it would be updated only after StoredLifeTime drops below 600
seconds.
So, I'm assuming this is might be a problem in your testing methodology
(made advertised lifetime really low and didn't wait long enough).
The two hour rule(s) don't exist in stock kernel; probably should.
I'm grateful for mentioning this though, as it made me look at the ndisc
code and spot at least one RFC2462 incompliancy: you can DoS systems by
advertising Lifetime 0 (the address will be removed immediately). This,
and other DoS'es by short, unauthenticated advertisements, is what the
two-hour rule has been set to prevent:
lifetime = ntohs(ra_msg->icmph.icmp6_rt_lifetime);
[...]
if (rt && lifetime == 0) {
ip6_del_rt(rt);
rt = NULL;
}
This check should be removed; it's left-over from RFC1971 days when the
two-hour rule didn't exist.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords