[arin-ppml] implementing RPKI prefix validation actually increases risk

[Scott Leibrand]

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.

-Scott

On Mon, Jun 5, 2023 at 7:45 PM Fernando Frediani <fhfrediani at gmail.com>
wrote:

> Hello Michael
>
> 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.
>
> Fernando
> On 05/06/2023 23:29, Michel Py via ARIN-PPML wrote:
>
> Hi folks,
>
>
>
> I am bumping into a dark side of RPKI prefix validation that actually
> increases risk to the network when deployed.
>
>
>
> As many others here do, I use BGP blackhole feeds (RTBH). This technique
> has been around for a long time.
>
> It is quite a common situation in some orgs to have the in-house SIEM/IDS
> redistribute blackhole prefixes via a BGP feed.
>
> Also, there are numerous publicly available ones such as :
>
>
> https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/
>
> https://www.spamhaus.org/bgpf/
>
> http://arneill-py.sacramento.ca.us/cbbc/
>
>
>
> 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.
>
> After implementing RPKI validation, it has generated some volume of
> firewall alarms for different type of attacks.
>
>
>
> c4321-michel#sh ip bgp | beg 152.89.196.
>
> BGP table version is 48156064, local router ID is 173.166.233.21
>
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal,
>
> Origin codes: i - IGP, e - EGP, ? - incomplete
>
> RPKI validation codes: V valid, I invalid, N Not found
>
>       Network          Next Hop            Metric LocPrf Weight Path
>
> I*    152.89.196.0/24  192.0.2.1                0     90      0 21719 I
>              <== Trusted RTBH
>
> N* i                   192.0.2.1                     100      1 i
>                    <== CBBC
>
> I*                     192.0.2.1                0     40      0 65190 i
>              <== Spamhaus
>
> V*>                    173.166.233.22                 30      0 1299 9002
> 57523 i    <== Prefix from full feed
>
>
>
> 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.
>
> 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.
>
> Unsurprisingly, Cisco says that doing something about it is impossible.
>
>
>
> 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.
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> Michel
>
>
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20230605/ef16f9f3/attachment.htm>