BGP Security Configuration in ISP Networks - PIERS

PIERS Proceedings, Beijing, China, March 23–27, 2009

700

BGP Security Configuration in ISP Networks Hexing Wang1 , Cuirong Wang1 , and Ge Yu2 1 2

Northeastern University at Qinhuangdao, Qinhuangdao 066004, China School of Information Science and Engineering, Northeastern University Shenyang 110004, China

Abstract— The Border Gateway Protocol (BGP) is the de facto inter-domain routing protocol used to exchange network reachability information between ISP networks in the global Internet. The border gateway router of ISP network runs BGP protocol and maintains a table of prefixes designating IP networks that can be reached. However, as the Internet routing infrastructure, BGP is vulnerable to both accidental misconfigurations and malicious attacks because it trusts unverified control plane information received from its peers. This paper considers the security risks of BGP system and surveys works relating to BGP security. While a number of enhanced protocols for BGP (such as S-BGP, SO-BGP, PGBGP, etc.) have been proposed to solve BGP security problem, these generally relay on a public key infrastructure or a central authority like ICANN, or require substantial changes to the protocol, hence none of them has been widely deployed. We present a security configuration framework based on currently available technologies to improve the security of BGP routers. The security configuration framework provides a set of guidelines to protect the BGP routers from misconfigurations and malicious attacks. We describe the countermeasures and security mechanisms of BGP system when it encounters potential attacks, such as BGP peer spoofing, BGP session hijacking, malicious or unallocated route injection, etc. Our proposition is easily deployable in ISP networks without additional cost and it can effectively improve the security of BGP system. 1. INTRODUCTION

The Internet is a vast global network which is made up of thousands of independently ISP networks. A network under the administrative control of a single organization is called an autonomous system (AS) [1]. An ISP often owns one or more AS number for administrative convenience, and provides the Internet Service to users. Within an AS, the intra-domain routing protocols such as RIP, OSPF, IS-IS are used to exchange routing information. And between ASes, the inter-domain routing protocol is introduced. The Border Gateway Protocol Version 4 (BGP-4) [2, 3] is the de facto inter-domain routing protocol used to exchange network reachability information between ISP networks in the global Internet; its simplicity and resilience have enabled it to play a fundamental role within the global Internet. However, BGP has historically provided few security guarantees. The ISP network is vulnerable to attack though BGP. Misconfigured or deliberately malicious attack can disrupt overall Internet by injecting bogus routing information or hijacking network address space. On Apr 25, 1997 at 11:30 a.m. AS 7007 announced more specific routes (/24s) for practically the entire Internet [5, 6]. Routing was globally disrupted as the more specific prefixes took precedence over the aggregations routes. Many routers have been crashed and most Internet connectivity has been disrupted for over two hours. February 24, 2008, Pakistan Telecom hijacked a subnet address space for political reasons [7]. One of border router announced a very specific route (with prefix “/24”) to Youtube. Because the more specific route to Youtube was announced, others routers took this route as the best route to Youtube. The effect was to take Youtube off the air globally for about two hours. Such incidents shows that BGP is vulnerable and ISP should improve the routing security by some effective ways. There are a number of enhanced protocols for BGP (such as S-BGP [8], SOBGP [9], PGBGP [10], etc.) have been proposed to solve BGP security problem, these generally relay on a public key infrastructure or a central authority like ICANN, or require substantial changes to the protocol, hence none of them has been widely deployed. In this paper, we present a security configuration framework based on currently available technologies to improve the security of BGP routers. The security configuration framework provides a set of guidelines to protect the BGP routers from misconfigurations and malicious attacks. Our approach rely on existing technologies supported by router vendors, that is to say we can use carefully configure commands to protect BGP systems in ISP networks. The paper is organized as following: Section 2 is related work. Section 3 analyzes the vulnerabilities of BGP systems in ISP networks. We propose the BGP security configuration framework to

Progress In Electromagnetics Research Symposium, Beijing, China, March 23–27, 2009

701

improve the BGP system security in Section 4. And in Section 5, we give the BGP configuration guidelines in detail. Finally the conclusion is described in Section 6. 2. RELATED WORK AND

