Unformatted Document Excerpt
Course Hero has millions of student submitted documents similar to the one
below including study guides, practice problems, reference materials, practice exams, textbook help and tutor support.
Course Hero has millions of student submitted documents similar to the one
below including study guides, practice problems, reference materials, practice exams, textbook help and tutor support.
IEEE ON SELECTED AREAS IN COMMUNICATIONS, VOL. 18, NO. 4, APRIL 2000
Secure Border Gateway Protocol (S-BGP)
Stephen Kent, Charles Lynn, and Karen Seo
AbstractThe Border Gateway Protocol (BGP), which is used to distribute routing information between autonomous systems (ASes), is a critical component of the Internet's routing infrastructure. It is highly vulnerable to a variety of malicious attacks, due to the lack of a secure means of verifying the authenticity and legitimacy of BGP control traffic. This paper describes a secure, scalable, deployable architecture (S-BGP) for an authorization and authentication system that addresses most of the security problems associated with BGP. The paper discusses the vulnerabilities and security requirements associated with BGP, describes the S-BGP countermeasures, and explains how they address these vulnerabilities and requirements. In addition, this paper provides a comparison of this architecture to other approaches that have been proposed, analyzes the performance implications of the proposed countermeasures, and addresses operational issues. Index TermsDenial of service, digital signatures, public-key cryptography, routing, security.
I. PROBLEM DESCRIPTION NTERNET routing is based on a distributed system composed of many routers, grouped into management domains called Autonomous Systems (ASes). Routing information is exchanged between ASes in Border Gateway Protocol (BGP)  UPDATE messages. BGP has proven to be highly vulnerable to a variety of attacks , due to the lack of a scalable means of verifying the authenticity and legitimacy of BGP control traffic. In April 1997, we began work on the security architecture described in this paper. In this section we describe the problemhow the protocol works; the nature of observed BGP traffic in the Internet; the correct operation of BGP; the threat model and BGP vulnerabilities; and the goals, constraints, and assumptions that apply to the proposed countermeasures. A. Overview of BGP The BGP-4 protocol, both message syntax and the route propagation algorithm, is described in . Routers implementing BGP, BGP speakers, exchange routing information via UPDATE messages. An UPDATE message consists of three parts: a list of address prefixes1 for destinations that are no longer reachable (via the previously specified route); a list of prefixes that are reachable; and the characteristics of the cumulative path and current inter-AS hop, contained in path attributes, that can be used to reach the address prefixes. The attribute used to specify the inter-AS path, the AS_PATH attribute, specifies a sequence
Manuscript received February 1, 1999; revised November 11, 1999. This work was supported by NSA in 1997, and by DARPA. The authors are with BBN Technologies, Cambridge, MA 02138 USA. Publisher Item Identifier S 0733-8716(00)01519-5.
1A prefix specifies an IP address block, and consists of a count of the most significant bits in an IP address, and the value of those bits.
of Autonomous Systems (ASes) along the path, each identified by its AS number. When propagating an UPDATE to a neighboring AS, the BGP speaker prepends its AS number to the sequence, and updates certain other path attributes. Since an UPDATE can specify only one path, only prefixes that share that path may be aggregated into the UPDATE. The backbone routers of the major internet service providers (ISPs) have a route to every reachable IP address. Analysis of BGP UPDATEs recorded during January 1999 showed routing databases that contained about 61 000 IPv4 address prefixes. Each (nonleaf) BGP speaker maintains a full routing table, and sends its best route for each prefix to each neighbor speaker. When a BGP speaker reboots, it receives complete routing tables (via UPDATEs) from each of its neighbors. The worst case arises at Network Access Points (NAPs), where ISPs are connected together via a high speed (100 Mb/s) LAN. A BGP speaker at a NAP might have about 30 peers. On a daily basis, a BGP speaker at a NAP receives about 1425 UPDATEs from each peer, an average UPDATE rate of about 1 per minute per peer. This rate is affected somewhat by Internet growth (about 25 network prefixes are added each day), but is mostly a function of UPDATEs sent due to link, component, or congestive failures and recoveries. Analysis shows that about 50% of all UPDATEs are sent as a result of route flaps, i.e., transient communication failures that, when remedied, result in a return to the original route. This sort of routing behavior has long been characteristic of the Internet2  and the proposed security mechanisms take advantage of this behavior to achieve acceptable performance, as discussed in Section VI. B. Correct Operation of BGP Security for BGP is defined by the correct operation of BGP speakers. This definition is based on the observation that any successful attack against BGP should result in other than correct operation, presumably yielding degraded operation. Correct operation of BGP depends upon the integrity, authenticity, and timeliness of the routing information it distributes as well as each BGP speaker's processing, storing, and distribution of this information in accordance with both the BGP specification and with the (local) routing policies of the BGP speaker's AS. The following statements characterize the primary correct operation features of BGP. Each UPDATE received by a BGP speaker from a peer was sent by the indicated peer, was not modified en route from the peer, and contains routing information no less recent than the routing information previously received for the indicated prefixes from that peer.
2In a discussion with David Mills, an architect of the NSFNET, he confirmed that route flapping has been a characteristic of the Internet since the mid 1980's.
07338716/00$10.00 2000 IEEE
KENT et al.: SECURE BORDER GATEWAY PROTOCOL
The UPDATE was intended for receipt by the peer that received it. The peer that sent the UPDATE was authorized to act on behalf of its AS to advertise the routing information contained within the UPDATE to BGP peers in the recipient AS. The owner of an address space corresponding to a reachable prefix advertised in an UPDATE was authorized by its parent organization to own that address space. The first AS in the route was authorized, by the owners of the address space corresponding to the set of reachable prefixes, to advertise those prefixes. If the UPDATE indicates a withdrawn route, then the peer withdrawing the route was a legitimate advertiser for that route, prior to its withdrawal. The peer that sent the UPDATE correctly applied the BGP rules and its AS's routing policies in modifying, storing, and distributing the UPDATE, in selecting the route, and in deriving forwarding information from it. The BGP speaker that received the UPDATE correctly applied the BGP rules and its AS's routing policies in determining whether to accept the UPDATE. The countermeasures developed for S-BGP meet the first six of these criteria, even in the face of subversion of BGP speakers (Byzantine failures). Section IV provides a detailed analysis of how each countermeasure contributes to correct operation. However, because the local policy features of BGP allows a speaker considerable latitude in determining how to process an UPDATE, these countermeasures cannot meet the last two criteria, i.e., such attacks could be attributed to local policies not visible outside an AS. To address such attacks, the semantics of BGP itself would have to change. Moreover, because UPDATEs do not carry sequence numbers, a BGP speaker can generate an UPDATE based on old information, e.g., withdrawing or reasserting a route based on outdated information. Thus the temporal accuracy of UPDATEs, in the face of Byzantine failures, is enforced only very coarsely by these countermeasures. (Section V provides more details on residual vulnerabilities.) C. Threat Model and BGP Vulnerabilities BGP has a number of vulnerabilities that can be exploited to cause problems such as misdelivery or nondelivery of user traffic, misuse of network resources, network congestion and packet delays, and violation of local routing policies. Communication between BGP peers is subject to active and passive wiretapping. BGP uses TCP/IP for transport and this protocol, and its payload, can be attacked. A speaker's BGP-related software, configuration information, or routing databases may be modified or replaced illicitly via unauthorized access to a router, or to a server from which router software is downloaded, or via a spoofed distribution channel. Effective security measures must address such Byzantine attacks. Exploitation of these vulnerabilities allows a variety of attacks. For example, fictitious BGP messages might be injected into a link (spoofing). Authentic BGP messages might be captured and either modified and reinjected into the link, combined incorrectly, or suppressed altogether. A compromised
BGP speaker could generate UPDATEs for routes that do not, legitimately, pass through that speaker. All of these attacks are countered by the mechanisms described in Section III. UPDATE messages could be generated too frequently by a compromised BGP speaker, or the selection of routes and distribution of UPDATEs could violate the local routing policies. These failures are not addressed by the proposed countermeasures. Better physical and procedural security for network management facilities, BGP speakers, and communication links; link-level encryption of inter-router (BGP speaker) traffic; and end-to-end encryption of management information would reduce some of these vulnerabilities. However, some aspects of such security approaches are economically unattractive or infeasible. Moreover, accidental (versus malicious) misconfiguration would not be prevented by such measures, and such misconfiguration has proved to be a source of several significant Internet outages in the past. Any security approach that leaves BGP vulnerable to such benign attacks violates the principle of least privilege and leaves the Internet routing system vulnerable at its weakest link. In contrast, the security approach described here satisfies this principle, so that any attack on any component of the routing system is limited in its impact on the Internet as a whole. D. Goals, Constraints, and Assumptions In order to create countermeasures that are both effective and practical, the S-BGP architecture is based on the following goals, constraints, and assumptions. The S-BGP architecture must handle the projected growth and usage of the Internet in terms of performance (storage, processing, network bandwidth). It should be dynamic (responding automatically to topology changes, including the addition of new networks, routers and ASes) and scalable (able to handle the growth of the Internet in terms of addresses, routes, BGP control traffic, etc.). The countermeasures must be consistent with the BGP protocol standards and with the likely evolution of these standards. This includes packet size limits, e.g., 4096 byte maximum for UPDATEs, and BGP features, e.g., path aggregation, communities, and multiprotocol support, e.g., multiprotocol label switching (MPLS). For example, we have chosen to employ the BGP optional, transitive path attribute as a mechanism for distributing countermeasures information, but the BGP path attribute format must not be modified. The S-BGP architecture must be deployable. A primary goal of this work is not only to find countermeasures for BGP vulnerabilities but to cause them to be adopted by ISPs and router vendors. To accomplish this, the countermeasures must use available technology that can be incrementally deployed and they should leverage off of the existing infrastructure, e.g., the Internet Corporation for Assigned Names and Numbers (ICANN), and routing registries. In addition, they must avoid dependency loops, i.e., the architecture cannot depend on correct operation of inter-AS routing during initialization, e.g., it cannot rely on nonlocal databases.
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 18, NO. 4, APRIL 2000
II. PRIOR WORK The earliest significant work published on the topic of routing protocol security is Perlman's doctoral dissertation . The S-BGP design shares several features of that work, e.g., we address Byzantine failures and make extensive use of digital signatures. However, we differ in many other respects, e.g., our design applies to a standard exterior (versus interior) routing protocol, and we pay considerable attention to infrastructure and performance implications. At the time that we began this work, previously published work on improving the security of BGP, and more generally distance-vector protocols, included proposals for adding sequence numbers to BGP messages , authentication of BGP messages , , , neighbor-to-neighbor encryption of BGP messages , and adding information to UPDATE messages to protect against tampering as the UPDATE propagates around the Internet , , . None of this work proposed a comprehensive solution to the BGP security problems described above; each focused on one or more aspects of the problem without considering the full range of issues that are critical to a viable solution. For example, none addressed issues associated with the generation and distribution of public key certificates and certificate revocation lists (CRLs) needed to support validation of signed UPDATEs. Some proposals made changes to BGP that are inconsistent with the protocol standards, a reasonable approach only if one were presented with a clean slate. None of the prior work examined the statistics of BGP operating in the Internet; this sometimes led authors to focus on performance concerns that are not the major impediment to deploying viable solutions. Some of the work developed solutions for distance vector protocols, but erroneously claimed applicability to BGP, a path vector protocol. In contrast, the BGP security architecture reported in this paper is comprehensive, including a design for the infrastructure needed to establish and maintain the system. The optional transitive path attribute it employs is consistent with BGP standards and can be safely carried through routers not implementing S-BGP. This architecture incorporates the notion of an address attestation, which establishes that a first hop BGP speaker is authorized to advertise a route to a destination. No prior work includes an equivalent notion. Finally, the performance of the design presented here has been modeled based on actual BGP statistics. No other work has been so rigorously analyzed from a performance perspective. In , the scheme proposed is similar to our route attestations in that before distributing an UPDATE to an external neighbor, the BGP speaker signs the route. Our approach differs from the scheme proposed in  in that we sign a routing data structure that specifies the next hop AS, explicitly indicating that this AS is authorized to advertise the route in question to the identified neighbor. Hence, our approach avoids a vulnerability not addressed in , i.e., provides protection against cut and paste attacks in which a BGP speaker inserts itself into a route (using a valid UPDATE containing a route which the speaker was not authorized to use). The approach proposed in  and  was developed in response to the perceived communication and computation over-
head of schemes such as . In the case of  (and our route attestations), each of the signatures must be carried in each UPDATE and verified by each recipient to validate each received UPDATE. The approach proposed in  and  includes only a single signature for a route in an UPDATE; this signature covers only the destination and penultimate ASes listed in the path and is generated by a BGP speaker in the destination AS. While the overhead of  and  is less than that of  or our route attestations, it fails to provide the protection afforded by the iterated signature schemes in an environment with more sophisticated routing policies (e.g., policies other than shortest path), such as those typically supported by BGP. Moreover, our analysis shows that generation, validation, and transmission of digital signatures does not impose an unacceptable computational or communication burden. III. PROPOSED COUNTERMEASURES The approach adopted to securing BGP route distribution involves two Public Key Infrastructures3 (PKIs), a new path attribute containing attestations, and the use of IPsec. These components are used by a BGP speaker to validate the authenticity and data integrity of BGP UPDATEs that it receives, and to verify the identity and authorization of the senders. This section discusses in more detail the PKIs and certificates, the attestations, the use of IPsec, and the distribution of this countermeasures information. A. Public Key Infrastructures (PKIs) and Certificates S-BGP uses two PKIs, based on X.509 (v3) certificates, to enable BGP speakers to validate the identities and authorization of BGP speakers and of owners of ASes and of portions of the IP address space. These PKIs parallel the existing IP address and AS number assignment delegation system and take advantage of this extant infrastructure. Because these PKIs mirror existing infrastructure, their creation avoids many of the trust issues that often complicate the creation of a PKI. The two PKIs involve four types of certificates, as illustrated below (in the diagrams). The higher node is the issuer for the certificates defined in the tier below it. The name of the current tree node (organization, AS, router, etc.) is the subject of the certificate. Any additional fields shown in the node, e.g., address block(s), are in an extension in the certificate. Other X.509 certificate fields are assumed, but not shownsequence number, subject public key, signature, validity period, etc. Note that the organizations that assign addresses (Registries, ISPs, DSPs, etc.) and the organizations that obtain autonomous system numbers from a Registry may be different. An organization could receive its AS number from a registry and its address block from an ISP. So the Org3_4 shown in
3Technically, two certification hierarchies are employed, but they might employ common procedures etc. and thus be considered a single PKI.
KENT et al.: SECURE BORDER GATEWAY PROTOCOL
Fig. 1. Address allocation PKI structure.
the first PKI hierarchy (Fig. 1) could correspond to the Org 1 shown in the second PKI hierarchy (Fig. 2). 1) A PKI for Address Allocation: This architecture calls for a certificate to be issued to each organization that is granted ownership of a portion of the IP address space. This certificate is issued through the same chain of entities that, in the existing environment, is responsible for address allocation. The root of this chain is the ICANN, followed by regional address space allocation authorities (e.g., ARIN and RIPE), ISPs, DSPs, and end users. Note that the proposed system does not require that address assignments be certified all the way to the subscriber. If a subscriber's address is allocated from that of a DSP or an ISP with which it is currently affiliated, then the certification process need only be effected as far as the ISP/DSP. The same applies to DSPs that receive their address-space assignments from ISPs. Also note that a subscriber (or a DSP) who does not participate in BGP exchanges (e.g., is singly homed) need not be issued a certificate if the subscriber's address space is derived from that of an encompassing ISP or DSP.4 Finally, if an organization owns multiple ranges of addresses, this design calls for assigning a single certificate5 containing a list of address blocks, so as to minimize the number of certificates needed to validate an UPDATE. This PKI reflects the assignment of address blocks to organizations by binding address block(s) to a public key belonging to the organization to which the addresses are being assigned. Unlike a typical X.509 certificate, the identity of the subject is not the primary focus of these certificates; instead, these certificates are used to prove ownership of a block of addresses.6 Each certificate in this PKI contains a (private) extension that spec4For historical reasons, the chain of issuance described above was sometimes short circuited. A subscriber (or DSP) who has an address-space assignment that has bypassed the normal allocation procedure, who has changed DSPs/ISPs and retained the originally assigned address, must also be certified, even if not a BGP user. 5If an organization acquires additional address blocks, a new certificate is issued to reflect the increased scope of ownership. 6One could place the address block in an X.509 attribute certificate, linked to an X.509 public key certificate, in a more elegant approach to representing this data. However, because the number of certificates involved is so great, and because attribute certificates are not yet widely supported, we have chosen to add the address block information as a private, v3 extension to a public key certificate.
Fig. 2. Autonomous system identification and BGP speaker PKI.
TABLE I ADDRESS ALLOCATION PKI CERTIFICATE OVERVIEW
ifies the set of address blocks that have been allocated to the organization. The subject alternate name in each certificate is the DNS name of an organization: an ISP, DSP, or a subscriber. The ICANN, as root, is represented nominally by a self-signed certificate that contains an extension expressing ownership of the entire address space. In Fig. 1, we note the following. a) ICANN is the root and issues certificates to the first tier of organizations (Org1_x). Under current practice, Org1_x would be an Internet Registry, although historically it could have been an ISP, an organization, etc. ICANN signs the tier 1 certificates using its private key. b) Org1_x then assigns sub-blocks of its address space to ISPs or DSPs. In the diagram, for example, Org1_1 issues a certificate to each of Org2_1 through Org2_7 and Org1_N issues a certificate to Org2_8. Org1_x signs the certificate using the private key corresponding to the public key in the certificate it received in (a). c) Org2_x then assigns sub-blocks of its address space to customers, DSPs, etc. In the diagram, Org2_1 issues a certificate to each of Org3_1 through Org3_4. Org2_x signs the certificate using the private key corresponding to the public key in the certificate it received in (b). d) And so on. Table I summarizes the Issuer/Subject relationships for the certificates in this PKI. 2) A PKI for Assignment of ASes and Router Associations: Three types of certificates will be used to support the authentication of ASes and BGP speakers, and the relationship
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 18, NO. 4, APRIL 2000
TABLE II AS AND BGP SPEAKER PKI CERTIFICATE OVERVIEW
between speakers and ASes. Here, too, the ICANN is the root and the next tier consists of registries, but the third tier consists of organizations that own ASes, followed by a tier of AS numbers and routers. The result is a broader, shallower certification tree. As before, this tree parallels existing trust relationships, i.e., the ICANN assigns AS numbers to registries, which in turn assign one or more AS numbers to organizations (e.g., ISPs/DSPs) that run BGP. Each of these organizations is authoritative for identifying routers as representatives (BGP speakers) for the AS(es) that the organization owns. In order to express the ownership of an AS by an organization, each third tier certificate carries an extension that enumerates the ASes assigned to that organization. Validation of fourth tier certificates requires matching asserted AS numbers against these extensions. For each fourth tier AS certificate [type (b), below] there are typically several router (BGP speaker) certificates [type (c), below], each specifying the same AS number. (Note that there could be more than one certificate assigned to a BGP speaker if the speaker acts as a proxy for another AS.) As shown in the Fig. 2, these three types of certificates bind together: a) AS numbers and an organization's public keya registry issues these to organizations and signs them using its private key. The alternate name in the certificate is the DNS name of the organization. An extension contains the (list of ranges of) AS number(s). b) An AS number and its public keyan organization issues these and signs them using the private key corresponding to the public key in the certificate described in (a). The issuer alternate name in the certificate is the DNS name of the organization. The subject alternate name is the AS number. c) A router (DNS) name, a router id, an AS number, and the router's public keyan organization issues these and signs them using the private key corresponding to the public key in the certificate described in (a). Both the router id (an IP address) and the AS number are extensions in this certificate, and the binding of three items is a critical aspect of this certificate. The alternate name in the certificate is the DNS name of the router corresponding to the router id. B. Attestations An attestation establishes that the subject of the attestation (an AS) is authorized by the issuer to advertise a path to the specified blocks of address space. There are two classes of attestations, address and route, although a single format is employed
to represent both. Route attestations are carried in a new type of optional BGP path attribute as part of UPDATE messages. Address attestations. Here the issuer is the organization that owns the address space and the subject is an AS that may originate it, e.g., the organization's provider. The issuer signs an address attestation using the private key that corresponds to the public key in the certificate (see Fig. 1) assigning this address space to the issuer. Route attestations. Here the subject is a transit AS. A route attestation is signed by the S-BGP speaker (or offline by the management of the AS). The signer uses the private key that corresponds to the public key in the certificate that binds the speaker to the subject AS (see Fig. 2). If an organization has more than one AS, there are separate attestations for each AS rather than just one attestation containing multiple AS numbers. Each AS will have its own set of BGP speakers and its own authentication certificate(s) as well. This applies to both the stub and transit AS cases. Figure 3 summarizes the structure for address and route attestations. C. Route Validation Attestations and certificates are used by BGP speakers to validate routes asserted in UPDATE messages, i.e., to verify that the first AS in the route has been authorized to advertise the address block(s) by the address block owner(s), and that each subsequent AS has been authorized to advertise the route for the address block(s) by the preceding AS in the route. To validate a needs: route received from 1 address attestation from each organization owning an address block or blocks in the NLRI 1 address allocation certificate from each organization owning an address block or blocks in the NLRI 1 route attestation from every S-BGP speaker (or its AS) to ), where the route attestation along the path ( ) specifies the generated and signed by router (or through NLRI and the AS_PATH from 1 certificate for each S-BGP speaker along the path ( to ) to check the signatures on the route attestations and, of course, all the relevant CRLs must have been verified. This means that, for each UPDATE, there must be attestations confirming that all the ASes in the BGP UPDATE are authorized to advertise routes to the destination IP address block(s). This includes ASes that are providing third party advertisements for ASes that are not running BGP. The attestations are not used for checking withdrawn routes because the authorization of the BGP speaker to advertise
KENT et al.: SECURE BORDER GATEWAY PROTOCOL
Fig. 3. UPDATE format with route attestations.
those routes was verified at the time they were installed into the local routing information base (Loc-RIB). Moreover, if the BGP speaker has lost the authorization to advertise that route, then the route is by definition no longer valid and should be withdrawn. Use of IPsec on inter-router communication paths prevents an active wiretapper from spoofing route withdrawals, or replaying valid UPDATEs at times when a BGP speaker would not transmit them, e.g., after a route has been withdrawn and prior to advertisement of the same or a different route.
D. Distribution of Countermeasures Information This subsection discusses the mechanisms used to distribute certificates, CRLs, and address and route attestations to the relevant devices performing route validation: S-BGP speakers, route servers, etc. 1) Distribution of Certificates, CRLs, and Address Attestations: Each S-BGP speaker must have access to the public keys required to validate UPDATEs. For nonleaf S-BGP speakers, this amounts to a full set of certificates encompassing all address space owners, AS owners, and some number of S-BGP speakers (plus the ICANN and registry certificates). An X.509 certificate used in this environment is about 450 bytes long, depending on naming conventions and extensions. In the current (June 1999) Internet environment, there are approximately 5300 autonomous systems, 44 000 organizations that own address prefixes, and 7500 BGP speakers. The resulting certificate database comprises about 25.5 Mbytes, and it can be expected to grow each year as more address prefixes, autonomous systems, and BGP speakers are added. The CRL database associated with these certificates would add to this total, although probably not significantly. At first glance, it might seem appropriate to transmit certificates as part of each UPDATE. This would ensure that each receiving BGP speaker would receive all the data needed to validate the route attestations in an UPDATE, and it would be easy for each BGP speaker to include its own certificate as part of the forwarding process. However, this would be very wasteful of bandwidth, as each BGP speaker would receive many redundant
copies of certificates.7 More importantly, this approach is infeasible, because BGP UPDATEs are limited in length to 4096 bytes and thus are too small to carry the necessary certificates for most UPDATEs.8 The introduction of a new type of BGP message for transmission of certificates (and CRLs) could address the packet size problem, but would still tend to be very wasteful of bandwidth and would not be backward compatible. Instead, this architecture uses out-of-band distribution of certificates and CRLs to all S-BGP speakers. This is an attractive approach to the distribution problem for several reasons. This database is relatively static and thus a good candidate for caching and incremental update. Moreover, the certificates can be validated (and processed against CRLs) and reduced to a more compact format by ISPs/DSPs prior to distribution to S-BGP speakers. This avoids the need for each speaker to perform this processing (entailing tens of thousands of signature and validations), it saves both bandwidth and storage space. Although memory is inexpensive, most currently deployed commercial routers do not possess sufficient memory to store all of these certificates so either additional memory or auxiliary systems will be needed, even with preprocessing. To address the distribution problem, we make use of two tiers of repositories from which one can download the entire certificate and CRL database. The top tier consists of several replicated, easy-to-access storage sites, e.g., the NAP route servers. The second tier of repositories are operated by the ISPs/DSPs, to provide local access for the S-BGP speakers within each AS. (Per-AS repositories avoid the dependency loop that would occur if one required inter-AS routing in order to access this database.) Bulk transfer of the whole certificate or CRL database, from the first to second tier repositories, can be effected via FTP or TFTP; since certificates and CRLs are signed and carry validity interval information, there is no need for additional integrity mechanisms in the transfer. The second tier repositories also will query top tier repositories to get new CRLs, based on the CRL NEXT UPDATE field, and to get new certificates, based on certificate expiration, e.g., using the Lightweight Directory Access Protocol (LDAP). Retrieval of newly issued certificates for newly created ASes, organizations with new address space ownership, etc., in between downloads of the complete database, could be effected in the same manner, from daily incremental update files. This allows an ISP/DSP to operate in an anticipatory fashion, retrieving certificates before it needs them. Each second tier repository will validate all of the certificates and CRLs it retrieves, and produce a more compact (locally signed) database ready for consumption by the S-BGP speakers within its administrative purview. If deemed necessary, the top tier repositories also can push CRLs issued prior to scheduled dates. The same analysis applies to address space attestations. Each address attestation requires about 115 bytes, and this amounts to approximately 5 Mbytes. Carriage of these data
7The redundancy arises from several sources. A BGP speaker tends to receive routes to the same destination, via each interface, with considerable overlap of ASes in each route. Withdrawal and later re-advertisement of the same routes via the same interfaces results in additional redundancy. 8Many UPDATEs contain routes for multiple address blocks and some routes contain many AS numbers, and each requires its own certificate.
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 18, NO. 4, APRIL 2000
items in UPDATEs would usually be redundant and thus is more effectively handled via the same, out-of-band distribution mechanism. Here, too, this distribution model allows preprocessing by ISP/DSP NOCs, further eliminating significant signature validation overhead (there would be roughly 44 000 such attestations currently). This model also simplifies revocation of address attestations, i.e., an address space owner can issue a CRL-like, signed data structure and include it in the database for downloading and preprocessing by each ISP/DSP. The total space required for the certificate and address attestation databases can be reduced from about 30.5 Mbytes to about 11.7 Mbytes as a result of preprocessing. 2) Distribution of Route Attestations: Route attestations are distributed with BGP UPDATEs in a newly defined, optional, transitive path attribute. This approach requires BGP speakers to be upgraded to a BGP release with these countermeasures. When an S-BGP speaker opens a BGP session with a peer, transmitting the advertisable portion of its routing information database via UPDATEs, relevant route attestations are sent with each UPDATE. These attestations employ a compact encoding scheme to help ensure that they fit within the BGP packet size limits, even when route or address aggregation is employed. The S-BGP speaker receiving an UPDATE9 caches the associated attestations with the route in its routing information database. Each BGP speaker generates route attestations based on receipt of UPDATEs from its neighbors, as described in Section IV-B, thus in-band distribution is appropriate. As noted below in Section VI-B, the bandwidth required to support in-band distribution of route attestations is negligible (compared to user traffic). E. IPsec and Router Authentication BGP is transported over TCP and thus is protected against misordered, lost, or replayed packets, to the extent that the TCP sequence number management facility is secure. BGP-4 provides a means for carrying authentication information in BGP messages, but there is no prescribed key management scheme and there is no facility for sequence numbering of BGP messages, hence this facility is not employed here. Instead, we use the Encapsulating Security Payload (ESP) protocol (with NULL encryption), from the IP security protocol suite (IPsec)  to provide authentication, data integrity, and anti-replay on a point-to-point basis, i.e., between BGP speakers. The Internet Key Exchange (IKE) protocol is used for key management services in support of ESP. The PKI established for router and AS authentication provides the necessary certificates (see Section III-A2). F. Other Issues BGP Path Attributes are being standardized to support Communities (to support policy) , Confederations (used to transparently split a large AS into several smaller ASes to reduce the squared peering requirements) , and to support additional protocols (IPV6, MPLS, and multicast) . The Route Attestation mechanism is designed to provide protection for these and
9We have not yet determined if a mechanism for revoking route attestations is required, or if a modest attestation lifetime will suffice.
other new path attributes, in the same manner in which it protects the current path attributes. IV. HOW THESE COUNTERMEASURES ADDRESS BGP VULNERABILITIES This section describes how the proposed countermeasures reduce the vulnerability of BGP to the attacks described earlier, and provide much of the functionality necessary for ensuring the correct operation of BGP. A. Certificates The certificates described above are used to enable verification of the following. An AS's authorization to advertise a block of addresses. The certificates from Section III-A1 are used to verify that an AS is authorized to advertise a block of addresses. Specifically, the signature on an address attestation must be verifiable using the public key in a certificate containing the address block or blocks that include the address block(s) in the address attestation. An organization's ownership of an AS number. The certificates from Section III-A2a are used to verify that an AS has been assigned to the holder of a particular public key, i.e., an ISP, DSP, or subscriber organization. They are used to validate Section III-A2b or III-A2c certificates through the AS number linkage. An AS's identity. The certificates from Section III-A2b (or certificate data preprocessed by a NOC and distributed to routers) are used to verify the signature of an AS on a route attestation. A BGP speaker's identity and its association with an AS. The certificates from Section III-A2c are used to verify the signature of a speaker on a route attestation, and in conjunction with Section III-A2a to make sure that the speaker is authorized to act on behalf of the AS. Identity and authorization of a BGP peer. The certificates from Section III-A2c are used by the BGP speakers when establishing peering sessions, to authenticate each other. B. Address and Route Attestations These two countermeasures support validation of the address prefixes and path information in an UPDATE. Address attestations protect BGP against misbehaving BGP speakers that originate or distribute erroneous UPDATEs and BGP speakers whose advertisable destination addresses have been misconfigured. Whenever an S-BGP speaker advertises itself as the starting point of a route for some address prefix, other S-BGP speakers will verify that the AS represented by that speaker is the subject of an address attestation signed by the owner of the address prefix. Since only the organization that owns the prefix can sign such an attestation, no S-BGP speaker can falsify such an advertisement. Each S-BGP UPDATE will include a set of route attestations, one per AS listed in the UPDATE, each of which is added to the UPDATE as it propagates among ASes. A route attestation indicates that the signing BGP speaker is authorized to advertise to
KENT et al.: SECURE BORDER GATEWAY PROTOCOL
the neighbor the route constructed thus far, by the organization owning the AS (in which the speaker resides). The route attestation is digitally signed by the S-BGP speaker distributing the UPDATE. It includes the identification of the S-BGP speaker's certificate issued by the owner of the AS, the destination addresses in the route, the list of identifiers of ASes in the route, the identifier of the AS to which the UPDATE is directed, a maximum lifetime, and other transitive data requiring protection. Each recipient of an UPDATE verifies the route attestations contained within it before deciding whether to accept and distribute the UPDATE. Route attestations protect BGP against misbehaving BGP speakers that distribute erroneous UPDATEs, and against misconfigured local routing policies. C. IPsec IPsec (specifically ESP and IKE) provides the security services needed by the receiving BGP speaker to verify message integrity, the identity of the sender, and the fact that it (the receiver) is the intended recipient of every message. Although the attestations in UPDATE messages protect against a wide range of active wiretap attacks, use of ESP provides protection for all BGP traffic, prevents replay of messages across a link, and protects TCP against various forms of attack, including SYN flooding and spoofed RSTs (resets). V. RESIDUAL VULNERABILITIES The S-BGP system (address attestations, route attestations, PKIs, and IPsec for all BGP messages) addresses many of the vulnerabilities of BGP-4. Nevertheless, there exist vulnerabilities that are not eliminated by this system, including the following. Suppression of BGP messages by a misbehaving BGP speaker is not addressed. Use of IPsec (and TCP) will detect active wiretap attacks that result in lost or reordered BGP packets. However, a compromised BGP speaker can elect to not transmit BGP messages, even when local policy would call for such transmission, e.g., for route withdrawal. This is undetectable by the proposed countermeasures, although coordinated network monitoring might be able to detect such misbehavior. The substantial flexibility afforded by local policies in BGP appears to preclude countering this vulnerability if such policies are to remain private to ASes (as allowed by the BGP specification and as currently practiced). Passive wiretapping to discover network connectivity information is not addressed. These attacks could be countered by enabling the confidentiality feature of ESP, if the risk exceeds the cost to encrypt and decrypt UPDATE messages. A BGP speaker may reassert a route that was withdrawn earlier, even if the route has not been readvertised. This vulnerability exists because BGP UPDATEs do not carry sequence numbers or timestamps that could be used to determine the currency of UPDATEs. However, route attestations do expire, so there is a limit on how long an old attestation can be used for such purposes. The possibility
also exists to add a CRL-like function for route attestation revocation, a possibility that will be explored later in our work. Verification that the BGP peers that exchanged the UPDATE, correctly applied BGP rules, local policies, etc., is not addressed. As above, BGP affords speakers considerable latitude with regard to local policy and ASes do not usually make public their local routing policies, hence it appears difficult to counter such problems. S-BGP restricts malicious behavior to the set of actions for which the speaker (or AS) is authorized, based on externally verifiable constraints. VI. PERFORMANCE AND OPERATIONAL ISSUES In developing the S-BGP architecture, we have paid close attention to the performance and operational impact of the proposed countermeasures. Previous work in the area of routing security has often focused almost exclusively on the costs of generating and validating digital signatures. While such costs are an important factor, our analysis suggests that the bandwidth and storage requirements associated with signatures, certificates, and CRLs are much bigger problems. The following analysis is based on examination of actual Internet routing data plus simulation of the effects of S-BGP countermeasures. A. Processing The computation burden for signature generation and validation appears to be tractable in this proposed architecture. We have selected the Digital Signature Algorithm (DSA) to minimize the size of the signatures, specifically for route attestations.10 DSA yields only a 40-byte signature, versus the 128-byte signature typical for RSA (using 1024-bit keys). DSA also allows for pre-computation, which permits lower latency in signature generation by S-BGP speakers. Other (S-BGP-specific) techniques (described below) significantly reduce the need for signature validation operations, so the processing asymmetry exhibited by DSA is not a concern here. The rate at which new UPDATEs are created is not so great that signature generation and validation of route attestations is expected to pose a bottleneck. A BGP speaker at a NAP, peering with about 30 other BGP speakers, receives an average total of about 0.5 UPDATEs per second. Each route contains an average of 3.6 ASes, and there is one route attestation per AS, yielding a rate of about 1.8 signature validations per second. In contrast, each UPDATE generated by an S-BGP speaker requires just one signature (added by the speaker), thus the signature generation rate is less than one third of this value. Peak load figures may be about a factor of ten greater, yielding a peak load of about 18 signatures per second. However, analysis of data from NAPs shows that 50% or more of all UPDATEs repeat routes already known to a BGP speaker (e.g., due to link flapping). Thus, caching just one route for each address prefix enables a speaker to avoid the need to validate signatures on the
10Since certificates, CRLs, and address attestations are stripped of signatures in preprocessing, the choice of signature algorithm is not so critical for these data structures.
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 18, NO. 4, APRIL 2000
vast majority of UPDATEs, reducing the peak load to about 9 signatures per second, which is a tolerably low computational burden.11 Upon initialization (reboot), a BGP speaker receives complete routing table UPDATEs from each peer. This means that an S-BGP speaker will receive a very large number of route attestations requiring validation, i.e., about 220 000 per peer, in a short time interval. This sort of initialization transient would be unacceptable, even though reboots and installation of new speakers is relatively infrequent.12 To avoid this problem, we propose the addition of nonvolatile storage for validated route attestations, to preserve the cache across reboots. When installing a new BGP speaker in an AS, a NOC could dump the cache from another speaker in the AS and reload it into the new BGP speaker, to seed the cache in the newly installed device. B. Transmission Bandwidth The transmission of countermeasures data in UPDATEs increases the size of these messages to approximately 450 bytes (based on an average of 3.6 route attestations per path), for a typical UPDATE that previously required only 63 bytes. This represents a significant percentage increase in BGP overhead (over 700%), but the transmission of UPDATEs represents a very, very small amount of data relative to subscriber traffic. As noted above, even a speaker at a NAP sees an average rate of less than one UPDATE per second, and such speakers are connected via 100 Mb/s interfaces today, with plans to transition to multi-Gb/s interfaces in the future. Downloading the certificate, CRL, and address attestation databases contributes an insignificant increment to this overhead. Full database transmission, from a top tier to a second tier repository entails about a 30 Mbyte file transfer for each ISP/DSP. Even if performed on a daily basis, this traffic is swamped by subscriber file transfers. Transfers from a second tier repository to each BGP speaker in its AS are smaller, about 12 Mbytes. Here, too, even if performed daily, this would be but a drop in the ocean of subscriber traffic, and use of incremental transfers is a more likely scenario. So the impact on utilization of Internet bandwidth due to transmission of all of the countermeasures data is minimal. Also, the speed of interrouter circuits continues to increase substantially, further minimizing the impact of transmission of additional control traffic. C. Storage/Memory UPDATEs received from neighbors are held by a BGP router in Routing Information Bases (RIBs) and used to generate new UPDATEs for transmission to other BGP routers. The additional memory required for preprocessed certificates and address attestations amounts to about 12 Mbytes, as noted earlier. The space required for route attestations is about 20 Mbytes per peer, a modest amount for a typical speaker with 2 or 3 peers, but a significant amount of storage for speakers at NAPs,
11For example, SSLeay software can perform about 40 1024-bit DSA signatures per second on a 450 MHz Pentium II processor. 12Because of the important service they provide, BGP speakers are usually afforded UPS protection and new software is deployed only after extensive testing, to minimize the likelihood of crashes.
where each speaker has about 30 peers. This amounts to a large but feasible amount of additional RAM by current standards, where a high end workstation can be configured with hundreds of megabytes of RAM. The routers that act as BGP speakers at NAPs are large, very expensive devices. However, the storage capacity of the routers currently used by ISPs/DSPs would not permit storage of S-BGP UPDATEs in their RIBs, if S-BGP were deployed. Thus, additional, nonvolatile storage is needed in BGP speakers to support these databases. It may be feasible to significantly reduce the storage required here, since the routes (and thus route attestations) received from different peers tend to exhibit significant overlap in their suffixes. D. Deployment and Transition Issues Deploying S-BGP raises a number of other issues. Adoption of S-BGP by several groups. The ISPs, DSPs, and subscriber organizations running BGP will need to cooperate in the generation and distribution of attestations. The first tier ISPs (those connected to the NAPs) must implement the S-BGP security mechanisms in order to offer significant benefit to the Internet community. (Lower level ISPs, DSPs, and subscriber organizations will need to implement the S-BGP security mechanisms only if the expense can be justified.) ICANN and registration authorities will need to expand their operational procedures to support generation of address space and AS number delegation certificates. Finally, router vendors need to provide additional storage in next-generation products, or offer ancillary devices for use with existing router products, and revise BGP software to support S-BGP. S-BGP interaction with other exterior and interior routing protocols. External routes received from external peers need to be redistributed within the AS in order to maintain a consistent and stable view of the exterior routes across the AS. Interior routing protocols will not propagate S-BGP attestations, but if each border S-BGP speaker maintains an iBGP13 connection with all other transit and border routers within the AS, this problem will be averted. BGP-4 to S-BGP transition. The route attestation path attribute is optional for both external and internal BGP exchanges. This allows extensive regression testing before deploying S-BGP on production equipment. VII. SUBSEQUENT OTHER WORK Since we began this work, there have been several other efforts toward securing BGP. These include an assessment of BGP vulnerabilities14 and several approaches to addressing some of these vulnerabilities. TCP/MD5 . This defines a TCP option for carrying an MD5 digest. This mechanism offers data origin authentication and data integrity, on a point-to-point basis. It protects the TCP connection used to transport BGP traffic
13The acronym iBGP denotes use of intra-AS use of BGP, in contrast to the common inter-AS use of BGP, sometimes referred to as eBGP. 14S. Murphy's BGP Security Analysis surveys this topic. At the time this paper was prepared, the most recent version was <draft-murphy-bgp-secr03.txt>, June 1999.
KENT et al.: SECURE BORDER GATEWAY PROTOCOL
from spoofing attacks and connection hijacking. Lack of an automated key distribution protocol complicates management and encourages overly long-term use of symmetric keys. Moreover, because it fails to protect against any attacks that subvert routers or the management of routers, its overall security efficacy is quite limited. NLRI Origin Verification . This mechanism proposes adding an address prefix delegation tree to Secure DNS . For each prefix that has been authorized for use, a new resource record specifies the number of the AS that is authorized to originate that prefix. This mechanism does not address route authorization, nor does the proposal describe in detail how this data would be distributed to BGP speakers. It does represent an alternative format and database option for the address attestations developed in our architecture. Routing Policy System Security . This approach places authorization information into a small number of databases (Internet Routing Registries) accessible by routers. The information is placed into a database by the organization responsible for the authorization, using some secure access method, e.g., SSL. It proposes that BGP speakers compare the routes that they receive to the routes listed in the database, rejecting any routes not found. No changes to BGP are required. This approach does not appear to be very dynamic, although details of how, and how often, the registries are to be accessed are omitted. Use of such registries would require ISPs/DSPs to publicize what is now local policy information, which most have refused to do. Moreover, the routes stored in the registries are not signed, so attacks against these databases, including malicious or benign errors by an ISP/DSP, could compromise security. Hash Chain Signatures . This work describes two protocols, COSP and IOSP, based on hash chain signatures, that offer very rapid signature generation and validation in a routing protocol context. COSP is not applicable because it requires signing messages at fixed time intervals, whereas BGP generates UPDATEs on demand, as a result of topology changes; IOSP is not applicable because its efficiency depends on each router receiving essentially all routing UPDATEs, which is not characteristic of the operation of BGP.
The results of this work will include the prototype software (GateD) and a report on the results of these tests, e.g., analysis of S-BGP performance and overhead costs with various optimizations. We hope to be able to pursue additional technology transfer activities to facilitate adoption of S-BGP. IX. SUMMARY BGP is a critical component of the Internet's routing infrastructure and highly vulnerable to a variety of attacks. The S-BGP countermeasures use IPsec, Public Key Infrastructure (PKI) technology, and a new BGP path attribute (attestations) to ensure the authenticity and integrity of BGP communication on a point-to-point basis, and to validate BGP routing UPDATEs on a source to (multicast) destination basis. These enhancements will allow Internet Service Providers (ISPs) and their customers to verify that: reachability information they receive is from an authentic and authorized BGP peering relationship and has not been modified without authorization; the authorization of an organization to claim ownership of a block of IP addresses (a (sub)network) is substantiated by a chain of authorizations rooted at the Internet Corporation for Assigned Names and Numbers; an originating AS is authorized to advertise reachability to a block of IP addresses by the organization owning that address block; the ASes that processed the routing information en-route from the originating AS are not, either through misconfiguration, internal error, or compromise, advertising reachability information that is inconsistent with nominal topology; each AS, and its BGP speakers, that advertise a given route are identifiable and authorized to participate in global Internet routing, by a chain of authorizations rooted at the ICANN. ACKNOWLEDGMENT Many individuals contributed to the design and development of S-BGP. Initial funding was provided by NSA, in April of 1997, yielding a first cut design. DARPA provided later support, under Dr. H. Orman, enabling us to refine, implement, and test the design. S-BGP has benefited significantly from the insight and efforts of M. Steenstrup and L. Sanchez. As members of the architecture team, their contributions were critical to the design of the attestation and PKI schemes and the associated evaluations of other approaches and performance and operational issues. The authors would also like to thank M. Casagni, for her work on the performance analysis and J. Mikkelson, D. Rockwell, and N. Shectman for their efforts during the ongoing implementation and experimentation phase. REFERENCES
 Y. Rekhter and T. Li, A border gateway protocol 4 (BGP-4),, RFC 1771, Mar. 1995.  An architecture for BGP countermeasures,, BBN Rep. 8217, Nov. 1997.
