The Implementation of BGP Monitoring, Alarming, and Protecting System by a BGP-UPDATE-Based Method using ECOMMUNITY in Real Time

Transcription

1 The Implementation of BGP Monitoring, Alarming, and Protecting System by a BGP-UPDATE-Based Method using ECOMMUNITY in Real Time Je-kuk Yun 1, Beomseok Hong 2, and Yanggon Kim 3 1 Information Technology, Towson University, Towson, MD, U.S.A. 2 Information Technology, Towson University, Towson, MD, U.S.A. 3 Computer Science, Towson University, Towson, MD, U.S.A. Abstract - As the number of IP hijacking incidents has increased, many IP hijacking monitoring tools have been implemented. However, none of the monitoring tools can directly control the data plane of BGP routers. Therefore, network administrators should protect their routers by using command line interface when the network administrator receives any warning from BGP hijacking monitoring tools. As the number of routers and prefixes continuously increased, checking the routing information in their routers manually is one of the big burdens on the administrators. In addition, when IP hijacking occurs, it is very important for the administrator to quickly block the bogus prefixes. Otherwise, thousands of traffic will be transferred to the wrong way within a very short moment. In this paper, we extended Quagga-SRx so that the Quagga-SRx can send a BGP update message including an opaque extend community to other ibgp peers for notifying bogus IP prefixes after detecting abnormal IP prefixes. As a result of this, the other ibgp peers can recognize bogus IP prefixes by accepting the BGP update message that includes the opaque extend community, and automatically blocks the bogus prefixes if the ibgp routers have an ability to process the opaque extend community. Therefore, when IP hijacking occurs, the bogus prefixes can be blocked automatically and quickly, which makes the ASes more secure. Keywords: BGP, border gateway protocol, interdomain routing, network security, networks, routing 1 Introduction The BGP is an Inter-domain routing protocol, and is the routing protocol that enables large networks to form a single Internet. The main functionality of BGP is to exchange Network Layer Reachability Information (NLRI) between Autonomous Systems (ASes) so that a BGP speaker can communicate with other BGP routers and ultimately can reach a destination of a certain router [1]. However, when the BGP was designed, its vulnerabilities were hardly considered [2]. Unfortunately, the lack of consideration of BGP vulnerabilities occasionally causes severe failure of Internet service provision. Such a failure called prefix hijacking causes attacks on the routing infrastructure or the control plane of the Internet. The prefix hijacking occurred on the 25th of April in 1997 by a misconfigured router that advertised incorrect prefixes and announced AS 7007 as an origin of them. As a result, it created a routing black hole for almost two hours [3]. Similar events occurred on the 22nd January in 2006, when Con Edison (AS 27506) stole several important prefixes by misconfiguring them [4], and on Christmas Eve 2004 TTNet in Turkey (AS 9121) advertised the entire prefixes on the Internet so that every route came to them rather than to the correct destinations [5]. The most well-known incident of prefix hijacking was the YouTube hijacking by Pakistan Telecom on the 24th of February in 2008, when in response to government order to block YouTube access within their country, Pakistan Telecom advertised a more specific prefix than the YouTube prefix. One router believes the Pakistan Telecom regarded the incorrect prefix as a more specific prefix and advertised it to the others. As a result, YouTube was not accessible from some ASes for a while [6]. Furthermore, Google was affected by a hijacking on the 9th of July in The reason of this hijacking was revealed as a copy and paste mistake by a network administrator. Next month Google was affected by another hijacking because AS30890 (EVOLVA Evolva Telecom s.r.l.), a provider from Romania announced the same prefix as Google's prefix which is /24 [7]. Such a prefix hijacking happens constantly on the Internet by mis-announcement or intentionally advertising malicious prefixes. In order to deal with the prefix hijacking and mis-announced prefix in a faster way, several monitoring tools have been developed such as PHAS, BGPmon, Cyclops, and Argus. However, none of the monitoring tools directly handle the data plane of BGP routers. Every time the malicious prefixes are found, the tools could only warn an administrator about the hijacking. In addition, the manual configuration would be a matter. Since the number of BGP routers and prefixes has increased steadily over the past years, we expect that the administrators need to check and manually block prefixes

