<div dir="ltr">This ad hominem attack is uncalled for. Please desist and stick to the facts, which were very clearly and dispassionately laid out. If you have a technical or policy solution to the technical problem presented, please share. If not, casting aspersions on someone for their previously stated views on unrelated matters instead of engaging with the technical issues is very disreputable political behavior that should not be allowed on this list.<div><br></div><div>-Scott</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 5, 2023 at 7:45 PM Fernando Frediani <<a href="mailto:fhfrediani@gmail.com">fhfrediani@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>Hello Michael</p>
    <p>If I am not forgotten you are someone who strongly opposed IPv6
      sometime ago, called it a undue burden and seems to be fighting
      against it with all forces and stating clearly and you don't need
      it. Not surprised now by your email about  RPKI as well.</p>
    <p>Fernando<br>
    </p>
    <div>On 05/06/2023 23:29, Michel Py via
      ARIN-PPML wrote:<br>
    </div>
    <blockquote type="cite">
      
      
      
      <div>
        <p class="MsoNormal">Hi folks,<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">I am bumping into a dark side of RPKI
          prefix validation that actually increases risk to the network
          when deployed.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">As many others here do, I use BGP blackhole
          feeds (RTBH). This technique has been around for a long time.<u></u><u></u></p>
        <p class="MsoNormal">It is quite a common situation in some orgs
          to have the in-house SIEM/IDS redistribute blackhole prefixes
          via a BGP feed.<u></u><u></u></p>
        <p class="MsoNormal">Also, there are numerous publicly available
          ones such as :<u></u><u></u></p>
        <p class="MsoNormal"><a href="https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/" target="_blank">https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/</a><u></u><u></u></p>
        <p class="MsoNormal"><a href="https://www.spamhaus.org/bgpf/" target="_blank">https://www.spamhaus.org/bgpf/</a><u></u><u></u></p>
        <p class="MsoNormal"><a href="http://arneill-py.sacramento.ca.us/cbbc/" target="_blank">http://arneill-py.sacramento.ca.us/cbbc/</a><u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">When configuring RPKI validation, here is
          what happens. <a href="http://152.89.196.0/24" target="_blank">152.89.196.0/24</a> is a real-world example of a
          prefix that has been blacklisted by three different RTBH
          feeds.<u></u><u></u></p>
        <p class="MsoNormal">After implementing RPKI validation, it has
          generated some volume of firewall alarms for different type of
          attacks.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal"><span style="font-family:Consolas">c4321-michel#sh
            ip bgp | beg 152.89.196.<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-family:Consolas">BGP
            table version is 48156064, local router ID is 173.166.233.21<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-family:Consolas">Status
            codes: s suppressed, d damped, h history, * valid, >
            best, i - internal,<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-family:Consolas">Origin
            codes: i - IGP, e - EGP, ? - incomplete<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-family:Consolas">RPKI
            validation codes: V valid, I invalid, N Not found<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-family:Consolas">     
            Network          Next Hop            Metric LocPrf Weight
            Path<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-family:Consolas">I*   
            <a href="http://152.89.196.0/24" target="_blank">152.89.196.0/24</a>  192.0.2.1                0     90      0
            21719 I              <== Trusted RTBH<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-family:Consolas">N*
            i                   192.0.2.1                     100      1
            i                    <== CBBC<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-family:Consolas">I*                    
            192.0.2.1                0     40      0 65190 i
                         <== Spamhaus<u></u><u></u></span></p>
        <p class="MsoNormal"><span style="font-family:Consolas">V*>                   
            173.166.233.22                 30      0 1299 9002 57523 i
               <== Prefix from full feed<u></u><u></u></span></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">The problem here is that RPKI validation is
          at the very top of the BGP bestpath decision process, before
          weight and local-preference, without any way to change that.<u></u><u></u></p>
        <p class="MsoNormal">Therefore, the “Valid” status of the RPKI
          route affectively renders the RTBH feeds useless. No matter
          what manipulations of other parameters may be configured in
          route-maps, the RPKI status will override everything else.<u></u><u></u></p>
        <p class="MsoNormal">Unsurprisingly, Cisco says that doing
          something about it is impossible.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">Unfortunately, the “Valid” RPKI status
          presents no warranties whatsoever that the prefix is not used
          for rogue activities. Same as HTTPS certificates, crooks and
          spammers have realized that a ROA was a necessary part of
          doing their dirty business.<u></u><u></u></p>
        <p class="MsoNormal">This particular prefix is a well-known
          source of attacks; there are very valid reasons it is present
          in multiple BGP blackholes. Unfortunately, RPKI validation,
          combined with Cisco’s implementation, as provided bad actors
          with a tool to disable a blacklisting method that plenty of
          orgs are currently using.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">I am forced to disable RPKI prefix
          validation. To me, RPKI prefix validation does not bring
          enough value to compensate for the loss of the protection that
          the BGP blackhole feeds provide. Implementing RPKI validation
          has actually increased the volume of attacks on my network,
          attacks that were previously blocked right at the very edge.
          The risk increase is immediate : implementing RPKI validation
          is what made me look at these new firewall alarms. On the
          other hand, the gain is not immediately perceptible.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">In terms of public policy and ARIN, I think
          that there is a consensus that deploying RPKI validation is
          good for everyone. I am posting this so that the community can
          build an understanding of why it may not be deployed
          universally. I am not deploying it because I don’t want it or
          don’t understand it, I am not deploying it because it simply
          does not work for me. I don’t think I will be the only one in
          that case. It looked like a good idea on paper, but the
          impossibility to accommodate currently implemented security
          measures is a no-go.<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
        <p class="MsoNormal">Michel<u></u><u></u></p>
        <p class="MsoNormal"><u></u> <u></u></p>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.
</pre>
    </blockquote>
  </div>

_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>