Wed, Aug 03, 2016 at 10:11:46PM -0400, Christopher Morrow: > 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.
or strike the language altogether. it is unnecessary. if it is their prefix and they want to blackhole it - whatever, their prerogative. > 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. I am not knowledgable of every facet of rpki, but I thought that it was possible to express /length-or-longer? But Randy has already pointed that rpki doesnt cover communities; to middle men can alter it. > > 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 :( and no-advertise is almost certainly wrong for most - it implies that you carry the traffic from a remote location to the penultimate hop before the customer only to /dev/null it there. > > >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? Not that I know of; orthogonal. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
