September 2003 Volume 6, Number 3 A Quarterly Technical Publication for From The Editor Internet and Intranet Professionals In This Issue The task of adding security to Internet protocols and applications is a large and complex one. From a user’s point of view, the security- enhanced version of any given component should behave just like the From the Editor .......................1 old version, just be “better and more secure.” In some cases this is simple. Many of us now use a Secure Shell Protocol (SSH) client in place of Telnet, and shop online using the secure version of HTTP. But Securing BGP: S-BGP...............2 there is still work to be done to ensure that all of our protocols and associated applications provide security. In this issue we will look at Securing BGP: soBGP ............15 routing, specifically the Border Gateway Protocol (BGP) and efforts that are underway to provide security for this critical component of the Internet infrastructure. As is often the case with emerging Internet Virus Trends ..........................23 technologies, there exists more than one proposed solution for securing BGP. Two solutions, S-BGP and soBGP, are described by Steve Kent and Russ White, respectively. IPv6 Behind the Wall .............34 The Internet gets attacked by various forms of viruses and worms with Call for Papers .......................40 some regularity. Some of these attacks have been quite sophisticated and have caused a great deal of nuisance in recent months. The effects following the Sobig.F virus are still very much being felt as I write this. Fragments ..............................41 Tom Chen gives us an overview of the trends surrounding viruses and worms. Closely related to the virus attacks is spam. Unfortunately, I know of no complete technical, or even legal, solutions to this growing problem, but I would love to hear your views and solutions. Send your comments to: [email protected], but don’t use the string “spam” in the subject field or it may get filtered out! Following Geoff Huston’s opinion piece “The Myth of IPv6” in our previous issue, we received a response from The IPv6 Forum. The article is entitled “IPv6 Behind the Wall” and is by Jim Bound. I was very pleased to hear that professor Peter T. Kirstein of University College London had been awarded the Internet Society’s Jonathan B. Postel Service Award for 2003. I have known Peter since about 1977, when we collaborated on SATNET packet voice conferences between Oslo, London, Boston, and Marina del Rey. Peter is truly an Internet You can download IPJ pioneer. (See “Fragments,” page 41). back issues and find —Ole J. Jacobsen, Editor and Publisher subscription information at: [email protected] www.cisco.com/ipj Securing the Border Gateway Protocol by Stephen T. Kent, BBN Technologies outing in the public Internet is based on a distributed system composed of many routers, grouped into management do- R mains called Autonomous Systems (ASes). ASes are operated by Internet Service Providers (ISPs) and by multihomed subscribers. (Throughout the remainder of this article, for brevity, we will talk in terms of ISPs, usually omitting references to multihomed subscribers.) Routing information is exchanged between ASes using the Border Gate- way Protocol (BGP)[1], via UPDATE messages. BGP is used in two different contexts. External BGP (eBGP) propa- gates routes between ISPs. BGP also is used within an AS to propagate routes acquired from other ASes. This latter use is referred to as inter- nal BGP (iBGP). eBGP is the primary focus of this article, because failures of eBGP can adversely affect large portions of the Internet, well beyond the administrative boundary of the source of the failure. None- theless, some ISPs have expressed interest in protecting the distribution of routes within an ISP. The security technology discussed in this article can be used to secure iBGP, but eBGP is the focus of this article. We use the term “BGP” to refer to eBGP throughout the article. BGP is highly vulnerable to a variety of attacks[2]. In some cases, this vulnerability arises because of a lack of integrity and authentication for BGP messages. However, the more substantive and harder problem is the lack of a secure means of verifying that BGP traffic is authorized, a concept explored in more detail in this article. In April 1997, BBN be- gan work on the security architecture described here, a system we refer to as S-BGP, to address the vulnerabilities of BGP. This article begins by reviewing the problem, discusses a model for correct operation of BGP, presents a threat model, and states the goals and assumptions that un- derlie our proposed security architecture. Before we begin the discussion of BGP in more detail, a few definitions are in order. A route is defined as an address prefix and a set of path at- tributes. One of the path attributes is an AS path, and that is the primary focus of BGP security considerations. The AS path specifies the sequence of ASes that subscriber traffic should traverse if forwarded via this route. When propagating an UPDATE to a neighboring AS, the BGP router prepends its AS number to the sequence, and may update certain other path attributes. The first AS included in the path is re- ferred to as the origin AS. Each BGP router (other than at the edges of the Internet) maintains a complete routing table, capable of routing traffic to any reachable desti- nation, and sends its best route for each prefix to each neighbor. In BGP, “best” is very locally defined. The BGP route selection algorithm has few criteria that are universal, thus limiting the extent to which any security mechanism can detect and reject “bad” routes emitted by a neighbor. The Internet Protocol Journal 2 Each ISP makes use of local policies that it need not disclose, and this gives BGP route selection a “black box” flavor, which has significant adverse implications for security. Correct Operation of BGP Security for BGP should be defined as the correct operation of BGP routers. This definition is based on the observation that any successful attack against BGP will result in other than correct operation, presum- ably yielding degraded routing. Correct operation of BGP depends upon the integrity, authenticity, and timeliness of the routing informa- tion it distributes, as well as each BGP router processing, storing, and distributing this information in accordance with both the BGP specification and local routing policies. Many statements could be made in an effort to characterize correct operation, but they rest on two simple assumptions. First, control (vs. subscriber traffic) communication between neighbor BGP routers must be authenticity and integrity secure. This is easily achieved through the use of a point-to-point security protocol capable of protecting BGP traffic; for example, IP Security (IPSec). Second, BGP routers must execute the route selection algorithm correctly and com- municate the results. There are two parts to this assumption: processing received UPDATEs, and generation and transmission of UPDATEs. In terms of an AS trying to protect itself against external attacks, correct operation of its own BGP routers is mostly a local security issue, but not an Internet-wide security issue. However, an AS should not rely on other ASes to operate properly; such reliance permits a failure in one AS to propagate to others, a domino failure effect. Thus it is important for a BGP router to be able to verify that each UPDATE it receives from a peer is valid (authorized) and timely. The validity of an UPDATE message is based on four primary criteria: • The router that sent the UPDATE was authorized to act on behalf of the AS it claims to represent; that is, the AS at the front of the AS path. • The AS from which the UPDATE emanates was authorized by the preceding AS in the AS path (in the UPDATE message) to advertise the prefixes in the UPDATE. • The first AS in the AS path was authorized, by the owner of the set of prefixes that are represented in the UPDATE, to advertise those prefixes. • If the UPDATE withdraws one or more routes (specified by the prefixes for the routes), then the sender must have advertised each route prior to withdrawing it. There are some limitations to the ability of any practical security mech- anism to detect all BGP security failures. The local policy feature of BGP allows each ISP considerable latitude in how UPDATEs are pro- cessed, making it difficult for an external observer—for example, a router in a neighboring AS—to determine if a router is operating properly. The Internet Protocol Journal 3 S-BGP: continued This is because such behavior might be attributed to local policies not visible outside an AS. To address such attacks, the semantics of BGP it- self would have to change. Moreover, because UPDATEs do not carry sequence numbers, a BGP router can emit an UPDATE based on au- thentic, but old, information; for example, withdrawing or reasserting a route based on outdated information. Thus the temporal accuracy of UPDATEs, in the face of Byzantine failures, is hard to enforce, except in a very coarse fashion. (Simply speaking, a Byzantine failure is one in which a nominally trusted or authorized entity misbehaves.) Threat Model and BGP Vulnerabilities Routers exhibit both architectural and implementation vulnerabilities. Implementation vulnerabilities are the result of errors that arise in devel- oping design details or coding; for example, translating the BGP specs into software. Architectural vulnerabilities permit various forms of at- tack, independent of implementation details, and thus are potentially more damaging, because they persist across all implementations. To make Internet routing robust, both forms of vulnerabilities must be ad- dressed.