nanog mailing list archives
Re: icmp rpf
From: Jared Mauch <jared () puck nether net>
Date: Tue, 26 Sep 2006 11:32:52 -0400
On Tue, Sep 26, 2006 at 12:17:27AM -0700, Tony Rall wrote:
On Monday, 2006-09-25 at 10:09 MST, Mark Kent <mark () noc mainstreet net> wrote:Mark Smith replied with two paragraphs, but it's not 100% clear to me that he got the reason why I asked. I asked because his initialstatementboiled down to "numbering on un-announced space breaks PMTUD"... but it doesn't, not by itself (which he later expanded). It only does so in the presence of filtering.Which is exactly what one might expect to happen. At least it seems to me that RFC 3704 (BCP 84, http://www.ietf.org/rfc/rfc3704.txt) applies. When your traffic is sourced with dubious addresses, you should expect much of it to disappear. And when this happens, you're hurting your customers and your customers' customers (okay, sometimes it's "just" your peer's customers - still a concern in my opinion).
I think this is the critical point, dubious ip sources have been used/abused in the past and those at "big.net" that have done something to mitigate the risk to the world from their customers and their customers from the world are doing a "community service" imnsho ;). I don't see anyone here really advocating spoofed sources (except for perhaps the mobile-ip users out there ;) How many people here have rpf enabled by default on their customer CPE devices they ship? (in your template or whatnot) Do you u-rpf your dsl/cable/dial/fract-t1/t1 customers that are not doing bgp? It's hard to get this implemented across an entire network. At one time I seem to recall someone saying that 7018 was fully bcp-38 compliant, but I could be wrong. While doing u-rpf on your customers won't mitigate attacks against them, it will help mitigate the costs of tracking spoofed attacks across your network infrastructure (which is harder if you're doing mpls) that you incur. Now, i'm guessing i may be the one responsible for the practices of "big.net", but i do encourage other big.nets to enable u-rpf strict or loose wherever possible based on their equipment capabilities. Every little bit will help. - jared -- Jared Mauch | pgp key available via finger from jared () puck nether net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Current thread:
- Re: icmp rpf, (continued)
- Re: icmp rpf Michael . Dillon (Sep 25)
- Re: icmp rpf virendra rode // (Sep 24)
- Re: icmp rpf Mark Kent (Sep 24)
- Re: icmp rpf Roland Dobbins (Sep 24)
- Re: icmp rpf virendra rode // (Sep 24)
- Re: icmp rpf Mark Smith (Sep 25)
- Re: icmp rpf Mark Kent (Sep 25)
- Re: icmp rpf Chris Adams (Sep 25)
- Re: icmp rpf william(at)elan.net (Sep 25)
- Re: icmp rpf Tony Rall (Sep 26)
- Re: icmp rpf Jared Mauch (Sep 26)
- Re: icmp rpf Mark Kent (Sep 24)
- Re: icmp rpf Bill Stewart (Sep 27)
- Re: icmp rpf Adrian Chadd (Sep 25)
- New router feature - icmp error source-interface [was: icmp rpf] Patrick W. Gilmore (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Joe Maimon (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Mark Smith (Sep 25)
- RE: New router feature - icmp error source-interface [was: icmp rpf] Berkman, Scott (Sep 25)
- Re: New router feature - icmp error source-interface [was: icmp rpf] Patrick W. Gilmore (Sep 25)
- RE: New router feature - icmp error source-interface [was: icmp rpf] David Temkin (Sep 25)