>RFC 2463 section 2.4 (e) specifies that Packet Too Big can be sent as a
>reply to a multicast message. Is this a source of a DoS problem? I.e.
>send a message with a large MTU to a large multicast group, lie about the source
>address, and flood real node with the forged source address with lots of traffic.
>All this with the cost of sending a single packet.
>
>Rate limitations are discussed in part (f) but I don't think that helps
>in this situation as each individual recipient would only be sending
>one ICMP message.

        Yes, there is DoS possibility with ICMPv6 too big messages.

        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.

        (from here, i'll use UNIX-oriented terms)
        there are two workarounds possible:
        - we can verify ICMPv6 too big messages by using information left in
          pcb (address/port pair), and the original packet presented in ICMPv6
          too big message.  note that this works for conneted pcb only
          (tcp socket is okay, udp/raw socket is harder).
        - to remedy the latter problem, we can set an upper limit to the
          number of routing entries generated by ICMPv6 too big messages.

        for netbsd/openbsd and recent KAME code (bsdi/netbsd/openbsd), we
        do have DoS prevention code.  not sure if it is complete - we need
        some torture-tests.

>The same situation exists also for the Parameter Problem ICMP message.

        ICMPv6 redirect has similar issue as ICMPv6 too big, and we can remedy
        the problem by using similar "upper limit" technique.  could you please
        give some more detail with parameter problem?

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

Reply via email to