Internet Routing Security Issues and Requirements ...

Internet Routing Security Issues and Requirements Definition 1

1

2

I. Feki , M. Achemlal and A. Serhouchni 1

France Telecom Research & Development, 42 rue des Coutures Caen, France, e-mail: {[email protected], [email protected]} 2

ENST, 46 rue Barrault 75013 Paris, France, e-mail: [email protected]

Abstract Internet is composed of a collection of autonomous networks managed by a single administrative authority. The Border Gateway Protocol is the exterior routing protocol used to exchange routing information between routers on the border of each autonomous system. This network reachability information will be used to forward IP packets between routers. The way BGP behaves and exchanged information in its messages are crucial to Internet infrastructure and global routing system. In this paper, we discuss several BGP vulnerabilities and global routing system threats. Different approaches were proposed aiming to secure the global Internet infrastructure. We describe all these approaches and present the advantages and the drawbacks of each one. This analysis helped us to identify requirements and constraints in securing interdomain routing.

Keywords Interdomain Routing, BGP, Security

1. Introduction Internet is composed of thousands of Autonomous Systems (ASes); those networks are owned and operated by a single administrative entity. The same policy is applied in the network and an Interior Gateway Protocol (IGP) is used to route IP packets. An Internet Service Provider (ISP) usually operates one AS, though some ISPs may operate multiple ASes for different business reasons (e.g. to provide more autonomy to administrators in different continents) or historical reasons (e.g. merge of organizations). ASes can be also operated by non ISPs (banks, enterprises, etc.) which let them apply their own policy to their traffic. Each AS is identified by an autonomous system number (ASN) and is reachable via an IP prefix. These prefixes and ASNs are managed by the Internet Assigned Number Authority (IANA) which delegates them either to organizations or to Regional Internet Registries (RIR). In the latter case, RIRs allocates later these resources to organizations. The exterior routing protocol used between ASes is the Border Gateway Protocol (BGP) [1]. It is used to exchange interdomain network reachability information between those ASes. BGP is a path vector routing protocol; its messages contain a path composed of a sequence or a set of ASes. This path should be used to reach the announced network prefixes. BGP uses a modified Bellman Ford algorithm to define the best path to use to reach a destination. This algorithm computes the single source shortest path in a weighted graph and optimizes iteratively the distance to a destination by traversing a neighbor router. A BGP router does not have a global view on the Internet topology; it only knows the neighbor capable of reaching a destination. When the reachability

changes it just sends updates to its neighbors which forward them to their neighbors and so on. BGP allows network administrators to apply routing policies used for different reasons (e.g. traffic engineering, load balancing, etc.). Business relationships play also an important role in defining those policies. It is possible, for example, for an organization to deny its traffic to traverse a competitor and to prefer another path, even longer. Moreover, providers often compete with one another for customers but must nonetheless cooperate to offer global connectivity to hundreds of millions of hosts. Routing policies are used to select which routes are advertised to which neighbors and which paths are used to send packets to any given destination. So, the way BGP works, its algorithm convergence and the reachability information contained in its messages are crucial for the Internet connectivity, reliability, and robustness. If this network prefix reachability information is incorrect, traffic may not reach its destination, networks may be isolated and traffic may be subverted to unintended networks. The current use of this protocol assumes that each router is not corrupted and is telling the truth to its neighbors. Although this assumption was consistent at the beginning of the IP networks deployment, it is not true anymore, since the number of the autonomous systems is increasing considerably. Agreements between peered neighbour ASes may be considered as a trust relationship between them. But the way BGP functions, based on a hop by hop paradigm, where each hop is able to modify the information and then forward it to another, impacts this trust relationship. Information traverses unknown ASes and is subject to modification or deletion maliciously or due to misconfigurations. Internet Routing problems are not only related to the routing protocol, but also to the other components of this system: RIRs and ASes. We discuss in the next section all these Internet Routing system vulnerabilities and their risks. The remainder of the paper is organized as follows. In section 3, we describe different research efforts related to this topic. We analyze all these solutions and present their advantages and drawbacks. Section 4 defines some requirements that we have identified in our analysis, and Section 5 presents our conclusions and directions for future research.