BGP security is an active area of research. Because this activity is relatively new, no solution has been universally deployed in the Internet. At present, most of research on BGP security has focused on the integrity, authentication, confidentiality, authorization, and validation of BGP data. PHAS [11] provides a web based service about possible prefix hijacks. The Listen and Wisper protocol [14] monitors TCP traffic flows and determines if hosts in remote prefixes are reachable, seeks to alert network administrators of potential routing inconsistencies. S-BGP [8] establishes a public-key infrastructure to stymie IP address spoofing. It enhances the security of BGP by verifying the authenticity and authorization of the BGP control traffic. It uses digital certificates to authenticate two pieces of data: which chunks of address space have been allocated to them and what autonomous system numbers have been allocated to them. SO-BGP [9] targets the need to verity the validity of an advertised prefix. It verifies a peer which is advertising a prefix has at least one valid path to the destination. PG-BGP [10] maintains a history of known origin ASes and prefixes. New origins and sub-prefix would be depreferenced for 24 hours and if they still exist in the RIB at that time, they would be added to the history. The delay period would provide monitoring ASes time to attend to events before they could cause widespread damage. This proposal is also facing difficulties to deploy, because of its need to change the BGP routing decision-making process. These proposals generally relay on a public key infrastructure or a central authority like ICANN, hence none of them has been widely deployed. However, ISPs hope minimal changes to adapt to the BGP protocol for security needs. So there should be a solution for BGP security 3. BGP VULNERABILITIES ANALYSIS

As the de facto inter-domain routing protocol, BGP is widely used in interconnection of ISP networks. The vulnerabilities and risks in BGP systems will inevitably affect the ISP’s network security and stability. RFC 4272 lists three primary limiting factors that lead to the vulnerabilities of BGP [4]: (1) BGP does not provide strong protection of the integrity, freshness, and peer entity authenticity of the messages. That’s means the malicious attacks may tamper with, replay or fabricate BGP messages in peer-peer BGP communications. (2) BGP does not validate the authority of an AS to announce network layer reachability information. This is related to path subversion, as an AS can currently announce that it has the shortest path to a destination by forging the path vector, even if it is not part of the destination path at all. (3)BGP does not ensure the authenticity of the path attributes announced by an AS. A malicious AS can impair or manipulate the packets’ routing path by changing the path attributes in BGP messages. The following is a list of potential attacks on BGP. While not a complete list, the attacks discussed here are the most common that are likely to be a concern for BGP. (1) BGP spoofing attacks. Peer IP addresses can often be found using the ICMP traceroute function. The attacker imitates the BGP peer with peculating the source address of peer’s IP connection. The goal of the spoofing attack may be to insert false information into a BGP peer’s routing tables. (2) BGP session resets attack. Current IETF specifications do not require checking sequence numbers of received ICMP messages. It is easy for attacker to send spoofed ICMP error messges to peer with encapsulating the victim’s IP address and port number, which cause TCP session reset. As a result, it causes loss of BGP peering sessions, forcing a need to rebuild routing tables and possibly causing route flapping. (3) Malicious route injection attacks. There are three types of illegal route injection: DUSA (Documenting Special Use addresses) route injection, unauthorized route injection and unallocated route injection. Malicious route injection of DUSA addresses might cause disruptions in networks that use these addresses within their designated functions. Attacker use unauthorized or unallocated route injection can make serious DOS and DDOS attack. (4) Hijacking attacks. Attacker hijackes netblock address by announcing a more specific route to target network, then packets to target network would be redirected to the attacker’s machine. Youtube accident is an obvious example for netblock address hijacking attacks.

PIERS Proceedings, Beijing, China, March 23–27, 2009

702

4. BGP SECURITY CONFIGURATION FRAMEWORK

In this section, we describe the BGP security configuration framework and the secure BGP configuration guideline in ISP networks. As shown in Figure 1, the framework can be divided into three layers. The first layer is session security protection layer, which secures BGP session between peers by protecting the connection port and using authentication mechanism. BGP stability protection layer using soft reconfiguration and other technicals to reduce BGP instability because of IGP protocol failure and occasional interface or link failure. The third layer is very important to ISP security operations, it uses access control list, inbound and outbound filter to protect ISP networks avoid from network address hijacking. Details of each layer in the framework will be described in the next section (Section 5). BGP routing policy security layer BGP stability protection layer Session security protection layer

Figure 1: BGP security configuration framework. 5. BGP SECURITY CONFIGURATION GUIDELINES

