Hi, We use this option in production environment (2.0.7 with patches) , started in 2020. Some side effects: Doubled number of tcp sessions with validator, doubled number of roa tables (per each BIRD instanse). Wbr, Milkhail, MSK-IX Douglas Fischer пишет 30.03.2021 16:04:

It does make sense! A LOT!

It is the only way I see that is possible to use RPKI as a source of information to validate RTBH with the available information existent now.

P.S.: I even mentioned some about that on SIDROPS https://mailarchive.ietf.org/arch/msg/sidrops/vbfKT9yduwAtTNQVBoc5KCRPkmM/

That is the same concept that is used on IRR, right? "If is BlackHole route is contained on the Route Objects on IRR, is acceptable..."

Em dom., 28 de mar. de 2021 às 10:42, Pier Carlo Chiodi <pierky@pierky.com <mailto:pierky@pierky.com>> escreveu:

Hello,

first, thanks to the devs for 2.0.8!

I see the option 'ignore max length' was introduced, and that it's possible to enable it at protocol configuration time.

ignore max length switch

Ignore received max length in ROA records and use max value (32 or 128) instead. This may be useful for implementing loose RPKI check for blackholes. Default: disabled.

I was wondering what other people's feelings would be about having a similar option available at validation time, more specifically as an argument of roa_check.

If my understanding is correct, being the current option available only at protocol level, it means that all the ROAs that are present inside the ROA table are used as if the maxLength attribute is not set. This means that it wouldn't be possible to configure a filter to perform a strict OV check (where the maxLength is also taken into account) using ROAs from that table.

Having that option available at roa_check time, the same table could be used to perform both strict validation and also a loose validation, for example depending on the presence of the BLACKHOLE BGP community:

(pseudo-code follows)

# ... regular sanity checks done here...

if BLACKHOLE { if (roa_check(ignore_max_lenght=True) = ROA_INVALID) then { reject; } accept; } else { if (roa_check() = ROA_INVALID) then { reject; } accept; }

(Assuming ignore_max_lenght has default value == False.)

Does it make sense?

Thanks

Pier Carlo Chiodi

-- Douglas Fernando Fischer Engº de Controle e Automação

Hi Ondrej! Your analysis is correct, based on RF7999, considering the Well-Know BlackHole community. But each Autonomous System can have its own Traffic Engineering Communities, including RTBH. This is a very useful resource for some type of reaction to attacks. Let's say that I'm an ISP here in Brazil, and I'm Under some type of attack(a silly one). A volumetric attack targeted a specific IP of that /24. My Flow Analysis Tool alow-me presume that 90% of that attack comes from Asia. I contracted a transit provider with very good Traffic Engineer Communities, and I even paid a bit more because of that. 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." An then my ITP would reannounce that /32 to IXPs in ASIA, removing his own specific community of selective Blackhole, and adding 65535:666. (P.S. This game gets even funnier with large communities.) So, resulting from that selective RTBH, I will need to deal only with 10% of the attack. Is this an ideal solution? NO! But what response to DDoS attacks is Ideal? I Believe that the stupid war between attackers and targets will end when this war stops being profitable to attackers. And one way to do that is to reduce the costs of responses to Attacks. So, resuming the exposed: - Yes, a route with well know RTBH community should not be propagated on eBGP. - But it does not mean that a route with well know RTBH community needs to have a single hop AS-Path. RPKI is Origin Validation, not Path Validation. Em ter., 30 de mar. de 2021 às 11:22, Ondrej Zajicek <santiago@crfreenet.org> escreveu:

On Tue, Mar 30, 2021 at 10:04:08AM -0300, Douglas Fischer wrote:

...

It does make sense! A LOT!

It is the only way I see that is possible to use RPKI as a source of information to validate RTBH with the available information existent now.

P.S.: I even mentioned some about that on SIDROPS

https://mailarchive.ietf.org/arch/msg/sidrops/vbfKT9yduwAtTNQVBoc5KCRPkmM/

Hi

I am not sure if the RPKI is reasonable way to validate RTBH. We have a request to implement check that ignores max length, so we did it in a way that was the least intrusive (which is in RPKI instead of in filtering code, although i suppose it could be done also there), but i still have doubts about its usefulness and i would like to get opinions of others about that. Here are my comments:

Let's assume an IXP has member A who has customer B, who propagates some address range. Who is responsible for originating blackhole route for IP addres from such range propagated to the IXP? As i understood RFC 7999, received blackhole routes are not propagated further (due to NO_ADVERTISE or NO_EXPORT), therefore such blackhole route has to be originated by member A. Which means its AS_PATH whould end with ASN A and even loose RPKI check would fail, because RPKI record specifies prefix range owned by B. The workaround would be that member A could forge ASNs in AS_PATH to end with ASN B, but that is not a good idea.

Or let's assume that an IXP has members A and B that both connect customer C and propagate its address range to the IXP. There are two routes for that range, let's assume that route through A is more preferred. But if member B generated blackhole route for IP address from such range, then such blackhole would be active even if associated route is less preferred to route from member A.

My conclusion is that proper validation for blackhole routes should follow the same logic as validating flowspec rules, i.e. a blackhole route should be considered valid if received from the same router/AS who is next hop for selected covering route. With this rule, RPKI validation of blackhole routes is pointless, as they are implicitly validated by validating covering route.

...

That is the same concept that is used on IRR, right? "If is BlackHole route is contained on the Route Objects on IRR, is acceptable..."