2. Internet Routing System Vulnerabilities and Risks Vulnerabilities in the Internet Routing System are related to all its components introduced above. First, BGP has vulnerabilities related to its specifications, added features, traffic management considerations, ASes relationship and TCP vulnerabilities. At the beginning of BGP specification [3], only one optional security function was specified: message authentication in the session initiation between peers. With the growth of Internet and the use of BGP as the de facto interdomain routing protocol between the increasing number of ASes, BGP threats have been taken more seriously. This optional authentication is not strong enough to provide the backbone control plane correctness. BGP messages can be modified, forged, and deleted maliciously or accidentally. Moreover BGP relies on TCP and is faced with TCP vulnerabilities. TCP reset attack aiming at falsely terminating an established TCP connection is the TCP related attack that has the most significant impact on BGP. Since BGP relies on a persistent TCP connection which is maintained between BGP peers, it is inconvenient when this TCP connection is terminated. It takes time to send all BGP messages and to rebuild routing tables. In order to protect BGP from spoofed TCP segments and specially TCP resets, an option was added to BGP. It is based on an extension to TCP where every TCP segment contains an MD5 digest [5]. The support of this authentication mechanism in BGP implementations is mandatory in the last version of BGP specification [1].

It provides connection oriented integrity and data origin authentication on a point to point basis. Another possibility is to use the Generalized TTL mechanism [6] where the TTL of BGP packets is set to the maximum value of 255. Any packets that do not have a TTL in the range of 255 – 254 are rejected [7]. If these vulnerabilities are exploited, the Internet Routing System will be faced with attacks such as blackholing, subversion or redirection attack. In a blackholing attack an AS may be isolated from the entire Internet and then its services become unreachable. Besides in a subversion or redirection attack, traffic in destination to an AS is forced to take another path [8]. Second, the autonomy of ASes in the definition of their routing policies may introduce other vulnerabilities. In [9], Zhang et al analyzed selective dropping attacks that result from intentionally drop of incoming and outgoing Updates messages. This is an example of how persistent loops and blackholes can be formed. Instability can also occur unintentionally due to routing policies of each participating AS. In [10], Feamster et al prove that certain received route rankings and announced route filters used by ASes may not ensure routing stability. They argue that AS's full autonomy and expressiveness of routing policies may have undesirable consequences on the routing system. Some accidents have occurred since BGP deployment. In 1997, AS7007 accidentally announced routes to most of the Internet and disrupted connectivity for over two hours [11]. Mahajan et al explored these misconfiguration problems [12]. They identified two types of BGP misconfigurations: Origin misconfiguration where an AS injects prefixes it should not, and Export misconfiguration where the advertised path is in violation of the policies of one of the listed ASes. Their observation shows that 2001200 prefixes, equivalent to 0.2-1.0% of the global BGP table size, at that time, suffer misconfiguration events each day. Origin misconfiguration is one of the illegitimate reasons for which some prefixes are announced by multiple origin ASes. According to RFC 1930 a prefix must be originated by a single AS. However, if we analyze public Internet routing information [13][14] many prefixes are frequently originated by multiple AS. Zhao et al analyzed these multiple origin AS conflicts (MOAS) in [15]. One of the legitimate reasons of these MOAS is related to prefixes associated to exchange points that can be originated by all ASes participating in the exchange point. Multihoming is also a legitimate reason to see MOAS conflicts occur. Another legitimate reason is the aggregation achieved in transit ASes. Misconfigurations, prefix hijacking or even faulty aggregation can also be the reasons for MOAS conflicts occurrence. Since multihoming is not explicit in BGP, we cannot distinguish between legitimate and illegitimate conflicts. Different IP prefix hijacking attacks have taken place; the last one occurred in January 2006 and led to a denial of services of a server provider because another ISP originated its prefixes [16]. Routing system vulnerabilities are also related to BGP added mechanisms. We have already said that aggregation [17][18] may be source of MOAS conflicts that can be considered as a hijacking attack. Another added mechanism is route flap damping [4]. It attempts to stabilize routing by suppressing unstable routes. An attacker may take advantage of this mechanism to intentionally generate route updates so that the original stable route is suppressed. This attack is described in [8] and was conducted in a testbed in [19]. This proves that if this attack is carried out in the Internet routing system it can have considerable impact. The selection of the incorrect path after an MOAS conflict may be avoided if Internet Resources ownership and ASes relationships are more explicit. In fact, routing registry provides databases [20] that contain information about prefixes, AS numbers and organizations to which these data was allocated. But, these databases do not contain all the prefixes and AS numbers allocated. This data is also not maintained up to date. Moreover,

