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@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > -- =============================================== David Farmer Email:far...@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 ===============================================
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
