ignore max length as an argument of roa_check

[Pier Carlo Chiodi]

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.

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
ignored makes that table unusable for strict origin validation, and in my
opinion poses an avoidable risk by creating an entity that could still be
consumed by roa_check for purposes that are different than the one we're
discussing in this thread, that is something-similar-to-origin-validation
for blackhole requests handling.

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.

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? That would allow to keep
only one ROA table, with all the bits in place to safely perform a strict
OV. roa_check could be changed to accept an additional argument,
ignore_maxlength, whose default value could be False. Additionally, the
code that takes ignore_maxlength=True into consideration could be
implemented to kick in only when BLACKHOLE is attached to the route being
processed. In my opinion this could be a "good" trade-off solution to still
satisfy the original need, while keeping the behaviour of roa_check
secure-by-default and not prone to misusage. This seems to me the "least
privilege" approach to prefer.

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. Discussing
this a bit with other people, they proposed the use of SLURM on the
receiving network side to tune the RPKI information in a way that the
BLACKHOLE routes could still be accepted. I understand that there may be
other implications on using a similar approach, which may collide with the
original requirement you had, but now that the outcome of the ROAs
processing is immediately reflected into the filters it could still be the
best trade-off between keeping a secure implementation, not prone to
misuse, and a solution able to satisfy the users requirement.

WDYT?

Cheers,

Pier Carlo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20210330/10dfab86/attachment.htm>