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
-- RPKI mailing list [email protected] https://lists.nlnetlabs.nl/mailman/listinfo/rpki
