Subject: [GROW] WGLC: draft-ietf-grow-blackholing - ENDS May 20, 2016

From: Christopher Morrow <[email-masked]>
Date: Fri, 6 May 2016 10:51:46 -0400

Howdy rough and Tumble WG folks:

The authors of: draft-ietf-grow-blackholing had asked for WGLC to be
started on their document. The abstract is:

   This document describes the use of a well-known Border Gateway
   Protocol (BGP) community for blackholing at IP networks and Internet
   Exchange Points (IXP).  This well-known advisory transitive BGP
   community, namely BLACKHOLE, allows an origin AS to specify that a
   neighboring IP network or IXP should blackhole a specific IP prefix.

The URL to the document:
  <https://tools.ietf.org/html/draft-ietf-grow-blackholing-00>

Please have a read, give it some consideration and send
comments/questions/ACK/NACK back so the authors can adjust course or
celebrate a process victory over the document snake.

-chris
co-chair GROW.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 May 2016 16:31:56 -0400

> celebrate a process victory over the document snake.

I'm generally supportive of the draft in its current state.  A (re-)read
does cause me to ask the following:

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

The "authorized to advertise" is a bit on the vague end. (I.e. how do you
write code for it?)  Could the authors give a bit more guidance here?  For
example, would an AS_PATH that is a proper prefix of the less specific
route's AS_PATH do?

The incremental deployment case is also a bit ugly.  If this more specific
route is received by a router that doesn't understand the community, it will
instead forward that more specific traffic toward the advertiser.
Presumably it would eventually reach a router that knows what it means and
blackhole it, so it's not tragic as long as the forwarding path in question
can absorb the traffic (which is presumably at DDoS levels).

-- Jeff

---

From: Thomas King <[email-masked]>
Date: Thu, 12 May 2016 10:48:46 +0000

Hi Jeff,

>example, would an AS_PATH that is a proper prefix of the less specific

The authors see different ways of checking an authoritative announcement: By using IRR databases, BGPSec, origin prefix validation (RPKI), or just checking if the more specific BGP announcement carrying the Blackhole BGP community contains the same AS_PATH as the less specific announcement.

I suggest to add this sentence at the end of the section:
Different approaches (e.g., IRR databases (4012), BGPSec (draft-ietf-sidr-bgpsec-protocol-15), RPKI-based prefix origin validation (RFC6480) or just AS_PATH matching between the more specific BGP announcement carrying the BLACKHOLE community and the less specific BGP announcement) can be utilised in order to validate if the neighbouring network is authorised to advertise a certain prefix.

Best regards,
Thomas

---

From: Job Snijders <[email-masked]>
Date: Thu, 12 May 2016 12:57:04 +0200

On Thu, May 12, 2016 at 10:48:46AM +0000, Thomas King wrote:
> The authors see different ways of checking an authoritative
> announcement: By using IRR databases, BGPSec, origin prefix validation
> (RPKI), or just checking if the more specific BGP announcement
> carrying the Blackhole BGP community contains the same AS_PATH as the
> less specific announcement.
> 
> I suggest to add this sentence at the end of the section: Different
> approaches (e.g., IRR databases (4012), BGPSec
> (draft-ietf-sidr-bgpsec-protocol-15), RPKI-based prefix origin
> validation (RFC6480) or just AS_PATH matching between the more
> specific BGP announcement carrying the BLACKHOLE community and the
> less specific BGP announcement) can be utilised in order to validate
> if the neighbouring network is authorised to advertise a certain
> prefix.

_how_ you validate whether a customer is allowed to blackhole the
destination or not is outside of scope of this document. I don't
nessecarily see the value of iterating various specific techniques here.

We could refer to https://tools.ietf.org/html/rfc5635 see section 3.2.3
""Customer-Triggered" RTBH filtering." - admittedly that section is a
bit vague.

Kind regards,

Job