Secure Border Gateway Protocol (S-BGP) — Real World Performance and Deployment Issues
Total Page:16
File Type:pdf, Size:1020Kb
Secure Border Gateway Protocol (S-BGP) — Real World Performance and Deployment Issues Stephen Kent, Charles Lynn, Joanne Mikkelson, and Karen Seo BBN Technologies Abstract configuration information, or routing databases may be The Border Gateway Protocol (BGP), which is used to modified or replaced illicitly via unauthorized access to distribute routing information between autonomous a router, or to a server from which router software is systems, is an important component of the Internet's downloaded, or via a spoofed distribution channel, etc. routing infrastructure. Secure BGP (S-BGP) addresses Such attacks could result in transmission of fictitious critical BGP vulnerabilities by providing a scalable BGP messages, modification or replay of valid means of verifying the authenticity and authorization of messages, or suppression of valid messages. If BGP control traffic. To facilitate widespread adoption, cryptographic keying material is used to secure BGP S-BGP must avoid introducing undue overhead control traffic, that too may be compromised. We have (processing, bandwidth, storage) and must be developed security enhancements to BGP that address incrementally deployable, i.e., interoperable with BGP. most of these vulnerabilities by providing a secure, To provide a proof of concept demonstration, we scalable system: Secure-BGP (S-BGP) [1,3]. Better developed a prototype implementation of S-BGP and physical, procedural and basic communication security deployed it in DARPA’s CAIRN testbed. Real Internet for BGP routers could address some of these attacks. BGP traffic was fed to the testbed routers via replay of a However, such measures would not counter any of the recorded BGP peering session with an ISP’s BGP many forms of attacks that compromise routers router. This document describes the results of these themselves. Experience with accidental mis- experiments – examining interoperability, the efficacy of configurations, and the many vulnerabilities of the S-BGP countermeasures in securing BGP control management system components, strongly argue in traffic, and their impact on BGP performance, and thus favor of countering such Byzantine failures if we are to evaluating the feasibility of deployment in the Internet. provide adequate protection for the Internet. The BGP-4 protocol, including descriptions of the 1. Border Gateway Protocol (BGP) UPDATE message and the route propagation algorithm, is described in [2,3]. Briefly, the numbers that identify IP networks are specified by a prefix, which consists of Internet routing is implemented using a distributed a count of significant bits in an IP address and the value system composed of many routers, grouped into of those bits. An UPDATE consists of three parts: administrative domains called Autonomous Systems “withdrawals” - a list of prefixes for destinations that (ASes). Routing information is exchanged between are no longer reachable via a previously specified route; ASes using Border Gateway Protocol (BGP) [2,3] “network layer reachability information (NLRI)” - a list UPDATE messages. BGP has a number of of IPv4 address prefixes that are reachable; and “path vulnerabilities [1,3,5] which can be exploited to cause attributes” - the characteristics of the cumulative path problems such as misdelivery or non-delivery of user that can be used to reach the NLRI in this UPDATE. traffic, misuse of network resources, network These path attributes include reachability information congestion and packet delays, and violation of local for IPv6 address prefixes in the “Multi-Protocol routing policies. Reachable NLRI” and “Multi-Protocol Unreachable NLRI” path attributes. The attribute used to specify the Communication between BGP peers is subject to active path, the AS_PATH attribute, is basically a sequence of and passive wiretapping attacks. BGP and the TCP/IP the Autonomous Systems (ASes) along the path, each protocol used by it can be attacked. A BGP speaker can identified by its AS number. When propagating an be compromised, e.g., a speaker's BGP-related software, Appeared in Proceedings of the Network and Distributed System Security Symposium (NDSS 2000), San Diego, California, February 2000. Copyright Internet Society Page 1 of 14 UPDATE to a neighboring AS, the BGP speaker 7. Finally, both the BGP speaker that sent the prepends its AS number to the sequence, and updates UPDATE, and the peer that received the UPDATE, other path attributes as appropriate. Since an UPDATE correctly applied BGP processing rules and the can specify only one path, only address prefixes that (local) routing policy specified by it's AS. share that path may be combined into the UPDATE. The security measures developed for BGP address the first six of these requirements, even if one or more BGP We maintain that security for BGP should be defined as speakers have been subverted. The last requirement is the correct operation of BGP speakers. This definition is not addressed by S-BGP, primarily because of the based on the observation that any successful attack considerable latitude afforded BGP speakers by local against BGP should result in other than correct routing policies, and because ASes generally do not operation, presumably yielding degraded routing. publish details of the policies. Without knowledge of Correct operation of BGP depends upon the integrity, these local policies, other ASes cannot determine if authenticity, and timeliness of the routing information local routing policies are being correctly applied. that BGP distributes (via UPDATEs). It also depends on Moreover, because UPDATEs do not carry sequence each BGP speaker’s processing, storage, and numbers, a BGP speaker is free to generate an distribution of this information in accordance with both UPDATE based on old information, e.g., it may the BGP specification and the routing policies of the advertise a route that was formerly valid but which has BGP speaker’s Autonomous System. The been withdrawn. Thus, in the face of Byzantine failures countermeasures being developed address the following (vs. active wiretapping attacks against inter-speaker points of correct (secure) operation of BGP: links), the timeliness of UPDATEs is enforced only on a very coarse basis by these countermeasures. 1. Each UPDATE that a BGP speaker receives from a peer was sent by that peer, was not modified en- 1.1 Deployment of S-BGP in the Internet route from that peer, and contains routing information no less recent than the routing In addition to the basic problem of how to secure BGP, information previously received for the indicated there is the problem of how to deploy the solution in the destinations from that peer. Internet. Deploying S-BGP will require the adoption of this technology by ISPs and by router vendors, plus PKI 2. The UPDATE was intended for the BGP speaker or support by the registries that allocate autonomous AS that received it. system numbers to ISPs and DSPs (down-stream providers), and address prefixes to customers. Because 3. The peer sending the UPDATE was authorized to of the distributed management of the Internet act on behalf of its AS to advertise the routing infrastructure, the anticipated growth in the size and information in the UPDATE to BGP speakers in the inter-connectivity of the Internet, the large volume of recipient AS. BGP UPDATE traffic, and resource limitations in the Internet’s routers and circuits, it is crucial that S-BGP 4. The AS originating the route, i.e., that contains the be scalable and incrementally deployable. BGP speaker that originally included the list of reachable destinations within the UPDATE, was • Scalability – The impact of S-BGP on a router’s authorized to represent those destinations by the CPU and storage utilization, and on network organization(s) that owns them. bandwidth must be within acceptable limits. 5. The organization owning the IP address space • Deployability – In order to successfully deploy advertised in the UPDATE was allocated that S-BGP, two major issues need to be addressed. address space through a chain of delegations First, S-BGP countermeasure information must be originating at the ICANN (formerly IANA). forwarded between S-BGP routers in the same AS. Also, since S-BGP introduces a new BGP path 6. If the UPDATE indicates a withdrawn route, i.e., attribute, one must provide backward compatibility one that is no longer feasible, then the peer between S-BGP and BGP-4 so that it is possible to withdrawing the route was previously authorized to incrementally deploy these countermeasures. advertise that route. Page 2 of 14 2. S-BGP countermeasures certification tree. For example, some ISPs and subscriber organizations hold addresses assigned This section provides a high-level overview of the directly by IANA, the predecessor to the ICANN.) The S-BGP architecture. For further details see [1,3]. next tier generally consists of ISPs. An additional tier Document [1] also contains an appendix that describes a represents DSPs or subscribers, when these entities number of alternative approaches that were studied but participate in BGP. Note that only those entities that not chosen, e.g., “path” and “neighbor” attestations (vs. execute BGP need these certificates. Finally, if an the selected “route” attestation), because of organization owns multiple ranges of addresses, this vulnerabilities in these approaches or because of adverse design calls for assigning a single certificate containing performance implications. a list of address blocks, so as to minimize the number of certificates