<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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 class="moz-cite-prefix">On 05/06/2023 23:29, Michel Py via
ARIN-PPML wrote:<br>
</div>
<blockquote type="cite"
cite="mid:cb7a020148ef4fe8886cc287915d2a77@arneill-py.sacramento.ca.us">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@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:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}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]-->
<div class="WordSection1">
<p class="MsoNormal">Hi folks,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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"><o:p> </o:p></p>
<p class="MsoNormal">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">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">Also, there are numerous publicly available
ones such as :<o:p></o:p></p>
<p class="MsoNormal"><a
href="https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/"
moz-do-not-send="true" class="moz-txt-link-freetext">https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/</a><o:p></o:p></p>
<p class="MsoNormal"><a href="https://www.spamhaus.org/bgpf/"
moz-do-not-send="true" class="moz-txt-link-freetext">https://www.spamhaus.org/bgpf/</a><o:p></o:p></p>
<p class="MsoNormal"><a
href="http://arneill-py.sacramento.ca.us/cbbc/"
moz-do-not-send="true" class="moz-txt-link-freetext">http://arneill-py.sacramento.ca.us/cbbc/</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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">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"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-family:Consolas">c4321-michel#sh
ip bgp | beg 152.89.196.<o:p></o:p></span></p>
<p class="MsoNormal"><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"><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"><span style="font-family:Consolas">Origin
codes: i - IGP, e - EGP, ? - incomplete<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">RPKI
validation codes: V valid, I invalid, N Not found<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:Consolas">
Network Next Hop Metric LocPrf Weight
Path<o:p></o:p></span></p>
<p class="MsoNormal"><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"><span style="font-family:Consolas">N*
i 192.0.2.1 100 1
i <== CBBC<o:p></o:p></span></p>
<p class="MsoNormal"><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"><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"><o:p> </o:p></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.<o:p></o:p></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.<o:p></o:p></p>
<p class="MsoNormal">Unsurprisingly, Cisco says that doing
something about it is impossible.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Michel<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
</body>
</html>