VIII. FUTURE WORK Deploying this technology into the Internet will require the creation of the supporting Public Key Infrastructures, rooted at the ICANN, and convincing ICANN, the Internet Registries, the major ISPs, the owners of IP address blocks and the router vendors of the benefits and supportability of these security mechanisms. To facilitate this transfer of technology, we are currently building a proof-of-concept prototype of S-BGP to demonstrate the viability and feasibility of deploying this technology into the Internet. This involves deploying the technology in DARPA's CAIRN testbed and running experiments with current Internet BGP traffic and Merit's historical BGP data.
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 18, NO. 4, APRIL 2000
 C. Villamizar, R. Chandra, and R. Govindan, BGP route flap damping,, RFC 2439, Nov. 1998.  B. R. Smith and J. J. Garcia-Luna-Aceves, Securing the border gateway routing protocol, in Proc. Global Internet'96, Nov. 1996.  B. R. Smith, S. Murphy, and J. J. Garcia-Luna-Aceves, Securing distance-vector routing protocols, presented at the Symp. Network Distributed Syst. Security, Feb. 1997.  B. Kumar, Integration of security in network routing protocols, ACM SIGSAC Rev., vol. 11, no. 2, Spring 1993.  S. Murphy, Panel presentation (no text) on security architecture for the internet infrastructure, presented at the Symp. Network Distributed Syst. Security, Apr. 1995.  S. Kent and R. Atkinson, Security architecture for the Internet protocol,, RFC 2401, Nov. 1998.  R. Glenn and S. Kent, The NULL encryption algorithm and its use with IPsec,, RFC 2410, Nov. 1998.  S. Kent and R. Atkinson, IP encapsulating security payload (ESP),, RFC 2406, Nov. 1998.  D. Maughan, M. Schertler, M. Schneider, and J. Turner, Internet security association and key management protocol (ISAKMP),, RFC 2408, Nov. 1998.  D. Harkins and D. Carrel, The Internet key exchange (IKE),, RFC 2406, Nov. 1998.  R. Chandra, P. Traina, and T. Li, BGP communities attribute,, RFC 1997, Aug. 1996.  P. Traina, Autonomous system confederations for BGP,, RFC 1965, June 1996.  T. Bates, R. Chandra, D. Katz, and Y. Rekhter, Multiprotocol extensions for BGP-4,, RFC 2283, Feb. 1998.  A. Heffernan, Protection of BGP sessions via the TCP MD5 signature option,, RFC 2385, Aug. 1998.  T. Bates, R. Bush, T. Li, and Y. Rekhter. DNS-based NLRI origin AS verification in BGP. presented at NANOG 12. [Online]. Available: http://www.nanog.org/mtg-9802  D. Eastlake, III and C. Kaufman, Domain name system security extensions,, RFC 2065, Jan. 1997.  C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, and C. Villamizar, Routing policy specification language (RPSL),, RFC 2280, Jan. 1998.  K. Zhang, Efficient protocols for signing routing messages, presented at the Network and Distributed Syst. Security Symp., Mar. 1998.  R. Perlman, Network layer protocols with Byzantine robustness,, MIT/LCS/TR-429, Oct. 1988.
