ietf
[Top] [All Lists]

Re: [GROW] Last Call: <draft-ietf-grow-blackholing-00.txt> (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

2016-07-02 05:37:50
On Sat, Jul 02, 2016 at 07:02:32AM +0900, Randy Bush wrote:
what could possibly go wrong with a well-known transitive attribute
which causes an un-authenticated prefix's traffic to be dropped on
the floor?

Today I have 5 or six of them... and my managment system has a
series of substitutions for the provider-appropriate one. So, what
can go wrong with a poorly understood and loosely coordinated
transitive attributes which cause unauthenticated prefixes traffic
to be dropped on the floor?

and you are kinda peotected by the community not being well-known,
i.e. different for each upstream. the attacker has to know the
community for each upstream and be able to not only inject the prefix
but also tag it with the correct community for each upstream.

Your argument comes down to "security through obscurity" - in essence an
argument against a lot of standardisation work. In fact, if
standardisation itself is a risk, it means the underlying system is
broken. You should address that in a different draft, seems out of scope
for this one. Proclaiming there is a security advantage because of lack
of regulation / standardisation feels like you are putting your head in
the sand.

You present your scenario as if it is difficult to figure out
communities. Already today adversaries can use their favorite search
engine to find which communities do what where. One can attach multiple
BGP communities to a route. Yes, (intentional) accidents do happen.
Should all cars be banned because accidents happen on the roads?

What this document provides is a well-known BGP community to be used for
a commonly understood purpose, and the document acknowledges that the
rules differ from provider to provider, just like today with the myriad
of communities. It is up to the operator to decide when to accept and
honor the blackhole community.

If one blindly accepts the blackhole community (ignoring section 3.3),
and at the same time manages to honor it (section 4 prevents vendors
from enabling this by default) you probably deserve whatever happens
next. Since when are side wheels mandatory?

Section 3.3 states : "BGP speakers SHOULD only accept and honor BGP
announcements carrying the BLACKHOLE community if the announced prefix
is covered by a shorter prefix for which the neighboring network is
authorized to advertise.", there is an option to make this MUST, but
networks choosing not to (or being unable to) filter may ignore this
anyway. 

it is the combination of well-known and transitive that is deadly.

You are exaggerating with the phrase "deadly". It seems we have ventured
into a subjective phase of the discussion "i dont like it" vs "i think
it is useful". Some disagreement is fine, in -02 of the draft the
intended status was lowered to "Informational".

Kind regards,

Job

<Prev in Thread] Current Thread [Next in Thread>