On Wed, Aug 3, 2016 at 11:26 PM, Terry Manderson <[email protected]> wrote:
> > > On 4/08/2016, 12:11 PM, "Christopher Morrow" > <[email protected]> wrote: > > > >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 think then there is a difference here worth pointing out. It isn't a > "one size fits all" approach and the nuances are important. > > can you propose some text that the authors could inject? > > > >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. > > Agreed. Please explicitly state this. I could honestly see that someone > falling into the (sad) trap of: > A) we are being DDoS'd > B) we need to BLACKHOLE a.b.c.d/32 > c) Provider X says RPKI ROA first > D) DDoS'd, so can't push ROA == Fail. > > Moreover, if the BGP peer IS RPKI validating and the ROA is structured to > have a maxLength=/24 and the prefix owner wants to blackhole a particular > /32, the validation state would be INVALID. > > That implies that this technique is blocked by RPKI validation, yes? no? > I'm no expert on juniper/cisco in-code validation logic. If I am following > the logic correctly, if you want to blackhole by sending a more specific > blackhole tagged route to your BGP peer for blackhole purposes, that peer > must not do RPKI validation or the ROA needs to be setup in advance. Which > seems a non-starter for RPKI as nearly every ROA would then need a > maxLength of a /32 or /128 *JUST INCASE* an address within a least > specific prefix was targeted in a DDoS. > > >---------------------------------------------------------------------- > >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? > > > > Any feedback on the comment? > > nope, I think extended communities with 4byte-asn is a problem though :(
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
