On Wed, Aug 3, 2016 at 9:16 PM, Terry Manderson <[email protected]> wrote:
> Terry Manderson has entered the following ballot position for > draft-ietf-grow-blackholing-02: Discuss > > 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-hestitancyhestitancygrow-blackholing/ > <https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/> > > > > ---------------------------------------------------------------------- > 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'd note (and I'm surprised no one else noted already, especially you) this odd bit of language: (I'm mad I didn't see it earlier as well, actually) "It has been observed that announcements of IP prefixes larger than /24 for IPv4 and /48 for IPv6 are usually not accepted on the Internet (see section 6.1.3 [RFC7454]). However, blackhole routes should be as small as possible?" So: "Large prefixes == /24 or /48" but: "small prefixes == /32 or /128" err, small/large, long/short... there's inconsistent use of these terms here, I think. At the least it's a bit confusing. I'd have stuck with: "It has been observed that announcements of IP prefixes LONGER than /24 for IPv4 and /48 for IPv6 are usually not accepted on the Internet (see section 6.1.3 [RFC7454]). However, blackhole routes should be as LONG as possible" (I prefer longer/shorter for prefix stuff) So, back to your discuss though: "BGP speakers SHOULD only accept and honor BGP announcements carrying the BLACKHOLE community if the announced prefix is covered by a shorter prefix for which the neighboring network is authorized to advertise." (note that 'shorter' is used here...again making the above bit more confiusing with smaller/larger) MUST vs SHOULD for this, I do think the MUST would be easy to handle. Is this a problem in an RS situation? Probbaly not... on the RS, but on the distant peer, it likely is hard(er) to deal with. I don't imagine many folk prefix filter the RS session very tightly only because memberships come/go and you may not always get timely notice (I have no idea when people come/go at the IX's I connect to). So, SHOULD makes some sense to me, at least in the RS peer/distant-peer world. Surely for direct BGP peerings MUST is a better idea, I think. 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. > > job and I chatted a bit about this (oddly, prior to your note here) and one thing to keep in mind with RPKI is that the ROA Owner (publisher?) would have to first know their special-prefix was going to be attacked, then set the ROA up (as a /32 or as a supernet -> /32). I'm skeptical of that being done, certainly today there are virtually no /32 ROA in the system. RPKI probably isn't the tool to use here, for this. > 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 > > ... you trailed off... I bet it was something like:"gazed upon require/use NO-advertise on the ISP side and no-export on the customer side that's the recipe I setup when last i was an ISP... I think the hesitancy for 'MUST' there is that there are cases in use today where you would send a route-server the /32 + commnuity and WANT that to get to the remote peers. If the RS did 'no-advertise' the route won't make it to the remote peer :( I can also imagine that an ISP network may just accept the /32 with 'isp-blackhole-community' and for expediency reset next-hop to their blackhole, and ship that in IBGP so their mesh gets the data 'fast'. > > ---------------------------------------------------------------------- > 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? > > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
