>There are two possible meaning for "DoS using ICMPv6 too big".
> - victim node cannot use larger MTU size for destinations, because of
> forged ICMPv6 too big from a bad guy.
> since IPv6 minimum MTU is 1280, the situation is much better
> than IPv4 case.
> - if the victim node is careless, the node will cache path MTU
> discovery results as many as possible. bad guy can inject lots of
> forged ICMPv6 too big messages, to chew up memory space on the victim
> node.
>the attack is easy and the problem is real.
Aah, I see... but I didn't actually even think yet of
the problems you mention. Those seem bad as well, but
here's what I was thinking:
A multicast group X contains the receivers R1, R2, ... RN.
The victim node is V - not necessarily anything to do with
X. The attacker is A. All nodes are different. Now, attacker A
sends a multicast packet with source = V and destination = X.
As the receivers R1 to RN or routers close to them receive the
messages, they complain about the message and ALL respond using
ICMPv6 Packet Too Big or Parameter Problem, causing V to be
flooded with messages.
In the above, the "complaining" has to do with either MTU
size or with a parameter problem as outlined in the exception
to rule e.2 in section 2.4 of RFC 2463. The MTU size then
has to be really too large, meaning that the attack can be
launched only if the receivers have smaller MTUs than what
the networks from A can carry. The parameter problem can
be caused simply by adding Destination Option header with an
option 10xxxxxx where xxxxxx is an unknown option number.
I'm not sure if I've missed something that prevents an
attacker from doing this. But if they can do this,
it is very hard to prevent the consequences since (a)
there is amplification involved, (b) each ICMPv6 sender
sends just one packet so rate limitation won't help, and
(c) the victim's pipe may be full because of the messages
and therefore any policies the victim may have on throwing
out them won't help.
What isn't clear to me though is for instance, which
nodes can send such multicast traffic like this. I
would assume at least those who are on the same network
with the real sender of the group, and at least when
the V is the same as the real sender. But how far beyond
this you can take the attack?
Jari
----
Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480
Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: [EMAIL PROTECTED]
Private WWW: http://www.iki.fi/jar. Standard disclaimers apply.
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
