<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Menlo;
        panose-1:2 11 6 9 3 8 4 2 2 4;}
@font-face
        {font-family:"Times New Roman \(Body CS\)";
        panose-1:2 2 6 3 5 4 5 2 3 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:Menlo;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo">Hello everyone,
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo">The arin-ppml list is open to the general public, and provides a forum to raise and discuss policy-related ideas and issues surrounding existing and proposed ARIN policies.  ARIN maintains
 another mailing list , arin-tech-discuss where those interested in providing feedback or seeking information from ARIN or other community members about ARIN's services on a more technical level. Information on all the mailing lists maintained by ARIN can be
 found on the ARIN website at the following link. (arin.net/participate/community/mailing_lists/#public-policy-mailing-list)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo">As stated deeper in this thread, the NANOG list is a location where participants will be better suited to provide more meaningful feedback on your comments and questions.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo;color:black">Best regards,</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo;color:black"> </span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo;color:black">Brad Gorman</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo;color:black">Sr Product Owner, Routing Security</span><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo;color:black">American Registry for  Internet Numbers</span><span style="color:black"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:Menlo"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">ARIN-PPML <arin-ppml-bounces@arin.net> on behalf of Michel Py via ARIN-PPML <arin-ppml@arin.net><br>
<b>Reply-To: </b>Michel Py <michel@arneill-py.sacramento.ca.us><br>
<b>Date: </b>Monday, June 5, 2023 at 10:29 PM<br>
<b>To: </b>PPML <arin-ppml@arin.net><br>
<b>Subject: </b>[arin-ppml] implementing RPKI prefix validation actually increases risk<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in">Hi folks,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">I am bumping into a dark side of RPKI prefix validation that actually increases risk to the network when deployed.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">As many others here do, I use BGP blackhole feeds (RTBH). This technique has been around for a long time.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">It is quite a common situation in some orgs to have the in-house SIEM/IDS redistribute blackhole prefixes via a BGP feed.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Also, there are numerous publicly available ones such as :<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><a href="https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/">https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/</a><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><a href="https://www.spamhaus.org/bgpf/">https://www.spamhaus.org/bgpf/</a><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><a href="http://arneill-py.sacramento.ca.us/cbbc/">http://arneill-py.sacramento.ca.us/cbbc/</a><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">When configuring RPKI validation, here is what happens. 152.89.196.0/24 is a real-world example of a prefix that has been blacklisted by three different RTBH feeds.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">After implementing RPKI validation, it has generated some volume of firewall alarms for different type of attacks.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:Consolas">c4321-michel#sh ip bgp | beg 152.89.196.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:Consolas">BGP table version is 48156064, local router ID is 173.166.233.21<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:Consolas">Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:Consolas">Origin codes: i - IGP, e - EGP, ? - incomplete<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:Consolas">RPKI validation codes: V valid, I invalid, N Not found<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:Consolas">      Network          Next Hop            Metric LocPrf Weight Path<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:Consolas">I*    152.89.196.0/24  192.0.2.1                0     90      0 21719 I              <== Trusted RTBH<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:Consolas">N* i                   192.0.2.1                     100      1 i                    <== CBBC<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:Consolas">I*                     192.0.2.1                0     40      0 65190 i              <== Spamhaus<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-family:Consolas">V*>                    173.166.233.22                 30      0 1299 9002 57523 i    <== Prefix from full feed<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Unsurprisingly, Cisco says that doing something about it is impossible.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Michel<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</body>
</html>