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

From: Job Snijders <[email-masked]>
Date: Fri, 1 Jul 2016 13:15:44 +0200

Dear all,

To address the latest concerns, draft-ietf-grow-blackholing-02 has been
posted.

Executive summary:

    - Changed intended status from STD to INFO
    - Added section 4 "Vendor Implementation Recommendations"
    - Simplify the security section
    - Clarify in introduction that this is about destination based
      blackholing

diff: https://www.ietf.org/rfcdiff?url1=draft-ietf-grow-blackholing-01&url2=draft-ietf-grow-blackholing-02

full read: https://tools.ietf.org/html/draft-ietf-grow-blackholing-02

Cheers!

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 01 Jul 2016 12:40:03 +0100

>     - Clarify in introduction that this is about destination based

Job,

Sorry, but this update does not address the concerns raised about
clarifying the behavioural semantics of this flag.  It's also not clear
why the security warning relating to denial of service attacks was removed.

Nick

---

From: Randy Bush <[email-masked]>
Date: Fri, 01 Jul 2016 21:29:33 +0900

> why the security warning relating to denial of service attacks was

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?

randy

---

From: joel jaeggli <[email-masked]>
Date: Fri, 1 Jul 2016 07:48:49 -0700

> which causes an un-authenticated prefix's traffic to be dropped on the

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?

> randy
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 1 Jul 2016 11:26:05 -0400

> why the security warning relating to denial of service attacks was removed.
first noting that it'd be helpful if you have concerns to suggestions that
you send text that might be used to address them. Playing 'bring me a rock'
is not fun for anyone.

As to the denial of service wording removal/change, i thought the change
was actually positive because it removed a bit of ambiguity "if a network
offering blackholing is traversed" only really applies if that network:
  1) hears the prefix with the community
  2) is configured to do something with that announcement

To back up a bit in the conversation I viewed the draft/document as doing
two specific things:
  1) reducing operational complexity between consenting bgp speaking adults
  2) letting operations staff decide how/where/what to do with a prefix
seen from their peer(s).

I think a community today is used (many actually) to signal requested
treatment of a prefix across an AS boundary (rfc1998 for example),
operators on both sides of the peering decide what to add to a prefix on
exit, and what to do with the additions on receipt. I expect peers to be
consenting adults and to not shoot themselves in the foot...

I would expect this proposed community to be used along with adding
no-export on receipt at the peer, because sending the community more
broadly isn't as helpful.

As to the issue with authenticating the announcement, the draft discusses
the fact that communities being 'protected' are explicitly a non-goal of
the coming protection mechanisms proposed for BGP. I don't see that
changing, because communities are grouping mechanisms used inside networks,
they may not survive across AS boundaries, and they almost certainly are
added inside networks for locally significant reasons.

I suggest that if there are objections to the current version we get some
text on-list where we can hash out next-steps, if there's no text offered I
think we all vote to move this document forward.

-chris

---

From: Randy Bush <[email-masked]>
Date: Sat, 02 Jul 2016 07:02:32 +0900

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

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

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 02 Jul 2016 07:26:26 +0900

> broadly isn't as helpful.

and we all know accidents never happen.  and, networks which do not
implement also will not drop export.

> I suggest that if there are objections to the current version we get
> some text on-list where we can hash out next-steps, if there's no text
> offered I think we all vote to move this document forward.

when something is fatally flawed, adding or changing text is not gonna
help a lot.

to make this not a serious attack vector, one or more of the following
are needed:
  o non-transitive
  o not well-known (which saves it today)
  o authenticated (no sidr is not very helpful.  though there might be a
    hack where the the community also contains a sig by the prefix
    owner.  but it would take the sidr wg five years to nit pick it to
    death)

randy

---

From: Job Snijders <[email-masked]>
Date: Sat, 2 Jul 2016 12:37:23 +0200

On Sat, Jul 02, 2016 at 07:02:32AM +0900, Randy Bush wrote:
> >> 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