Stephen Kent received the B.S. degree in mathematics from Loyola University, New Orleans, and the S.M., E.E., and Ph.D. degrees in computer science from the Massachusetts Institute of Technology. He is the Chief Scientist for Information Security for BBN Technologies, where he has engaged in information security R&D for over 20 years. His most recent work focuses on public-key certification infrastructures for government and commercial applications, security for Internet routing, and high assurance cryptographic modules. He has served on the Internet Architecture Board and chaired the Privacy and Security Research Group of the IRTF, both for over a decade. He currently co-chairs the Public Key Infrastructure Working Group of the IETF and is a member of the editorial board of the Journal of Computer Security. Dr. Kent is a Fellow of the ACM and a member of the Internet Society and of Sigma Xi.
Charles Lynn received the S.B., S.M., E.E., and Ph.D. degrees in electrical engineering from the Massachusetts Institute of Technology. He is a Division Scientist in the Internet Research Department of BBN Technologies where he has been involved in the design and implementation of advanced internetwork research projects for over 15 years. Recent research has included high performance QOS support for IP multicast over ATM, implementation and evaluation of novel routing architectures, and the work described in this paper.
Karen Seo received the S.B. degree in biology and management and the S.M. degree in management from the Massachusetts Institute of Technology. She is a member of the Security Practice Center at BBN Technologies where she has been involved in the development and operations of advanced networking systems for more than 15 years. Her responsibilities have included management of the Terrestrial Wideband Network (a transcontinental T1 network), BBN's communications and computer services, and the (trans) Atlantic Packet Satellite Network (SATNET), as well as research projects on real-time multicast communications, QOS support for distributed real-time applications, and the work described in this paper.
Find millions of documents on Course Hero - Study Guides, Lecture Notes, Reference Materials, Practice Exams and more.
Course Hero has millions of course specific materials providing students with the best way to expand
Below is a small sample set of documents:
Berkeley - MSE - 205
Elastic Inclusions: ApplicationsJ.W. Morris, Jr., January, 2008Chapter 20: Elastic Inclusions - ApplicationsCHAPTER 20: ELASTIC INCLUSIONS - APPLICATIONS20.1 The Preferred Shape and Habit of an Elastic Inclusion 20.1.1 Anisotropic elastic energy funct
Providence CC - NR - 12146
STAFF SUPERVISOR USER'S GUIDEProvidence College Employment Application SystemTABLE OF CONTENTSINTRODUCTION . 3 PROVIDENCE COLLEGE WORKFLOW PROCESS. 5 GETTING STARTED. 6 CREATE USER . 7 CREATING A REQUISITION/POSTING . 8 Entering Requisition/Posting Inf
CSU Long Beach - IS - 233
2003 Annual Report Seatek-Parkway Enterprises January 2004Corporate Overview The consumer products industry has seen dramatic change in the last decade, due to increasing costs in manufacturing, need for innovative products, and decrease in brand loyalty
Plymouth - OZ - 5905
Dana C. ErnstStatement of Teaching PhilosophyIn my opinion, the purpose of education is to train the mind to learn how to learn. According to Plato, "mathematics is the best training for the mind." Many people believe that mathematics solely exists to p
Arkansas State - MIS - 1503
Mountain View Apartment Complex October 2004 Newsletter Winter will soon be upon us, so we're starting this newsletter by providing some basic maintenance instructions for you. As the managers of the apartment complex, we want to provide a safe, comfortab
Bethel VA - MS - 140702
MELANIE SULLIVANOBJECTIVE614.203.0035 - email@example.com 215 North Vine Street - Westerville, Ohio 43081 http:/oak.cats.ohiou.edu/~ms140702To obtain a teaching position where my philosophy of challenging and supporting students to become positive and
Stanford - EE - 410
EE410 / Saraswat Week 1: PreparationEE410 CMOS PROCESS FLOW1. Wafer Start: Starting material is n-type silicon [STEP 00.000] Standard piranha clean 2. Photomask #0: Zero level marks [STEPS 0.00-0.22] Singe and prime (yes oven) Resist coat (svgcoat1/2, p
National Taiwan University - ECONOMICS - 501
ECON501 Review Sheet Equilibrium condition in a market: Q dQsElasticity of demand: E dQd Qd P PElasticity of supply: E sQs Qs P PIndifference curve=bundles of goods yielding the same level of utility when consumed; the slope of an indifference curve
Cal Poly Pomona - ECON - 316
Constrained OptimizationRational behavior entails doing the best we can for ourselves, given the constraints on us due to scarce resources. In this course so far, we have examined profit maximization without any explicit constraints. In reality, there we
Clarkson - MA - 383
zR '~ | Y ` AA '| Y ~ m r ig n fbjqsutjig # x h v t t tt g gh g g g gh h # fbTiugirg x x CuCsC o m C s sest x x z x qqiCqh yxv CuTpitr x uqf x CfTug `v R iiqib P 'R| Y T ~ ~ ` srbCP w ErbCP T '!y| Y x h uk bjsfeqCiet x iigurg x x zv g htth g x v t t CGez
Penn State - KRP - 5028
Diffusion of 1832 Cholera Epidemic In the 1832 situation, there were two different routes taken by the disease. The assumption that the cholera outbreak began in Plattsburg and then spread radially outward from there is not entirely correct. Plattsburg wa
Dallas - LXS - 055000
BA 4371-004 International Business Class 11 International Alliances and M&ASunny Li SunNov. 8, 20081Obama'sVictory:ThreeLessonsforBusiness Leader A clear, consistent vision His message was simple and aspirational. Stick to a limited number of points
Fairfield - EC - 150
CH. 4 Law's Order COASE THEOREMWhat's Wrong With The World IIA. INTRODUCTION1. Story of Ch.3: A.C. Pigou "We must internalize externalities." a. An externality is said to be internalized when the market participants are forced to recognize their interd
Penn State - MLS - 5195
Michelle Smyth Dr. London PL SC 14 March 6th, 2007 Was the Agreement as a Real Success? This land may be so far from our American soil yet it affects a great deal of our international policies and concerns each day. The North Korea we have known for many
Columbia - C - 1112
Phyllis Kao Differences Between Chinese and American Customs My parents do not belong to the `traditional Chinese parents' category. They have given my sister and I much freedom, never pressuring us to major in `that,' or apply to `this school,' or look f
Acton School of Business - BIOS - 334
page 1 of 6 Exam 1 2003. NAME_HONOR CODE_ 1. Make sure you have all 6 pages. Most questions require short answers, but note that the last question is a longer essay. After each question, the first number is the number of points The second number, if pres
Lake County - IB - 150
Theplan for thelast thre le e cture of s these e r: m ste- Monday Dec. 5 - The Red Queen Hypothesis: Microevolution in Pathogenic Microorganisms Wednesday Dec. 7 - Dr. Berlocher's research (Apples, Pests, and Evolution) Friday Dec. 9 - Careers in Integra
Lake County - EDUC - 362
Representing the Solution Process by GraphingName _1. Examine the solution to the following equation: 5(3 x) + 4 = 2x 9 15 5x + 4 = 2x 9 19 5x = 2x 9 19 + 9 = 2x + 5x 28 = 7x 4=x Think of each side of each equation as a separate equation to be graphed (
Lake County - CI - 301
COMMUNITY HOURS ACTIVITY CPS Bus Trip Tutoring (10/7) Tutoring (10/14) Tutoring (10/15) Tutoring (10/21) Tutoring (10/28) Tutoring (11/4) Tutoring (11/11) Tutoring (11/12) Tutoring (11/18) Franklin B-Ball Game(11/18) Tutoring (11/19)HRS 4 1 1 1 1 1 1 1 1
University of Hawaii - Hilo - MATH - 135
Math 135 - Fall 2008Final Examination Sample Questions1. The diagram represents the schematic for an open box. The box is made by cutting out squares of length x from the corners of a cardboard rectangle measuring 20 by 26 inches. Express the volume V o
Purdue - EE - 595
EE595S : Class Lecture NotesParameter Identification and Maximum Torque Per Amp Control AlgorithmFall 2005Outline GA based AQDM Characterization Procedure MTPA Control strategy AMTPA Control StrategyFall 2005EE595S Electric Drive Systems2Alternate
National Taiwan University - HCS - 612
Tiller Dynamics (Text Vol II pg 11-15) Vegetative vs reproductive pathways Seed survival . Some people manage . In NZ Chapman found . . . . . . .
Paul Quinn - ANTHRO - 102
Order PrimatesAnthro 102 Flowchart of Primate Relationships and Featuresretain clavicles grasping hands and feet nails and tactile pads stereoscopic vision reduced sense of smell increased brain size lost some teeth foramen magnum is under the skullSub
Northeastern University - COM - 1355
Attribute grammar for generating MacScheme machine assembly code from aquirk20 source program. [Version 0]For simplicity the attribute grammar is defined over abstract syntax treesthat have been type checked. This code generator ignores types.Syntacti
CSU LA - CS - 312
CS312 Course OutlineWeek 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Week 11 CS212 Review Algorithm Analysis / Recurrences Recurrences / Trees Search Trees Midterm Sorting Algorithms Sorting Algorithms Sorting Algorithms / Graph The
csubak.edu - MATH - 305
Gaussian Elimination with Scaled Partial Pivoting: L2 cache pagesize page table TLB size/place std/optional typeinst/data - ---Pentium IV256Kbytes/CPU4K/4M bytes direct128/64G4 PowerPC 1Mbytes4K bytesinverted128/128UltraSparc III
Southern Oregon - HR - 5110
Career Development:Organizational and Individual Approaches HR 5110Online FormatProfessor: James P. Pappas, Ph.D.Social and Societal ChangeUnit 1Work in retrospect and prospect emerging culture impacted division of labor Early hunting, gathering, c
CofC - MGMT - 408
BUILDING A NEW CIRCUIT CITYCIRCUIT CITY STORES, INC. ANNUAL REPORT 2004We are revitalizing the Circuit City shopping experience. Prime real estate for relocations and new stores offers high visibility and great convenience. Inside, you will find better
Lake County - ANSC - 438
Lactation Biology Lactation Crossword PuzzleAcross 5. exhibiting sympathy 7. toward the brain 9. rate of cycles 11. FIL 13. removes iodine 15. adrenaline 16. left-over milk 17. inhibits prolactin secretion 18. remove the thyroid 19. one fifth the oxytoci
University of Toronto - CSC - 209
I/O MultiplexingHaviland 7.1.61The problemc1 "gone for coffee" server read(c1) blocked read(c2) write c2 When reading from multiple sources, blocking on one of the sources could be bad. An example of denial of service. One solution: one process for e
Cornell - ECON - 620
Cornell University Department of Economics Econ 620 Instructor: Prof. KieferSolution to Problem set # 31) Recall that e = y - X = y - X (X X)-1X y = I - X (X X)-1X y = My= M (X + ) = M X + M = M Then, E (e) = E (M ) = M E () = 0 since M = I - X (X
University of Toronto - CSC - 363
CSC363Lecture Notes 22Spring 2005Metric TSP Recall that a function d : [n]2 R+ is called a metric if d(i, j) = d(j, i) d(i, j) d(i, k) + d(k, j) The problem METRIC-TSP-OPT is: Instance: A metric d : [n]2 R+ Solution: A permutation : [n] [n] Objective:
Duke - CPS - 006
Writing and Understanding C+There are language independent skills in programming (C+, Java, ) However, writing programs in any language requires understanding the syntax and semantics of the programming language Syntax is similar to rules of spelling and
National Taiwan University - PS - 597
Long Walk to Freedom and Democracy / 391A Long Walk to Freedom and Democracy: Human Rights, Globalization, and Social Injustice*HAVIDN RODRGUEZ, University of DelawareBefore I entered the polling station, an irreverent member of the press called out, M
Iowa State - MKT - 451
<html> <head> <linkrel="stylesheet"type="text/css" href="http:/www.bus.iastate.edu/Include/style/style.css"/> <metaname="GENERATOR"content="MicrosoftFrontPage12.0"> <metaname="ProgId"content="FrontPage.Editor.Document"> <title>IowaStateUniversityCollegeof
University of Rochester - PHYS - 344
Phys 344Mon. 3/12 C 10.7, S 6.0, 6.1 Boltzmann Statistics Wed. 3/14 C 10.8.9, S 6.2, A.4 Average Values, Rotation Fri. 3/ 16 C 10.8.0-10.8.7, S. B.1 Gaussian, 6.3-.5 Equipartion, MaxwellLect 15March 7th , 20071HW15: 2, 3, 4, 6, 12 HW16 S. 6.15, 16, 2
University of Hawaii - Hilo - GG - 101
Streams: Transport to the OceanP= RO + I + ETGary D. McMichael/Photo ResearecherHydrologic CycleTHE HYDROLOGIC CYCLEP = RO + I + ETP = PRECIPITATION RO = RUN OFF (ALL STREAMS) RUN I = INFILTRATION (GROUNDWATER) ET = EVAPO-TRANSPIRATIONStreams (P =
University of Toronto - ECE - 241
University of Toronto Faculty of Applied Science and Engineering Midterm ExaminationECE 241S - Digital Systems Examiner: Belinda Wang, Jianwen Zhu February 27th, 2002 Duration: 90 minutesANSWER QUESTIONS ON THESE SHEETS, USING THE BACKS IF NECESSARY. 1.
Lake County - CI - 430
A Tribe ApartPatricia Hersch C&I 430 Book Report06/01/09Lucas Allen and Michael Sacks1IntroductionPatricia Hersch"America's own adolescents have become strangers. They are a tribe apart, remote, mysterious, vaguely threatening. Somewhere in the tra
Michigan - CHEM - 461
CHAPTER 4PRINCIPLES OF QUANTUM MECHANICSIn this Chapter we will continue to develop the mathematical formalism of quantum mechanics, using heuristic arguments as necessary. This will lead to a system of postulates which will be the basis of our subseque
Lake County - IB - 109
Pest control March 31, 2008, Pages 284-295 1.True or false: Chemical control of insects began in the nineteenth century. Egyptian Book of the Dead was an early source of info about pest control. 2. A massive compilation of agricultural writings from 200 B
Cornell - MATH - 293
Math 293 Solutions to Problem Set 4. 14.2 #10. We need to compute C xy dx + yz dy + xz dz for each of the curves C. In part (a) the curve has x = y = z = t for 0 t 1, so dx = dy = dz = dt, and plugging 1 1 these values into the integral gives 0 3t2 dt = t
University of Alaska Fairbanks - WLF - 625
THE MULTINOMIAL DISTRIBUTIONDiscrete distribution - The Outcomes Are Discrete. distribution from only 2 outcomes to k outcomes. Typical Multinomial Outcomes: red white blue A B C D F area1 area2 area3 area4 area5 year1 year2 year3 year4 never A generaliz
Acton School of Business - PHYS - 532
PHYS 532 One Problem:HOMEWORK 2DUE 2/5/07Working alone in your laboratory late at night, you discover incontrovertible proof that the Coulomb's law Maxwell equation is wrong. The correct expression, you determine, is% ! " E + # $E = & $t ' -24 where 1
Los Angeles Southwest College - STAT - 205
Binomial Distribution Let's refresh our memory on computing probability with an example. Consider the experiment where we toss a fair coin 3 times. Find the probability distribution for flipping "heads" in this experiment. Now, think about finding probab
University of Toronto - ECE - 1770
Push TechnologyHumie Leung 981777020 University of Toronto firstname.lastname@example.org Liangjie, Huo University of Toronto Liangjie.email@example.com multipoint data exchange in an optimized fashion. By multicasting, data traverses the network exactly once to get to
Rutgers - BIOCHEM - 581
How do proteins fold? Folding in a test-tube Thestructureofproteinsisdeterminedbytheaminoacidsequence; manyproteinsinsolutioncanbeunfoldedbyheatandother denaturantssuchashighconcentrationsofureaandguanidinium chloride,buttheywillspontaneouslyrefoldonretur
Montana - MB - 105
Chapter 4Proteins and ProductsSearch for new and novel proteins Going to extremes. Tropical rain forests Yellowstone hot springs and soils Branches and pine needles in hot springs are a potential source of thermophilic lignin-degrading microbes and t
SUNY College of Environmental Science and Forestry - FCH - 495
EmploymEnTEmploymEnt & Salary SurvEyUptick in the job market for chemists in 2006 and a routine salary boost for those with jobsmich a El hE y l in , C &E N Wa s hiNgtoNThe latest version of the amer- index for urban consumers rose by 3.4% ican Chemi
University of Rochester - PHYS - 232
Q1 A1Electric Field of a Uniformly Charged Spherical Shellr r1r E2r r2 Q2 r E1 Ao2Inside E1=1 4 oQ1 r12whereQ1 A1 A1 = Q1 = Q Q A As1r r1o 1 sowhereA1 = (s1 2 )where2s = r11 (r11 2 )2 Q A = r12 Q (1 ) 4A2E1 =1 4 o1 4 oQ1 A1Elec
CSU LA - MKT - 342
Cultural Influences on Consumer BehaviorChapter 16Understanding Culture Culture = societys personality The accumulation of shared meanings, rituals, norms, and traditions among members Discussion: If your culture were a person, how would you describe
Evansville - B - 43402
Chapter 10 - Phylum CiliophoraTaxonomyPhylum CiliophoraClass Litostomatea Order Vestibuliferida Genus Balantidium Class Oligohymenophorea Order Hymenostomatida Genus IchthyophthiriusPhylum Ciliophora Possess cilia simple cilia or compound ciliary org
George Mason - MASON - 601
EDIT 705 FALL SEMESTER 2006 Emad GodaDesign Idea: iscreating an Instructional design that teaches a group of youth how to develop and update an existing web-site.Problem Identification: Thereis a group of youth in the church who has been trained to de
North-West Uni. - V - 101
Copyright 2007 by Northwestern University School of Law Northwestern University Law ReviewPrinted in U.S.A. Vol. 101, No. 1A PRAGMATIC DEFENSE OF ORIGINALISMJohn O. McGinnis* & Michael B. Rappaport*INTRODUCTION Originalism and pragmatism are uneasy co
Rose-Hulman - CHEM - 490
J. Agric. Food Chem. 2002, 50, 6575-65786575Oxidative Degradation of Bisphenol A by Crude Enzyme Prepared from PotatoYING JI XUAN, YASUSHI ENDO,*ANDKENSHIRO FUJIMOTOGraduate School of Agricultural Science, Tohoku University, 1-1 Tsutsumidori-Amamiya
CSU Long Beach - SOC - 455
Soc.355 / M arlowe Group Mem bers: Lab Exercise #03 Cleaning Data / Using Descriptive and Inferential Statistical TechniquesUsing the data from the questionnaire data I provided on your data disk (Master-survey2.sav): (1) perform the statistical techniqu
Winthrop - ECON - 315
Answers to Questions for Review1. The five factors include: exclusive control over inputs, government licensing, patents, economies of scale and the networked economy. Economies of scale derive from technological conditions rather than institutional arra
CSU Northridge - CCS - 53520
AP Chapter Four Outline Part Two I. The Mole and Chemical Reactions In a balanced chemical equation, the coefficients on each species can be interpreted as the numbers of moles of each compound. These coefficients also provide the mole ration that relates
University of North Carolina, Wilmington - CHM - 211
Answers to questions for Chapter 111. The reaction will more likely happen via SN 1 because water is a poor nucleophile and the halide is secondary. (a) Mechanism for both possibilities:SN 1 + H H O Br heat H + O H + Br - H O H OH + H3O+SN 2 BrH O H +
Pima CC - MARK - 221
Technology and OperationsPrentice Hall, 2001Chapter 141Learning Outcomes Learn how to calculate productivity Learn how technology affects productivity Explain how managers use information technology for decision support Describe the advantages of com
Wyoming - RS - 4111
HistoryofRemoteSensingThankstoJimCampbellformanyofthese slides!Photo from Flickr by Steve Reno (hawks914)Value of historical perspective Place events in proper context; Understand connections between events; Understand origins of the science Recognize