Last week I learned something about BitCoin that entirely changed my view on the urgency for implementing uniform security in the global routing system. While I value and appreciate that the Internet is made up of a network of independently owned and operated networks, I think there is compelling reason for network operators to peer over the parapet of their network borders and focus on routing security as a contribution beyond their own realm.
For most of the history of the Internet, the being in the routing business meant delivering packets on a “best effort basis”. In practical terms, as the Internet has gotten more commercially important, that has meant that individual network operators have focused on improving the efficiency and effectiveness of traffic within their own networks. For handoffs between networks (routing to the rest of the world), the emphasis has been on ensuring connectivity to well-positioned neighbour networks.
That point of handoff between networks is a vulnerable one. Sure, it’s reasonable to assume that a packet sent from Network A to Network B will successfully arrive at Network B. But, should it have been sent there? Is Network B going to hand it along to the appropriate next hop network on its way to its destination? Is Network B even rationally on a path from Network A to the intended destination of that packet? Historically, networks (e.g., Network A) have addressed those questions by choosing their neighbours carefully, ensuring solid terms in business relationships with them, and using their best operational knowledge to weed out suspicious paths for connections (routing advertisements).
To date, the cost of dealing with failure to detect bad paths (due to misconfigurations or malicious route hijacks) hasn’t been deemed to merit the expense and operational complexity of deploying the standardized technology for securing the routing system (RPKI-based origin validation (ROV) and BGPSec). In a large part, that cost/benefit analysis has been restriected by the mentality of focusing on local network borders and viewing hijacks as single path outages. So, one network falls off the Internet for a bit — as soon as the problem is detected, it can be addressed by an intervention updating routing tables to drop the broken announcement. Detection and remediation methods are, like all aspects of internal networking, completely up to the individual network operator to determine and implement. There are a number of competing theories for best practices, not all of which actually work together.
That approach has worked to date, even as the stakes have gotten higher. The Amazon Route53 DNS server attack earlier this year (https://blog.thousandeyes.com/amazon-route-53-dns-and-bgp-hijack/) was clearly designed to attract e-currency traffic, perhaps to gain passwords or to outright defraud unsuspecting customers of MyEtherWallet. Network operators with effective operational practices (e.g., supporting MANRS, https://www.manrs.org/ ) dropped the fake route advertisement, thereby limiting the exposure. But not every network supports those practices, and best practices have their limits of effectiveness.
However, last week at the RIPE 77 meeting, I heard something that I believe is a game-changer for routing security. Maria Apostolaki presented a clear outline of how to take down blockchain-based services, such as Bitcoin, with a relatively small number of route hijacks (“Routing Attacks in Cryptocurrencies”, https://ripe77.ripe.net/presentations/19-ripe_15_10.pdf). That is, the blockchain network could be rendered unusable with multiple, independent instances of the kind of attacks that network operators have, to date, handled on an operational case by case.
Bluntly: BitCoin-based e-commerce could grind to a standstill while every operator sifts through routing announcements to find and drop the hundred or so hijack announcements.
Now, we’re not talking about individual sites being compromised, or a handful of network operators with fumbled network updates. There is no single point of failure; no opportunity for a single “hero network” to fix the problem and save the day. The threat is for a pan-network attack to undermine a valuable distributed service, and the risk is real (given, for eg, the Route53 attack).
The only credible safeguard against this threat, and others like it that will follow as the services built on top of the Internet’s infrastructure become more complex, is to implement uniform, reliable, building-block technology to provide security in and of the routing system. And if RPKI-base ROV and BGPSec are not going to work for the world’s Internet network operators, then we need to understand why, and what better alternatives there are, yesterday.
The game has changed. It sure feels to me like it’s time to put away the toys, and build some tools that work to solve the problem of uniform, reliable, infrastructure security for the Internet’s routing system. I have to believe that network operators are doing the same math, and hope to see some concrete progress on improved routing security, soon.