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

Tue Jun 6 00:11:53 EDT 2023

Isn’t this why there is SLURM, RFC 8416, I think you should be able to
cause the RTBH feeds to be locally Valid from an RPKI point of view and
then prefer them in BGP. I think you could create 0.0.0.0/0 with max prefix
length 32 ROA for the RTBH feed ASNs. That or two /1 prefixes with a max
prefix length 32 ROAs, should do the trick, if I’m understanding your issue
correctly.

Hope that helps.

On Mon, Jun 5, 2023 at 21:29 Michel Py via ARIN-PPML <arin-ppml at arin.net>
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.
>
-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20230605/e13ba7df/attachment.htm>