Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Dec 2000 17:20:05 +0200

>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-masked]
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-masked]
--------------------------------------------------------------------

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 21 Dec 2000 10:39:46 -0500

> ICMPv6 Packet Too Big or Parameter Problem, causing V to be

Hello;

Why SHOULD they respond ? Having all recipient of a multicast stream respond
to something is not a good idea - you don't need an attack, as you would be always only
one bad packet away from disaster. In IPv4, multicast packet errors generally are not
responded to, and I do not see why things should be different here.

                                 Regards
                                 Marshall Eubanks

> Private WWW: http://www.iki.fi/jar. Standard disclaimers apply.

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : [email-masked]     [email-masked]

http://www.on-the-i.com http://www.buzzwaves.com

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 21 Dec 2000 19:56:08 +0200

> to something is not a good idea - you don't need an attack, as you would be always only

Well... because RFC 2463 section 2.4 point (e.2) wants you to?

The RFC names two exceptions to the never-respond-to-multicast rule: Packet
Too Big and Parameter Problem code 2. For the former there is a justification that
in this manner Path MTU selection may work for multicast as well. Note the
difference to v4, where longer packets would just have been fragmented
For Parameter Problem, no justification is given. But I agree, it is a
dangerous business...

Interestingly enough, for anycast the system can't support Path MTU selection
since point e.5 in the same RFC prohibits it.

Jari

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 21 Dec 2000 16:49:39 -0500

rfc1122 (host requirements) says:
 
         An ICMP error message MUST NOT be sent as the result of
         receiving:
	 ...
         *    a datagram destined to an IP broadcast or IP multicast
              address, or
         *    a datagram sent as a link-layer broadcast, or
	 ...

however, rfc2463 (icmpv6) weakens this:

    (e) An ICMPv6 error message MUST NOT be sent as a result of
        receiving:
	 ...
         (e.2) a packet destined to an IPv6 multicast address (there
	       are two exceptions to this rule: (1) the Packet Too Big
               Message - Section 3.2 - to allow Path MTU discovery to
               work for IPv6 multicast, and (2) the Parameter Problem
               Message, Code 2 - Section 3.4 - reporting an
	       unrecognized IPv6 option that has the Option Type
	       highest-order two bits set to 10), or
         (e.3) a packet sent as a link-layer multicast, (the exception
               from e.2 applies to this case too), or
         (e.4) a packet sent as a link-layer broadcast, (the exception
               from e.2 applies to this case too), or

The path mtu discovery case almost makes sense, and topologies which
could be abused into being "smurf" amplifiers may well be very rare in
practice.

[I do it odd that there's no rationale given for responding with a
"parameter problem"..]

					- Bill