This issue was originally posted by Ken Powell in February 2000:
====================== begin citing ============================
I recently ran some experiments in our lab to see how our IPv6
implementation responds to sudden network topology changes.
In the course of these experiments, I caused the prefix from one
LAN (LAN A) to be advertised on the other LAN (LAN B). As expected,
all communications between LAN A and LAN B died immediately. The
hosts on LAN B treated the hosts on LAN A as on-link. I could not
restore communications until both the preferred and valid LAN A
prefix lifetimes expired on LAN B's host systems.
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. This behavior
follows RFC 2462 section 5.5.3:
(snip)
Obviously I could easily reset IPv6 on each of the three hosts
in our lab to clear this problem. I'm concerned about something
like this happening on a corporate network where LAN B has
hundreds of client nodes connected to servers that reside on
LAN A. Assuming nobody bothered to configure ipsec on the
network yet, a malicious attacker could disrupt all the clients
by sending a router advertisement on LAN B with LAN A's prefix.
I know of nothing a network administrator can do to recover in
less than two hours short of resetting IPv6 on each of the
client systems (probably with reboots).
The above rules from RFC 2462 were intended to block a denial of
service attack where a single router advertisement could be used
to cause all prefixes to expire. It looks like these same rules
make the attack I outlined more effective than it otherwise would
be.
====================== end citing ============================
The DoS attack itself is actually covered by draft-ietf-send-psreq-04
(4.2.5 Bogus On-Link Prefix), (and the attack itself is not related to
2462,) so my proposed resolution for this was "do nothing".
However, we may still want to note this since his another point is
that the attack can be more effective due to the "two-hour" rule
specified in RFC2462. I re-read the discussion and found someone had
pointed out a possible workaround for this is to use proxy-ND. I
believe there is an easier workaround (that no one said before):
override the prefix (of the other network) with the L-bit being zero.
Still, this may be a minor attack that we can ignore in rfc2462bis.
So my first question is: should we describe the issue since the attack
can be more effective by a rule described in rfc2462(bis)? Or can we
simply ignore this case?
My next question is: if we should describe the issue, does it make
sense to describe either or both of the workarounds? If only one is
suitable, which one?
My current impression is we can simply ignore this case.
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
--------------------------------------------------------------------
