BLACKHOLE Community
draft-ietf-grow-blackholing-03

[Ballot comment]

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

[Ballot discuss]
Firstly, thank you for documenting operational practice.

With regards to section 3.3:

"BGP speakers SHOULD only accept and honor BGP announcements carrying the BLACKHOLE community .."

I really question why this is a "SHOULD" and not a "MUST", even in an informational RFC. Is the ability for a transit provider so loose that appropriate route filters from a peer ASN can't be applied so that only a "SHOULD" is practical? In which case I do question the sanity of making such a recommendation and thus service available if some other ASN might be able to inject the route and affect another service, even by mistake. Potentially if RPKI is in use, then a peer AS might be able to validate the announcement against a ROA. But it strikes me that this is not the machinery you would want to tack on in this case.

The same could be said for section 3.2. I would be rather wary of NOT adding a NO_ADVERTISE (at the very least) and to be honest SHOULD still seems far too loose for me. Almost all of the recipe's that I've gazed upon

[Ballot comment]
From a comment point of view, this informational document is agnostic on any operational differences between 2-byte and 4-byte ASNs. Is that intentional? Are there any operational differences worth calling out in regard to using extended communities etc?

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot discuss]

First, I have to say that I'm pretty ignorant about
practical routing operations, so my plan is to briefly
discuss this and to then probably move to an abstain
position, unless the issues I raise resonate with folks
who are expert in this space.

(1) I agree with the points raised in IETF LC that the
transitive nature of this proposal has dangers that may
outweigh its utility. Was there discussion in the WG about
potential solutions that do not have the transitivity
property? If so, can you point me at those? If not, is
there a reason to think no such solution is feasible?  (I
suspect the answer may be "no" which is the main reason I
plan to move to an abstain ballot.)

(2) IIUC, this proposal envisages BGP speakers commonly
telling others to blackhole specific /32's or /128's. And
of course as the draft says BGP doesn't provide us with a
way to "prevent the unauthorized modification of
information by the forwarding agent." Given those two
things, this scheme seems to be an ideal new way to cause
any service that advertises a fallback to actually fall back,
e.g to use a secondary MX or DNS resolver rather than a
primary. That seems like a fine way to try and possibly
succeed in attacking many possible things.  The discuss
point here is to ask if this really is a new attack
vector, and if so, if the appropriate level of analysis of
its impact has been done? If this is new, then I don't see
that the security considerations text adequately describe
the range of possible attacks that could be mounted using
this scheme. (As an aside, I wonder if asking to blackhole
/32's and /128's might impact on routing table sizes and
if something ought be said about that?)

(3) Given that there are dangers associated with this
mechanism, why is there no statement in the draft that
actions taken based on this scheme ought be logged or
otherwise publicised as a possible way to provide some
level of accountability, even if only after the fact?

[Ballot comment]

- 3.2: It isn't clear to me how one might exercise
"extreme caution" here - can you explain? Or is that
obvious to the intended audience of this?

[Ballot comment]
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.]

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

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

Working Group Summary

The working group had decent discussion on this draft and consensus on content/intent.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The proposal does not include code requirements, but does include use of a (proposed) standard bgp community 'BLACKHOLE' to accomplish a task (discard traffic inside the IXP fabric or connected networks).

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: christopher.morrow@gmail.com
AD: joelja@bogus.com

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I read the document more than one time (once at initial request, once during WG review, once just now), I believe it's well enough written and describes a solution to a problem which some folk have.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I don't have any concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

I don't believe there are portions of the document which require special review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I don't have any concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

consensus was as solid as ever in GROW.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no threats of appeal were lodged or hinted at during the process.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are some style nits which can get cleaned up before final submission to the editor, and a reference which will surely change by the time of editor-queueing.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

no reviews required.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

no normative references.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

no

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

no

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section requests registration of a single well-known community, nothing special.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

no new registries are required.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no automated checks were required.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-grow-blackholing-00.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the BGP Well-known Communities subregistry of the Border Gateway Protocol (BGP) Well-known Communities registry located at:

https://www.iana.org/assignments/bgp-well-known-communities/

a single, well-known community is to be registered as follows:

Attribute Value: 0xFFFF029A
Attribute: BLACKHOLE
Reference: [ RFC-to-be ]

IANA understands that this is the only action that needs to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 


Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: grow-chairs@ietf.org, joelja@gmail.com, draft-ietf-grow-blackholing@ietf.org, christopher.morrow@gmail.com, "Christopher Morrow" , grow@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (BLACKHOLE BGP Community for Blackholing) to Proposed Standard


The IESG has received a request from the Global Routing Operations WG
(grow) to consider the following document:
- 'BLACKHOLE BGP Community for Blackholing'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-07-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

'Proposed Standard

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

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

Working Group Summary

The working group had decent discussion on this draft and consensus on content/intent.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The proposal does not include code requirements, but does include use of a (proposed) standard bgp community 'BLACKHOLE' to accomplish a task (discard traffic inside the IXP fabric or connected networks).

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: christopher.morrow@gmail.com
AD: joelja@bogus.com

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I read the document more than one time (once at initial request, once during WG review, once just now), I believe it's well enough written and describes a solution to a problem which some folk have.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I don't have any concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

I don't believe there are portions of the document which require special review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I don't have any concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

consensus was as solid as ever in GROW.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

no threats of appeal were lodged or hinted at during the process.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There are some style nits which can get cleaned up before final submission to the editor, and a reference which will surely change by the time of editor-queueing.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

no reviews required.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

no normative references.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

no

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

no

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section requests registration of a single well-known community, nothing special.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

no new registries are required.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

no automated checks were required.