90
SECURE BORDER GATEWAY PROTOCOL USING TIGER
ATTACKS
P.GIRIJA1, G.SARANYA2, S.KOUSALYA3 1,2,3
ASSISTANT PROFESSOR-CSE
A.S.L PAULS COLLEGE OF ENGINEERING AND TECHNOLOGY, Coimbatore
Abstract—Border Gateway Protocol (BGP) is vulnerable to routing attacks because of the lack of inherent verification mechanism. Several secure BGP schemes have been proposed to prevent routing attacks by leveraging cryptographic verification of BGP routing updates. In this paper, we present a new type of attacks, called TIGER, which aims to invalidate the “proven” security of these secure BGP schemes and allow ASes to announce forged routes even under full deployment of any existing secure BGP proposal. By launching TIGER attacks, malicious ASes can easily generate and announce forged routes which can be successfully verified by the existing secure BGP schemes. Furthermore, TIGER attacks can evade existing routing anomaly detection schemes by guaranteeing routing data-plane availability and consistency of control- and data-plane. Toward a new securing BGP scheme, we propose Anti-TIGER to detect and defend against TIGER attacks.
Anti-TIGER enables robust TIGER detection by collaborations between ASes. In particular, we leverage Spread Spectrum Communication technique to watermark certain special probing packets, which manifest the existence of TIGER attacks. Anti-TIGER does not require any modifications in routing data-plane, therefore it is easy to deploy and incrementally deployable. We evaluate the effectiveness of TIGER and Anti-TIGER by experiments with real AS topologies of the Internet. Our experiment results show that TIGER attacks can successfully hijack a considerable number of prefixes. In the meanwhile, Anti-TIGER can achieve 100 percent detection ratio of TIGER attacks.
1 INTRODUCTION
BORDER Gateway Protocol (BGP) is the de-facto protocol to ensure the inter-AS connectivity of the Internet. However, since BGP does not have built-in mechanisms to verify if a route is genuine, it suffers severe security plagues. Any AS (or BGP router) can announce a fake route, and its neighbors cannot verify if the route is valid. For example, on Feb. 24th, 2008, Pakistan Telecom (AS17557) started an unauthorized announcement of the prefix 208.65.153.0/24 [7]. One of Pakistan Telecom’s upstream providers, PCCW Global (AS3491), forwarded this announcement to the rest of the Internet, resulting in the hijacking of YouTube traffic on a global scale for more than two hours. Many similar traffic backholes and interceptions with active routing attacks and mis-configurations have been reported [1], [2].
In TIGER attacks, which aims to
launch routing attacks even with fully deployment of these “proven secure” BGP proposals. In TIGER, two ASes equipped with the existing BGP security mechanisms collude to generate forged routing paths, whose signatures can be successfully verified by other ASes. That is, with TIGER, any pair of colluding ASes can invalidate the existing idealized
BGP security proposals and launch routing attacks at will, e.g., generating routing blackholes or attracting traffic. For example, in Fig. 1, TIGER routers in AS3 and AS6 collude to build a tunnel session between them and generate a fake BGP link AS3-AS6 over the tunnel. In the meanwhile, they encapsulate the traffic from AS1 to AS7. Thus, AS1 cannot perceive the existence of the tunneled ASes, i.e., AS4, AS8, and AS7, in the traffic forwarding path to AS7. Through the tunnel session, AS3 and AS6 also can obtain the signatures of the routing updates from each other, which allow them to re-announce the routing updates with the “correct” signatures generated by S-BGP or S-BGPsec. For example, as shown in Fig. 1, AS1 receives a routing update announcing the fake routing path {AS3, AS6}. In the meanwhile, AS1 can identify its “real” data-plane path to AS6 by probing packets, e.g., using trace route. Since the colluding ASes can encapsulate the probing packets, the forwarding route returned by trace route is valid and consistent with the routing updates.
2 BACKGROUND: BGP SECURITY 2.1 Objectives of Attacking BGP
91
2.2 Securing BGP Proposals
Aims to provide similar security guarantee,
i.e., authenticating prefix origin and routing paths
3 DESIGN OF TIGER
3.1 TIGER: Stealthy Routing Attacks
(1) Routers in the colluding ASes, i.e., R1 in ASx and R3 in ASy, build tunnels, e.g., IP-in-IP tunnels [29],
Generic Routing Encapsulation (GRE) tunnels [12], or Layer two Tunnel protocol (L2TP) tunnels [31], between themselves. With the tunneled traffic, R1 and R3 have a virtual link between them.
(2) R1 and R3 build a BGP session (called a
TIGER session) with each other with the tunnel link ASx-ASy. That is, the network operators in ASx sets R3 as R1’s BGP peer in BGP session configuration, and the operator
in ASy sets R1 as R3’s BGP peer in BGP session configuration.
4 DETECTING TIGER ATTACKS: ANTI-TIGER
4.1 Challenges in Detecting TIGER
1) Valid signatures for forged routing paths. TIGER attacks allow colluding ASes to generate fake links with valid signatures with traditional secure BGP proposals [15], [20], [26], [32], [35], thus produced forged routing paths also have valid signatures from the point view of victim ASes. Therefore, these fake routing paths can be successfully verified and adopted by the ASes deployed with the existing secure BGP proposals, e.g., S-BGP and BGPsec.
2) Tunneled forged routing paths. Traditional routing anomaly detection schemes use probing packets to check the data-plane availability and consistency between control- and data-planes . Under TIGER attacks, all traffic including probing packets from victim ASes to the specific destinations are tunneled and hijacked by colluding ASes.
Hence, all intermediate ASes are invisible to the victim ASes and they cannot identify any anomaly in routing by probing. Therefore, these routing anomaly detection mechanisms also cannot detect TIGER attacks. Furthermore, probing packets may be tampered by adversary ASes to evade attack detection. Hence, any detection result may not be trusted to victim ASes. 3) Verifiable data-plane availability for forged routing paths.
4.2 Overview of Anti-TIGER
4.2.1 Key Observations
There is a fundamental difference between a forged routing path generated by the TIGER attack and its genuine routing path—the forged routing path uses one or more fake links produced by tunnels to deliver control- and data-plane traffic. All the intermediate ASes in the tunnel between ASx and ASy are involved in forwarding traffic from ASx to ASy or from ASy to ASx. However, if ASx-ASy is a genuine link, the traffic between ASx and ASy should be sent directly to each other.
4.2.2 Design Overview
To address these issues, we propose Anti-TIGER, a monitoring service deployed in each AS to detect TIGER attacks. After deployed, Anti-TIGER connects the BGP routers in the AS to learn routing updates and monitors the traffic delivered by them, which is similar to deployment of route view routers to monitor routing updates [4].
5 DESIGN OF ANTI-TIGER 5.1 NAG Construction
Anti-TIGER constructs the NAG of each AS with AS-level topology according to routing updates with different prefixes (destinations), which is similar to existing AS graph construction schemes for routing attack detection [12].
5.2 Suspicious Traffic Detection
In Anti-TIGER, two types of traffic are treated as suspicious traffic: the traffic is apparently tunneled by tunnel protocols, such as IP-in-IP tunnels [29], GRE tunnels [12], and L2TP tunnels [31], or the traffic is manipulated and the traffic payload cannot be identified, e.g., payloads are encrypted. These traffic can be easily identified by the existing techniques, such as Netflow [3].
5.3.1 DSSS-Based Packet Watermarking
Anti-TIGER uses Direct Sequence Spread Spectrum [33] to transport watermark TIGER detection traffic between ASes. With this technique, the detection traffic is embedded into normal data flow such that only desired ASes can identify and capture the information captured in the watermark. This evades the interference from possible colluding ASes during detection.
5.3.2 TIGER Detection Protocol
In order to accurately and robustly detect TIGER attacks, we use a three-way protocol in TIGER identification, which includes two rounds of challenge and response operations.
92
atermark and send report traffic to the closest victim AS ASz that appears in its NAG. Consider that encoding watermark into normal user traffic may add jitter to the traffic, ASi can generate and encode traffic to different specific destinations and ensure that all these traffic gets into ASz. Since the watermarked traffic
is disguised as normal legitimate traffic, the colluding AS (ASy) cannot detect this communication.
(ii) Acknowledgement. ASz receives the
watermarked traffic and uses pre-shared PN code to decode the watermark. In general, they can use a set of PN codes to decode the watermarked traffic in parallel. Successful traffic decoding means that both ASes use the correct Pr (where Pt ¼ Pr) in the set of PN codes. Then, ASz can easily identify the sending AS. As acknowledgement, ASz generates a watermark and encodes it into traffic with PN code P0 t . The traffic destination ensures that ASi can capture the traffic. (iii) Identification. ASi captures the watermarked acknowledgement traffic from ASz using PN code P0.
5.4 TIGER Defense
Once an AS notices that it is a victim AS under a TIGER attack, its Anti-TIGER service generates a routing update to the BGP routers within the same AS. These routers can modify their routing policies by filtering routing updates to corresponding destinations, e.g., ASy in Fig. 3. This timely defends against the forged routing paths announced by ASy, and triggers routing path reselection, e.g., by assigning low preference values to the forged routing path in its routing table [16].
5.5 Attacks to Anti-TIGER
5.5.1 Routing Inconsistency Attack Since
Anti-TIGER leverages routing graphs for attack detection, it may be vulnerable to routing inconsistency attacks proposed in [14], where ASes announce shorter routing paths while using longer routing paths. Countermeasure. The detection mechanisms used in Anti- TIGER can be used to identify the routing inconsistency attacks. Similar to TIGER attacks, the routing inconsistency attacks cannot be prevented by existing secure BGP proposals since an announced shorter routing path in these
attacks is authentic.
It assume that link AS3-AS6 really exists. By launching an attack, AS3 announces the routing path {AS3, AS6} but uses the routing path {AS3, AS4, AS8, AS7, AS6}. Although the announced
shorter routing path has correct routing signatures, the routing path is still not “legitimate” because the routing path is not used for data forwarding. It is easy to see that the victim AS1 and the intermediate AS4 can collaborate to detect the routing inconsistency attacks using our three-way detection protocol. 5.5.2 Random Packet Delaying and Dropping
Colluding ASes may randomly increase traffic jitter or drop some traffic between intermediate ASes and victim ASes so that they can interfere in TIGER detection over convert channels
between them. sending to interfere in
communications between intermediate ASes and victim ASes. Countermeasure. Normally, each AS in the Internet is at least two-connected [9], [14], [12], which means that one AS cannot completely control the connectivity of its customer ASes (i.e., downstream ASes).
That is, it can select more than one neighbor to send watermarked traffic according its NAG. Note that, the traffic watermarked by PN code P0 r at a victim AS at the acknowledgement stage should be directly sent to a colluding AS to infer TIGER existence. The watermarked traffic can be set with different destinations and sent to different neighbors to guarantee that the corresponding ASes can receive the signals and reduce the possibility of interference from colluding ASes.
5.5.3 Routing Dropping Attack
In order to evade detections by Anti-TIGER deployed in intermediate ASes, colluding ASes can maliciously drop routing updates such that the intermediate ASes cannot construct complete NAGs. Countermeasure. Basically, as we discussed above, each AS in the Internet is at least two-connected, thus it can easily learn the link connecting colluding ASes and victim ASes by routing updates from other ASes. Hence, the effectiveness of this attack is limited. Actually, colluding ASes do not have incentives to launch such type of attacks because it may not have any effectiveness but impact their own routes. Specifically, to achieve routing dropping attacks, colluding ASes want to drop routing updates from all their direct and indirect downstream ASes that specify the existence of the links connecting the colluding and victim ASes.
7 EXPERIMENTAL EVALUATION OF TIGER AND ANTI-TIGER CAPABILITY
7.1 Methodology
93
We use the measured 830- node AS topology from the SSFNet project that is obtained from BGP routing table,3 which is referred to as the 830-set topology, and the measured real Internet AS topology from a CAIDA dataset4 to generate the graph of ASes. In the CAIDA topology, we focus on all the 34 ASes that contribute to the Router-Views repository and their neighbor ASes, which is referred to as the rv-set topology. These two topologies include tier-1 ASes, tier-2 ASes and other ASes, and the relationships between these ASes can set according to the CAIDA AS relationship report. Due to the limitations of inferring AS relationships [10], [11], the Internet AS topology constructed from CAIDA includes many isolated links. We remove these links in our experiments, and the resulting AS topology forms a sparse graph. Table 1 shows the number of links in these two subgraphs. Even though with these two subgraphs, we already obtain interesting observation and validate Anti-TIGER’s effectiveness. It simulate BGP routing polices on the Internet topology according to Gao-Rexford conditions [13]. Basically, ASes prefer routes from their customer ASes over from their peer ASes, and prefer routes from peer ASes over from provider ASes. For routes announced by the same type of ASes, they adopt routes with shorter path length. With these routing policies, each AS node can compute its routing paths to the rest of the Internet. Note that, due to the routing policy constraints, the graphs cannot ensure connectivity between all node pairs. TIGER attacks. We use three different strategies to launch TIGER attacks. We select 10 AS pairs with different outdegree
in the 830-set and rv-set subgraph as colluding ASes to launch TIGER attacks. We select 20 ASes with high and low outdegrees, and randomly select 10 AS pairs as well, which are referred to as high-attack, low-attack, random-attack, respectively. These ASes complies with the constraints that they have more than three neighbors. We investigate the number of ASes in the graph that are impacted by the attacks and measure the number of routing paths in each node that are hijacked by the TIGER attacks.
Anti-TIGER. In the experiments, we assume that all ASes deploy Anti-TIGER services and each AS builds its own NAG. Traffic between colluding ASes’ downstream ASes is delivered by the intermediate ASes concealed by the colluding ASes. We also assume that the colluding ASes delivery traffic hijacked from the victim ASes, which ensures that intermediate ASes can catch the tunneled traffic.
In particular, we evaluate the effectiveness of Anti-TIGER with collaborations between all intermediate ASes and the victim ASes that are direct downstream nodes of the colluding ASes.
7.2 The Impacts of TIGER Attacks
In this experiment, we evaluate the number of hijacked routing paths over which their traffic is hijacked. TIGER only hijacks routing paths at 17 percent nodes in the low-attack scenario. Since the colluding ASes in the scenario are lower tier ASes and has less customer ASes, and thus they hijack less routing paths. We observe that, in the random-attack and high attack scenarios, TIGER hijacks most nodes’ routing paths in the topology. Only about 11 percent nodes’ routing paths are not impacted by the TIGER attacks. There are 72 and 44 percent nodes in the rvset graph that have at least one routing path hijacked in the random-attack and high-attack scenarios. In the randomattack and high-attack scenarios, 23,932 are 108,422 routing paths are hijacked the TIGER attacks. Similar to the results in the 830-set topology, as AS in the random-attack scenario has more routing paths hijacked than ASes in the high-attack scenario. One thousand six hundred thirty three routing paths are hijacked in the AS. Note that, the number of hijacked routing paths by TIGER attacks may be restricted by the limitations of the inferred real AS topology. Many real eBGP links are missed in these AS topology [10]. These links may be highly preferred victim ASes to deliver packets. Therefore, colluding ASes may hijack more routing paths if TIGER attacks are launched in the whole Internet.
7.3 Anti-TIGER Effectiveness
In this experiment, we evaluate if Anti-TIGER can effectively detect Anti-TIGER attacks and investigate the detection ratio with different depths of NAG (the x value—the diameter of NAGs constructed by ASes). Recall that each AS needs to construct and maintain its NAG to identify victim ASes and then detect TIGER existence.
94
Internet that have more eBGP connectivity for each AS.
7.4 Effectiveness of TIGER Detection under Dropping and Delaying Attacks
In this experiment, we evaluate the detection ratio in the presence of routing dropping attacks, i.e., packet dropping and delaying attacks. These attacks impact TIGER detection because colluding ASes hinder the three-way detection protocol between intermediate and victimASes. Here, we consider three attack scenarios: (i) forward: packets from intermediate ASes to victim ASes are dropped or delayed by the colluding ASes; (ii) reverse: packets from victim ASes to intermediate ASes are dropped or delayed by the colluding ASes; and (iii) bidirectional: packets in both directions are dropped or delayed by the colluding ASes. We also consider the impact of x values on TIGER detections under these attacks.
7.5 Overhead of Anti-TIGER
In the meanwhile, an AS needs to share PN codes with all ASes that appear in its NAGs. Normally, a smaller value of x means that a NAG constructed in the AS only includes fewer ASes, which means that a smaller overhead is required to store the PN codes shared with these ASes. In our experiment, for one AS, we use 2 bytes memory to store the PN codes shared with each of other ASes in its NAG. In the 830-set AS graph, if each AS constructs two-NAG, 90 percent ASes only use less than 800 bytes to store the PN codes. For a better detection ratio, ASes need to have larger NAGs, e.g., constructing eight-NAG can reach near 100 percent detection ratio (in the absence of packet dropping and delaying attacks).
9 CONCLUSION
To propose TIGER attacks that successfully invalidate existing BGP security schemes, e.g., S-BGP and S-BGPsec. Internet ASes can easily hijack prefixes by launching TIGER attacks even though the network is fully deployed with BGP security schemes. In the meanwhile, existing routing anomaly detection schemes also fail to detect this new type of attacks. To address this issue, we propose TIGER to detect and defend against TIGER. Anti-TIGER is implemented with an efficient and robust three-way detection protocol by leveraging a traffic watermark technique, i.e., Direct Sequence Spread Spectrum. Anti-TIGER is implemented with an efficient and robust three-way detection protocol by leveraging a traffic watermark technique, i.e., Direct
Sequence Spread Spectrum. Our experimental studies show that Anti-TIGER can easily and accurately identify TIGER attacks in presence of interference from adversary ASes. We hope that this paper will force a rethink of secure BGP security design and shed light on designing a secure Internet routing. REFERENCES
[1] China’s 18-minute mystery. [Online].
Available:http://www.renesys. com/blog/2010/11/chinas-18-minute-mystery.shtml, 2010.
[2] Defending against BGP man-in-the-middle attacks.
[Online]. Available:
http://www.renesys.com/tech/presentations/pdf/ blackhat-09.pdf, 2009.
[3] Detecting IPv6 tunnels in an enterprise network. [Online]. Available:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps65 37/ps6553/white_p aper_c11-629391.html, 2013.
[4] The route view project. [Online]. Available:
http://www. routeviews.org/, 2013.
[5] Stealing the internet: An internet-scale man in the
middle attack. [Online].
Available:http://www.defcon.org/images/defcon-16/ dc16-presentations/defcon-16-pilosov- kapela.pdf, 2008
[6] TEAM CYMRU BGP/ASN analysis report. [Online].
Available: http://www.cymru.com/BGP/summary.html,
2013
[7] Youtube hijacking: A RIPE NCC RIS case study. [Online]. Available:
http://www.ripe.net/news/study-youtube-hijacking.html, 2008
[8] H. Ballani, P. Francis, and X. Zhang, “A study of prefix hijacking and interception in the internet,” in Proc. Conf. Appl., Technol., Archit., Protocols Comput. Commun., 2007, pp. 265–276.
[9] O. Bonaventure, C. Filsfils, and P. Francois, “Achieving sub-50 milliseconds recovery upon BGP peering link failures,” IEEE/ ACM Trans. Netw., vol. 15, no. 5, pp. 1123–1135, Oct. 2007.
[10] K. Chen, D. R. Choffnes, R. Potharaju, Y. Chen, F. E. Bustamante, D. Pei, and Y. Zhao, “Where the sidewalk ends: Extending the internet as graph using traceroutes from P2P users,” in Proc. 5th Int. Conf. Emerging Netw. Experiments Technol., 2009, pp. 217–228.
[11] X. Dimitropoulos, D. Krioukov, M. Fomenkov, B. Huffaker, Y. Hyun, k. claffy, and G. Riley, “As
relationships: Inference and validation,”
SIGCOMMComput. Commun. Rev., vol. 37, pp. 29–40, 2007.
[12] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina, Generic routing
encapsulation (GRE), RFC 2784, 2000.
95 [14] S. Goldberg, S. Halevi, A. D. Jaggard, V. Ramachandran, and R. N.
Wright, “Rationality and traffic attraction: Incentives for honest
path announcements in BGP,” in Proc. ACM Conf. Appl., Technol.,
Archit., Protocols Comput. Commun., 2008, pp. 267–278. [15] G. Goodell, W. Aiello, T. Griffin, J. Ioannidis, P. McDaniel, and A. Rubin, “Working around BGP: An incremental approach to improving security and accuracy of interdomain routing,” in Proc.
ISOC Netw. Distrib. Syst. Security Symp., 2003, pp. 75– 85.
[16] X. Hu and Z. M. Mao, “Accurate real-time identification of IP prefix hijacking,” in Proc. IEEE Symp. Security Privacy, 2007, pp. 3–17.
[17] Y.-C. Hu, A. Perrig, and D. B. Johnson, “Packet leashes: A defense
against wormhole attacks in wireless networks,” in Proc. Conf. Comput. Commun., 2003, pp. 1976–1986.
[18] G. Huston and R. Bush, (Jun. 2011). “Securing BGP with BGPsec,” The ISP Column. [Online]. Available:
http://www.cisco.com/web/
about/ac123/ac147/archived_issues/ipj_14-2/142_bgp.html [19] J. Karlin, S. Forrest, and J. Rexford, “Pretty good BGP: Improving BGP by cautiously adopting routes,” in Proc. IEEE Int. Conf. Netw. Protocols, vol. 14, no. 2, 2006, pp. 290–299.
[20] S. Kent, C. Lynn, and K. Seo, “Secure border gateway protocol,” IEEE J. Sel. Areas Commun., vol. 18, no. 4, pp. 582–592, Apr. 2000.
[21] N. Kiyavash, A. Houmansadr, and N. Borisov, “Multi-flow attacks against network flow watermarking schemes,” in Proc. USENIX Secur. Symp., 2008, pp. 307– 320.
[22] M. Lad, D. Massey, D. Pei, Y. Wu, B. Zhang, and L. Zhang, “PHAS: A prefix hijack alert system,” in Proc. USENIX Secur. Symp., 2006, p. 12.
[23] Q. Li, Y.-C. Hu, and X. Zhang, “Even rockets cannot make pigs fly sustainably: Can BGP be secured with BGPsec?” in Proc. NDSS Workshop Security Emerging Netw. Technol., 2014, pp. 1–6.
[24] Q. Li, M. Xu, J. Wu, P. Lee, X. Shi, D.-M. Chiu, and Y. Yang, “A unified approach to routing protection in IP networks,” IEEE Trans. Netw. Serv. Manag., vol. 9, no. 3, pp. 306–319, Sep. 2012.
[25] Q. Li, X. Zhang, X. Zhang, and P. Su, “Invalidating idealized BGP security proposals and countermeasure es,” Graduate School at Shenzhen, Tsinghua University, Shenzhen, China, Tech. Rep
No. 20140001, 2014.
[26] E. M. Lepinski, BGPSEC Protocol Specification, Internet-Draft draftietf- sidr-bgpsec-protocol-03.txt, IETF Secretariat, May 2012.
[27] Y. J. Pyun, Y. Park, D. S. Reeves, X. Wang, and P. Ning, “Intervalbased flow watermarking for tracing
interactive traffic,” Comput. Netw., vol. 56, pp. 1646– 1665, 2012.
[28] Y. Rekhter, T. Li, and S. Hares, A border gateway protocol 4 (BGP-4), RFC 4271, 2006.
[29] W. Simpson, IP in IP tunneling, RFC 1853, 1995. [30] L. Subramanian, V. Roth, I. Stoica, S.Shenker, and R. Katz, “Listen
and whisper: Security mechanisms for BGP,” in Proc. 1st Symp.
