On 8/3/16 7:11 PM, Christopher Morrow wrote: > > > On Wed, Aug 3, 2016 at 9:16 PM, Terry Manderson > <[email protected] <mailto:[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).
public route servers can have quite well developed per peer prefix filtering, if it's built on route objects, the adjacent peers on the other hand probably do not since they don't know apriori what's on the other side all the time. likewise internal to a datacenter or a network under one span of control you may have quite relaxed import filtering between a bunch of private ASNs. but a very narrowly controlled export policy facing the world. > 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. you're not likely to do that for /128s in any event. > > 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? > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
