BLACKHOLE Community
RFC 7999

Note: This ballot was opened for revision 02 and is now closed.

(Joel Jaeggli) Yes

Alvaro Retana Yes

Comment (2016-08-02 for -02)
No email
send info
I think this is an important document...but I do have some non-blocking comments:

1. This document defines a community, not an attribute, so Section 2 (for example) should be renamed — there are a couple more places that also need updating.

2. In Section 3.1. (IP Prefix Announcements with BLACKHOLE Community Attached):  "When a network is under DDoS duress, it MAY announce an IP prefix covering the victim's IP address(es)…In such a scenario, the network operator SHOULD attach BLACKHOLE BGP community."  I think the "MAY" is not needed because this whole process is optional…and the qualification really comes in the next sentence.  Why is the "SHOULD" not a "MUST"?  In other words, if the sender decided to make an advertisement "for the purpose of signaling to neighboring networks that any traffic destined for these IP address(es) should be discarded", when would it not include the new community?

3. Section 3.2. (Local Scope of Blackholes) says that "Unintentional leaking of more specific IP prefixes to neighboring networks can have adverse effects.  Extreme caution should be used when purposefully propagating IP prefixes tagged with the BLACKHOLE BGP community outside the local routing domain."  However, no further examples or security-related considerations are mentioned about the first sentence.  The Security Considerations section does talk about an attack resulting from inserting the BLACKHOLE community where it shouldn't be, but I would like to see some more on the effects of propagating a prefix that was correctly tagged (as mentioned in the second sentence).  In summary, I think that the statements above are not without merit, but it would be helpful for others to better describe the potential effects.

4. I think that Section 4. (Vendor Implementation Recommendations) is superfluous.  It talks about explicit configuration — the community is already defined as providing "advisory qualification" in Section 2.  And then it suggests calling the community "blackhole"…

5. In Section 6. (Security Considerations)…

5.1. The correct reference for BGPSec is draft-ietf-sidr-bgpsec-protocol.

5.2. The RPKI reference (RFC6810 = The Resource Public Key Infrastructure (RPKI) to Router Protocol) seems out of place.  I'm not sure if you really want to refer to Origin Validation (rfc6811) or something else (?).  In any case, it is true that communities are not protected.

5.3. Section 3.3. (Accepting Blackholed IP Prefixes) says that "BGP speakers SHOULD only accept and honor BGP announcements…for which the neighboring network is authorized to advertise."   That sounds like Origin Validation to me.  Given that Section 3.2. (Local Scope of Blackholes) is not strict (uses "SHOULD" and not "MUST" when talking about propagation of marked routes outside the receiving AS), I would like to see a sentence or two about how Origin Validation can help determine if the neighbor is in fact authorized. [Non-normative.]

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2016-08-03 for -02)
No email
send info
I'm balloting "no objection", but I share some of the discomfort around Stephen's discuss point 1, and will follow the conversation in the resulting thread. 

The "extreme caution" admonition in 3.2 could use elaboration. In the email thread related to Stephen's discuss, Jeff mentioned existing undocumented operational practices that mitigate the risk of accidental propagation; perhaps something along those lines could be mentioned here?

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2016-08-01 for -02)
No email
send info
Shepherd write-up says intended status is "Proposed Standard". I assmue Informational is correct though.

(Terry Manderson) (was Discuss, No Objection) No Objection

Comment (2016-08-15)
No email
send info
Thank you for the work in addressing my concerns, clearing my DISCUSS.

(Kathleen Moriarty) No Objection

Comment (2016-08-02 for -02)
No email
send info
Thanks for writing this draft to document the practice.

Alissa Cooper Abstain

Comment (2016-08-03 for -02)
No email
send info
After reading the IETF LC thread on this, I am quite conflicted. I appreciate that defining this community will make things easier operationally, but I'm concerned that it will also make it easier to intentionally or unintentionally cutoff traffic to a destination that is not suffering a DDoS attack. I don't see the changes from the -00 to the -02 really helping much in that regard. The change from PS to informational is not terribly meaningful since the community is being registered either way and the removal of the bits about IXPs doesn't mitigate the risks either. If there was a way to authenticate the attribute I would feel differently, but my understanding is that that is not currently possible with BGP.

This is far outside my area of expertise so I don't intend to try to block publication or offer anything in the way of an alternative, but I also don't feel comfortable supporting the publication of this document.

(Stephen Farrell) (was Discuss) Abstain

Comment (2016-09-04)
No email
send info
Thanks for the discussion. My conclusion after that (and now that
I'm back from vacation myself) is that I'm in the rough along with 
the others (Nick, Randy) who have expressed concerns at approving 
this document.

I'd also note that the discussion of the PRs [1,2] that Nick created
after -03 was published doesn't seem to me to have reached a
conclusion.  That's probably down to it being vacation time but
I hope folks do finish up the discussion of those.

[1] https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/pull/1/files
[2] https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/pull/2/files