2 more than they do now. On the other hand, when IP hijacking occurs, it is very important for the administrator to quickly block the bogus prefixes. Otherwise, thousands of network traffic will be transferred to the wrong way within a very short moment. In this paper, we extended the previous work [8] to automatically protect their ibgp peers by sending an update message that includes an opaque extended community as well as monitor bogus prefixes. Therefore, ibgp peers can be protected without the network administrator s manual configuration. We describe two main problems of BGP and a solution in Section 3. In section 4, we explain how the BGPMAPS works. In addition, we discuss the implementation of BGPMAPS and the result of BGPMAPS performance test in section 5. Lastly, we conclude the paper in section 6. 2 RELATED RESEARCH 2.1 Monitoring tools Prefix Hijack Alert System (PHAS) is a system that detects an attempt to hijack prefixes, owned by other BGP routers, with BGP routing data collected by BGP collectors and it notifies prefix owners of the hijack attempt through a reliable manner. However, PHAS does not guarantee to detect anomaly advertisements [9]. BGPmon is designed to collect a large number of data and provides real-time access with clients for real-time analysis [10]. The collected data is consolidated into a single XML steam that can be extended by clients for their purposes. Cyclops is a system that collects real-time updates of hundreds of routers and displays a graphic view of how the routers are connected to each other [11]. As a result, network administrators can use the tool to detect and diagnose BGP misconfigurations or BGP hijacking. Argus is an agile system that receives real-time updates from BGPmon and daily updates from CAIDA iplane. Based on the updates, Argus checks whether the update has an anomalous origin according to its local routing information database [12]. After finding the suspicious prefixes, Argus makes a final decision by computing the fingerprint for the suspicious prefixes. 2.2 BGP-SRx BGP-SRx, developed by the National Institute of Standards and Technology (NIST), consists of the SRx Server, the SRx API, and the Quagga SRx [13]. SRx provides a proxy with APIs, which allows the proxy to be embedded on the router and communicate with the SRx Server. The Quagga SRx is a software router on which the proxy is embedded. The SRx Server is connected to the RPKI validation cache, so the SRx Server can validate BGP announcements by comparing the BGP announcements to ROAs in the RPKI validation cache. 3 BGP THEATS AND SOLUTION 3.1 IP hijacking Once BGP routers are connected to each other, the BGP routers fully trust each other. If a BGP router intentionally originates a bogus prefix to neighbors, the neighbors that receive the announcement trust the prefix and their traffic is hijacked by the hijacking router. Fig. 1 shows that AS 500 is trying to hijack the traffic heading for AS 600. AS 600 announces /16 to neighbors and traffic heading for /16 is transferred to AS 600. However, if AS 500 announces a bogus prefix, /16, to AS 100, then the traffic in AS 100 goes to AS 500 because the number of hops to AS 500 is shorter than AS 600 s hops. As a result, AS 100 takes AS 500 as the destination for the /16. Fig. 1. IP prefix hijacking 3.2 Mis-announced route BGP doesn t validate announcements, so if an AS administrator unintentionally mis-types the length of a prefix or IP address, then any routers that receive the announcements trust the mis-typed length of the prefix or IP address. As a result of this, traffic in the routers that received the wrong announcements goes to the wrong destination. 3.3 Origin Validation Many studies have been conducted to solve IP hijacking, such as Secure BGP (S-BGP) [14], Secure Origin BGP (SO- BGP) [15], Pretty Secure BGP (psbgp) [16], Pretty Good BGP (pgbgp) [17], and so on. Secure Inter-Domain Routing (SIDR) working group completed Resource Public Key Infrastructure (RPKI) [18]. In order to prevent IP hijacking, the only BGP speaker that has been authorized by the IANA

