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.] _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