Em dom., 28 de mar. de 2021 às 10:42, Pier Carlo Chiodi < pierky@pierky.com> escreveu:

...

Hello,

first, thanks to the devs for 2.0.8!

I see the option 'ignore max length' was introduced, and that it's possible to enable it at protocol configuration time.

ignore max length switch

Ignore received max length in ROA records and use max value (32 or 128) instead. This may be useful for implementing loose RPKI check for blackholes. Default: disabled.

I was wondering what other people's feelings would be about having a similar option available at validation time, more specifically as an argument of roa_check.

If my understanding is correct, being the current option available only at protocol level, it means that all the ROAs that are present inside the ROA table are used as if the maxLength attribute is not set. This means that it wouldn't be possible to configure a filter to perform a strict OV check (where the maxLength is also taken into account) using ROAs from that table.

Having that option available at roa_check time, the same table could be used to perform both strict validation and also a loose validation, for example depending on the presence of the BLACKHOLE BGP community:

-- Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."

-- Douglas Fernando Fischer Engº de Controle e Automação

On Tue, Mar 30, 2021 at 09:31:32PM +0200, Pier Carlo Chiodi wrote:

Hi,

...

Let's assume an IXP has member A who has customer B, who propagates some address range. Who is responsible for originating blackhole route for IP addres from such range propagated to the IXP?

FWIW, my understanding of "Local Scope of Blackholes" from https://tools.ietf.org/html/rfc7999#section-3.2 is that it's allowed to cautiously propagate a route tagged with BLACKHOLE when policies are explicitly in place between adjacent networks to treat those routes according to RFC7999.

If I got your example right, B originates the BLACKHOLE prefix to ask A to mitigate an attack that they are receiving. B announces it to A. A is a member of IXP, and it has peering relationships with peer n (n could be either another member or a route server). If there is an agreement between A and IXPn to treat BLACKHOLE routes according to RFC7999, in that case (according to my understanding) A could propagate that route to IXPn as it is, with AS_PATH "A, B". The origin AS would still be B. IXPn would be the one in charge of implementing the sanity checks to verify that the route is valid.

That is pretty clear, but i thought more about the other case - /32 address from B is DDoSed, link from IXP to A is saturated, and A does not wait for B to originate BLACKHOLE route, and originates it themselves and propagates it to IXP. Such blackhole route would have AS_PATH just 'A', so RPKI check would fail (as RPKI registered origin is B). Not sure if this is considered appropriate, but i would say that it is both intentionally valid (provider A says which traffic want and do not want to accept) and allowed by RFC 7999: o The announced prefix is covered by an equal or shorter prefix that the neighboring network is authorized to advertise. (A is authorized to advertise, but not originate such prefix) So my point/idea is that if this case is valid, then using RPKI-style checking for BLACKHOLE is broken idea anyway, and perhaops we should instead focus on implementing (IMHO) proper checking for BLACKHOLE routes, similar to one for flowspec validation: BLACKHOLE route received from A is valid if i have (RPKI-valid) regular route from A for network N covering the BLACKHOLE route and (optionally) such route is best route for network N. I am interested in opinions about this criterion of blackhole validity vs loose/ignore_max_length-RPKI criterion of blackhole validity. But that is probably more a question for SIDROPS mailing list.

The point I wanted to raise with my original message is that I believe the current implementation of 'ignore max length' might be a bit too loose.

That knob de-facto goes against the way RFC6811 works, and if I understand it correctly, it does it at a very global level, for all the ROAs inside the table. Having a ROA table where the maxLength of all the ROAs is

Yes, it is intended for creating separate ROA table just for loose RPKI OV.

On the basis of my experience, sometimes, having a handy solution to quickly solve reachability issues could be seen as the way to go, especially while under pressure, but that would cause more damage than it solves ;-) I believe that turning 'ignore max length' on, seeing that it "solves" the issue, and then forgetting about it could be a very easy and likely path in certain circumstances, and that it could undermine the benefits given by the whole global RPKI/OV deployment effort.

That is a possibility, and probably more likely than using per-roa_check() knob improperly.

To your point, I also believe that RPKI OV as per RFC6811 is not appropriate to handle blackhole requests. In a recent message to Sidrops we can read:

...

Work in under way to harmonize RPKI & BGP blackholing. The IETF's draft submission window currently is closed, but as soon as it opens, I will upload a document detailing a possible way forward. (1 or 2 weeks from now)

(https://mailarchive.ietf.org/arch/msg/sidrops/v0tVaVcT2WHe9vW2x_GKg52KX-E/)

It will probably take a bit of time before a solution based on the above will be ready for production, but I believe that in the meantime it could be worth exploring other less intrusive methods to satisfy the request you received, without weakening RPKI OV "too much".

If the desire is to really tweak OV in a way that it could deal with such blackhole routes, I'd suggest rethinking the way that config knob is used today.

We just heard feedback on this list where the author mentioned the need of dealing with multiple ROAs tables. This seems very suboptimal to me. What do you think about moving that knob to roa_check?

Could be done, but adding optional arguments is problematic due to limitations of scripting language, so perhaps just add another operation called roa_loose_check().

Another more drastic proposal could be to just drop the config knob completely and keep the OV implementation secure, leaving it up to other forums to come up with a solution, agreed upon by the community.

I am interested in alternate solutions (like flowspec-style validation as i suggested above). -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."