Re: Public shaming list for ISPs announcing other ISPs IP space by mistake

[Jared Mauch <jared () puck nether net>]

On Wed, Aug 13, 2008 at 04:52:46PM -0400, Patrick W. Gilmore wrote:
> On Aug 13, 2008, at 4:48 PM, Jared Mauch wrote:
> > On Wed, Aug 13, 2008 at 10:04:27PM +0200, Mikael Abrahamsson wrote:
> > > The italian courts seem to have told ISPs there to block ThePirateBay
> > > (bittorrent tracker), and this evening (CET) LLNW (AS22822)  
> > > originated
> > > 88.80.6.0/24 via 6762 (telecom italia) to what I presume is most of
> > > Europe.
> > >
> > > Basically same thing that happened when people tried to block  
> > > YouTube a
> > > few months back (afghanistan?).
> > >
> > > How do we hinder this in the short term? I know there are a lot of  
> > > long
> > > term solutions that very few is implementing, but would the fact that
> > > these mistakes are brought up into the (lime)light by a public  
> > > shaming
> > > list make ISPs shape up and perform less mistakes?
> > >
> > > I am still waiting for a response from LLNW NOC on the issue.
> >
> >      Sure.  I'd also like to see providers actually just shut
> > off customers that originate stuff like ms-sql slammer
> > packets still.  But it keeps flowing.  I'm sure there are
> > smurf amps and other badness still going.  codered anyone?
> >
> >      these are all issues, but operational?  depends.
>
> I beg to differ, this is absolutely operational.

        So, I should shut down or depeer networks that
continue to originate the crap to me?  (packets, announcements).

> > If LLNW is not being filtered by telecom italia, time for
> > 6762 to fix that.  If they persist, will you depeer them
> > as a security risk until they clean up their act?
>
> De-peering won't help if someone is propagating it as a transit customer 
> route.  Filtering the prefix is all you can do.

        Taking this example, if I were to depeer 6762 becuase
they can't keep their routing table clean to me, I suspect
they would look at how to fix the issue.  I could just filter their
as-path globally until they contact me to resolve the issue.

        I'm not saying I would actually do that, but there is
a question of what level of action should be taken to resolve
these issues, and a timescale for their resolution.  I've found
some networks excellent to work with, and others "we'll stop
leaking to you in a few days once we finish escalating
the issue to our tier-n NOC in XXX city".

        Honestly, I find that to be kinda lazy considering how
critical the routing infrasturcture is for our survival as an
industry.

> P.S. Obligatory BCP38 shout-out, even though it's not exactly on-point. 

        I can't agree with this more, If you're not doing u-RPF on your
customer interfaces (t1, ds3, ge, fe, colo, etc..) you should be.  The only
excuses are broken software or incapable hardware from your vendor.

        Sadly those last two seem to impair the ability to take these
basic network security requirements into account for a network of any
size.

        It'll help reduce the possible attack home-base for various spoofing
attacks (including some DNS one, did you hear about it?)

        - Jared

-- 
Jared Mauch  | pgp key available via finger from jared () puck nether net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.