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@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contacti...@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@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.
