Hi Jeroen/all, >Hi, > >A little mail for a nice Monday morning discussion/flamebait: > >I became to realize that RH0 filtering is at all not really necessary. > > >Networks who have uRPF enabled, they check the source of the packet and >as such the packet pingpong doesn't work, yes the packet arrives, but >when the packet has to be sent out onto the network again, it gets >caught by the uRPF filter. > >Networks who do not have uRPF enabled and thus are not properly checking >where a packet is actually being sourced from are open to the RH0 attack. > >As such, any network which does not have uRPF enabled is vulnerable to >some nice RH0 packet ping ponging. > >Now, what we should hope is that people actually do NOT filter out RH0 >and then send out a lot of packets with RH0 headers ping ponging >throughout the Internet. This will take care that the networks who are >not properly applying uRPF will in effect nicely melt down. > >Maybe that brings to their attention that doing uRPF is actually a good >thing as is being specified in BCP38 (BCP stands for Best Common >Practices, but clearly a lot of networks don't take it in common).
Sort of a re-hash of my 11May07 posting: The authors of BCP 38 clearly decided against also doing strict RPF because of the number of asymmetric routes in the Internet. If any kind of RPF is to be done in conjunction with ingress filtering (on the edge), it would not be the strict kind. It was pointed out (correctly I believe) that with the implementation of BCP 38 (aka RFC 2827) on the edges, potential for ping-ponging RH0 traffic would be limited (at worst) to internal networks. Should site administrators implement (loose) RPF in the cores of their respective networks, internal attacks would be mitigated (if the source address being spoofed is not in the routing table of the core router that receives the packet). In intended validation of earlier e-mail, support from major router vendors for these features lags behind specification/recommendation for their use. Strict RPF clearly will not work well on peering and transit interfaces. > >Greets, > Jeroen Best Regards, Tim Enos Rom 8:28 > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >[email protected] >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