This section describes the configuration guidelines of each layer, and then gives a BGP security template based Cisco IO. Most of guidelines can be found in the actual configuration corresponding to the configuration commands. So it can be easily deployed in ISP networks without additional costs. 5.1. Session Security Protection Layer

This layer protects session security. Since BGP runs on TCP/IP, any TCP/IP attack can be applied to BGP. These guidelines below will protect TCP session and BGP session from spoofing attacks and session hijacking attacks. Guideline 1. Protect port 179 through access control lists. TCP port 179 is the standard port for receiving BGP peer’s OPEN message, so attempts by peers to reach other ports are likely to indicate faulty configuration or potential malicious activity. Allow peers to connect to port 179 only and deny any other connections to or from this port. Guideline 2. Use TTL security check feature in configuration. Most ISP peers are normally adjacent, so only one hop should be required for a packet sent in a BGP message, the TTL of IP packet is required to be 1. This feature can be used to protect the EBGP session between peers. Guideline 3. Use TCP MD5 authentication. The MD5 hash algorithm (RFC 2385 [31]) can be used to protect BGP sessions by creating a hash key for TCP message authentication. Commercial routers offer MD5 as a configuration option, and it is relatively easy to set up, using one or two statements in configuration files. This option provides protection against TCP-based attacks such as spoofing and session hijacking, because the attacker must know the secret key used in the hash computation. Guideline 4. Record peer changes. Logging whenever a peer enters or leaves established state provides useful records for debugging or audit trails for investigating possible security problems. 5.2. BGP Stability Protection Layer

Stability is an important aspect of BGP security. Instability in BGP system may have a wide range of routing oscillation, leading to large-scale routing failure, making the lost connection between communication hosts. Below is a detail list of guidelines that will help reducing BGP connection failure, controlling the scale of BGP routing table, and protecting connctions to DNS servers. Guideline 5. Shut down synchronization with IBGP. BGP synchronization feature refers to a requirement that BGP wait until the IGP propagates a newly learned route within the AS before advertising the route to external peers. Shut down synchronization can avoid instability by IGP protocol failure. Guideline 6. Turn off fast external failover feature. Turn off fast external failover to avoid major route changes due to transient failures of peers to send keepalives. Guideline 7. Use soft reconfiguration. Normally a change in policy requires BGP sessions to be cleared before the new policy can be initiated, resulting in a need to rebuild sessions with

Progress In Electromagnetics Research Symposium, Beijing, China, March 23–27, 2009

703

consequent impact on routing performance. Soft reconfiguration allows new policies to be initiated without resetting sessions. It can be set up for either or both inbound and outbound for updates from and to neighbors, respectively. Guideline 8. Disable BGP version negotiation. This option provides BGP faster startup. Peers change infrequently in practice, so BGP versions for known peers can be established statically rather than renegotiated each time BGP restart. Guideline 9. Use loopback interface for IBGP announcements. Using a loopback interface to define neighbors is common with iBGP, but not with eBGP. Normally the loopback interface is used to make sure the IP address of the neighbor stays up and is independent of hardware functioning properly. Guideline 10. Shut down auto summarize announcements feature. Auto summarization causes the router to summarize network paths according to traditional Class A, B, C, and D boundaries. This behavior can be problematic if, for example, the AS does not own the complete classed network that is summarized. Guideline 11. Use max prefix limits to avoid filling router tables. Routers should be configured to disable or terminate a session and issue warning messages to administrators when a neighbor sends in excess of a preset number of prefixes. Guideline 12. Do not use route flap damping for netblocks that contain DNS root servers. DNS root servers are critical for Internet operations, so degraded access to them by damping netblocks could cause widespread disruption of network operations. 5.3. BGP Routing Policy security Layer

