<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">I recently sent this email(below) to the NLNetLabs RPKI list.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><a href="https://lists.nlnetlabs.nl/pipermail/rpki/2021-February/000261.html">https://lists.nlnetlabs.nl/pipermail/rpki/2021-February/000261.html</a>  <br><br>And I was recommended to bring this topic to sidrops.<br><br><br>I am not yet familiar with the M.O. of this community, so I apologize and accept guidance for any inappropriate behavior.<br><br>I am concerned to keep the healthy use of RTBH viable...<br>I know that this is not the best mechanism to solve problems with DDoS and similar.<br>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.<br><br>The purpose of this email is to present two possibilities that I have been imagining for some time as good measures for RPKI.<br><br>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.<br><br>-----<br>1 - Increase the levels, officially in the protocol, the status of a route based on the RPKI, Specially of Invalid Status.</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small">-----<br>In the email below, this concept is reasonably well described.<br>I kindly ask you to read this detail below.<br><br>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.<br><br>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.<br><br><br>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.<br><br>-----<br>2 - Add the possibility of using the "minimum prefix length" attribute in RPKI ROAs.<br>-----<br>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.<br><br>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.<br>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.<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:small"><br><br></div><br><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">Thanks in advance for your patience and comprehension.</div><br><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small"><span class="gmail_default"></span><span style="font-family:Arial,Helvetica,sans-serif">--</span></div><div dir="ltr" class="gmail_signature"><font size="2"><span style="font-family:"courier new",monospace">Douglas Fernando Fischer</span><br style="font-family:"courier new",monospace"></font></div><div class="gmail_default" style="font-family:"courier new",monospace;font-size:small">Engº de Controle e Automação</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>De: <strong class="gmail_sendername" dir="auto">Douglas Fischer</strong> <span dir="auto"><<a href="mailto:fischerdouglas@gmail.com">fischerdouglas@gmail.com</a>></span><br>Date: ter., 23 de fev. de 2021 às 08:14<br>Subject: IETF draft - The Use of Maxlength in the RPKI<br>To:  <<a href="mailto:rpki@lists.nlnetlabs.nl">rpki@lists.nlnetlabs.nl</a>><br></div><br><br><div dir="ltr"><div 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" target="_blank">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 style="font-family:courier new,monospace;font-size:small"><br>If (is into AS-SET My-Customer) and \</div><div style="font-family:courier new,monospace;font-size:small">   (has Black-Hole-Community) and \</div><div style="font-family:courier new,monospace;font-size:small">   ((is IPv4 and is /32) or (is IPv6 and is /128)) and \</div><div 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 style="font-family:courier new,monospace;font-size:small">   accept as Blackhole...</div><div style="font-family:courier new,monospace;font-size:small"><br></div><div 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 style="font-family:courier new,monospace;font-size:small"><br></div><div style="font-family:courier new,monospace;font-size:small"><br></div><div 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 style="font-family:courier new,monospace;font-size:small"><br></div><div style="font-family:courier new,monospace;font-size:small"><br></div>-- <br><div dir="ltr" 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>
</div><br clear="all"><div><br></div></div>