Subject: [2462bis] preferred lifetime and the 'two-hour' rule

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 04 Feb 2004 16:38:20 +0900

While working on the rfc2462bis (stateless address autoconf) work,
I've found a new issue, and would like to hear opinions.

The current RFC2462 describes in Section 5.5.3 e) how the valid
lifetime of an autoconfigured address is updated, considering the
avoidance of DoS attack with too short lifetimes.  However, it doesn't
mention preferred lifetimes.  5.5.3 e) says:

    e) If the advertised prefix matches the prefix of an autoconfigured
       address (i.e., one obtained via stateless or stateful address
       autoconfiguration) in the list of addresses associated with the
       interface, the specific action to perform depends on the Valid
       Lifetime in the received advertisement and the Lifetime
       associated with the previously autoconfigured address (which we
       call StoredLifetime in the discussion that follows):
    ...

This document doesn't say anything about preferred lifetimes from this
part to the end of this section.

On the other hand, RFC1971, which was obsoleted by RFC2462, clearly
said in Section 5.5.3 how the preferred lifetime should be updated:

 d) If the advertised prefix matches the prefix of an autoconfigured
    address (i.e., obtained via stateless or stateful address
    autoconfiguration) in the list of addresses associated with the
    interface, set the preferred timer to that of the option's preferred  <---
    lifetime, and set the valid lifetime to that of the option's valid
    lifetime.

I guess this part was unintentionally dropped in RFC2462 while we
concentrated on the DoS avoidance.

If so, it should make sense to recover this part in rfc2462bis.
Possible options include:

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
3) leave this as implementation dependent

I don't think option 3 is the way to go, since RFC1971 clearly
mentioned the preferred lifetime.

The KAME/BSD implementation behaves as option 1.  However, it seems to
me that option 2 makes much more sense because a rejected valid
lifetime indicates a possibility of attack and the other parts of
the information may then be bogus as well.  And, in fact, item 2 of
5.5.3 e) says:

       2) If the StoredLifetime is less than or equal to 2 hours and the
          received Lifetime is less than or equal to StoredLifetime,
          ignore the prefix,...

that is, it specifies ignoring "the prefix", not just "the valid
lifetime".

What do others think?  As I already indicated, I'd propose to revise
the text clearly with option 2 above.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2004 10:10:37 +0200

> part to the end of this section.

Oops. This could cause all addresses to go deprecated. That in itself
may not be too dangerous, however, since according to 5.5.4 you must be
able to still use deprecated addresses even on new connections if there
are no other available addresses. But I agree that it would be good to
avoid this.

> the information may then be bogus as well.

I agree. Option 2 sounds right.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Wed, 04 Feb 2004 10:17:44 +0100

In your previous mail you wrote:

   The current RFC2462 describes in Section 5.5.3 e) how the valid
   lifetime of an autoconfigured address is updated, considering the
   avoidance of DoS attack with too short lifetimes.

=> the DoS attack is about valid lifetime only because when a valid
lifetime is dropped to zero an implementation can (IMHO it is in fact
a SHOULD) kill all connections using a now unvalid address.
The behavior for zero preferred lifetime is far less drastic ("deprecated"
addresses are not used for new "connections" when there are other
available addresses) and (IMPORTANT) we need for multi-homing to be
able to play with preferred lifetimes.

   However, it doesn't mention preferred lifetimes.  5.5.3 e) says:

       ...

=> this is on purpose.

   
   
=> I agree. I am in favor of 1 or 2 with a little preference for 1
which seems more logical (I suggest to introduce a notion of
valid prefix information and to make prefix informations which don't
follow the two hour rule invalid).

=> we agree.

  And, in fact, item 2 of
   5.5.3 e) says:

=> s/prefix/prefix information/ ?

=> same comment.

=> please proceed.

Regards

[email-masked]

---

From: "S. Daniel Park" <[email-masked]>
Date: Thu, 05 Feb 2004 11:35:53 +0900

> the text clearly with option 2 above.

To reduce logically redundancy, KAME just omitted "two-hour" rule IMHO.
So I think you can propose both of them to clarify this rule with high
preference
for (2). 

Hope this helps...

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, Samsung Electronics.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 05 Feb 2004 12:00:27 +0900

>>>>> On Thu, 05 Feb 2004 11:35:53 +0900, 
>>>>> "S. Daniel Park" <[email-masked]> said:

> To reduce logically redundancy, KAME just omitted "two-hour" rule IMHO.

What do you mean by "omitted 'two-hour' rule"?  KAME implements the
two-hour rule just as specified in RFC2462 with one exception:
omitting the following part of 5.5.3 e)

       2) If ...(snip) and the

since this condition is "logically redundant" as already discussed in
the wg.

(but the details of the KAME behavior about the two-hour rule itself
is not directly related to the main point in this thread.  So let's
stop discussing this particular point in this thread)

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 05 Feb 2004 12:19:46 +0900

>>>>> On Wed, 04 Feb 2004 10:17:44 +0100, 
>>>>> Francis Dupont <[email-masked]> said:

   

> => this is on purpose.

I know the rationale why the two-hour rule only affects the valid
lifetime.

Perhaps I was not clear enough in the previous message, but my point
is that RFC2462 doesn't say **anything** about preferred lifetime
update.

