<div dir="ltr">Hi Ondrej!<br><br>Your analysis is correct, based on RF7999, considering the Well-Know BlackHole community.<br><br>But each Autonomous System can have its own Traffic Engineering Communities, including RTBH.<br>This is a very useful resource for some type of reaction to attacks.<div><br>Let's say that I'm an ISP here in Brazil, and I'm Under some type of attack(a silly one).<br>A volumetric attack targeted a specific IP of that /24.<br>My Flow Analysis Tool alow-me presume that 90% of that attack comes from Asia.<br>I contracted a transit provider with very good Traffic Engineer Communities, and I even paid a bit more because of that.<br>One of the communities of that ITP could be "Remote Trigger this /32 only on Asia, and spread that announce to peers just over there."</div><div>An then my ITP would reannounce that /32 to IXPs in ASIA, removing his own specific community of selective Blackhole, and adding 65535:666.<br>(P.S. 

This  game gets even funnier with large communities.)   <br><br>So, resulting from that selective RTBH, I will need to deal only with 10% of the attack.<br><br>Is this an ideal solution? NO!<br>But what response to DDoS attacks is Ideal?<br><br>I Believe that the stupid war between attackers and targets will end when this war stops being profitable to attackers.<br>And one way to do that is to reduce the costs of responses to Attacks.<br><br><br></div><div>So, resuming the exposed:<br>- Yes, a route with well know RTBH community should not be propagated on eBGP.<br>- But it does not mean that 

a route with well know RTBH community needs to have a single hop AS-Path.<br><br>RPKI is Origin Validation, not Path Validation.<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 30 de mar. de 2021 às 11:22, Ondrej Zajicek <<a href="mailto:santiago@crfreenet.org">santiago@crfreenet.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Mar 30, 2021 at 10:04:08AM -0300, Douglas Fischer wrote:<br>
> It does make sense! A LOT!<br>
> <br>
> It is the only way I see that is possible to use RPKI as a source of<br>
> information to validate RTBH with the available information existent now.<br>
> <br>
> P.S.: I even mentioned some about that on SIDROPS<br>
> <a href="https://mailarchive.ietf.org/arch/msg/sidrops/vbfKT9yduwAtTNQVBoc5KCRPkmM/" rel="noreferrer" target="_blank">https://mailarchive.ietf.org/arch/msg/sidrops/vbfKT9yduwAtTNQVBoc5KCRPkmM/</a><br>
<br>
Hi<br>
<br>
I am not sure if the RPKI is reasonable way to validate RTBH. We have a<br>
request to implement check that ignores max length, so we did it in a way<br>
that was the least intrusive (which is in RPKI instead of in filtering<br>
code, although i suppose it could be done also there), but i still have<br>
doubts about its usefulness and i would like to get opinions of others<br>
about that. Here are my comments:<br>
<br>
Let's assume an IXP has member A who has customer B, who propagates some<br>
address range. Who is responsible for originating blackhole route for IP<br>
addres from such range propagated to the IXP? As i understood RFC 7999,<br>
received blackhole routes are not propagated further (due to NO_ADVERTISE<br>
or NO_EXPORT), therefore such blackhole route has to be originated by<br>
member A. Which means its AS_PATH whould end with ASN A and even loose<br>
RPKI check would fail, because RPKI record specifies prefix range owned<br>
by B. The workaround would be that member A could forge ASNs in AS_PATH<br>
to end with ASN B, but that is not a good idea.<br>
<br>
Or let's assume that an IXP has members A and B that both connect<br>
customer C and propagate its address range to the IXP. There are two<br>
routes for that range, let's assume that route through A is more<br>
preferred. But if member B generated blackhole route for IP address from<br>
such range, then such blackhole would be active even if associated route<br>
is less preferred to route from member A.<br>
<br>
My conclusion is that proper validation for blackhole routes should<br>
follow the same logic as validating flowspec rules, i.e. a blackhole<br>
route should be considered valid if received from the same router/AS who<br>
is next hop for selected covering route. With this rule, RPKI validation<br>
of blackhole routes is pointless, as they are implicitly validated by<br>
validating covering route.<br>
<br>
<br>
> That is the same concept that is used on IRR, right?<br>
> "If is BlackHole route is contained on the Route Objects on IRR, is<br>
> acceptable..."<br>
> <br>
> Em dom., 28 de mar. de 2021 às 10:42, Pier Carlo Chiodi <<a href="mailto:pierky@pierky.com" target="_blank">pierky@pierky.com</a>><br>
> escreveu:<br>
> <br>
> > Hello,<br>
> ><br>
> > first, thanks to the devs for 2.0.8!<br>
> ><br>
> > I see the option 'ignore max length' was introduced, and that it's<br>
> > possible to enable it at protocol configuration time.<br>
> ><br>
> > ignore max length switch<br>
> ><br>
> >     Ignore received max length in ROA records and use max value (32 or<br>
> > 128) instead. This may be useful for implementing loose RPKI check for<br>
> > blackholes. Default: disabled.<br>
> ><br>
> > I was wondering what other people's feelings would be about having a<br>
> > similar option available at validation time, more specifically as an<br>
> > argument of roa_check.<br>
> ><br>
> > If my understanding is correct, being the current option available only at<br>
> > protocol level, it means that all the ROAs that are present inside the ROA<br>
> > table are used as if the maxLength attribute is not set. This means that it<br>
> > wouldn't be possible to configure a filter to perform a strict OV check<br>
> > (where the maxLength is also taken into account) using ROAs from that table.<br>
> ><br>
> > Having that option available at roa_check time, the same table could be<br>
> > used to perform both strict validation and also a loose validation, for<br>
> > example depending on the presence of the BLACKHOLE BGP community:<br>
<br>
-- <br>
Elen sila lumenn' omentielvo<br>
<br>
Ondrej 'Santiago' Zajicek (email: <a href="mailto:santiago@crfreenet.org" target="_blank">santiago@crfreenet.org</a>)<br>
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, <a href="http://wwwkeys.pgp.net" rel="noreferrer" target="_blank">wwwkeys.pgp.net</a>)<br>
"To err is human -- to blame it on a computer is even more so."<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>