3 should originate its prefixes. Therefore, BGP speakers should be authorized by the IANA. The IANA manages an officially verifiable database of the authorized IP prefixes and AS numbers. Therefore, BGP routers need to periodically retrieve the collection of the IP prefixes and AS numbers called Route Origin Authorizations (ROAs) [19] that consist of IP prefix, ASN, and maxlength. When a BGP router originates its prefix, the length of the accompanying prefix must be an integer less than or equal to the maxlength. Otherwise, the prefix is considered invalid. For example, if the IP prefix is /16 and the maxlength is 19, then the BGP speaker is authorized to originate /17, /18, or 10,30,0.0/19, not but /20. 4 IV. DESIGN OF THE BGPMAPS 4.1 Overview Fig. 2 depicts the simple architecture of the BGPMAPS. The ex-quagga-srx is connected to a BGP router with ebgp connection and learns routes from the BGP peers of other ASes. The ex-quagga-srx forwards the routes to the internal BGP routers and announces the internal routes of the AS to the BGP peers of other ASes. peers of the bogus prefix quickly and automatically when a bogus prefix is forwarded from BGP peers of other ASes, and (3) it should be a long living process. In the past decade, network administrators were worrying about the growth of the number of routes in the Internet because network routers have a limited memory capacity of storing many prefixes in the routing table. The router may need an extra space to save additional routing information for preventing IP hijacking. As the number of prefixes is increased, the results of the validation are saved in the local database instead of the main memory of the router. It is very important for network administrators to block bogus prefixes as soon as they detect the bogus prefixes. In case of a big company such as Google, YouTube, Amazon, and so on, a considerable number of Internet packets come and go every single second. However, the network administrators cannot keep paying attention to their routing table. Even though the administrators subscribe IP hijacking alarm service [10] and receive an alarm message through , it takes time for the network administrators to block the bogus prefixes by using command line interface. In order to detect the bogus prefixes and notify ibgp peers of the bogus prefixes, the opaque extended community attribute, which is including validation state, is added to the update message and the update message is forwarded to ibgp peers. 4.3 The architecture of the BGPMAPS Fig. 3 shows the architecture of the BGPMAPS. The BGPMAPS consists of the Extended Quagga SRx (ex- Quagga-SRx), Data Agent (DA), Alarm Server, and Web Service Agent (WSA). The ex-quagga-srx sends an update message to BGP peers and receives update messages from BGP peers through a BGP connection. Then, the ex-quagga- SRx sends update message information such as ASN, prefix, and maxlength to the SRx Server. Fig. 2. The simple architecture of the BGPMAPS In order to learn new routes from ebgp peers, the BGPMAPS is required to establish a BGP connection to the ebgp peers. Whenever the BGPMAPS receives a BGP update message, the ex-quagga-srx saves the result of the RPKI validation to the Data Agent as well as the routing table, such as ASN, PREFIX, AS_PATH, NEXTHOP, etc. In addition, the ex-quagga-srx forwards the update message that includes a new attribute of the opaque extended community to the ibgp peers for notifying the ibgp peers of the validation state of the update message. 4.2 Operational requirements In the design of the BGPMAPS, we consider three requirements: (1) it should store a large amount of prefixes history, (2) it should detect the bogus prefix and notify ibgp Fig. 3. The architecture of the BGPMAPS.

4 The SRx compares the update message information to the ROAs and returns the result of validation to the ex- Quagga-SRx. In case of ebgp peers, the Data Agent receives the result of the BGP update message from the ex-bgp-srx. If the result is invalid, the Alarm Server notifies the Alarm System of the invalid update message. Then, the Alarm System makes an alarm sound, and BGP router administrators can check the invalid update message through the web interface. The Quagga-SRx is connected to a BGP router via ibgp. Once the Quagga-SRx receives update messages, the Quagga-SRx sends a query to the SRx server and receives the result of the update messages. We extended the existing Quagga-SRx so that the Quagga-SRx saves the validation results of the update messages in the database. The Data Agent maintains and manages the validation results of update messages. When an invalid prefix is detected in the database, the Alarm Server makes an alarm sound through the Alarm System to warn AS administrators. The Alarm server sends signal to the Alarm System through TCP by using the IP address and port. The WSA provides AS administrators with a web interface that displays the validation result of update messages. The Alarm System is required to be installed in the AS that wants to receive the alarm service. When an invalid message is detected by the BGPMAPS, the Alarm System receives a signal from the Alarm Server. As a result, the AS administrator doesn t need to monitor a BGP routing table all the time to protect from IP hijacking. 5 IMPLEMENTATION AND PERFORMANCE TEST 5.1 Creating the Opaque Extended Community BGP speakers keep updating their routing table by sharing their routing through an update message. Fig. 4 shows the update message consists Withdrawn Routes Length, Withdrawn Routes, Total Path Attribute Length, Path Attributes, and Network Layer Reachability Information. The path attributes includes a number of attributes such as ORIGIN, AS_PATH, NEXT_HOP, COMMUNITY, EXTENDED COMMUNITY, and so on. The EXTENDED COMMUNITY attribute will contain opaque extended community to carry the validation state of the update message between ibgp peers. The opaque extended community is a work in progress by Secure Inter-Domain Routing working group and may be standardized on March An update message can include a number of Path Attributes. So if a BGP speaker receives an update message that includes a bogus prefix, then the BGP speaker adds the opaque extended community to the update message and forwards the update message to ibgp peers. The ibgp peers can know whether the prefix is hijacked by checking the opaque extended community. Fig. 4. The update message format 5.2 Notifying functions with update message An operation of notifying function is as follows (see Fig. 5) The ebgp peer announces an update message The Ex-Quagga SRx sends a query to the SRX Server for an update validation The SRX server requests ROAs to the RPKI Validation Cache The RPKI Validation Cache provides ROAs The SRx Server conducts RPKI validation by comparing a prefix and an ASN to ROAs The SRx Server returns the result of validation to the Ex-Quagga SRx The Ex-Quagga SRx saves the result of validation to the Data Agent The Alarm Server sends notification to the Alarm System according to database in the Data Agent The Web Server Agent provides web interface service by using the validation information provided by the Data Agent The Ex-Quagga SRx adds the opaque extended community to the update message The Ex-Quagga SRx forwards the update message to ibgp peers ibgp peers update their control plane according to the update message