The complexity of BGP policy and AS relationship could lead to conflict configuration and human misconfiguration. Mahajan et al. [13] analyse the influence of BGP misconfiguration. Caesar and Rexford [14] discussed BGP routing policies in ISP networks. The list of guidelines belowing gives a basic principle when configuring BGP policies in ISP networks. Guideline 13. Do not redistribute prefixes from an IGP protocol. Redistributing from an IGP is dangerous. AS 7007 incident is caused by misconfiguration which redistributing from IGP to EBGP. In practice, we should avoid unnecessary dynamic coupling of IGP and eBGP to prevent propagation of instability from IGP to EBGP (and vice versa). Guideline 14. Set announce prefix list to allow announcing only designated netblocks. It will prevent the router from inadvertently providing transit to networks not listed by the AS. Guideline 15. Filter all bogon prefixes. Bogon prefixes should not appear in routes. Filtering them reduces load and helps reduce the ability of attackers to use forged addresses idenial of service or other attacks. Guideline 16. Block inbound announcements of bogon prefixes. Since these prefixes do not represent valid routes, they should not be announced or propagated. Guideline 17. Deny over-specific prefix lengths. It can reduce the volume of update messages and BGP routing table. Outbound filter should deny all of the over-specific prefix, in addition to those can be confirmed. Guideline 18. Deploy enhanced sinking hole to reduce the attack damage when DOS/DDOS attack occurs. DOS/DDOS attack cannot be removed but its hazards can be reduced as much as possible. Using enhanced black hole routing technology triggered by the BGP can protect the data center sever effectively. 6. CONCLUSIONS

In this paper we described the BGP security configuration framework based on currently available technologies to improve the security of BGP routers. The framework is made up of three layers. In each layer, specific guidelines according to configuration commands are described. The deployment of the framework doesn’t rely on public key infrastructure or other central authority. So it can be easily deployed in ISP networks without additional costs. ACKNOWLEDGMENT

This work was partially supported by the National natural science foundation, China, under Grant 06273078 and by the Doctor funds of science and technology bureau, Hebei, China, under Grant 55470130-3.

704

PIERS Proceedings, Beijing, China, March 23–27, 2009

REFERENCES

1. Hawkinson, J. and T. Bates, “Guideline for creation, selection, and registration of an autonomous system (AS),” RFC1930, March 1996. 2. Rekhter, Y. and T. Li, “A border gateway protocol 4,” RFC1771, March 1995. 3. Rekhter, Y., T. Li, and S. Hares, “A border gateway protocol 4 (BGP-4),” RFC 4271, January 2006. 4. Murphy, S., “BGP security vulnerabilities analysis,” RFC 4272, January 2006. 5. Misel, S. A., “Wow, AS7007!” April 1997, http://www.merit.edu/mail.archives/nanog/199704/msg00340.html. 6. Bono, V. J., “7007 explanation and apology,” April 1997, http://www.merit.edu/mail.archives/nanog/-199704/msg00444.html. 7. RIPE. YouTube Hijacking: A RIPE NCC RIS case study. http://www.ripe.net/news/studyyoutube-hijacking.html. 8. Kent, S., C. Lynn, and K. Seo, “Secure border gateway protocol,” IEEE Journal on Selected Areas in Communications, Vol. 18, No. 4, 582–592, 2000. 9. Ng, J., “Extensions to BGP to support secure origin BGP (soBGP),” Internet Draft draft-ngsobgp-bgp-extensions-02, April 2004. 10. Wan, T., E. Kranakis, and P. van Oorschot, “Pretty secure BGP, psBGP,” Proceedings of network and distributed system security, 2005. 11. Lad, M., D. Massey, D. Pei, Y. Wu, B. Zhang, and L. Zhang, “PHAS: A prefix hijack alert system,” USENIX Security, 2006. 12. Subramanian, L., V. Roth, I. Stoica, S. Shenker, and R. Katz, “Listen andWhisper: Security mechanisms for BGP,” Proceedings of Networked Systems Design and Implementation, March 2004. 13. Mahajan, R., D. Wetherall, and T. Anderson, “Understanding BGP misconfiguration,” Proceedings of ACM SIGCOMM, 3–16, 2002. 14. Caesar, M. and J. Rexford, “BGP policies in ISP networks,” IEEE Network Magazine, October 2005. 15. Wang, L., X. Zhao, D. Pei, R. Bush, D. Massey, and L. Zhang, “Protecting BGP routes to top level DNS servers,” IEEE transactions on parallel and distributed systems, Vol. 14, No. 9, 851–860, 2003. 16. Gill, V., J. Heasley, and D. Meyer, “The generalized TTL security mechanism (GTSM),” RFC3682, February 2004. 17. CISCO, “BGP support for TTL security check,” http://www.cisco.com/en/US/docs/ios/12 2sx/feature/guide/fsxebtsh.html.