some databases do not have the same standardized format [20], so their utilization requires the conception of a system compatible with all databases. So, different fields are distinguished in Internet Routing System security. The first one is related to securing BGP message transportation and exchange in order to guarantee source authentication and message integrity and to protect the infrastructure from outsiders' attacks. The second one is related to message content correctness and the legitimacy of each AS to announce routes. Even if the identity of an AS is verified, it does not guarantee that it is not lying and using resources it should not use. Finally, registries should provide a more efficient IP prefixes delegation and allocation information base which can be used proactively to prevent incorrect data propagation or reactively in order to validate or reject suspicious data.

3. Related Work Some efforts have been made to solve internet routing security problems. They vary from the utilization of cryptographic methods, the utilization of the forwarding plane to validate announcements, and anomaly detection based on monitoring and statistical analysis. Different solutions are based on cryptographic methods aiming to avoid and to prevent incorrect information propagation. One of these approaches is Secure BGP [20]. The goal of Secure BGP is to assure the integrity of BGP messages, the authorization of a router to originate and to announce a route. IPSec is used to messages integrity and peer authentication. A public key infrastructure is used to support the authentication of address blocks, ownership of autonomous system numbers and identities, the given BGP router's identity and its right to represent the AS it claims to. RIRs are involved in this authorization scheme. They issue AS number and prefixes certificates to organization as they allocate them. These certificates are used to check the authorization of an AS to originate a route. Another public key infrastructure is used to express the authorization of a router to send an announcement to another router. The main disadvantage of SBGP is to add complexity and increase the convergence time. In addition, the strict hierarchal public key infrastructures (PKIs) make it difficult to deploy over Internet [23]. Zhao et al [24][25] addressed these drawbacks and proposed some enhancements. They used different cryptographic methods in order to make it less complex and to minimize the added convergence time. In addition, SBGP does not address issues such as detecting policy violations or incorrect propagation of route announcements or withdrawals. Secure Origin BGP [26] is a second solution using cryptographic methods. It uses a PKI to identify the AS; RIRs are not involved as Certificate Authorities (CA) for their authentication. ASes issue certificates to authorize other ASes to announce their prefixes. So, SoBGP is based on the idea that ASes publish their policies which may be considered as a drawback since some ASes consider them confidential. Pretty Secure BGP [27] uses both centralized and distributed trust models used in SBGP and SoBGP. The first model is used for AS number authentication and the latter is used for IP prefix ownership and origination verification. PsBGP differs from SBGP and SoBGP in that it makes use of a single-level PKI for AS number authentication, a decentralized trust model for verifying the propriety of IP prefix origin, and a rating-based stepwise approach for path (integrity) verification. The three solutions described above were presented in IETF Routing Protocols Security Working Group but there was no consensus on those solutions [28]. A fourth proposal based on cryptographic mechanisms is Secure Path Vector (SPV) [29]. It improves on S-BGP through the use of more efficient symmetric cryptography for securing against the truncation and modification attacks. SPV is configurable to allow tradeoffs

between security and CPU usage. SPV uses high speed signature algorithm and verification tasks based on cryptographic hash function in order to provide a better performance. Besides cryptographic solutions, other works focused on the MOAS conflicts. Wu et al worked on BGP anomalies and MOAS visualization tools [30][31]. ISPs may be interested in this type of tools to detect and alert prefix hijackings. But all that they can do is to call the service provider and try to settle the problem. Meanwhile the attack may have many negative consequences. It would be more efficient to have a mechanism that detects and reacts to anomalies as the routing system is running or even a mechanism that prevent those attacks. Zhao et al proposed to create a list of multiple ASes who are entitled to originate a prefix and attach it in BGP community attribute in announcements [32]. To distinguish valid from invalid origin ASes they also proposed to enhance the DNS database to carry the information of valid ASes for each address prefix [33]. The limitation is that the attribute is optional and may be dropped; moreover using DNS is vulnerable to DNS vulnerabilities and answers to lookups may be wrong. In order to validate received paths, Kim et al proposed to use ICMP traceback messages [34]. Another solution that validates announcements is Interdomain Route Validation (IRV) [35]. It introduces a new protocol and a framework to validate routing information announced between ASes. IRV allows ASes to acquire and validate static (policies) and dynamic (advertisements) interdomain routing. The approach is based on an interdomain routing validator which resides in each participant AS. This validator receives requests from the other elements placed in the other ASes. These latter elements send a request in order to validate the routes they have just received and consider as malicious or abnormal. The reasons that trigger the requests are not mentioned. It is left to ASes to choose its algorithm. This can be considered as an advantage and a drawback also since it gives flexibility to the AS but if the validation process is not frequent benefits will be reduced.

4. Requirements In this paragraph, we address all the requirements for a resilient and robust interdomain routing system. Globally, Internet resources can be seen in global routing system if they were delegated by IANA to RIRs then allocated to ISPs by RIRs and assigned to end users. So, one of the global requirements is that private and non delegated resources should not be present in global routing. If we take a look at the requirements of an AS, the basic need is to be sure that its inbound and outbound connectivity is ensured. That means that for a stub AS needs to be sure that its prefixes are announced correctly by their providers and that they will let it reach all networks. Furthermore, if this AS is multihomed and uses BGP to apply some traffic engineering rules and policies, it needs to be sure that its policies are applied. In the same way, a transit AS needs to be sure that not only its prefixes but also those of its customers are correctly announced and that the traffic in their destination won't be subverted, redirected or blackholed. They also need to be sure that the traffic sent reaches its intended destination. So, when an AS border router receives BGP announcements, it needs to check its content and verify: - Internet resources validity (public and allocated ASN and prefixes) - AS legitimacy to originate the prefix - Validity and policy conformance of the path In the following, we address every requirement and some operational requirements 3.1. Resources validity