5 Fig. 5. Sequence of detecting and preventing functions 5.3 Simulation of the BGPMAPS Fig. 6 shows a topology that includes four ASes and 6 BGP routers. AS 200, AS 300, and AS 400 include one router that doesn't have RPKI capability. AS 100 includes two routers that doesn't have RPKI capability and one software router that has RPKI capability, called Ex-Quagga-SRx. Through this topology, we explain how the Ex-Quagga-SRx automatically notifies ibgp peers of an invalid update message when the Ex-Quagga-SRx detects a bogus message. AS 200 originates /24 and the announcement is forwarded to neighbors. AS 300 originates /24, /24, and /24. Then, the announcements are forwarded to the neighbors, AS 200, AS 100, and AS 400. Suppose AS 400 hijacks the traffic heading for AS 300 by originating /17 to AS 200. Then, Ex-Quagga-SRx receives the bogus announcement and sends a query to the SRx Server to validate the bogus announcement. After detecting the bogus announcement, the Ex-Quagga-SRx creates the opaque extended community attribute, adds the opaque extended community attribute to the update message, and sends the update message to the ibgp peers. Then the ibgp peers can recognize bogus prefixes and will not select the AS 400 as the destination of /24. Furthermore, the Ex-Quagga-SRx saves the bogus announcement in the database. The Server monitors the database and automatically makes an alarm sound when the bogus announcement is discovered in the database. Once the sound of the alarm is made in AS 200, the AS 200 network administrator can realize that there is a bogus prefix in the BGP router. In addition, the AS 200 administrator can check the bogus prefix through the webpage that is provided by the BGPMAPS. As a result of this, the AS 200 administrator can ignore the bogus prefix in a short time. Fig. 7 shows the BGP table on the Ex-Quagga-SRx. The SRxVal shows the results of validation after the SRx Server validates the update messages. We created an eval column on the table to show the opaque extended community value. Fig. 6. Topology for simulation First, RPKI validation Cache includes 3 ROAs which are /24 300, /24 300, and / Fig. 7. Ex-Quagga-SRx BGP table

