North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: BCP38 making it work, solving problems
On Tue, Oct 19, 2004 at 01:36:18PM +0000, Paul Vixie wrote: > > > ... the first thing is, some nets who want the internet to work this > > > way have to implement BCP38 in their own corner of the internet. > > > then they have to start de-peering with nets who don't do it, and > > > offer a better rate to customers who do it than to those who don't. > > > then they have to de-peer with anyone who doesn't require their > > > peers and customers to do it. then they have to refuse as customers > > > anyone who won't do it. ... > > > > As it was "in the old days": first clean up your own act and then > > start pointing at others that they're doing "it" wrong. > > > > It's a mentality I see very rarely amongst the larger ISP's who've > > been part of that 'I' in their name since the very early beginning. > > i'm pretty depressed at the lack of self regulation among the techiefolk. > responses to BCP38 of the form "but my customer has a good reason to spoof" > or "but my equipment can't do wire speed SAV" or "but BCP38 will not solve > all DDoS problems single-handedly" are small minded, provincial, and wrong. > ... it's just "but if man was meant to fly he'd have wings" all over again. I've been a strong advocate of getting uRPF enabled on our customer links. So much so, that we've found interesting limitations of some of the routers out there. While, I'd like to enable SAV on all our links, it's just not possible. Some major routing vendors have not re-released their time-to-market hardware with versions that can still do full port density and line-rate, while others have re-spun their hardware in order to support new features at the same densities/costs. These are just a few of the challenges that providers face.. The more I see these days though is non-spoofed attacks, that are semi-sophisticated in nature. *BUT* this doesn't mean that you people that aren't u-rpfing your non-multihomed T1/DSL customers should just ignore the need for u-rpf. It will save you a lot of grief in your networks operationally. No more tracking spoofed DoS attacks from your customers. No forwarding packets with these bogus sources across your expensive links. This will only help you and your customers operate a "clean" network. My employers network isn't perfect, nor do I suspect many peoples are, but SAV filtering/u-rpf is important enough that everyone should be doing it. Just picking on one router, I see many billions of packets dropped over it's 25 day uptime: RPF Failures: Packets: 34889152, Bytes: 12838806927 RPF Failures: Packets: 4200, Bytes: 449923 RPF Failures: Packets: 3066337401, Bytes: 122772518288 RPF Failures: Packets: 30954487, Bytes: 3272647457 RPF Failures: Packets: 4707582841, Bytes: 227001949225 RPF Failures: Packets: 11291931, Bytes: 643099278 RPF Failures: Packets: 291592413, Bytes: 20642951232 RPF Failures: Packets: 380355, Bytes: 22616137 RPF Failures: Packets: 607543, Bytes: 31687907 RPF Failures: Packets: 0, Bytes: 0 RPF Failures: Packets: 91, Bytes: 6978 RPF Failures: Packets: 0, Bytes: 0 RPF Failures: Packets: 0, Bytes: 0 RPF Failures: Packets: 2, Bytes: 80 RPF Failures: Packets: 13904, Bytes: 1093686 this means the junk isn't reaching root servers, peers, or our customers. mitigating the need to carry this traffic when it is of (virtually) no use. - Jared (working to make the packets on my corner of the network a little less messy) -- Jared Mauch | pgp key available via finger from [email protected] clue++; | http://puck.nether.net/~jared/ My statements are only mine.