Re: BCP38 making it work, solving problems
... 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 found out from verisign that big companies call something "innovation" if it hasn't been generally done before and if it immediately increases revenue. failing the "immediately increases revenue" part, no big company will do anything that hasn't been generally done before. unless their insurance companies or their government insists, that is. the same cfo's who are choking the life out of your backbone (equipment, staff, etc) are perfectly happy to pay a little more to get UL-listed refrigerators for the company's break rooms. i guess the grownups really are in charge? 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.
Date: Tue, 19 Oct 2004 13:36:18 +0000 From: Paul Vixie <paul@vix.com> To: nanog@merit.edu Subject: Re: BCP38 making it work, solving problems
[ ... ]
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 found out from verisign that big companies call something "innovation" if it hasn't been generally done before and if it immediately increases revenue.
failing the "immediately increases revenue" part, no big company will do anything that hasn't been generally done before.
<aol> And continuing on that road would lead to innovation, how ? </aol>
[ ... ] i'm pretty depressed at the lack of self regulation among the techiefolk.
Techiefolk are 'commodity' nowadays. The ones that do care are vastly outnumbered. (which doesn't mean they should stop caring!)
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.
Thinking outside of the box or about "The Greater Good" is something of a quaint idea nowadays :( Think I'll go dust off my wings... ;D Regards, JP Velders
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 jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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.
And those you do see it indicates a misconfigured / compromised system. A compromised system that is sending spoofed traffic can also launch attacks using regular traffic. Think of this as a early warning system. The same with those ISP's that block outbound port 25. Think of it as a early warning system. The customer is misconfigured or compromised. You need to find out which. [This is not to say that I agree with the practice of blocking port 25] Apply the same logic to anything else you filter outbound.
participants (4)
-
Jared Mauch -
JP Velders -
Mark Andrews -
Paul Vixie