Subject: IPv6 Prefix Deprecation Problem

From: "T.J. Kniveton" <[email-masked]>
Date: Thu, 01 Feb 2001 23:06:31 -0800

Hi,

I am looking through the Address Autoconfig (RFC 2462) and Neighbor
Discovery (RFC 2461) drafts, and there seems to be a bit of discrepancy
about deprecating prefixes.

Specifically, let's consider the scenario described in RFC 2461 on page
78-79. A prefix has been advertised with a lifetime of two months, a
machine is turned off on July 31st, then on Aug. 1st, it's decided the
prefix should expire on Sep 1st. The host is turned back during
September, at which point the prefix is deprecated, but the node's last
received advertisement indicates the prefix is valid until the end of
September. 2461 states:
    The only way to force a node to stop using a prefix that was
previously advertised
    with a long Lifetime is to have that node receive an advertisement
for that prefix
    that changes the lifetime downward. The solution in this example is
simple: continue
    advertising the prefix with a lifetime of 0 from September 1st until
October 1st.
However, RFC 2462 has stated that unless router advertisements are
authenticated, any router advertisement trying to expire the prefix
(which still has a few days, to most of a month, of validity left), will
just lower it to two hours.

Is it OK with everyone that a node that has been turned off for a while,
could possibly be *unusable* on a network for two hours? We can not say
that an admin will log into this machine and manually remove the prefix,
or that router advertisements after a network renumber will be
authenticated. Both of these make far too many assumptions.

Aside from whether this is "OK," there is inconsistency between these
drafts. 2461 does not seem to account for the DoS attack which 2462 is
trying to avoid.

Comments?
-- 
T.J. Kniveton
NOKIA Research Center
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 02 Feb 2001 22:26:25 +0900

>>>>> On Thu, 01 Feb 2001 23:06:31 -0800, 
>>>>> "T.J. Kniveton" <[email-masked]> said:

> authenticated. Both of these make far too many assumptions.

In this case, we can reasonably assume that a new prefix (with positive
valid and preferred lifetimes) is being advertised.  Thus, we have at
least one preferred address.  Also, in the scenario above, the old
prefix is being advertised with zero lifetimes, the old address is
immediately deprecated (note that the "two hours" protection described
in RFC 2462 is not applied to preferred lifetime.)  Consequently, we
would just use the (only) preferred address when we start a new
communication by the definition of the "deprecated" address, and would
not see any problems in a normal operation.

> drafts. 2461 does not seem to account for the DoS attack which 2462 is

No, we don't care about zero-lifetime attack in prefix (i.e on-link)
manipulation, which RFC 2461 describes.  We only care about the attack
that attemps to make a victim's *address* invalid.

Note that we can still send packets to default routers even if we
don't have any known on-link prefixes, while we can't make any
off-link communications if all the global addresses are invalidated.

Of course, you could say that this policy is "wrong", but at least the
two policies are not inconsistent.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 02 Feb 2001 09:41:15 -0600

I think "unusuable" is too strong.  There will presumably be newer
prefixes advertised and no rule makes the node ignore those.

Also, doesn't the node's stack need to allow for the possibility that
when it is powered back on, it is connected to a different link entirely?
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 02 Feb 2001 11:17:32 -0800

> not see any problems in a normal operation.

OK, thanks, that is clearer.

Isn't this still vulnerable to a desnial of service attack? If I only have
one global address and a malicious node deprecates my address, I can not
open any new connections. Granted, I can continue using the connections that
are open, but it still prevents further communication. I would assume that
whenever there are no valid prefixes, the node would send a router
solicitation. But if the attacking node is fast, it can deprecate prefixes
as soon as they're advertised.

> two policies are not inconsistent.

The distinction between deprecating a prefix and invalidating it was what I
was missing in my read of the draft. I still see a problem vis a vis the
zero-lifetime attack. Am I missing something?
-- 
TJ Kniveton
NOKIA Research

---

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 02 Feb 2001 11:57:39 -0800

[I am crossposting to Mobile-IP since I am throwing in some info about
mobiles]

> prefixes advertised and no rule makes the node ignore those.

OK, here is why I posted the message. We can certainly imagine good
implementations that handle this renumbering case without a hitch. However,
in reading the rules of the draft, I can imagine correct, and possibly even
reasonable, implementations that choke at this point. For instance, if my
implementation has a strong affinity for my primary global address as long
as it remains valid, and it thinks the address is valid for a couple more
hours, it might continue to try to use that address.

