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

[Douglas Fischer]

Sorry!

Please disregard this e-mail...

Em seg., 1 de mar. de 2021 às 08:46, Douglas Fischer <
fischerdouglas at gmail.com> escreveu:

> 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
>
>
> ---------- Forwarded message ---------
> De: Douglas Fischer <fischerdouglas at gmail.com>
> Date: ter., 23 de fev. de 2021 às 08:14
> Subject: IETF draft - The Use of Maxlength in the RPKI
> To: <rpki at lists.nlnetlabs.nl>
>
>
> I don't know if this is the best forum to discuss this ...
> If not, I apologize.
>
> 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 ).
>
> 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.
>
>
> So I would like to hear from other colleagues about this Draft, and it
> will change the way every ASN should filter RPKI, specially RTBH.
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/rpki/attachments/20210301/01cfe2d1/attachment-0001.htm>