[RPKI] IETF draft - The Use of Maxlength in the RPKI
fischerdouglas at gmail.com
Tue Feb 23 11:14:11 UTC 2021
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.
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...
More information about the RPKI