SABRE against routing attacks

Routing attacks represent a significant security issue with the current internet and is quite common across the internet. These attacks change the destination of the data from the intended recipients by incorrectly redirecting the traffic between AS’s. Such attacks might have grave consequences in blockchain systems where an AS-level adversary can split the network into half using BGP highjacking. While surveying the various attacks that are possible on blockchain networks to ensure that Marlin protects against such attacks, we have come across “SABRE: Protecting Bitcoin against Routing Attacks” by Apostolaki et al which is a secure and scalable Bitcoin relay network which relays blocks worldwide through a set of connections that are resilient to routing attacks. The protocol is generic and can be applied to any blockchain protocol. In this post, we analyse the SABRE relay network which provides protection against routing attacks, ideas behind the design of SABRE as well as ways in which we can incorporate it as part of blockchain networks.

BGP Protocol

The Internet is a collection of individual networks called Autonomous Systems (ASes) which exchange information about how to reach the IPs in the individual networks using Border Gateway Protocol(BGP). Each AS selects one single best route to reach any IP prefix including self-owned ones, that it selectively exports to its neighbouring ASes with which it has business relations. There are 2 types of relations between neighbouring ASes.

  1. Customer - Provider/Transit: Here, the customer AS pays the provider AS to get full internet connectivity. The provider then provides connectivity by exporting all the best routes to its customers and exporting the prefixes(IP ranges) advertised by the customer to all its neighbours.
  2. Peer - Peer: ASes connect to transfer traffic between respective customers and internal users. So they only announce their own prefixes and routes learned from their customers to each other.

BGP prefers customer learned routes over peer learned routes because customers are paying for the service and any request whose path (IP) that matches with a customer route (IP range) will be preferred over peers. BGP also prefers peer learned routes over provider learned routes.

Customer > Peer > Provider

Specific paths are preferred over generic path i.e an advertisement for 7.0.0.0/8 is preferred over 7.0.0.0/24. If both paths are equally specific, then paths with minimum AS path length are selected.

BGP Highjacking

BGP routers do no validate route advertisements. So a malicious AS can fake advertisements for any prefix to its neighbours. This is known as BGP hijacking. Highjacks are very effective in redirecting traffic directed to given destinations. BGP highjacks can be divided into 2 types depending on what the fake announcement contains.

  1. Specific Prefix: Hijacker AS attracts all traffic independent of where it is in the internet topology as routers prefer more specific matching prefix
  2. Equally Specific Prefix: Hijacker competes with legitimate advertisement and the amount of traffic diverted depends on the relative position of the attacker and the victim in the internet topology

Specific prefix attacks are more powerful but because they are more visible as they are propagated to the whole internet while the equally specific prefix attacks are local as there is a competition between legitimate advertisement and the attacker one. A drawback on specific prefix attack is that network operators often filter out BGP advertisements who are more specific than /24. Thus with legitimate advertisements propagated with /24 are not affected by the Specific prefix attack.

SABRE

SABRE is a relay network which any Bitcoin node can connect to. It provides a channel for propagating blocks that is secure against routing attacks. SABRE doesn’t aim to replace the Bitcoin network but to augment it. So any Bitcoin node which is always connected to the SABRE network is secure against routing attacks.

Attacker model

A single AS level attacker whose goal is to partition the Bitcoin network into 2 disjoint components is considered. To do so, the attacker first diverts all the traffic using more specific prefix attack on the data that is supposed to reach either of the partition. Then the attacker identifies the Bitcoin connections by inspecting the network and transport layer headers and drops the connections bridging the partitions. This effectively results in the bitcoin network to split into 2 partitions. Such partitions reduce the security of the network by increasing the wastage of hash power which also leads to a revenue loss for miners.

As SABRE is a public network, it is assumed that the attacker knows the IP addresses of all the SABRE nodes and the code running on them. The attacker can perform a DDoS attack on the relay nodes or hijack prefixes hosting relay nodes and drop all the traffic.

Design Overview

SABRE depends on 2 key insights to guarantee connectivity

  1. Hosting nodes in inherently safe location
    Host SABRE nodes in locations that prevent attackers from diverting relay to relay connections which guarantees SABRE network integrity and also host in paths that are attractive to many Bitcoin clients (economic or efficient paths), thus reducing the likelihood that attackers will be able to intercept connections to relay network.
  2. Resiliency through software/hardware codesign
    As SABRE is a public network with known IP addresses, it is attractive for the attackers to DDoS the relay network to disrupt the connections to relay networks. However, relay operations are network heavy than being compute-heavy. This insight, along with caching, SABRE suggests can be used to offload operations to programmable network devices which can sustain tbps of load that might be produced by malicious attackers trying to DDoS.