A prefix or an ASN is considered valid if it has been delegated by IANA to a RIR and allocated by the RIR to an organization. It is possible to ensure this if all ASes filter received and sent announcements using prefix lists that filters private and unallocated prefixes, and filter lists that filter AS numbers. The challenge consists in updating filters as ASNs and prefixes are allocated. This type of information is distributed via emails and there is no automatic and "on line" way that permit all ISPs to update their filters. 3.2. Origin AS legitimacy Origin legitimacy is the ability of an AS to originate a prefix. This ability is infered from prefix delegation and allocation hierarchy. ASes relationships are also involved in the definition of an AS legitimacy. An AS originates legitimately a prefix if: - IANA has directly allocated the prefix for the AS. - The prefix was delegated to a RIR that allocated it to the AS whether the prefix is assigned to this AS or sub allocated to another organization. - The AS is one of the providers of a multihomed AS to which the prefix was allocated RPSec working group considered this requirement in the definition of a solution to routing security. But, there was no consensus in the definition of the AS legitimacy to originate a prefix. 3.2 Path validity and Policy conformance Path validity is defined by its existence physically and logically. A path exists physically if a BGP session exists between routers of ASes in the path. It exists logically if routing policies of each AS in the path authorizes its creation and advertisement. Let import(AS) and export(AS) be AS's import and export policies where. Here are examples of policies - import : from AS2 action pref = 1; accept { 128.9.0.0/16 } o This example states that the prefix 129.9.0.0/16 is accepted from AS2 with preference 1. - export : to AS2 announce AS4 o In this example, AS4's routes are announced to AS2 A path containing a sequence of ASn ASn-1 ….. AS2 AS1 to a destination is valid and policy conformant if: export(AS1) contains announce d to AS2 or any and import (AS2) contains accept d from AS1 and export(AS2) contains announce d to AS3 …….. and import(ASn-1) contains accept d from ASn-2 export(ASn-1) contains announce d to ASn or any import(ASn) contains accept d from ASn-1 An AS that receives an announcement containing a sequence of ASes is unable to verify this policy conformance if it does not know routing policies of every AS in the path.

3.3. Operational requirements One of the operational requirements is a low cost of the solution to be deployed. When deploying a secure routing protocol using cryptographic features to attest address ownership, expenses of issuing credentials is an ISP and RIR responsibility. It is a costly solution since it requires RIRs and ISPs involvement while their benefits from this investment are limited. A second requirement is related to BGP convergence time which should not be heavily increased. Finally, the solution that will be adopted should be incrementally deployable.

4. Conclusion In this paper we introduced Internet Routing security issues. We presented all the vulnerabilities related to Internet Routing System which are associated with each component of this system: the routing protocol, autonomous systems relationships and policies, and Internet Resources delegation and allocation lack of correct information from Internet Registries. We also analyzed proposed solutions and discussed their advantages and drawbacks. Finally, we defined a set of requirements that should meet to solve routing security problems. Now that we have defined these requirements, we will use available internet resources data from registry databases to verify the validity of announcements. Moreover, we work on a heuristic which will be used to distinguish between anomalous and normal new announcements. The process that we will use to check announcements, before their acceptation, should meet the operational requirements and should not impact BGP convergence.

4. References [1] [2] [3] [4]

Y, Rekhter, S. Hares and T. Li, "the Border Gateway Protocol", RFC 4271, 2006. www.potaroo.net/cidr Y Rekhter and T. Li "the Border Gateway Protocol", RFC 1771, 1995. C. Villazimar, R. Chandra and R. Govindan, "BGP Route Flap Damping", RFC 2439, 1998. [5] A. Heffernan, "Protection of BGP sessions via TCP MD5 signature option", RFC 2385, 1998. [6] V. Gill, J. Heasley and D.Meyer, "The Generalized TTL Mechanism", RFC3682, 2004. [7] www.nanog.org/mtg-0302/hack.html [8] O. Nordström and C. Dovrolis, "Beware of BGP attacks" ACM SIGCOMM Computer Communication Review, Volume 34, Issue 2, April 2004. [9] K. Zhang, X. Zhao and S. Felix Wu "An analysis on selective dropping attack in BGP", in Proceedings of IEEE International Conference on Performance, Computing, and Communications, 2004. [10] N. Feamster, R. Johari, and H. Balakrishnan "The Implications of Autonomy for Stable Policy Routing", ACM SIGCOMM, August 2005 [11] http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.html [12] R. Mahajan, D. Wetherall and T. Anderson, "Understanding BGP misconfigurations", ACM SIGCOMM, 2002. [13] http://www.routeviews.org/ [14] http://www.ripe.net/projects/ris/index.html

