[150461] in North American Network Operators' Group
Re: do not filter your customers
daemon@ATHENA.MIT.EDU (Richard Barnes)
Fri Feb 24 14:50:32 2012
In-Reply-To: <3DCB02DA-0961-4744-89D1-6BBFAB99294E@tcb.net>
Date: Fri, 24 Feb 2012 14:49:38 -0500
From: Richard Barnes <richard.barnes@gmail.com>
To: Danny McPherson <danny@tcb.net>
Cc: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
>> I think if we asked telstra why they didn't filter their customer some
>> answer like:
>> 1) we did, we goofed, oops!
>> 2) we don't it's too hard
>> 3) filters? what?
>>
>> I suspect in the case of 1 it's a software problem that needs more
>> belts/suspenders
>> I suspect in the case of 2 it's a problem that could be shown to be
>> simpler with some resource-certification in place
>> I suspect 3 is not likely... (or I hope so).
>>
>> So, even without defining what a leak is, providing a tool to better
>> create/verify filtering would be a boon.
>
>
>
> Yes, I agree!
>
> What I'd hate to see is:
>
> 4) We fully deployed BGPSEC, and RPKI, and upgraded our
> infrastructure, and retooled provisioning, operations and processes
> to support it all fully, and required our customers and peers to use it,
> and even then this still happened - WTF was the point?
I think this is the point:
<https://twitter.com/#!/atoonk/status/165245731429564416>
> This "leak" thing is a key vulnerability that simply can't be brushed
> aside - that's the crux of my frustration with the current effort.
You seem to think that there's some extension/modification to BGPSEC
that would fix route leaks in addition to the ASPATH issues that
BGPSEC addresses right now. Have you written this up anywhere? I
would be interested to read it.
--Richard
