Suresh Krishnan said: > On Wed, 10 Mar 2004, Stephen Sprunk wrote: >>Suresh Krishnan said: >>> Aha. That makes more sense to me. But why should we point to just >>> 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. >> >>Wait a minute... Now we're talking about prohibiting ANY multicast app >>from responding unicast to multicasted data? That's a basic part of >>functionality that is assumed in many apps! >> >>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? > > The problem is not about apps responding unicast to multicast data. It is > 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. > The statement about IP4v4 always responding to multicast echo requests > is not entirely true. The expected IPv4 host behavior is described in RFC > 1122 RFC 1122 Sec 3.2.2.6 is ambiguous. The only self-consistent reading I can find is that hosts MUST respond if they receive an echo request, but the _network_ may drop broadcast or multicast pings before delivering them. >>>>The only real solution for this of course is filtering, but I am >>>>not going to see that happen knowing that quite a number, make >>>>that most, IPv4 based ISP's don't filter their customers on source >>>>addresses. Even RFC1918 addresses seem to be unfiltered at most ISP's. >>>>Talking about source filtering here, which should be very easy as >>>>you know yourself as an ISP which prefixes one assigned to that user >>>>or simply to yourself as an ISP, a simple "source !myprefix drop" >>>>entry in your peering/transit router fixes this all, better stick >>>>as close to the client as possible et voila. >> >>I don't see the relevance of this to multicast, since RPF inherently >>stops all off-subnet spoofing. What problem are we trying to solve? > > I did not write the above passage even though you attributed it to me ;-). It's been quoted many times, but I figured it was worth responding to. S -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