6 Fig. 8 shows the normal BGP table in case that the opaque extended community doesn t exist in the BGP update message. The normal BGP table indicates that the router will select AS 400 as the destination of /24 because the prefix /25 announced by AS 400 has longer prefix than /24 announced by AS 300. In that case, the AS 300 is hijacked and the traffic for will be transferred to the AS 400. TABLE I. THE NUMBER OF PREFIXES IN WHOLE AS Minimum Maximum Average Prefix(IPv4) Prefix(IPv6) Total We varied the number of prefixes and Fig. 10 illustrates the result of the performance test. When a router originates 1000 prefixes and the Ex-Quagga-SRx receives the prefixes, it takes 7.54 seconds. As the number of prefixes is increased, the time it takes increases linearly. Therefore, we can say it takes a reasonable time to notify ibgp peers of invalid prefixes. Fig. 8. Normal BGP table Fig. 9 shows R1-1 BGP table after the R1-1 receives the opaque extended community from the Ex-Quagga-SRx. Even though the R1-1 doesn t have a capability of validating update messages, the R1-1 can recognize the invalid prefix by accepting the opaque extended community. The BGP table includes the eval to show the validation state. As a result, the R1-1 will not select AS 400 as a destination of /24. Fig. 9. R1-1 BGP table 5.4 Environment and the result of performance test We set up a topology that is the same as figure 6 where each router runs on a 3.40 GHz i machine with 1 GB of memory running CentOS 6.3 and the SRx Server runs on a 3.40 GHz i machine with 1 GB of memory running CentOS 6.3. Because it is important to quickly notify ibgp peers of bogus prefixes, we measured the duration from the moment that Ex-Quagga-SRx receives an update message to the moment that the Ex-Quagga-SRx forwards the update message, which includes the opaque extended community, to ibgp peers. We stored 8000 ROAs in the RPKI validation Cache because the number of ROAs in the RPKI validation Cache affects the performance and there are around 8000 ROAs in the real world. We collected the number of prefixes that originated from each AS the 25th of May in According to TABLE 1, the BGP router originates, on average, prefixes and at most 5230 prefixes. Fig. 10. Result of performance test 6 CONCLUSION As the number of IP hijacking incidents is increased, many IP hijacking monitoring tools are implemented, but network administrators still should pay attention to their routing table to protect their routers by using command line interface when the network administrator receives any warning from BGP hijacking monitoring tools because none of the monitoring tools can directly access the data plane of BGP routers. As the number of ASes and prefixes continuously increase, checking the routing information in their routers manually is one of the big burdens on the administrators. In addition, when IP hijacking occurs, it is very important for the administrator to quickly block the bogus prefixes. Through our performance test, we showed ibgp peers can recognize the invalid prefixes in a reasonable time by accepting the opaque extended community even though the ibgp peer doesn t have a capability of validating update messages. As a result, when IP hijacking occurs, the bogus prefixes can be blocked in a timely manner, which makes the ASes more secure. We automatically prevent IP hijacking within ibgp peers, though ebgp should still be monitored in person.

7 7 References [1] Rekhter, Y A Border Gateway Protocol 4 (BGP- 4). RFC [2] Murphy, S BGP Security Vulnerabilities Analysis. RFC [3] "7007 Explanation and Apology," Apr 1997, [4] Rensys Blog, Con-Ed Steals the Net. [Online]. Available: html [5] Rensys Blog, Internet-Wide Catastrophe Last Year [Online]. Available: trophela.shtml [6] Rensys Blog, Pakistan hijacks YouTube [Online]. Available: be_1.shtml [14] Kent, S., Lynn, C., and Seo, K Secure Border Gateway Protocol (S-BGP). IEEE Journal on Selected Areas in Communications. 18, 4 (Apr. 2000) [15] White, R Securing BGP through secure origin BGP. Internet Protocol Journal. 6, 3 (September 2003). [16] Karlin, J., Forrest, S., and Rexford, J Pretty Good BGP: Improving BGP by Cautiously Adopting Routes. In IEEE International Conference on Network Protocols. [17] Van Oorschot, P., Wan T., and Kranakis, E On Interdomain Routing Security and Pretty Secure BGP (psbgp). ACM Transactions on Information and System Security. 10, 3(July 2007). [18] Manderson, T., Vegoda, L., and Kent, S Resource Public Key Infrastructure (RPKI) Objects Issued by IANA(Feb. 2012). [Online]. Available: [19] Lepinski, M., Kent, S., and Kong, D A Profile for Route Origin Authorizations (ROAs). Work in progress (Internet Draft), Feb [7] BGPmon, Google s services redirected to Romania and Austria [Online]. Available: [8] J. Yun, B. Hong, Y. Kim, "The BGP Monitoring and Alarming System to Detect and Prevent Anomaly IP Prefix Advertisement", Research in Applied Computation Symposium (RACS 2013), Montreal, QC, Canada, 1-4 October [9] Lad, M., Massey, D., Pei, D., Wu, Y., Zhang, B., and Zhang, L PHAS: A prefix hijack alert system. In Proceedings of the 15th conference on USENIX Security Symposium - Volume 15 (USENIX-SS'06), Vol. 15. [10] D. Matthews, Y. Chen, H. Yan, and D. Massey. BGP Monitoring System. Available from: [11] Y.-J. Chi, R. Oliveira, and L. Zhang. Cyclops: The ASlevel connectivity observatory. ACM SIGCOMM Computer Communication Review, pages 7 16, [12] Xingang Shi, Yang Xiang, Zhiliang Wang, Xia Yin, Jianping Wu. Detecting Prefix Hijackings in the Internet with Argus. In Proc. of ACM IMC [13] BGP Secure Routing Extension (BGP-SRx) by NIST ]Online]. Availble: