Practical Security Approaches against Border Gateway Protocol (BGP) Session Hijacking Attacks between Autonomous Systems

The border gateway protocol (BGP) is the default inter domain routing protocol used on the internet for exchanging information between autonomous systems. Available literature suggests that BGP is vulnerable to session hijacking attacks. There are a number of proposals aimed at improving BGP security which have not been fully implemented. This paper examines a number of approaches for securing BGP through a comparative study and identifies the reasons why these proposals have not been implemented commercially. This paper analyses the architecture of internet routing and the design of BGP while focusing on the problem of BGP session hijacking attacks. Using Graphical Network Simulator 3 (GNS-3), a session hijack is demonstrated and a solution which involves the implementation of route filtering, policy-maps and route-maps on CISCO routers representing ASes is carried out. In the end, a workable industry standard framework for securing and protecting BGP sessions and border routers from exploitation with little or no modification to the existing routing infrastructure is demonstrated.


Introduction
The internet is a global decentralized network of networks comprised of end systems that originate or receive IP packets usually identified by IP addresses.
The internet started off as a US Department of Defense (DoD) network to connect scientists and university professors around the world [1]. The internet has transformed the computer and the communications world like nothing before: providing opportunity for worldwide broadcasting, mechanisms for information dissemination and a medium for collaboration and interaction between individuals and their computers without regard for geographic location. The internet consists of thousands of autonomous systems (AS) each owned and operated by a single institution [2]. Hence the internet can be said to be a conglomeration of autonomous systems that define the administrative authority and routing policies of different organizations. Autonomous systems are made up of routers that run interior gateway protocols such as Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), Intermediate system-Intermediate System (IS-IS) within their boundaries and interconnect via an Exterior Gateway Protocol. The current internet de facto standard EGP is the Border Gateway Protocol Version 4 (BGP-4) defined in RFC 1771 on 4 March 1995 by Rekhter et al. [3] and revised in RFC 4271 on 4 January 2006 by Rekhter et al. in 2006 [4]. Exterior Gateway Protocols such as BGP logically binds the ASes that make up the internet together by providing a mechanism for BGP peers to exchange route information. BGP unfortunately possesses some fundamental vulnerability that could be exploited to carry out different forms of attack capable of destabilizing the Internet. This paper sheds light on a number of proposals set forth towards addressing numerous other BGP problems and also attempts to propose a solution to BGP session hijacking by simulating a BGP session hijack and a countermeasure using GNS-3 (Graphical Network Simulator) simulator.
Session hijacking Session hijacking is when an attacker places himself in between the source device and the destination device. This is also known as the man in the middle attack.
BGP operates on trust. BGP speakers themselves inject bogus routing information either by masquerading as any other legitimate BGP speaker or by distributing unauthorized routing information as themselves. Hypothetically, we postulate that the problem of BGP session hijacking could be effectively mitigated through the strict enforcement of already known industry's best practices while utilizing the already deployed routing infrastructure. The solution we believe doesn't rest with overhead ridden protocol extensions such as Secure BGP (sBGP), Pretty Secure BGP (psBGP), Secure Origin BGP (soBGP) and a host of others, all of which rely on the use of additional layers of authentication and encryption. The overall effect is a protocol that is not commercially feasible due to the capacity of the existing deployed infrastructure which in most cases is not able to handle the sort of such overhead protocol extensions placed on it. In place of the several other protocols put forward for securing BGP sessions, we believe that the solution ensures that up streams (typically ISPs) of various ASes verifing their downlinks, i.e. the routers advertising routes through them, actually own the prefixes they are announcing. These uplinks must then set up filters to ensure that their downlinks are only allowed to advertise the routes that they own and nothing else. To buttress our view point, we design and implement simulations whose conclusions support our hypothesis. The simulations are implemented in Graphical Network Simulator (GNS-3) running standard industry deployed CISCO devices.

Current Proposals for Securing BGP
We analyze some major proposals aimed at securing BGP through a comparative analysis of a number of tools and approaches available for securing BGP-pointing out their strengths and weaknesses; while bringing to light the relevance of the intended research.

