[RPKI] IETF draft - The Use of Maxlength in the RPKI

[Douglas Fischer]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/rpki/attachments/20210223/4fe914d8/attachment.htm>