Subject: [GROW] Alvaro Retana's Yes on draft-ietf-grow-blackholing-02: (with COMMENT)

From: "Alvaro Retana" <[email-masked]>
Date: Tue, 02 Aug 2016 14:52:48 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-grow-blackholing-02: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/

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