[150457] in North American Network Operators' Group
Re: do not filter your customers
daemon@ATHENA.MIT.EDU (Danny McPherson)
Fri Feb 24 14:27:24 2012
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
Date: Fri, 24 Feb 2012 14:26:14 -0500
To: North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 24, 2012, at 1:10 PM, Steven Bellovin wrote:
> But just because we can't solve the whole problem, does that
> mean we shouldn't solve any of it?
Nope, we most certainly should decompose the problem into
addressable elements, that's core to engineering and operations.
However, simply because the currently envisaged solution
doesn't solve this problem doesn't mean we shouldn't
acknowledge it exists.
The IETF's BGP security threats document [1] "describes a threat
model for BGP path security", which constrains itself to the
carefully worded SIDR WG charter, which addresses route origin
authorization and AS_PATH "semantics" -- i.e., this "leak"
problem is expressly out of scope of a threats document
discussing BGP path security - eh?
How the heck we can talk about BGP path security and not
consider this incident a threat is beyond me, particularly when it
happens by accident all the time. How we can justify putting all
that BGPSEC and RPKI machinery in place and not address this
"leak" issue somewhere in the mix is, err.., telling.
Alas, I suspect we can all agree that experiments are good and
the market will ultimately decide.
-danny
[1] draft-ietf-sidr-bgpsec-threats-02
