Pekka Savola wrote:

Note that when you send to a multicast address, your source address is checked to be RPF-wise correct, otherwise it's dropped in the multicast forwarding. So, I don't think spoofing is that feasible a scenario in "multicast ping".

Right. I think this protection is good enough that we can generally rely on it, as long as the remaining case (on path attacker) is understood and mentioned in the security considerations.

If we disallow ICMP Echo Request, what about other services (TCP/UDP) that may be listening at the receiver systems? Those could be likewise affected -- TCP SYN/ACK, or a UDP response packet could have tremendous effect on the network as well.

Yes. A couple of comments:


- Some of those applications might not be answering if the destination
  address is a multicast address. So this may not apply to all
  applications. But it would apply to some.

- As discussed in the context of the ICMPv6 spec revision, there are
  similar multicast respond flooding issues even with base IPv6
  processing before you get to any "application" such as ping.
  Unrecognized destination option, for instance, would cause a
  flood of responses.

In general, we may not wish to limit the ability of applications
to respond to multicast, that may be needed in some cases. However,
applications that do respond to multicast probably want to say
something about the remaining case in their security considerations
section. Some applications may also use some form of source authentication
to ensure that only the legitimate sender's messages are processed.

This still leaves open what the behaviour for ICMPv6 Echo Request
should be. I would not bundle this issue with what the other
applications do, but my default answer would be to not respond
to multicast requests unless there is a specific reason to do
so. In this case there seems to be some discussion about multicast
debugging capabilities. I do not have experience of that myself.
Are multicast echo requests the primary multicast debugging
mechanism? If yes, we should allow responses to be sent. If not,
I agree with Suresh that it should be disallowed. Note that
multicast debugging through echo responses is naturally limited
to rather small multicast groups ;-) So I suspect people who
need multicast in a large scale are going to need another
debugging tool in any case.

--Jari


-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------

Reply via email to