Suresh Krishnan said:The ICMPv6 specs is pretty careful on Error Messages in response to multicast packet.
On Wed, 10 Mar 2004, Stephen Sprunk wrote:
Suresh Krishnan said:
Aha. That makes more sense to me. But why should we point to justWait a minute... Now we're talking about prohibiting ANY multicast app
ICMPv6 Echo request? Pretty much all data packets which need an
ack can be used for this attack. It could be any protocol, not
just ICMPv6. Anyway all the more reason for a MUST NOT.
from responding unicast to multicasted data? That's a basic part of
functionality that is assumed in many apps!The problem is not about apps responding unicast to multicast data. It is
Can someone explain why we're looking for a different solution to this
behavior for IPv6 when the IPv4 behavior is already set in stone? For
apps which may not even be aware which version they're using, why should
IPv6 not respond in some or all cases when IPv4 always does?
specifically only about apps sending unicast ICMPv6 Echo replies in
response to ICMPv6 echo requests sent to multicast addresses. Everything
else (all data packet behavior) is not under discussion here.
You pointed out that ICMP echo is not the only protocol this attack can (supposedly) use; my argument is that turning off ICMP echo replies is only useful if we prohibit all other apps from replying as well. Given the noted holes in other aspects of ICMP that still MUST respond in error conditions, we're just shifting the problem around without making it any more difficult for attackers. If they can't flood someone with Echo Replies, they'll just flood someone with Destination Unreachables (or some other response) -- assuming, of course, they find a way around RPF.
2.4. Message Processing Rules
(e) An ICMPv6 error message MUST NOT be sent as a result of
receiving:
...
(e.3) 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.4) a packet sent as a link-layer multicast, (the exception
from e.3 applies to this case too), or (e.5) a packet sent as a link-layer broadcast, (the exception
from e.3 applies to this case too), or (e.6) a packet whose source address does not uniquely identify
a single node -- e.g., the IPv6 Unspecified Address, an
IPv6 multicast address, or an address known by the ICMP
message sender to be an IPv6 anycast address.I find it contradicting to be this careful for error conditions while to easier to generate non-error condition reply SHOULD be sent.
I agree that multicast ping is useful tool and would not like to totally get rid of it. Still it is dangerous in case of large multicast groups.
How about the following wording:
An Echo Reply MUST be sent in response to an Echo Request message
sent to an IPv6 multicast address. By default hop-limit IPv6 header
field MUST be set to value 1 [on non-router hosts?]. The hop-limit
SHOULD be administratively configurable. Hop-limit limitation is used to
prevent Echo Reply message storms on large multicast groups.
If Echo Reply message is sent in responce to an Echo Request message sent to an IPv6 multicast or anycast address, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received.
This makes it possible to use ping to multicast address and get always response, if other nodes are on the same link. By default there would be no echo reply storm for multi-link groups (except on each link the number of multicast listeners on link causes two packets: echo reply and time exceeded back from router).
For multilink case group can still be investigated by increasing some nodes echo-reply hop-limit may be increased to bigger value.
If [on non-router hosts?] is added to the wording, routers would send echo reply messages to multicast echo request packets. Still the resulted echo reply storm will be decreased from the current situation. --- Jyrki Soini
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