To make the story simple, let's forget the DoS issue and the two-hour
rule for now.  Assume we receive a valid RA containing a prefix
information option, and the processing the RA reaches at 5.5.3 e).
Also assume the valid and preferred lifetimes of the prefix
information are long enough so that I don't have to worry about a DoS.

Now please re-read 5.5.3 e) carefully.  It is very clear that we
should reset the valid lifetime to the advertised valid lifetime.  But
we cannot be sure how we should do about the preferred lifetime
because 5.5.3 e) doesn't say anything about the preferred lifetime.

Of course, a common sense would suggest that we also reset the
preferred lifetime to the advertised value, and I believe all
implementations work this way, at least in normal (i.e., non-DoS)
cases.  Still, it's just a guess; RFC2462 doesn't say anything about
this point.

So my first point is that we should clearly specify how the preferred
lifetime is updated in 5.5.3 e) of rfc2462bis, mainly for normal
cases.  My second point is what we should do about the preferred
lifetime when the valid lifetime is ignored due to the two-hour rule.

My suggestion to the first point is that the preferred lifetime should
basically be reset to the advertised value (of course!).

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.

Hope I'm clear this time.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 05 Feb 2004 12:25:11 +0900

>>>>> On Wed, 04 Feb 2004 10:10:37 +0200, 
>>>>> Jari Arkko <[email-masked]> said:

> are no other available addresses. But I agree that it would be good to

(I'm not objecting to this particular view, but)

To make the point clearer, my main point was not how to avoid "DoS"
for preferred lifetime.  My point was RFC2462 didn't say anything
about the update of the preferred lifetime, even for normal cases.
(See my response to Francis for more details)

					JINMEI, Tatuya

---

From: "S. Daniel Park" <[email-masked]>
Date: Thu, 05 Feb 2004 13:27:41 +0900

> since this condition is "logically redundant" as already discussed in

It's my fault. I said what you say... and I may lost track of this
point.

Danel

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 5 Feb 2004 17:00:58 -0800 (PST)

> the information may then be bogus as well.  And, in fact, item 2 of

I'm trying to understand the utility/danger scale here.

An operational possibility is that somebody accidentally 
configures an incorrect prefix in a router and advertises that with the
default lifetimes (which are greater than 2 hours).
When that is detected a minute later the operator can
 - drop the valid lifetime on the hosts down to 2 hours (by starting to
   advertise the prefix with a 2 hour valid lifetime which decrements over
time)

If we take alt #1 then the preferred lifetime can be immediately dropped
to zero, which will stop the incorrect prefix from being used as a source
address for new communication (which is good).

Does alt #2 mean that the preferred lifetime would be 2 hours?
Or that the preferred lifetime could be announced as zero as long as the
valid lifetime is annouced with an acceptable value?
I think you are suggesting the second one.

And on the danger scale,
with alt. #2 an on-link attacker can cause immediate deprecation by
advertising the prefix with a valid lifetime = 3 hours and a preferred
lifetime = 0, so I don't think it makes a difference whether we choose
#1 or #2. 

I must be missing something.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 5 Feb 2004 17:40:44 -0800 (PST)

> basically be reset to the advertised value (of course!).

Yes!

> preferred lifetime if the valid lifetime is ignored due to the

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).

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.

> This issue was originally posted by Ken Powell in February 2000:

> I was able to force the preferred lifetime to zero by reconfiguring
> a router to send advertisements with near-zero lifetimes, but the
> valid lifetime couldn't be reduced below two hours. 

Question: did advertizing the prefix with both lifetimes = 0 not
mean that the hosts stopped thinking that the prefix was on-link?

The intent was that the 2-hour rule only apply to address autoconfiguration
and not to the on-link'ness of the prefixes. That is why it is specified
in RFC 2462 and RFC 2461 is silent on the issue.

Thus advertising an existing prefix with both lifetimes=0 should remove it
from the on-link prefix list (RFC 2461) but keep the addresses as deprecated
from 2 hours (RFC 2462).

Perhaps this is something we should look into clarifying?

  Erik

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 06 Feb 2004 11:46:07 +0900

>>>>> On Thu, 5 Feb 2004 17:40:44 -0800 (PST), 
>>>>> Erik Nordmark <[email-masked]> said:

> (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.

> but I haven't seen an equally strong argument for ignoring the preferred

Okay, I reconsidered this issue.

(For reference, I've copied the options below I brought up before:)

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 06 Feb 2004 12:02:36 +0900

I changed the subject because I believe this is a separate issue.

> mean that the hosts stopped thinking that the prefix was on-link?

Ahh, another good catch.  RFC2461 clearly says this point:

   Stateless address autoconfiguration [ADDRCONF] may in some
   circumstances increase the Valid Lifetime of a prefix or ignore it
   completely in order to prevent a particular denial of service attack.
   However, since the effect of the same denial of service targeted at
   the on-link prefix list is not catastrophic (hosts would send packets
   to a default router and receive a redirect rather than sending
   packets directly to a neighbor) the Neighbor Discovery protocol does
   not impose such a check on the prefix lifetime values.
(Section 6.3.4)

So, this is actually a non-issue.  And, in fact, I've implemented the
prefix information processing this way, but I totally forgot it...

We may probably want to add a similar note in rfc2462bis, but my
current impression is that the note in RFC2461 is enough.

So, I'll basically do nothing on this.

Thanks,

					JINMEI, Tatuya