Jari Arkko said: > 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.
With the noted exception, do we have consensus that multicast ping is not useful as a DoS attack vector? > 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. I don't think anyone would object to individual protocols being hardened, or at least studied, for multicast-specific security problems. > 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. IMHO, a multicast ping is the only tool that is simple enough and ubiquitous enough for end users to attempt diagnostics before calling their support folks -- one simple command tells you whether your problems are at the network layer or application layer. I say keep it. S -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
