[Sidrops] Improvements in RPKI ensuring backward compatibility - Would be possible?

[Douglas Fischer <[e-mail]>]

I recently sent this email(below) to the NLNetLabs RPKI list.
https://lists.nlnetlabs.nl/pipermail/rpki/2021-February/000261.html

And I was recommended to bring this topic to sidrops.


I am not yet familiar with the M.O. of this community, so I apologize and
accept guidance for any inappropriate behavior.

I am concerned to keep the healthy use of RTBH viable...
I know that this is not the best mechanism to solve problems with DDoS and
similar.
But in practice, it ends up being the most cost-effective tool for the
operator of the ASN itself that is being targeted by what I call "silly
attacks" to react and evade those attacks.

The purpose of this email is to present two possibilities that I have been
imagining for some time as good measures for RPKI.

Note: As I know that I am locked in the point of view of those who only see
the positive side of an idea ... I am open to seeing the negative side of
these ideas.

-----
1 - Increase the levels, officially in the protocol, the status of a route
based on the RPKI, Specially of Invalid Status.
-----
In the email below, this concept is reasonably well described.
I kindly ask you to read this detail below.

This is already possible to implement today if the protocol is "sliced" a
little, but it needs to be done using specific ROA validator engines, and
it needs to be done on a host that allows you to execute specific code,
which prevents this from being natively implemented and standard routers on
the market.

The idea is to give the ASN operator the autonomy to decide (on
routing-filter policies) what to do with some route, based on the detailed
RPKI status of that route.


P.S .: I have observed that other initiatives are inclined to go the same
way of further analyzing the status of the Route based on ROA. Unless
mistaken, there are discussions about this in projects involving some
Route-Server used by several IXPs to improve Police-Filtering of RTBH.

-----
2 - Add the possibility of using the "minimum prefix length" attribute in
RPKI ROAs.
-----
With that, I believe that the reality of the routes generated by the ASNs
would be better represented. In addition to allowing ROAs exclusively
created for RTBH and the like to be created.

Ex.1: An organization with an IPv4 / 16 block will rarely advertise this
block only with a single route. Whether for geographic reasons or for
routing strategy, it will probably advertise this in / 18-20 block.
Ex.2 .: This same organization may want to tell the world that Routes
originated by its own ASN, or by ASNs of scrubing companies, of the prefix
of this / 16 with the mask "LE 32" "GE 32" are valid.



Thanks in advance for your patience and comprehension.

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


Em ter., 23 de fev. de 2021 às 08:42, Ben Maddison <[e-mail]>
escreveu:

> Hi Douglas,
>
> On 02/23, Douglas Fischer via RPKI wrote:
> > I don't know if this is the best forum to discuss this ...
> > If not, I apologize.
> >
> The SIDROPS WG list would probably be a better bet, but we can start
> here!
>
> > So far I was not aware of this draft, which already has 6 versions, and
> is
> > heading towards the final version.
> >
> > https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-06
> >
> > As far as I could understand, the main reason for proposing this draft is
> > to enable a safe and fast way to make the security of the RPKI origin
> > validation also include the cases of RTBH ads that are generally of
> unique
> > IPs (/ 32 or / 128 ).
> >
> I think that you have misunderstood the intention of the draft, and in
> particular the latest version (which made substantial changes to the
> section that deals with RTBH).
>
> The point of the draft is to call attention to that fact that creating
> ROAs which permit the origination of more-specific prefixes than are
> usually present in the DFZ creates an attack vector that can be
> exploited by hijackers.
>
> E.g. if I create a ROA:
>     41.78.188.0/22, maxLength: 24, asID: 37271
> But then only originate:
>     41.78.188.0/22, AS_PATH 37271
>
> Then an attacker can announce:
>     41.78.191.0/24, AS_PATH 666_37271
>
> And will likely succeed in becoming the best path.
>
> It was observed that this issue is particularly present in ROAs where
> the issuer had made use of the maxLength field - hence the title of the
> draft.
>
> The draft also points out that because RTBH routes are typically for
> much longer prefixes, operators might be tempted to use maxLength to
> allow those routes to be ROV valid, and that doing so is a bad idea,
> because it creates the above attack vector.
>
> It doesn't try to propose any solution to the real issue of how ROV/RTBH
> should co-exist beyond that.
>
> If you think that any of the above could be made clearer in the current
> text, please feel free to propose changes.
>
> > Honestly, so far I am undecided as to whether this is the best
> methodology
> > for such a solution.
> >
> > Until now I was adopting (especially for route-servers) the methodology
> of
> > further analyzing the possible status of RPKI.
> > - Valid -> complements do not fit
> > - Unknown -> complements do not fit
> > - Invalid -> by previous ROA Date
> > - Invalid -> by Later ROA Date
> > - Invalid -> by ASN of Origin
> > - Invalid -> for less specific mask
> > - Invalid -> by more specific mask
> >
> > Thus, in the route filtering tests received against Blackhole I was using
> > the following logic:
> >
> > If (is into AS-SET My-Customer) and \
> >    (has Black-Hole-Community) and \
> >    ((is IPv4 and is /32) or (is IPv6 and is /128)) and \
> >    ((is RPKI Valid) or (is RPKI unknow) or (is RPKI invalid by mas more
> > specific)) then \
> >    accept as Blackhole...
> >
> > P.S.: This is a very summarized way to express the logic... I had to do
> > some gymnastics to implement it... Converting RPKI JSONs belonging to
> each
> > AS-SET to Prefix-lists.
> >
> That algorithm looks mostly sensible, and roughly similar to how we
> (AS37271) are planning to implement this in the next couple of months.
>
> However, I'd like to stress that is *not* proposed in
> draft-ietf-sidrops-rpkimaxlen.
> Doing that would require an update to RFC6811, and I would argue
> strongly against it!
>
> Cheers,
>
> Ben
>


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