Summary: Support I'm going to wade in here with a number of points:
Firstly, I buy the argument that it brings benefits to operator documentation (reducing the numerous communities we all have to learn down to one) , and as an operator myself, this makes me extremely happy. I don't think anybody disagrees with this one. I don't have anything authoritative to add about linking it (or not) to IXPs, suffice to say, regardless as to whether the draft has (or had) intentions to be linked, I want to point out that I disagree with those who are worried (or have fears about) what this could lead to. This is a discussion to have off (this) list I think. The main point seems to revolve around the community being well known and transitive, and the implications of this. I'll start by saying, that it seems that the author's intention is for this to not be transitive in most cases, due to the language in sec 3.2: "A BGP speaker receiving a BGP announcement tagged with the BLACKHOLE BGP community SHOULD add a NO_ADVERTISE, NO_EXPORT or similar community to prevent propagation of this route outside the local AS." But I can see why the authors might want the ability for this to be technically transitive, at the very least, it should be able pass through an IXP RS, though, I expect this can be achieved in any case by the RS operator, through some kind of hack to the RS. Also, there may be an agreement to pass the community between peers, especially in a design where there are networks in the middle which are passing routing information between smaller and larger operators (think transit aggregators, resellers etc..), but, this can also be hacked (using an operator internal community to transit the middle-man, for instance). Given the above, and the fact that it would require 'hacks' to realise this transitive nature, to ask the authors to reduce the scope to it being non-transitive, would render the draft somewhat impotent in these regards. I can see why there is resistance from the authors to do this. There is a point to make here concerning one of the normative references, RFC5635 (RTBH). This document, in its security considerations, states: "The techniques presented here provide enough power to cause significant traffic forwarding loss if incorrectly deployed" the document goes on to say: "It is imperative that the announcements that trigger the black-holing are carefully checked and that the BGP policy that accepts these announcements is implemented in such a manner that the announcements:(a) Are not propagated outside the AS (NO_EXPORT)." <snip> Now, the author(s) here are effectively saying "Be Careful!" and "scope your announcements". In the case of somebody following this document (to do RTBH) , but making use of the proposed blackhole community, I would expect a level of care to be exercised. If the announcement is not intended to be transitive, then I would expect it to be correctly scoped (and its scope restricted with NO_EXPORT if need be). Still, this is for the transmitter of the prefix, what about the receiver(s)? In the draft, the authors (in section 6) , state: "In order to further limit the impact of unauthorized BGP announcements carrying the BLACKHOLE BGP community, the receiving BGP speaker SHOULD verify by applying strict filtering (see section 6.2.1.1.2. [RFC7454]) that the peer announcing the prefix is authorized to do so. If not, the BGP announcement should be filtered out. " This is a pretty clear message for a potential receiver. They should be filtering, and they should confirm authority when dealing with this community. Still, the draft, in Section 4, goes on to say: "Without an explicit configuration directive set by the operator, network elements SHOULD NOT discard traffic destined towards IP prefixes which are tagged with the BLACKHOLE BGP community." So, even if the receiver receives the prefix, the operator must make an explicit configuration to cause traffic to be dropped. This is yet a third layer of protection, and , just a reminder about the text in 3.2, they also have strong advice to make it non-transitive where it doesn't make sense. With the above in mind, I think the authors have taken steps to mitigate a disaster, and I feel credit should be given here. I think at this point, I'd ask detractors to provide some constructive and comprehensive advice to the authors about what they should be doing next. At present, please consider this a vote of support. Dave. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