Connection Security

Relays have to be placed in locations where attackers cannot divert traffic. The constraints on relayer placement for securing each type of connection in the network are shown below.

Relay to Relay Connections

Relay nodes should be placed such that relay to relay connections cannot be diverted by BGP hijacking. Following are some guidelines to make such redirections difficult.

  1. Provide a more specific prefix: SABRE nodes are hosted in /24 prefix ASes, so that a more specific prefix will be dropped by the routers.
  2. Provide a strictly better route with similar prefix: SABRE nodes are connected to each other by direct peering which ensures that the legitimate SABRE node route is one of the best paths in any case. SABRE also ensures that ASes hosting the relay nodes have no customers without which it is possible for a customer learned path to be preferred over the peer learned path.
  3. The attacker has to directly peer with ASes hosting relays: As the other peers in the SABRE network directly peer with each other, the attacker also needs to directly peer with the AS hosting relay node without which the attacker will not be able to provide a better path which limits the attackers who can perform such attacks.
  4. Chances of diverting relay connections decrease exponentially: SABRE requires the nodes to have multiple connections with other relays in the network. Assuming an attacker can provide an equally preferred path, then with a probability of 0.5 the attacker can disconnect the connection. For an attacker to disconnected a relay from the SABRE network, all connections have to be disconnected which means the probability of an attacker doing that is $0.5^k$ if the relayer is connected to $k$ other relays. So the chances of diverting relay connections decrease exponentially with connectivity.

So due to the above reasons SABRE network requires the relay nodes to

  1. be hosted in /24 prefix in AS
  2. host in AS with no customers
  3. have direct peering connections
  4. form a k-connected graph

which ensures that the client to client connections are secure against redirection by malicious actors.

Client to Relay Connections

As Bitcoin clients can join the Internet at any point in the topology, it is not possible to ensure that client to relay connections are secure against AS-level adversaries and active routing attacks.

SABRE tries to protect the client to relay connections by ensuring that relays are placed such that ASes with Bitcoin nodes prefer the advertisements of relays compared to any other malicious actor. By strategically placing the relay nodes, SABRE lowers the amount of traffic that can be diverted by a malicious AS.

As in the current Bitcoin network, the majority of clients are hosted by a small number of ASes making it possible to provide a high degree of security by using a small number of SABRE relay nodes.

Relay to Client Connections

An attacker might try to attack traffic from the relay to a Bitcoin client. The attack is harder as there are a lot more Bitcoin clients than relay nodes. SABRE makes the attack even harder by obfuscating the traffic and forcing the attacker to analyse the complete traffic that is diverted. Though we think it might not be very hard for the AS level attacker to filter the traffic by the client IP and drop all the connections.

Traffic is obfuscated by using a different IP to connect to peers in the Bitcoin network or the bitcoin client can connect to relay using a VPN/proxy thus making it hard for the attacker to detect Bitcoin traffic without analysing the complete traffic.

Hardware Software codesign

As SABRE is a public network, it avoids DDoS attacks by using very capable hardware which performs basic operations of serving the block to client even at huge request volumes or during a DDoS attack. As the same data has to be propagated to all the clients, a cache is used to serve the data. The operations like block verification which require high computation are elevated to the software agent. So a relay node consists of 2 components

  1. Controller
    Responsible for validating new blocks, advertising them to connected clients and updating switch memory.
  2. Switch
    Responsible for serving client connections, protecting the controller from a malicious client, propagating blocks and distinguishing old blocks from new blocks.

The switch contains some memory where it stores the peerlist, whitelist and blacklist. Peerlist contains the list of all connected peers. The whitelist contains peers that can communicate with controller directly, clients which have produced a valid block stay in the whitelist for 4 days. Blacklist contains the list of peers that have misbehaved and hence aren’t allowed to connect to the relay. The switch also contains the currently known hash to check if the received blockhash has not seen before.

Application to Blockchain networks

SABRE attempts to solve routing attacks in blockchain networks. SABRE also augments the blockchain p2p network rather than replace it. We feel that one of the downsides of SABRE to be used in blockchain networks is its usage of AS-level relay nodes which might not be easily accessible to every user. Another downside is the use of high-end networking hardware which might again be not accessible to a general user. Though the paper rightly mentions that the network has to be funded by large miners who are most affected from a network partition, it is not very practical for miners to coordinate and contribute to such network as it requires a significant driving force for such an action to be taken up by the mining community.