mailing list archives
Re: Lazy Engineers and Viable Excuses
From: Jared Mauch <jared () puck Nether net>
Date: Tue, 26 Aug 2003 10:43:00 -0400
On Tue, Aug 26, 2003 at 10:10:57AM -0400, Leo Bicknell wrote:
In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote:
Yes, it is that hard. Sadly, almost everyone I see push the IRR
works for a small ISP. And at least half of those work for a small
ISP in Europe.
C&W, Level3, Global Crossing and NTT/Verio are small isps?
Please correct me if I'm wrong, but they all use the IRR to filter
customers. That's a fine application of the IRR, and one I encourage.
I don't think any of them use the IRR to filter peers. Indeed, I
can provde they don't filter certian big peers due to the fact they
don't register thier routes at all. :)
I'd have to imagine all those proxy registered routes
for sprint prefixes that you see in the LEVEL3 rr are used for
something other than consuming disk space.
My rant is on peer-to-peer filtering. Customers should always be
filtered by every ISP. Period. ISP's should automate that as much
as possible for their customers, and using the IRR is a fine solution.
Every ISP on the planet would have to reconfigure their filters
for /EVERY/ customer change worldwide.
Exactly. And this is a bad thing how? You can't plan ahead
and register route objects 24 hours in advance of a customer
It's a bad thing because it doesn't scale. It's not a matter of
before or not, it's that there is a linear relationship between the
size of the internet and the processing needed to be done by each
ISP. That doesn't scale.
Hmm.. you are missing some of the benifits that I
see associated with this. If I have a list of all the
prefixes that I could get sourced from MFN/above.net in a easily queryable
format, I can install anti-spoofing filters.
No, you couldn't. Please go back and take routing 101 again.
Yes I could, if you and your customers had all the routes
they sourced packest from registered. This has nothing to do
with routing 101, this has to do with filtering customers and
having anti-spoofing filters as well as route objects for any
prefix you will source packets from.
Internet routing is asymetrical, the source of the packet has nothing
to do with where the return route points in the core. If it were that
simple we could just use Unicast RPF on all peering links and spoofing
would be a thing of the past.
Actually, it sounds like you're not that clued on how Juniper
handles unicast-rpf at all (for example). It allows you to do
unicast-rpf on a per-interface basis for all routes that you receive
regardless of if they're installed for forwarding. this means that
people could use this and set the necessary community so it doesn't
leave the peer router (no-export + no-advertise), or prepended so much
it's not used and use that to perform filtering. If best-path
for returning the packet is not across the link, it will still
not drop this. This is a nice feature on the part of Juniper.
I suggest you (and others) take a look at these features and
use them where possible to mitigate spoofed DoS attacks from your
Jared Mauch | pgp key available via finger from jared () puck nether net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.