Jari Arkko wrote:
> >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.
>
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
>
> 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]
> --------------------------------------------------------------------
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 PROTECTED] [EMAIL PROTECTED]
http://www.on-the-i.com http://www.buzzwaves.com
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
