|
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.
|