Tools for Securing BGP
A number of mechanisms for securing BGP have been developed which begin at the session level and also includes the tools that are used to protect the TCP session at both the sending and receiving end. According to Gill et al. [5] the TTL security mechanism is one such proposal that could substantially limit the effective radius of potential attack on the session. There are two tools to protect the BGP TCP session from external disruption that rely on the use of a cryptographic function.
These are the use of IPSEC at the IP level proposed by Kent et al. [6] and the TCP MD5 signature option at the TCP session level proposed by Rivest [7] and revised by Hefferman [8]. The MD5 signature option has some potential weaknesses when compared with IPSEC based on the assessment of Murphy [9] however the MD5 signature option is preferable to no form of TCP protection at all. The choice between IPSEC and MD5 is made by considering their key relative capabilities. No standard key rollover mechanism exists in MD5 as asserted by Behringer [10] alongside the cryptographic processing load it comes with; whereas the load of IPSEC processing is significantly higher than MD5 processing.
The cryptographic validation requirement of these two mechanisms provides room for a potential denial of service threat where a BGP speaker could be flooded with invalid messages each of which must be cryptographically processed before being detected as invalid and discarded [11]. In addressing the message integrity limitation, an approach is suggested by Schneier [12] which aims to provide transparent session level protection through the use of digital signatures. By this mechanism, a set of credentials is assigned that allows peers to verify the correctness of the information carried as the message payload in BGP.
The reason for the use of digital signatures instead of an integrity check which uses some form of shared secret key is due to the fact that the number and identities of all external recipients of the information is not known in advance [9].
Apart from being able to determine whether or not a message had been altered en route to the destination, a mechanism to actually verify the authenticity of the original information is necessary.
This meant that the digital signatures used had to be verified thus using some form of mechanism that authenticates the public key associated with an address prefix or an AS number [13].

Approaches for Securing BGP
A very significant contribution to this area is the secure BGP (SBGP) proposal by Kent et al. [14]. This happens to be one of the most complete contributions in this direction despite the fact that the assumptions relating to the processing capabilities of the routing equipment needed to run the protocol far exceeds what is available in real life.

Secure Border Gateway Protocol (sBGP)
The sBGP protocol places digital signatures over the address and AS path information contained in routing advertisements and defines an associated PKI for validation of these signatures. sBGP defines the correct operation of a BGP speaker in terms of constraint placed on individual protocol messages, including ensuring that all protocol UPDATE messages have not been allowed in transit between the BGP peers and that the UPDATE messages were sent by the peer is indicated. The basic security framework proposed in sBGP is that of digital signatures thus x.509 certificates and PKI's. This enables BGP speakers to identify and authorize other BGP speakers as well as AS administrators and address prefix owners. The verification framework for sBGP requires a PKI for address allocation, where every address assignment is reflected in an issued certificate [14]. In addition, sBGP proposes the use of IPSEC to secure the inter-router communication paths as well as the use of attestations. An address attestation is produced by an address holder, and authorizes a nominated AS to advertise itself as the origin AS for a particular address prefix.
There are a number of significant issues that have been identified with sBGP including the computation burden for signature generation and validation as well as the increased load in BGP session restart. There is also the issue of piecemeal deployment and the completeness of route attestations [15].

Secure Origin Border Gateway Protocol (SoBGP)
A refinement to the sBGP approach is secure origin BGP (SoBGP) proposed by White [16] in an effort to find a middle ground between the additional security processing overhead and the capabilities of deployed routing systems and security infrastructure. Here, the requirements for AS path verification are relaxed and the nature of the related Public Key Infrastructure is altered to remove the requirement for a strict hierarchical address PKI that precisely reflects the address distribution framework. The overall approach proposed in soBGP represents a different set of design trade-offs to sBGP, where the amount of validated material is a BGP UPDATE message is reduced. This can reduce the processing overhead for validation of UPDATE messages. In soBGP each local BGP speaker assembles a validated inter-AS topology map as it collects AS PolicyCerts, and each AS path in UPDATE messages is then checked to see if the AS sequence matches a feasible inter-AS path in this map. The avoidance of a hierarchical PKI for the validation of AuthCerts and EntityCerts could be considered a weakness in this approach, as the derivation of authority to speak on addresses is very unclear in this model.

Pretty Secure BGP (PSBGP)
Another refinement of the SBGP model is pretty secure BGP (psBGP) proposed by Oorschot et al. [17]. This approach represents a similar effort aimed at achieving a compromise between security and deployed capability through the introduction of a trust rating for assertions based on assessment of confidence in corroborating material. psBGP puts forward the proposition that the proposals relating to the authentication of the use of an address in a routing context must either entirely rely on the use of signed attestation that need to be validated in the context of PKI, or rely on the authenticity of information contained in Internet Routing Registries. The weakness of routing registries is that the commonly used controls in the registry are insufficient to validate the accuracy or the current authenticity of the information that is represented as being contained in a route registry object. psBGP allows for partial path signature to exist, mapping the validation outcome to a confidence level rather than a more basic BGP model of accepting an AS path only if the AS path in the BGP UPDATE completely verifiable. The essential approach of psBGP is the use of a reputation scheme in place of a hierarchical address PKI, but the value of this contribution is based on accepting the underlying premise that a hierarchical PKI for addresses is feasible. psBGP appears to be needlessly complex and bears much of the characteristics of making a particular solution for the problem, rather than attempting to craft a solution within the bounds of the problem space.

Interdomain Route Validation (IRV)
Another technique, inter-domain route validation (IRV) proposed by Goodell et al. [18] attacks the problem from a different angle by extending the existing model of Internet Route Registries into per-AS route registries. It attempts to replace the configuration of the BGP protocol with security credentials, in a query based credential retrieval system. The approach assesses the security function as an incremental overlay on the existing routing infrastructure.
This approach is midway between the strict AS path test of sBGP that validates that the UPDATE message was passed along the AS sequence described in the AS Path and the soBGP AS Path feasibility that validates that there is a set of AS peer connections that correspond to the AS sequence. Here the validation test is that each AS in the sequence is currently advertising this prefix to the next AS in sequence.
This IRV architecture has a number of issues that are not completely specified, including IRV discovery, IRV query redirection, authentication of queries and responses, selective responses, transparent layer protection and imposed overheads. It is unclear how an IRV response is to be validated, and how the relying party can verify that the received response originated from the IRV server of the AS in question, that the response has not been altered in any way, and that the response represents the actual held state in the queries AS. A similar concern lies in the estimation of additional overhead associated with performing a query to each AS in the AS Path for every received BGP update. It is also unspecified whether the query and response is a pre-condition for acceptance of a route would appear to offer a route robust form of security; it is also the case that IRV would be unreachable until the route is accepted.
There is no clear cut solution to the problem of routing security that attains a balance between security and acceptable deployment overhead [19]. Current research on BGP security focuses on the integrity, authenticity, and verifiability of routing information [20]. A more stable routing system capable of providing stable routing state is also capable of verifying routing information updates.
We believe the solution to BGP session hijacking does not necessarily rest with protocol extensions or modifications but rather the implementation of policy based routing such as the use of filters, route-maps and policy maps as well as a number of already known best practices in the service provider industry. This approach will require no additional hardware but what exist already and should guarantee a level of BGP session security at service provider level if implementation is efficiently done. Unlike the earlier suggested approaches to securing BGP, this approach focuses on the optimization of BGP configuration using Defensive Routing Policies from Cisco IOS to create a more robust BGP session better equipped to forestall session hijacking attacks while taking into consideration the processing capabilities of the existing routing infrastructure or equipment in other to prevent undue overhead associated with the implementation of other proposals for securing BGP.

Session Hijacking Simulation
Session hijacking involves intrusion into an ongoing BGP session by masquerading as a legitimate peer in a BGP session [21]. The difference as compared to a TCP reset attack is that session hijacking attack may be designed to achieve more than simply bringing down a session between BGP peers. The objective may be to change routes used by a peer or black holing [22]. In EBGP, neighbor routers add all routes they receive from their downstream neighbors into their routing table and then advertise those routes to the next hop. BGP session hijacking could occur when ISPs do not filter advertisements. An attacker could then hijack such an ISP and use their routers to advertise any prefix they want leading to a diversion of traffic or a black hole as the simulations would demonstrate. Session hijacking attacks could result in serious outages culminating in a complete loss of connectivity. Specific instances include the 2008 incident where at least eighty US universities had their traffic diverted to block access to their site from inside the country but accidentally black holed the route in the global BGP table [23]. In studying the session hijacking problem, case studies were developed that feature a number of routers representing ISPs and other autonomous systems connected together through EBGP peering. To successfully carry out the attack, a rogue AS (autonomous System) was included in the case study to advertise legitimate routes to its downstream neighbors creating a masquerade effect that causes downstream neighbors to forward traffic towards the rogue AS with the fake identity.
Routes forwarded to this AS by its downstream neighbors are not forwarded to the next hop address (router) consequently creating a Black Hole.
The purpose of this experiment is to demonstrate a Border Gateway Protocol (BGP) session hijack. To facilitate this demonstration, Graphical Network Simulator 3 (GNS-3) running Cisco routers have been employed.
The experiment consists of three main scenarios. 1) Scenario one-this depicts a normal BGP operation.
2) Scenario two-in this scenario the BGP session hijacking is demonstrated.
3) Scenario three-the third and final scenario shows how this session hijacking can be prevented.

Scenario Three-Solution
To prevent this particular kind of BGP session hijacking, it is imperative that all the up streams (typically ISPs) of the various ASes verify that their downlinks, i.e. the routers advertising routes through them, actually own the prefixes they are announcing. These uplinks must then setup filters to ensure that their downlinks are only allowed to advertise the routes that they own and nothing else.
In the case of this lab, R2, R8 and R4, the uplink providers of R7 check and implement filters to allow R7 to advertise only the routes that belong to that AS (Figure 1).

Scenario Two
A Rogue Router, R7, in as 700 begins to advertise a more specific route (20.20.20.0/22) than the 20.20.0.0/19 being advertised by R6. Due to the nature of routing protocols preferring longer/more specific prefixes, all the BGP routers now point to AS 700 to reach the 20.20.20.20/24 server. R7 originally does not have a server with the specified IP so traffic meant for that server coming from the BGP routers all end at R7's AS 700 and get dropped, essentially creating a "blackhole" for the 20.20.20.20/24 IP on the Internet. The "blackhole" is rectified by using an AS prepend to make the R7s path to the 20.20.0.0/19 network and ultimately the 20.20.20.20/24 server undesirable (Figure 2).

Conclusions
The objective of the above BGP session hijacking simulation is to bring to light the inherent vulnerability of External BGP (EBGP) sessions and the measures taken to mitigate this vulnerability. A typical EBGP peering between different ASes on the Internet is described. A setting in which a number of ASes serve as uplinks/upstreams, passing on routes from the ASes originating these routes from their local systems, unto the global Internet.
In each of the scenarios, the flexibility of BGP is demonstrated. Naturally, BGPs comprehensive stock of attributes allows routes to be altered, forwarded and dropped with relatively minimal fuss. The widely accepted notion that BGP can be tweaked to behave in many ways and choose any of several paths as it traverses the Internet making it difficult to pinpoint a particular behavior as malicious.
For example, in the above scenarios, R2 could modify the routes it receives from R1, its downstream peer to make them seems like that R2 was originating those routes. This might not necessarily constitute malicious behavior since R2 could do this to make some routes seem preferable to other routes that it receives from other peers.
Again Router, R3 could for instance drop routes originating from R1's AS, but forward every other route. BGPs nature therefore makes policing the protocol to identify inconsistent behavior not entirely straight forward. Concerns have been raised that perhaps it is about a different Inter-domain routing protocol with fewer "quirks" and a more well defined stable set of rules (in a security sense) developed to replace the already ubiquitous BGP. This argument might hold some merits considering the fact that BGPs flexibility is what allows for our attacker (R7) to surreptitiously manipulate routes in such a way as to suite its malicious intentions.
Verifying and filtering the routes advertised by immediate peers can go some way to make BGP a more secure Inter-domain routing protocol. However, this might be an exercise in futility unless all peers thereof participate in this process of verification and filtering of routes. The task of getting every provider to filter routes is daunting if it is not a seemingly improbable quest.
In conclusion, it is imperative to point out that although BGP might be inherently flawed mainly because the propagation of routes by peering ASes is based fundamentally on trust, and this undoubtedly raises several levels of security concerns. However, the tradeoff between security and BGPs presently unmatch ability to adapt and traverse myriad paths to re-establish lost connectivity that cannot be ignored. Hence, we believe the current protocol in use can be effectively tweaked to provide an adequate assurance of security without necessitating modifications to the existing routing infrastructure as demonstrated in our simulations.