is the protection of the second-to-last information contained in the AS PATH attributes by digital. signatures, and the use of techniques developed for detecting ...
Securing the Border Gateway Routing Protocol Bradley R. Smith and J.J. Garcia-Luna-Aceves May 20, 1996 Abstract We analyze the security of the BGP routing protocol, and identify a number of vulnerabilities in its design and the corresponding threats. We then present a set of proposed modi cations to the protocol which minimize or eliminate the most signi cant threats. The innovation we introduce is the protection of the second-to-last information contained in the AS PATH attributes by digital signatures, and the use of techniques developed for detecting loops in path nding protocols to verify the selected route's path information. With these techniques we are able to secure full path information in near constant space, and avoid the recursive protection mechanisms previously assumed necessary. This allows us to relax the assumption of trust in remote BGP speakers.
1 Introduction Inter-domain routing protocols are designed to perform policy based routing in an internet of autonomous systems. In its basic sense, policy routing is any routing that is in uenced by factors other than nding the shortest path [5]. Inter-domain protocols route among autonomous systems. An autonomous system (AS) is de ned as a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using exterior gateway protocols to route packets to other ASs. In practice, this de nition is relaxed to allow multiple intra-domain protocols and several sets of metrics, the focus being on a single technical administration. 1
Two inter-domain, path-vector routing protocols currently de ned are the Border Gateway Protocol (BGP) [18] and the Inter-Domain Routing Protocol (IDRP) [19, 6]; these two protocols are of particular interest because of their current roles as the inter-domain protocols maintaining the global Internet routing infrastructure. Routing protocols dynamically con gure the packet forwarding function in internets which allows for the continued delivery of packets in spite of changes in network topology and usage patterns. These changes typically occur due to the ongoing introduction, failure, and repair of network links and routing nodes, which the protocols have been designed to accommodate. The compromise of the routing function in the global Internet can lead to the denial of network service, the disclosure or modi cation of sensitive routing information (e.g. routing policies), or, via the recon guration of the logical routing structure in the Internet, the diversion of network trac possibly leading to the disclosure of network trac to an attacker or the inaccurate accounting of resource usage. Current routing protocols contain few, if any mechanisms to provide for the security of their operation. Those that exist are incompletely de ned or unimplemented. Given the evolution of the global Internet to a commercial, production network infrastructure this state of a airs is clearly unacceptable. The proposed Internet Security Architecture (ISA) [21] provides an architecture for the inclusion of security facilities in the design of protocols to be used in the Internet. Fundamental to the ISA are four concepts: vulnerabilities, threats, security services, and countermeasures. A vulnerability is a weakness in a system's security that may be exploited by an intruder. A threat is a potential violation of security, and requires an intruder who has the capability to exploit an existing vulnerability. Threats can be classi ed into four general categories. Disclosure is an event in which an entity gains access to data that the entity is not authorized to receive. Deception is an event that results in an authorized entity receiving false data and believing it to be true. Disruption is an event that interrupts or prevents the correct operation of system services or functions. And, usurpation is an event that results in control of system services or functions by an unauthorized entity. Vulnerabilities and threats are minimized or eliminated through the provision of six security 2
services [16]. Con dentiality is the protection of data so it is not made available or disclosed to unauthorized individuals, entities, or processes. Integrity is the protection of data so it is not altered or destroyed in an unauthorized manner. Authenticity is the veri cation of the identity claimed by a system entity. Access Control is the protection against unauthorized use of system resources. NonRepudiation is the protection against false repudiation of a communication. Availability is the assurance that resources are accessible and usable upon demand by an authorized entity. A countermeasure is a mechanism or feature that provides a security service. Examples of countermeasures include encryption of network trac to provide con dentiality, and the use of challengeresponse technology for providing authentication of user logins. The cryptographic tools we will use to implement countermeasures to routing protocol vulnerabilities are primarily encryption and digital signatures. Given these cryptographic tools and the concepts from the ISA, this paper presents a strategy for securing BGP using the following methodology: 1. Analyzing the protocol design to identify vulnerabilities and threats. 2. Identifying the security services needed to reduce or eliminate the vulnerability. 3. Designing the appropriate countermeasures to provide the needed services. During this design process, we assume that intruders can position themselves at a point in the network through which all trac of interest to them ows, and that they have the capability to fabricate, monitor, modify, or delete any of this information. Section 2 states our assumptions, and goals for securing BGP. Section 3 analyzes the security of BGP, and identify its vulnerabilities, and the threats it is susceptible to. Section 4 presents our proposed strategies and countermeasures for securing BGP. Section 5 reviews related work.
2 Goals for BGP Security There are four basic components in a BGP system: speakers, peers, links, and border routers. 3
A BGP speaker is a host in the network that executes the BGP protocol. BGP peers are two BGP speakers that form a connection and engage in a BGP dialog. A BGP peer is either an internal or external peer, depending on whether it is in the same or a di erent AS as the reference BGP speaker. The connections between BGP peers are called links, with internal and external links being de ned similarly to internal and external peers. BGP links are formed using a reliable transport protocol such as TCP. This eliminates the need to implement transport services such as retransmissions, acknowledgments, and sequence numbers in the routing protocol. A border router is a router with an interface to a physical network shared with border routers in other autonomous systems. Similar to BGP speakers, border routers are either internal or external. Note that BGP speakers need not be border routers (or even routers of any kind). It is possible that a non-routing host could serve as the BGP speaker, gathering routing information from internal or other external routing protocols, and advertising that information to internal and neighboring external border routers. This feature is currently in use in the Route Servers of the Routing Arbiter project [2]. In designing security mechanisms for BGP we make a number of assumptions:
The BGP version 4 protocol as de ned in [18]. Of particular note is the use of the TCP transport protocol speci ed in this standard.
A BGP speaker can trust its internal peers.
The only external BGP speakers a given speaker can trust are its external peers, and only for information generated by that speaker.
All links can be compromised by an intruder with the ability to fabricate, monitor, modify, or delete trac on the compromised link.
Perlman has de ned network failures as either simple or Byzantine; and four classes of network robustness [17]. A simple failure occurs when a node or a link in a network becomes inoperative, and 4
ceases to function at all. A Byzantine failure, de ned in terms of the \Byzantine Generals Problem" [13], occurs when nodes or links continue to operate, but incorrectly. A node with a Byzantine failure may corrupt, delay, or forge messages, or may send con icting messages to di erent nodes. Possible causes of Byzantine failures include mis-con gured nodes, software bugs, unusual hardware failure modes, and hostile attacks. Simple Robustness is the resistance to malfunctions caused by simple failures. In the context of network routing protocols it is robustness in the context of changes in network topology and usage patterns that result from the introduction, failure, and repair of network links and routers. Self Stabilization is the guarantee of convergence to correct operation even with a history of Byzantine failures. Byzantine Detection is the level of robustness where, while correct behavior may not be maintained in the presence of Byzantine failures, the failed node can easily be identi ed. Byzantine Robustness is the ability to continue correct operation in the presence of arbitrary nodes with Byzantine failures. Modern routing protocols are designed to provide simple robustness with some degree of self stabilization. In the context of the stated assumptions and de nitions , our goals for securing BGP are to provide: Byzantine robustness to faults in non-routing nodes in an internet, Byzantine Robustness to faults in routing nodes that a ect information concerning resources not a part of their direct environment, and simple robustness with self stabilization of all other faults in routing nodes.
3 BGP Threats and Vulnerabilities We now identify the threats to which BGP is susceptible, and the vulnerabilities these threats exploit. We consider separately threats to the ow of routing trac and threats to the ow of data trac that involve portions of the routing infrastructure. We describe attacks in terms of di erent classes of internet nodes, including: authorized BGP speakers, authorized BGP routers, and intruders. Authorized BGP speakers are those nodes intended 5
by the authoritative network administrator to perform as a BGP speaker. Authorized BGP routers are authorized BGP speakers that also are intended by the authoritative network administrator to participate in the packet forwarding function.
3.1 Intruders As described earlier, we assume an intruder can position themself at any point in the network through which all trac of interest ows, and that the intruder has the capability to fabricate, monitor, modify, or delete any of this trac. Interpreting this description for a BGP environment, we identify the following three general classes of intruders: subverted BGP speakers, unauthorized BGP speakers, and subverted links. A subverted BGP speaker occurs when an authorized BGP speaker is caused to violate the BGP protocols, or to inappropriately claim authority for network resources. This typically occurs by causing a BGP speaker to load unauthorized software or con guration information, which can be achieved by many means depending on the design and con guration of the BGP speaker. An unauthorized BGP speaker occurs when a node on an internet that is not authorized as a BGP speaker manages to circumvent any access control mechanisms in place, and establish a BGP link with an authorized BGP speaker. Again, how this is achieved depends on the design and con guration of existing access control mechanisms. There are a number of forms that a subverted link can take. One is to gain access to the physical medium (e.g. coper or ber optic cable-plant, the \air-waves", or the electronics used to access them) in a manner that allows some control of the channel. In addition, a link may be subverted by compromising the network layer protocol in use on the link in a manner that allows control of the channel. Examples of such attacks include the IP spoo ng [14] and TCP session hijacking [7] attacks. Again, we assume control including the ability to fabricate, monitor, modify, or delete in the design of security measures. 6
3.2 Deception or Disruption of the Routing Messages There are a number of vulnerabilities that allow a strategically placed intruder to fabricate, modify, replay, or delete routing information. With these capabilities an intruder can compromise the network in a number of ways. The modi cation or fabrication of routing updates allows an intruder to recon gure the logical routing structure of an internet, potentially resulting in the denial of network service, the disclosure of network trac, and the inaccurate accounting of network resource usage. Speci c attacks include:
An intruder can initiate a BGP connection with an authorized BGP speaker. The result of successfully establishing a BGP peer connection by an intruder is the full participation of that intruder in the routing computation.
Any intruder, using the IP spoo ng attack [14], can fabricate a half-duplex BGP session masquerading as an authorized BGP speaker. Given the half-duplex nature of this attack it is not clear that it poses a serious threat.
An intruder located on a subnet through which BGP links pass can arbitrarily delete BGP trac. Due to the use of a reliable transport protocol connection, the e ect of this attack will be a denial of service due to the connection being interrupted or disconnected.
An intruder located on a subnet through which BGP links pass can, using a TCP session hijacking attack [7], arbitrarily fabricate, modify, delete, or replay routing information while masquerading as an authorized BGP speaker.
Any authorized BGP speaker can arbitrarily fabricate, modify, delete, or replay routing information while masquerading as another authorized BGP speaker.
The vulnerabilities these attacks exploit is the lack of access control, authentication, and integrity of BGP message contents. 7
3.3 Disclosure of Routing Messages It is relatively easy for an intruder to gain access to routing trac. The information available from this trac includes the appropriate next hop to reach a destination, and the path taken by trac to di erent destinations. The next hop information is available from other sources, such as monitoring authorized trac to the desired destination for the next hop it uses, and therefore cannot be protected solely by measures directed at the routing trac. However, in some circumstances, the path used to reach di erent destinations may be considered con dential. Speci c attacks to obtain this path information include:
An intruder located on subnets through which BGP links pass can snoop all routing exchanges on that link, and determine full path information for any reachable destination.
An authorized BGP speaker can disclose routing information to any node.
The vulnerabilities these attacks exploit are the lack of con dentiality of peer links, and the level of trust placed in BGP speakers.
3.4 Disclosure of Data Packets It is relatively easy for an intruder to snoop or disclose data trac. The vulnerability exploited here is the lack of end-to-end or link encryption services for data trac. Being beyond the scope of our intended modi cations to BGP we will not address these possible countermeasures further.
3.5 Deception or Disruption of Data Packets It is relatively easy for an intruder to fabricate, modify, replay, or delete data packets. The e ectiveness of these attacks at deceiving or disrupting the source and destination processes depends on the endto-end protocols in use at the transport layer and above, and is not a routing protocol issue. 8
However, the e ectiveness of these attacks at deceiving the intermediate routing nodes is not an end-to-end protocol issue. Countermeasures to these vulnerabilities will depend on mechanisms in the network or lower layers of the protocol hierarchy. The appropriateness and e ectiveness of end-toend vs. link layer security measures is a fundamental issue in the design of the Internet protocols [20, 10, 22]. While in general these issues do not involve routing protocol mechanisms, two exceptions include the ability to use multiple paths to a single destination, and the inclusion of authentication and access control mechanisms in the packet forwarding function (e.g. [3]). We will not address these measures further in this paper.
4 BGP Security Countermeasures The general outline of our proposed countermeasures is as follows:
Encrypt all BGP messages between peers using session keys exchanged at BGP link establishment time. This encryption provides integrity and authenticity of all path attributes whose values are valid for at most one AS hop, and con dentiality of all routing exchanges.
Include peer-to-peer and attribute
Digitally sign the destination's predecessor information in the AS PATH attribute to allow the veri cation of the path information in a manner similar to that used in path nding routing algorithms to detect loops [15].
Digitally sign all UPDATE message elds and path attributes whose values are generated by a single AS, and are valid for more than one AS hop. These digital signatures provide integrity and authenticity of all single-source, multi-hop path attributes.
UPDATE
message sequence numbers to ensure the freshness of each
In the following sections we will present a more detailed functional speci cation of these countermeasures, and an analysis of the e ectiveness of these countermeasures against the threats and 9
vulnerabilities identi ed above.
4.1 Functional Overview of Countermeasures A number of the following countermeasures are, e ectively, implementing secure transport services not available from current transport protocols. Speci cally, the peer-to-peer encryption, peer-topeer sequence number, and link termination on detection of invalid peer-to-peer data are providing corruption detection, sequencing, acknowledgment, and retransmission mechanisms that are redundant to those provided by TCP. They are required, however, due to the insecurity of the TCP mechanisms [9, 1]. These BGP countermeasures would no longer be required if a secure transport protocol [8] were available and used.
4.1.1 Peer-to-Peer Encryption Upon establishment of each BGP link, a session key is exchanged by the peers for use in encrypting each BGP message transmitted over that link. One purpose of this encryption is to provide con dentiality of the messages. The other purpose is to provide authenticity and integrity of the KEEPALIVE and NOTIFICATION messages, and of some of the path attributes carried in UPDATE messages. A number of path attributes carried in UPDATE messages are modi ed in each AS they transit. These include the NEXT HOP, MULTI EXIT DISC, and LOCAL PREF attributes. The use of peer-to-peer encryption for authenticity and integrity of these path attributes is based on two points: (a) the recipient of these path attributes receives them from either the most recent modi er or via a single relay that is an internal peer, and (b) our assumption that internal peers are trusted. Given these, peer-to-peer encryption provides a high degree of security in an ecient manner. On detection of corrupted information the link is terminated using a NOTIFICATION message.
10
4.1.2 Sequence Numbers Two sequence numbers are included to prevent message replay and to ensure the freshness of each message: a peer-to-peer BGP message sequence number, and a per-AS UPDATE message sequence number. The peer-to-peer message sequence number is initialized to zero on establishment of a BGP link, and is incremented with each message. On detection of a skipped or repeated sequence number, the BGP link is terminated with a NOTIFICATION message, and re-established. The size of the sequence number is made large enough to virtually eliminate the chance of it cycling back to zero. However, in the event that it does, the link is terminated and a new link is established, resetting the sequence number to zero. The UPDATE message sequence number is initialized to zero on the initial con guration of a BGP speaker, and is incremented with each UPDATE message. Due to changes in the network architecture or routing policies, gaps may be introduced in the values seen by a given receiving speaker. Therefore, only repeated or decreasing sequence numbers are de ned as invalid; messages with invalid sequence numbers are dropped. UPDATE message sequence numbers are maintained on a per BGP speaker basis. To allow the identi cation of a BGP speaker within an AS we introduce a BGP speaker index number that is unique in an AS. As above, the size of the UPDATE sequence number is made large enough to virtually eliminate the chance of it cycling back to zero. However, in the event that it does, the old BGP speaker index number is retired, a new one con gured, and the UPDATE sequence number is reset to zero.
4.1.3 Secure AS PATH Attribute with Predecessor Information To ensure the authenticity of the AS PATH attribute we augment it with a digital signature of the destination's predecessor. By having the destination router authenticate the second-to-last hop in the AS PATH reported for each destination, the authenticity and integrity of the complete path reported by a router to any destination can be established by the router's neighbors in a manner similar to that used to detect loops in path nding routing protocols. Speci cally, this can be done by means of a 11
path traversal of the veri ed predecessor information reported by the route. To accommodate this new information we de ne a new AS PATH segment type called an AS PREDECESSOR. This segment type includes the following information: the destination (origin) AS number; the UPDATE message sequence number and speaker index described in Section 4.1.2; one of the following predecessor segment types: ADD, PRED DELETE, DEST DELETE, or TRANSIT; the DELETE segment types include the predecessor AS number; and a digital signature of the following information: destination AS number, sequence number, speaker index, segment type code, and the predecessor AS number.
Predecessor Segment Types The ADD version of the AS PREDECESSOR segment is generated by the speaker that creates the rst version of an UPDATE message. This may either be the rst AS in an un-aggregated UPDATE, or the last speaker to perform an aggregation of the routing information in the current UPDATE. This segment type always must precede an AS SEQUENCE segment. This segment type serves two purposes. First, it provides authenticated predecessor information for use by other ASs in verifying AS PATH attributes. Second, it establishes the sequence number to be used in the digital signatures for other path attributes to be de ned below. This second function is important in that it binds together the information in an UPDATE message to establish freshness of the message as a unit. The DELETE versions of the AS PREDECESSOR segment serve the purpose of identifying a previously reported predecessor relationship that is no longer valid. Possible reasons for this change include the failure of an inter-AS link at the connectivity level, or termination of a transit trac agreement at the policy level. These segment types may occur anywhere in the AS PATH attribute, and have no implications for the AS ordering de ned by the attribute. These segment types may be generated by either end of the deleted link; thus a PRED DELETE is generated by the predecessor AS end of a link, and a DEST DELETE by the destination AS end of a link.
12
Transit-Only Predecessor Information Due to the policy-based selection and propagation of routes in BGP, it is possible that a node could be used on a path to a destination by a speaker while it is not reachable as a destination itself. To ensure propagation of predecessor information for such transit-only ASs to all potential source ASs of transit trac, we use the nal AS PREDECESSOR segment type of TRANSIT. A TRANSIT predecessor segment is used to identify transit-only predecessor information required by the current AS PATH that has previously not been transmitted to the current AS. This predecessor is to be added to the predecessor table, but does not de ne a sequence number to be used by other UPDATE signatures. To detect when such transit-only predecessor information should be added to an UPDATE message, each speaker must track what predecessor attributes have been forwarded to each neighbor. When a route is selected for propagation to a neighbor, any predecessor information implied by the AS PATH for that route not already transmitted to the neighbor must be included in the UPDATE. How to handle any lack of predecessor information by either the sender or receiver of an UPDATE is a policy decision. Transit-only predecessor information is removed using the DELETE predecessor segment types.
Predecessor Table This predecessor information is used by each node to, conceptually, maintain a predecessor table similar to the routing table use in path nding algorithms. Speci cally, the predecessor table is a column vector of predecessor sets for each destination known by a speaker. It is updated as each AS PREDECESSOR segment is processed. The information maintained in the predecessor table is used to verify an AS PATH attribute. Before a speaker selects a route for use, that route's AS PATH attribute should be veri ed by a walk through the predecessor table. The precise timing of this veri cation is not speci ed, being in uenced by the expected frequency of invalid AS PATH attributes, expected load, and the performance requirements of the speaker. Options for when to perform this veri cation include on receipt of the AS PATH, or on selection of the route for use.
13
4.1.4 Digitally Sign Single-Source, Multi-Hop Path Attributes The remaining path attributes are single-source, multi-hop path attributes. The value of these attributes is generated by one AS, and they are transmitted across multiple AS hops to many ASs. Without protection, trust of the values of these attributes requires trust of the BGP speakers in each possible transit AS. Something we explicitly do not do. To ensure the authenticity and integrity of these attributes we introduce a number of new path attributes containing digital signatures of these attributes. To limit the number of signatures needing computation and veri cation we de ne these new signature attributes in terms of related clusters of path attributes. Speci cally, we de ne two signature attributes as follows:
WR SIG: digital signature of the sequence number, origin AS number, and Withdrawn Route information.
NLRI SIG: digital signature of the sequence number, origin AS number, AGGREGATOR, ATOMIC AGGREGATE, and ORIGIN attribute
information, and the NLRI.
The sequence number used in these signatures is the sequence number established by the single AS PREDECESSOR/ADD attribute carried in the AS PATH attribute. The origin AS number is that of the speaker that last modi ed the Withdrawn Routes or NLRI information. The rest of the information (Withdrawn Routes, NLRI, AGGREGATOR attribute, and ATOMIC AGGREGATE attribute) are as de ned in BGP.
4.2 Countermeasure E ectiveness Referring back to Section 3, we now analyze the impact of each countermeasure on the identi ed threats.
Deception of Routing Messages: Digital signatures protect against the fabrication and modi cation of AS PATH, AGGREGATOR, ATOMIC AGGREGATE, ORIGIN, Withdrawn Routes, and NLRI 14
information in the UPDATE message by subverted speakers. Peer-to-peer encryption protects against the fabrication or modi cation of BGP messages by subverted links.
Disruption of Routing Messages: The peer-to-peer sequence numbers protect against the replay or deletion of BGP messages by subverted links. The UPDATE message sequence number protects against the replay of the UPDATE message information listed above by subverted speakers.
Disclosure of Routing Messages: The encryption of BGP messages protects against the disclosure of routing messages by subverted links.
Threats and Vulnerabilities not Addressed: The deletion of UPDATE messages by authorized BGP speakers. The disclosure of routing messages by authorized BGP speakers. Provision of access control to protect against masquerading BGP speakers is still dependent on implementation.
4.3 Performance Analysis The cost of these countermeasures is in the space for the new sequence numbers and digital signatures, and the time for computing encryption and digital signatures, and verifying these protections. In speci c, from the perspective of the actions occuring in a BGP system, the costs are as follows:
Message generation and reception: Space: None. The Marker eld is used for the sequence number. Time: The cost of a symmetric key encryption and decryption of each message. Initiation and reception of new or aggregated UPDATE messages: Space: Each AS PATH attribute will contain one ADD segment, zero or more DELETE segments, and zero or more TRANSIT segments. Each UPDATE message will optionally contain one WR SIG and one NLRI SIG path attribute. Time: The time to perform the computation and veri cation of the above signatures.
Route Selection: Time: The time to verify signatures for each link. This cost will only be incurred twice for each used link: once for the ADD and once for the DELETE. 15
5 Related Work In [4] Finn analyzes the security of routing protocols, and identi es a number of vulnerabilities that, if exploited, could result in widespread failure of an internet. He then proposes a number of actions or countermeasures to improve the ability of routing protocols to resist attacks. He de nes a taxonomy of attacks similar to our failure modes where a direct attack is similar to our simple failure, and an indirect attack is similar to our Byzantine failure. He de nes attack resistance as the \attribute of a routing protocol where the results of an attack at a single point do not adversely a ect net operations over a wide region or for an extended period of time." Based on these, he asserts that the primary requirement of an attack resistant network is that any single indirect attack is detectable if its longterm result more adversely a ects network operations than any single direct attack. He concludes with a number of recommendations to improve the attack resistance of routing protocols, including: use of link encryption, support for multiple paths to a destination, enforcement of limits on use of high-priority trac (e.g. multicast), and the use of routing protocols that strongly limit the in uence a router can have on routes chosen by other routers. In broad strokes, the results of Finn's analysis are similar to ours, although the recommended countermeasures di er due to a di erent focus. In [11] Kumar analyzes the security requirements of network routing protocols, and discusses the general measures needed to secure the distance-vector and link-state routing protocol classes. He identi es two sources of attacks: subverted routers, and subverted links. Since attacks by subverted routers are seen as dicult to detect, and of limited value to the intruder, he focuses his attention on securing protocols from attacks by subverted links. For distance-vector protocols this translates to the modi cation or replay of routing updates. The speci c countermeasures he proposes are neighborto-neighbor digital signature of routing updates, the addition of sequence numbers and timestamps to the updates, and the addition of acknowledgments and retransmissions of routing updates. In [12] Kumar and Crowcroft perform a similar analysis of inter-domain protocols, and come to similar conclusions as the previous paper for providing security of distance-vector related routing protocols (they speci cally address the path-vector routing protocol IDRP). The one addition they make is to 16
encrypt neighbor-to-neighbor updates. These results are similar to ours with the exception that we explicitly assume the existence of subverted routers, and provide countermeasures to protect against them. We feel this is important as BGP speakers are potentially vulnerable to attacks from a number of sources, with potentially catastrophic results from success.
6 Concluding Remarks In this paper we analyze the security weaknesses of the BGP protocol. We identify a number of threats involving the deception, disruption, and disclosure of routing message trac. In addition we identify a number of threats involving the disclosure data trac and the usurpation of the data packet forwarding function. We proposed countermeasures to the threats of deception and disruption of the routing message trac. We explained our recommendation to wait on standards e orts for a solution to the threat of disclosure of routing message trac. And we explained why the threats relating to data trac are not addressable in full and give suggestions of possible partial solutions. The primary additional requirement that these proposed countermeasures to secure BGP make on infrastructure services is for a key distribution mechanism. Our hope is to leverage the secure DNS e orts currently underway. Our work continues to address the following issues: provide a rigorous analysis of the space and time costs of the proposed countermeasures; provide a speci c design of the sequence number mechanism, addressing how to re-acquire sequence numbers on loss of state by either source or destination speakers, and how to handle sequence number wrap-around; develop a migration strategy that would allow portions of an internet to run an unsecured version of BGP; provide a design for a key distribution mechanism, utilizing the results of e orts currently underway to design such a mechanism.
17
References [1] Whit eld Die. Security for the DoD Transmission Control Protocol. In Proceedings: Advances in Cryptology. CRYPTO '85, pages 108{127. Springer-Verlag, 1985. [2] Deborah Estrin, Jon Postel, and Yakov Rekhter. ftp://ftp.isi.edu/pub/hpcc-papers/ra/ra-arch.ps, June 1994.
Routing Arbiter Architecture.
[3] Deborah Estrin, Martha Steenstrup, and Gene Tsudik. A Protocol for Route Establishment and Packet Forwarding Across Multidomain Internets. IEEE Transactions on Networking, 1(1):56{70, February 1993. [4] Gregory G. Finn. Reducing the Vulnerability of Dynamic Computer Networks. Technical Report ISI/RR-88-201, Information Sciences Institute, 4676 Admiralty Way, Marina del Rey, CA 902926695, June 1988. [5] Christian Huitema. Routing in the Internet. Prentice Hall, 1995. [6] International Standards Organization. ISO/IEC 10747: Information technology - Telecommunications and information exchange between system - Protocol for exchange of inter-donain routeing information among intermediate systems to support forwarding of ISO 8473 PDUs, August 1994. [7] Laurent Joncheray. A Simple Active Attack Against TCP. In Proceedings, 5th UNIX Security Symposium, pages 7{19. The USENIX Association, June 1995. [8] Laurent Joncheray. Public Key Encryption Support for TCP. Internet Draft: draft-joncherayencryption-00.txt, May 1995. [9] Stephen Kent. Some Thoughts on TCP and Communication Security. MIT Laboratory for Computer Science, Local Network Note No. 6, April 1977.
18
[10] Stephen Kent. Comments on \Security Problems in the TCP/IP Protocol Suite". Computer Communications Review, 19(3):10{19, July 1989. [11] Brijesh Kumar. Integration of Security in Network Routing Protocols. ACM SIGSAC Review, 11(2):18{25, Spring 1993. [12] Brijesh Kumar and Jon Crowcroft. Integrating Security in Inter-Domain Routing Protocols. Computer Communications Review, pages 36{51, 1993. [13] L. Lamport, R. Shostak, and M. Pease. The Byzantine Generals Problem. IEEE Transactions on Programming Languages and Application Systems, 4(3):382{401, July 1982. [14] Robert T. Morris. A Weakness in the 4.2BSD Unix TCP/IP Software. Technical Report 117, AT&T Bell Laboratories, Murray Hill, New Jersey 07974, February 1985. ftp://netlib.att.com/netlib/att/cs/cstr/117.ps.Z. [15] Shree Murthy and J.J. Garcia-Luna-Aceves. An Ecient Routing Protocol for Wireless Networks. ACM NOMAD Journal, 1996. Special issue on Routing in Mobile Communication Networks. http://www.cse.ucsc.edu/research/ccrg/publications.html. [16] Dan Nessett. The Internet Security Architecture. In Proceedings: Internet Security Workshop. IEEE, November 1994. [17] R. Perlman. Network Layer Protocols with Byzantine Robustness. Report MIT/LCS/TR 429, Massachusetts Institute of Technology, October 1988. [18] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). RFC 1771, March 1995. [19] Yakov Rekhter. Inter-domain Routing Protocol (IDRP). Internetworking: Research and Experience, 4:61{80, 1993. [20] J. H. Saltzer, D. P. Reed, and D. D. Clark. End-to-End Arguments in System Design. ACM Transactions on Computer Systems, 2(4):277{288, November 1984. 19
[21] Robert W. Shirey. Security Architecture for Internet Protocols. A Guide for Protocol Designs and Standards. Internet Draft: draft-irtf-psrg-secarch-sect1-00.txt, November 1994. [22] Victor L. Voydock and Stephen T. Kent. Security Mechanisms in High Level Network Protocols. Computing Surveys, 15(2):135{171, June 1983.
20
