Origin authentication a small step toward resolving BGP security issues
Although content verification, origin authentication and shared information can address aspects of BGP security, it's unlikely we'll be able to resolve the issues completely.
One of the crucial underlying protocols of the global internet -- and many other networks today -- is the Border Gateway Protocol.
Now in version 4, BGP provides reachability and loop-free paths for just about every corner of the world in computer networking terms -- from data centers and software-defined WANs to the fabrics of internet exchange points and the global internet itself.
Since the very beginning, however, worries about BGP security issues have persisted.
In recent memory, a number of incidents where reachable destinations, or prefixes, have been hijacked -- a network operator claims to have reachability to a destination it does not -- have highlighted the concerns over BGP security.
For instance, one possibility is to use a routing-level attack to target a secure connection over a protocol such as Transport Layer Security (TLS), as shown in the diagram below.
In this case, Host A would like to retrieve information -- perhaps a webpage or some financial data -- from Server B. The host will set up a three-way handshake to build a TLS connection. During this process, Host A will need to somehow validate the server's certificate. To do this, the host will attempt to reach a certificate authority.
An attacker reroutes traffic to Server C instead of Server B, thus compromising the integrity of the transmission path.
At this point, an attacker can begin the process of subverting the connection between the host and the legitimate server. The attacker subverts the routing system, so the address Host A has for the certificate server is redirected to some other server. This other server then validates the certificate using C's address, rather than Host A's. The host will build a connection with C believing it has a trust connection with B. The attacker can set up a corresponding connection with the original server, B, so traffic will now proceed in the following progression:
Host A sends encrypted traffic to C, believing C is the trusted, and correct, server.
The attacking server, C, unencrypts the data, records it, re-encrypts the data and sends it on to B.
B, thinking it is talking with the original host, sends an encrypted reply to C.
C receives this data, unencrypts it, records it, re-encrypts it and sends it on to A.
Neither A nor B can detect it isn't talking to the other in this situation; as routing has been subverted, the source and destination IP addresses appear to be normal, as do the certificates used to secure the session. A more secure routing system could help thwart such attacks by ensuring traffic is sent to the intended destination.
Linking BGP to the validity of the data won't work
The problem is getting such a secure routing system to work. There are two broad ways to think about the problem. The first is to ensure the proper operation of the routing system. For instance, in this network, if AS65000 could know the information it receives from AS65001 and AS65003 is semantically correct -- in that AS65002 sent the information to AS65001, and then AS65001 sent the information to AS65000 -- this validation approach might go some ways toward solving the problem.
This is precisely what BGPsec -- a set of standards produced through the Internet Engineering Task Force to improve BGP security -- provides. There are many problems with this approach, however.
First, there is no way to equate the correct operation of BGP with the validity of the data. For example, just because AS65001 once had a connection to AS65002 doesn't mean it does now. Information about the state of the protocol must keep pace with the protocol itself. BGP simply is not built to support this kind of semantic, as the information withdrawal within BGP is rather ad hoc. To make matters worse, proving the absence of information using any cryptographic system is quite difficult -- perhaps even impossible.
Second, there is no way to positively equate the proper operation of BGP, as a protocol, with the proper routing of packets through the network. Just because the BGP advertisement says traffic should be routed along the path AS65000, AS65001 and AS65002 to reach Server B, there is no particular reason the network must forward traffic along this path.
One of the strengths of packet-based networks is they can forward traffic along any path to reach a destination. This means traffic can be rerouted on the fly, based on local conditions. From a security perspective, however, this ability is a weakness. There is little indication anyone is willing to move back to a world of circuit-switched networks to solve the security problems inherent in packet-based networks.
Verifying the actual contents of the routing database
The second broad way to think about this problem is to attempt to verify the contents of the routing database. Moving in this direction necessarily moves from certainties to probabilities, because there is no way to know, for certain, what the routing table should contain or in which direction any individual router might send traffic. In this case, if AS65000 had information that AS65002 normally receives traffic through AS65001, rather than through the attacker's autonomous system (AS), or that AS65002 considered the path through AS65001 to be the best path, then AS65000's edge routers could reject the route through the attacker, AS65003.
Ultimately, the closest the internet community is likely to come to addressing BGP security issues is resolving 80% of the problem by using a combination of information sources.
Where would such information come from? First, there is origin authentication. The numbering authority that assigns AS65002's AS number and IP address space can authenticate these two things go together and that AS65002 should advertise a particular range of reachable addresses. This can be solved through the resource public key infrastructure system and through policy databases such as the Internet Routing Registry (IRR). This does not, however, resolve the problem of knowing that AS65002 prefers the connection through AS65001, rather than the one through AS65003.
If AS65002 is willing to put this information into an IRR database, this could provide the information AS65000 needs in order to understand which route is preferred. Otherwise, AS65000 will need to infer this information, primarily from historical data about internet connectivity, combined with policies found in various IRR databases. For instance, the RIPE Atlas tools can be used to infer network connectivity and the types of peering relationships among different network operators. The PeeringDB database can be used in this way, as well. The information contained in route-view servers and information gathered through tools such as OpenBMP -- which collects information sent between BGP speakers -- can provide information in this area, as well.
Ultimately, the closest the internet community is likely to come to addressing BGP security issues is resolving 80% of the problem by using a combination of information sources. No silver bullet is likely to ever exist that will solve this kind of problem for a large-scale, distributed packet-switched network run by a large number of entities.
