<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">I don't know if this is the best forum to discuss this ...<br>If not, I apologize.<br><br>So far I was not aware of this draft, which already has 6 versions, and is heading towards the final version.<br><br><a href="https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-06">https://tools.ietf.org/html/draft-ietf-sidrops-rpkimaxlen-06</a>  <br><br>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 ).<br><br>Honestly, so far I am undecided as to whether this is the best methodology for such a solution.<br><br>Until now I was adopting (especially for route-servers) the methodology of further analyzing the possible status of RPKI.<br>- Valid -> 

complements do not fit

<br>- Unknown -> complements do not fit<br>- Invalid -> by previous ROA Date<br>- Invalid -> by Later ROA Date<br>- Invalid -> by ASN of Origin<br>- Invalid -> for less specific mask<br>- Invalid -> by more specific mask <br><br>Thus, in the route filtering tests received against Blackhole I was using the following logic:</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br>If (is into AS-SET My-Customer) and \</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">   (has Black-Hole-Community) and \</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">   ((is IPv4 and is /32) or (is IPv6 and is /128)) and \</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">   ((is RPKI Valid) or (is RPKI unknow) or (is RPKI invalid by mas more specific)) then \<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">   accept as Blackhole...</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">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.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">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.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><font size="2"><span style="font-family:courier new,monospace">Douglas Fernando Fischer</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">Engº de Controle e Automação</span></font><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;word-wrap:break-word;color:black;text-align:left;line-height:130%;font-family:courier new,monospace"></div></div></div>