On 4/08/2016, 12:11 PM, "Christopher Morrow" <[email protected]> wrote: > >---------------------------------------------------------------------- >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)
Ditto, and thanks for noticing that :-) > > >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. > >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. > > >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 > Yes, I did.. coffee called and I lodged the DISCUSS before finishing my text. Sorry. It was good coffee. And yes. That is what I intended to say. :) > >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. I think then that this nuanced usage needs to be captured here, and provide the rationale for doing exactly that. > >If the RS did 'no-advertise' the route won't make it to the remote peer :( > Granted. > > >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? > Any feedback on the comment? Cheers Terry
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
