[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ICMPv6 echo reply to multicast packet thread

Hash: SHA1

Suresh Krishnan wrote:

> Hi Jyrki,
> 	Find comments inline.
> Regards
> Suresh
> On Mon, 8 Mar 2004, Jyrki Soini wrote:
> >The consequence is that the original Echo Request packet gets 100 000
> >000 unicast Echo Reply messages back.
> I do not see anything wrong with this scenario. If I send an 
> ICMP Echo 
> Request to 100M nodes I MUST expect a Echo reply from 100M nodes. How 
> about if I sent a DATA packet, which requires an ACK, to the group by 
> mistake? 

I guess that Jyrki's thoughts where more along the lines of:
"What if I send a simple ICMPv6 Echo Request with *your* source address".

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.

But then still other ISP's don't and you are still vulnerable.

> >Ping to multicast address has operational usage as debugging tool and
> >totally disabling reply to Echo Request message sent to an IPv6
> >multicast address would not be a good solution.
> Agree. I would really like to have this. But if I had to 
> choose between probabilistic echo replies or none, I would pick none.

None would indeed be better as then you are not thinking "but maybe
they have configured it to not do it".

This is somewhat the same problem that occured when there where
a lot of icmp attacks over unicast and Cisco set a default ratelimit
on their routers, after some time even simple traceroutes would
not work anymore due to this.

The Mtrace method is the real answer to debugging multicast.

<SNIP long confidentiality clause>


Version: Unfix PGP for Outlook
Comment: Jeroen Massar / http://unfix.org/~jeroen/


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6