---

From: Randy Bush <[email-masked]>
Date: Sat, 02 Jul 2016 19:44:02 +0900

> Your argument comes down to "security through obscurity"

no.  non-transitiveness through local naming, the reason this has not
allowed serious damage in current practice.

randy

---

From: Michel Py <[email-masked]>
Date: Sat, 2 Jul 2016 18:59:45 +0000

> Job Snijders wrote :
> 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.

With the changes in -02, I now support this text.

Michel.

---

From: heasley <[email-masked]>
Date: Sun, 3 Jul 2016 18:49:47 +0000

> allowed serious damage in current practice.

a receiving operator could limit scope, if they chose.  something like

route-map foo p 10
 match community blackhole
 match as-path ^([0-9]+_){1,2}$
 set ip next-hop null0
route-map foo d 20
 match community blackhole
route-map foo ...

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 03 Jul 2016 21:18:07 +0100

Christopher Morrow wrote:
> first noting that it'd be helpful if you have concerns to suggestions
> that you send text that might be used to address them. Playing 'bring me
> a rock' is not fun for anyone.

"bring me a rock" was not intended.

Also, email is a terrible medium for communication (mea culpa) :-(

> was actually positive because it removed a bit of ambiguity "if a
> network offering blackholing is traversed" only really applies if that
> network:
> To back up a bit in the conversation I viewed the draft/document as
> doing two specific things:

which is fine and we all agree on this.  What we don't agree on is
whether creating this particular weapon will cause more problems than it
solves.

> consenting adults and to not shoot themselves in the foot...

that isn't the problem, though.  The problems will be caused by other
people either injecting prefixes into their own rtbhs and accidentally
leaking them to upstreams or else deliberately staging hijacks.  Other
people have argued that there's no new attack vector here, just a
different outcome from the same attack vector (i.e. dropping instead of
redirecting traffic).  There's a case to be made with this argument, but
OTOH, prefix hijacking is rampant and there are lots of situations where
people do not or cannot feasibly implement prefix filtering.  This is
what bothers me.

> broadly isn't as helpful.

Yeah, not doing this is going to be a common misconfiguration.

I can't decide on the overall aims of the draft.  It would be hugely
convenient to have a community like this, no doubt about it, but the
transitive nature of the community and humanity's utter inability not to
screw things up means that problems are going to happen.  I'd be happier
if the text were tightened up to be much more specific about what the
semantics of the term "blackhole", and then we could do an IETF and
write any problems off as operational misconfiguration, but even still,
that niggling feeling that this is overall a bad idea is not going away.

Summary: conflicted.

Nick

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Jul 2016 09:08:07 +0900

>  match community blackhole

yes, they *could* if they so chose.

the problem is that most won't.  as we know, unintentional (or more
correctly, thoughtless) leakage of all sorts of garbage is rampant
today.  weaponizing (you gotta love american verbing of nouns)
well-known communities that will assuredly be leaked; what could
possibly go wrong?

randy

---

From: <[email-masked]>
Date: Thu, 7 Jul 2016 13:59:29 +0000

Hi all,

I've not been following the discussion in all details, sorry for this.
IINM, one comment was that it would be safer to use a non-transitive BGP community.
In which case, you may be interested in the following draft which proposes to define "well known" non-transitive communities based on existing non-transitive extended BGP communities.
https://tools.ietf.org/html/draft-ietf-idr-reserved-extended-communities

Caveats: this draft is currently not progressing to RFC publication because it has a normative reference to draft-ietf-idr-as4octet-extcomm-generic-subtype. The latter is not progressing because it is lacking 2 independent implementations (as per IDR rule). Note however that the implementation effort is quite modest so it could be implemented quickly by someone with the motivation to do so.

Hope this may help,
Regards,
--Bruno

> From: GROW [mailto:[email-masked]] On Behalf Of Nick Hilliard > Sent: Sunday, July 03, 2016 10:18 PM
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.