Subject: Re: [GROW] New Version Notification for draft-ymbk-grow-blackholing-00.txt

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Jun 2015 15:30:26 -0400

On Thu, May 28, 2015 at 08:51:40PM +0000, Thomas King wrote:
> Hi Everybody,
> 
> we submitted this document in order to unify and simplify triggering blackholing at IXPs. We propose to define a well-known BGP community for this.
> 
> Any feedback is highly appreciated.

I'm generally supportive of this draft.  The Security Considerations cover
the majority of the issues this standardized blackhole community introduces.

I would suggest one additional consideration be added: Since the presence of
this community may otherwise bypass prefix-limit checks, the presence of
this community may allow for a resource exhaustion attack by shorter than
usual prefixes.

It would be good to see an example of integration of this feature with some
IXP's filtering mechanism, e.g. IRR database.

-- Jeff

---

From: Thomas King <[email-masked]>
Date: Fri, 26 Jun 2015 15:50:36 +0000

Hi Jeffrey et all,

> On 15 Jun 2015, at 21:30, Jeffrey Haas <[email-masked]> wrote:

…

> the majority of the issues this standardized blackhole community introduces.

Thanks for your feedback.

> this community may allow for a resource exhaustion attack by shorter than

I added the following text to the draft:
The presence of this BLACKHOLEIXP BGP community may introduce a resource exhaustion attack to BGP speakers. If a BGP speaker receives many IP prefixes containing the BLACKHOLE BGP community its internal resources such as CPU power and/or memory might get consumed, especially if usual prefix sanity checks (e.g. IP prefix length or number of prefixes) are disabled (see Section 3.2).

Does this cover your point?

> IXP's filtering mechanism, e.g. IRR database.

Do you want to see the example in the document? If yes, how detailed do you want to see the example? Down to the configuration of BGP speakers and data records in the IRR database?

In the EURO-IX community we discussed to rename the community to BLACKHOLE. Is this fine with everyone?

I am going to upload a new version of the document right before the cut-off deadline.

Best regards,
Thomas

---

From: Job Snijders <[email-masked]>
Date: Fri, 26 Jun 2015 19:13:32 +0200

On Thu, May 28, 2015 at 08:51:40PM +0000, Thomas King wrote:
> we submitted this document in order to unify and simplify triggering
> blackholing at IXPs. We propose to define a well-known BGP community
> for this.
> 

In every single RBTH implementation I know of (on the operator side, not
the IXP RS side), NO_EXPORT is added to routes which have passed the IRR
filters and are requested to be blackholed.

Should Network A accept a route tagged with BLACKHOLEIXP, and not add
NO_EXPORT, it might distribute the route to Network A's peers. If these
peers accept said route, they are likely to have accepted the most
specific version of that route, and network A might unwillingly be
drawing additional traffic towards itself.

Another remark, should you decide to rename BLACKHOLEIXP to just
BLACKHOLE, you might want to replace the references to "IXP" throughout
the document and make it more general.

Kind regards,

Job

---

From: Thomas King <[email-masked]>
Date: Fri, 26 Jun 2015 18:27:23 +0000

Hi Job et al,

> On 26 Jun 2015, at 19:13, Job Snijders <[email-masked]> wrote:
> 

so, do you propose that the IXP RS MUST add a NO_EXPORT to the route that passed the IRR filters and which is requested to be blackholed?
This is completely fine with me.

> the document and make it more general.

I am not sure if a more general approach (= ISP / transit environment) makes lots of sense given RFC 3882.

Best regards,
Thomas

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 26 Jun 2015 14:51:55 -0400

> This is completely fine with me.

Or NO_ADVERTISE, if appropriate.

I'm wondering if people would be supportive of only permitting the blackhole
behavior if and only if it also contains NO_EXPORT or NO_ADVERTISE?

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 26 Jun 2015 14:53:15 -0400

Thomas,

> Does this cover your point?

It does. Thanks!

> Do you want to see the example in the document? If yes, how detailed do you want to see the example? Down to the configuration of BGP speakers and data records in the IRR database?

I think I'd be fine with some text saying "check this against routes
discovered from an appropriate aut-num" or something similar.  The goal is
really to show how the systems should interact.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Fri, 26 Jun 2015 21:02:09 +0200

On Fri, Jun 26, 2015 at 02:51:55PM -0400, Jeffrey Haas wrote:
> > so, do you propose that the IXP RS MUST add a NO_EXPORT to the route
> > that passed the IRR filters and which is requested to be blackholed?
> I'm wondering if people would be supportive of only permitting the
> blackhole behavior if and only if it also contains NO_EXPORT or
> NO_ADVERTISE?

That sounds sane.

---

From: Job Snijders <[email-masked]>
Date: Fri, 26 Jun 2015 21:27:05 +0200

> makes lots of sense given RFC 3882.

Can you elaborate what the conceptual difference would be between a
transit network and an IXP Route Server in this context? RFC 3882 does
not define any well known community.

Whether packets are discarded inside the IXP fabric or somewhere in the
Transit provider's fabric^Wmagic.. I don't see much of a difference.

In section 2:

    "The semantics of this attribute is to allow an IXP to interpret the
    presence of this community as an advisory qualification to drop any
    traffic being sent towards this prefix."

One could consider changing it to:

    "The semantics of this attribute is to allow a network to interpret
    the presence of this community as an advisory qualification to drop
    any traffic being sent towards this prefix."
    (of course the rest of the document would also need some updating)

For years IP networks have offered blackhole services to their
customers, much like some IXPs are now starting to do. One could argue
that a standardized blackhole community is beneficial, in the spirit of
the NOPEER community. Today NTT uses 2914:666 while Level3 uses
3356:9999, if multi-homed networks only need to remember 1 community,
that might be easier. 

IXPs offer the blackholing (1) either themselves inside the fabric, (2)
or through a construct where IXPs ask participants to implement routing
policy honoring a 'blackhole' community, or (3) asking participants to
at least accept the route with a blackhole-next-hop of sorts.

Scenario (2) is no different then the offering of today's blackhole
community by most IP networks.

Kind regards,

Job