ignore max length as an argument of roa_check

[Douglas Fischer]

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


-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20210330/d1376252/attachment.htm>