Some layer above IP is choosing the source address -- either the
application, or an upper network layer on its behalf. This layer "should"
[2462] choose a prefix that has a positive preferred lifetime remaining when
it opens a connection. Perhaps that "should" should change to "must".

What bothers me boils down to the fact that we have a VALID prefix, though
it may not be preferred. A deprecated address is still a valid address and
MAY be used to start new communication. Yet the autoconfig rules do not have
any way to remove this invalid address/prefix.

> when it is powered back on, it is connected to a different link entirely?

Good point. I didn't even get into the problems with mobile nodes. Imagine,
for instance the following twist:

The mobile node had one global address based on its home prefix. It was
turned off on July 31st. The mobile's Home Network was renumbered, as
described in RFC 2461, between August 1st and September 1st. Mappings from
the old prefix to the new prefix were removed from routers on September
15th. The old prefix is dead.

Now the mobile node is turned on, on September 25th, in a visited network.
It starts receiving router advertisements for the local link. It configures
a link-local care-of address. It wants to contact its Home Agent to register
a binding for its care-of address.

"I can't contact my home agent."
"I can't contact any routers on my home network to do Home Agent Discovery."
"My cached home address has not expired...but my home network has
disappeared."
"Help!"

Hmmm. This could be a problem. I am writing a draft to address possible
courses of action at this point..unless anyone can provide a good, clear,
obvious answer.

-- 
TJ Kniveton
NOKIA Research

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sat, 03 Feb 2001 14:36:32 +0900

>a binding for its care-of address.

	link-local care-of address?  are you sure you want to do that?  I hope
	this is typo of "global care-of address".
	(note that you can only contact correspondent nodes that is on-link
	to the mobile node)

	scope issue with mobile-ip6 is hairy...

itojun

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sat, 03 Feb 2001 13:38:51 -0800

>         scope issue with mobile-ip6 is hairy...

You caught me typing too fast. Instead of "link-local care-of address,"
I meant to say simply "care-of address," which would obviously be a
globally routable autoconfigured address using a prefix advertised on
the visited network link.

TJ

---

From: "T.J. Kniveton" <[email-masked]>
Date: Sat, 03 Feb 2001 13:38:51 -0800

TJ

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 05 Feb 2001 23:44:08 +0900

>>>>> On Fri, 02 Feb 2001 11:17:32 -0800, 

> as soon as they're advertised.

If you only have one global address, you can just use the address even
if the address has been deprecated.  RFC2462 says

   A deprecated address SHOULD continue to be used as a source
   address in existing communications, but SHOULD NOT be used in new
   communications if an alternate (non-deprecated) address is available
   and has sufficient scope.
(Section 5.5.4)

Note that the if-clause at the end of the sentence.

> zero-lifetime attack. Am I missing something?

Which zero-lifetime attack did you mean?  For the address lifetime,
the attacker can only make the address deprecated.  This is not a
significant attack as I said in the previous message and above.  For
the prefix (on-link) lifetime, the attacker can make all the prefixes
of a victim off-link.  However, since the victim still knows default
routers, it can just send packets to a router, and (if it is lucky
enough,) can make any on-link and off-link communications.

However, the attacker can also
- make all valid routers' lifetimes zero, or
- be a "blackhole" router.

I admit these attacks can be a real threat, and are diffcult to
protect.

					JINMEI, Tatuya

---

From: Mattias Pettersson <[email-masked]>
Date: Mon, 05 Feb 2001 10:03:20 +0100

> courses of action at this point..unless anyone can provide a good, clear,

Are your prefix lifetimes not supposed to be in the same order as the
renumbering period? If your renumbering takes one month, set valid
lifetime to one month for prefixes announces long before the renumbering
phase starts. In this way you won't end up in situations like this. 

Next, I wouldn't be sure that a Mobile Node would remember it's home
prefix lifetime if it was switched off.

One requirement that we came up to when writing Mobile IPv6 i-d v13 was
that the Mobile Node must somehow know its home prefix or a DNS name
representing the home prefix or home agents anycast address. How the
Mobile Node learns this is out of scope of the draft. Thus, the upper
layer that provides the Mobile Node with the home prefix in the first
place, must also provide the new renumbered home prefix in cases like
this when the Mobile Node is switched off during renumbering.

/Mattias