Hi Jeroen, Find comments inline. Regards Suresh
On Wed, 10 Mar 2004, Jeroen Massar wrote: >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". 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. > >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 agree. > >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". Exactly. I would rather live without the uncertainity. > >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. Didn't know mtrace worked with v6 addresses. Is there an implementation out there for IPv6? Would be cool to have. > ><SNIP long confidentiality clause> Sorry. Can't help it. It is appended by the mail server ;-). > >Greets, > Jeroen This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
