Can Canada’s Internet be hijacked?

One-hop trust protocols, like Border Gateway Protocol (BGP) or Signalling System 7 (SS7), are used to spread information around and control the working of the Internet. These protocols allow for things like the synchronization of data and the location and path to various elements.

However, these protocols don’t supply any information about the origin of the data or the path that the data took to get to you. All a system knows is that its neighbouring system provided the information. So, if you trust your neighbour, you trust what it tells you. Your neighbour is one-hop away. That’s one-hop trust. It’s a big game of ‘telephone’.

This is fine if your neighbourhood, or network, is closed and you know all of your neighbours. However as we’ve expanded the Internet, it is not possible to trust all of your neighbours because there ARE malicious agents on the Internet.

BGP specifically is vulnerable to hijacking and man-in-the-middle-attacks. An attacker can pretend to be something it is not (“I’m google – tell the world”) by either originating the announcement or modifying a path announcement that came from a neighbour.

However, an attack is only possible if the malicious provider goes unchecked by its neighbours. Currently, there are two fixes proposed for this problem:

1. Resource Public Key Infrastructure (RPKI) proposes to host a central database that shows the ownership of an Internet address, along with a cryptographic key to prevent tampering. So, a recipient of any BGP information could do a reverse check to see if the provider that originated the info is valid.

2. BGPSec proposes to have put a digital footprint on the information in every hop in the path 

3. – essentially a cryptographic stamp each time the information is relayed from provider to provider. With a full record of the information’s path, you could determine if a hop wasn’t the one you expected and could be malicious.

However, I think neither one of these fixes is likely to get implemented soon (if at all).

RPKI was launched a few years ago, and after an initial ramp-up, adoption has flattened out. Only a handful of providers have registered their addresses or are checking. The main difficulty would seem to be the additional check required on data that you receive.

Currently the data is processed automatically and efficiently in routers. RPKI requires providers to implement a new system that does an offline (over-the-shoulder) check of the data. In addition, it can be defeated. Since it only verifies the owner of an address, all the attacker has to do is tie some false ownership to the information at the same time. Again, if the malicious provider’s upstream is not doing its job, it will accept the false info and circulate it.

So, value for effort is low.

BGPSec is likewise hobbled. It solves the problem of authenticating each hop in the path, which should prevent the attacker from lying about the origin, however it DEPENDS on RPKI adoption. In addition, it would require a replacement of BGP – so all carriers would have to stop using the current version of BGP and start using a new version (or they could run two systems in parallel). Lastly, it only works if everyone does it. If anybody in the path does NOT support BGPSec, the system is designed to throw away all security information and continue using the old, insecure BGP.

This fix suffers from a completeness problem. Everyone has to do it (and that’s unlikely), or it doesn’t work.

What to do?

The potential damage from a massive BGP hijacking problem is fairly significant, so it doesn’t seem reasonable just to give up, and it doesn’t look like we have a good technical solution to try.

In essence, this was the point of my Calgary B-Sides talk in April. I discussed a community-based approach: For a country like Canada, with a reasonable number of providers and a common jurisdiction, it should be relatively easy to organize a system that limits BGP attacks on our own neighbourhood.

Each one of the providers in Canada hosts a limited number of networks (in the thousands each), and we all have one-hop or two-hop connections to each other. If we were able to share those networks with each other (like the RPKI registry), we could put filters on the rest of our Internet connections to block any false advertisements of these routes (like the path-verification of BGPSec). In essence, we’d be saying: only allow these 30,000 routes that represent Canada to come from the known connections we have between Canadian providers.

It is technically doable (configuration exists and is supported by vendors), it is organizationally doable (the security community among Canadian providers exists via the government-sponsored Canadian Telecommunications Cyber Protection working group) and there is a reasonable threat model to justify the effort.

Networking teams argue against this type of solution as it may affect the resiliency of the Internet. I don’t think resiliency is a real issue. The odds are low that a multiple point failure of this type would exist, and there is a reasonable mitigating control in the communications that we have between each other – we could call each other up and have the block removed if required.

In the end, there is a little risk, but the gain is a more stable Canadian network that is resilient to network hijacking.

At its heart, this is the type of decision that security professionals must make. There are no absolutes and everything comes down to a threat/value assessment with the goal of reducing risk to an acceptable level.