ignore max length as an argument of roa_check

[Ondrej Zajicek]

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 at 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 at 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."