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

Wed Aug 13 21:14:43 UTC 2008

On Aug 13, 2008, at 5:04 PM, Jared Mauch wrote:
> On Wed, Aug 13, 2008 at 04:52:46PM -0400, Patrick W. Gilmore wrote:

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

Saying something is Operational (and on-topic for nanog) does not mean  
you should de-peer them.

That said, I will not stop you from de-peering a network who can't  
keep its table clean.  Your network, your decision.

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

You wield a much bigger hammer than 99.999% of the people here, and  
you know it.

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

While I doubt "shame" will work in all but the most extreme cases, I  
believe brokeness does, eventually have an impact.  Let's just hope  
that impact is not blunted by (for instance) monopoly power, so that  
"voting with your wallet" will force network to fix things.

Too bad we know monopoly power is blunting most of the effects. :(

>> 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?)

Just thought I'd say "BCP38" again.

-- 
TTFN,
patrick