On 5/08/2016, 1:12 AM, "Christopher Morrow" <[email protected]> wrote:
> > >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? > Suggested text: BGP speakers in a direct peering relationship MUST 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. In topologies where a Route Server or other distant-peer relationships, BGP speaker SHOULD accept and honor BGP announcements under the same conditions. >> >>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 :( > > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