[15] X. Zhao, D. Pei, L. Wang, D. Massay, A. Mankin, S Felix Wu and L. Zhang, "An Analysis of BGP Multiple Origin AS (MOAS) Conflicts", in Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement, 2001. [16] http://www.mail-archive.com/[email protected]/msg40003.html [17] E. Chen and J. Stewart, "A Framework for Inter-Domain Route Aggregation", RFC2519, 1999. [18] V. Fuller, T. Li, J. Yu and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, 1993. [19] K. Zhang, S-T. Teoh, S-M. Tseng, R. Limprasittipom, K-L. Ma, S. F. Wu, C. Chuah, "Performing BGP Experiments on a Semi-Realistic Internet Testbed Environment", Proceedings of the Second International Workshop on Security in Distributed Computing Systems (SDCS), 2005. [20] www.whois.net [21] Alaettinoglu, C. Villamizar, C. Gerich, E. Kessens, D. Meyer, D. Bates, T. Karrenberg, D. and Terpstra M. (1999), "Routing Policy Specification Language (RPSL)", IETF RFC2622. [22] Stephen Kent, Charles Lynn and Karen Seo, "Secure Border Gateway Protocol", IEEE Journal on Selected Areas in Communications, Vol. 18, No. 4, pp. 582-592, April 2000. [23] R Atkinson and S Floyd, "IAB Concerns and Recommendations Regarding Internet Research and Evolution", RFC 3869, August 2004. [24] Meiyuan Zhao et al, "Evaluation of Efficient Security for BGP Route Announcements using Parallel Simulation", Journal on Simulation Modeling Practice and Theory, 2004. [25] Meiyuan Zhao et al, "Aggregated Path Authentication for Efficient BGP Security", in proceedings of ACM Conference on Computer and Communications Security, 2005. [26] Russ White, "Securing BGP through Secure Origin BGP", Internet Protocol Journal, Cisco, Vol. 6 Num 3, p15-22, 2003. [27] Tao Wan et al, "Pretty Secure BGP", in proceedings of Network and Distributed System Security Symposium Conference, 2005. [28] www.ietf.org/html.charters/rpsec-charter.html [29] Y. Hu, A. Perrig and M. Sirbu, "Secure Path Vector Routing for Securing BGP", in proceedings of ACM SIGCOMM, 2004. [30] S T. Teoh, K L. Ma, S F. Wu, D Massey, X L. Zhao, D Pei, L Wang, L Zhang and R Bush, "Visual-based Anomaly Detection for BGP Origin AS Change (OASC) Events", DSOM2003. [31] S. Teoh, K. Ma, K. Zhang, S. Tseng, F. S. Wu "Combining visual and automated data mining for near-real-time anomaly detection and analysis in BGP", CCS Workshop on Visualization and Data Mining for Computer Security, 2004. [32] X. Zhao, D. Pei, L. Wang, A. Mankin, S F. Wu and L. Zhang, "Detection of Invalid Routing Announcement in the Internet" in Proceedings of International Conference on Dependable Systems and Networks, 2002. [33] T. Bates, R. Bush, T. Li, and Y. Rekhter. DNS-based NLRI origin AS verification in BGP. Internet Draft, Work in Progress, 1998. [34] E. Kim, D. Massey and I. Ray, "Global Internet Routing Forensics: Validation of BGP Paths using ICMP Traceback", in Proceedings of the First annual IFIP WG 11.9 International Conference on Digital Forensics, 2005.

[35] B. Zhang, V. Kambhampati, M. Lad, D. Massey and Lixia Zhang, "Identifying BGP Routing Table Transfers", in Proceedings of ACM SIGCOMM Workshop on Mining Network Data (MineNet-05), 2005. [36] G. Goodell, W. Aiello, T. Griffin, J. Ioannis, P. McDaniel, A. Rubin, "Working Around BGP: An Incremental Approach to Improving Security and Accuracy of Interdomain Routing", in proceedings of Network and Distributed Systems Security, 2003.