Network Working Group Sandra Murphy INTERNET DRAFT Trusted Information Systems draft-murphy-bgp-secr-00.txt December 1997 BGP Security Analysis Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet Draft, please check the 1id-abstracts.txt listing contained in one of the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), venera.isi.edu (US West Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). Abstract BGP, along with a host of other infrastructure protocols designed before the Internet environment became perilous, is designed with little consideration for protection of the data it communicates or of its own behavior. There are no mechanisms in BGP to protect against attacks that modify, delete, forge, or replay data, any of which has the potential to be destructive of overall network routing behavior. This internet draft discusses some of the security issues with BGP routing data dissemination, and possible security solutions and the costs of those solutions. This internet draft does not discuss security issues with forwarding of packets. 1. Introduction The two most common inter-domain routing protocols, BGP and IDRP, were created when the Internet environment had not yet reached the present contentious state. Consequently, neither protocol was designed with Murphy Expires: Jun 1998 [Page 1] INTERNET DRAFT BGP Security Analysis December 1997 protection against deliberate or accidental errors causing disruptions of routing behavior. We here discuss the vulnerabilities of BGP, based on the BGP RFC [1]. Vulnerabilities in IDRP should be similar. We propose several different security solutions to protect these vulnerabilities, discuss the benefits derived from each solution and its cost. It is clear that the Internet is vulnerable to attack through its routing protocols. BGP is no exception. Faulty, misconfigured or deliberately malicious sources can disrupt overall Internet behavior by injecting bogus routing information into the BGP distributed routing database (by modifying, forging, or replaying BGP packets). The same methods can also be used to disrupt local and overall network behavior by breaking the distributed communication of information. The sources can be either external or internal to the protocol, i.e., non-BGP speakers or true BGP speakers. Under the present BGP/IDRP design, any external source can inject believable BGP/IDRP packets into the communication between BGP/IDRP peers and thereby inject bogus routing information or break the peer to peer connection. With IP spoofing, the external sources of bogus BGP information can reside anywhere in the world. Furthermore, external sources can disrupt communications between BGP peers by breaking their TCP connection with spoofed RST packets. Internal sources, i.e., BGP speakers themselves, can inject bogus routing information masquerading as information from any other legitimate BGP speaker. Bogus information from either external or internal sources can affect routing behavior in the Internet over a wide, possibly unbounded, area. Bogus routing information can have many different effects on routing behavior. If the bogus information removes routing information for a particular network, that network can become unreachable for the portion of the Internet that accepts the bogus information. If the bogus information changes the route to a network, then packets destined for that network may be forwarded by a sub-optimal path, or a path that does not follow the expected policy, or a path that will not forward the traffic. If the bogus information makes it appear that an autonomous system originates a network when it does not, then packets for that network may not be deliverable for the portion of the Internet that accepts the bogus information. A false announcement that an autonomous systems originates a network may also fragment aggregated address blocks in other parts of the Internet and cause routing problems for other networks. Murphy Expires: Jun 1998 [Page 2] INTERNET DRAFT BGP Security Analysis December 1997 2. Specific Vulnerabilities Each message introduces certain different vulnerabilities: 2.1. OPEN Because receipt of a new OPEN message in the Established state will cause the close of the BGP peering session and thereby induce the release of all resources and deletion of all associated routes, the ability to spoof this message can lead to a severe disruption of routing. 2.2. KEEPALIVE Receipt of a KEEPALIVE message when the peering connection is in the OpenSent state can lead to a failure to establish a connection. The ability to spoof this message is a vulnerability, but difficult to exploit deliberately, as it must be carefully timed in the sequence of messages exchanged between the peers if it is to cause damage. 2.3. NOTIFICATION Receipt of a NOTIFICATION message will cause the close of the BGP peering session and thereby induce the release of all resources and deletion of all associated routes. Therefore, the ability to spoof this message can lead to a severe disruption of routing. 2.4. UPDATE The Update message carries the routing information. The ability to spoof any part of this message can lead to a disruption of routing. 2.4.1. Unfeasible Routes Length, Total Path Attribute Length There is a vulnerability arising from the ability to modify these fields. If a length is modified, the message is not likely to parse properly, resulting in an error, the transmission of a NOTIFICATION message and the close of the connection. As a true BGP speaker is always able to close a connection at any time, this vulnerability represents an additional risk only when the source is external, i.e., it presents no additional risk from internal sources. Murphy Expires: Jun 1998 [Page 3] INTERNET DRAFT BGP Security Analysis December 1997 2.4.2. Withdrawn Routes An external source could cause the elimination of existing legitimate routes by forging or modifying this field. An external source could also cause the elimination of reestablished routes by replaying this withdrawal information from earlier packets. A BGP speaker could "falsely" withdraw feasible routes using this field. However, as the BGP speaker is authoritative for the routes it will announce, it is allowed to withdraw any previously announced routes that it wants. As the receiving BGP speaker will only withdraw routes associated with the sending BGP speaker, there is no opportunity for a BGP speaker to withdraw another BGP speaker's routes. Therefore, there is no additional vulnerability from internal sources via this field. 2.4.3. Path Attributes The path attributes present many different vulnerabilities. Attribute Flags, Attribute Type Codes, Attribute Length An internal or external source could modify the attribute length or attribute type (flags and type codes) so they did not reflect the attribute values that followed. If the length were modified, the likely result would be that the UPDATE message would not parse correctly. If the flags were modified, the flags and type code could become incompatible (i.e., a mandatory attribute marked as partial), or a optional attribute could be interpreted as a mandatory attribute or vice versa. Modifying the type code could cause the attribute value to be interpreted as if it were the data type and value of a different attribute. The most likely result from modifying the attribute flags or type code would be a parse error of the UPDATE message. A parse error from any modification would cause the transmission of a NOTIFICATION message and the close of the connection. As a true BGP speaker is always able to close a connection at any time, this vulnerability represents an additional risk only when the source is external, i.e., it presents no additional risk from internal sources. ORIGIN This field indicates whether the information was learned from IGP or EGP information. If the route is used in inter-AS multicast routing, a values of INCOMPLETE may be used. This field is not used in making routing decisions, so there are no vulnerabilities arising from this field, either from internal or external sources. Murphy Expires: Jun 1998 [Page 4] INTERNET DRAFT BGP Security Analysis December 1997 AS_PATH An internal or external source could announce an AS_PATH that was not accurate for the associated NLRI. Forwarding for the NLRI associated with the AS_PATH could potentially be induced to follow a sub-optimal path, a path that did not follow some intended policy, or even a path that would not forward the traffic. It is not clear how far an inaccurate AS_PATH could deviate from the true AS_PATH. It may be that the first AS in the AS_PATH, at least, must be a legal hop. The RFC states that a BGP speaker prepends its own AS to an AS_PATH before announcing it to a neighbor. If the BGP speaker must prepend its own AS, then a BGP speaker that produced a bogus AS_PATH could end up receiving the traffic for the associated NLRI. This could be desirable if the error was deliberate and the intent was to receive traffic that would not otherwise be received. Receiving the mis-routed traffic could be undesirable for the faulty BGP speaker if it is not prepared to handle the extra (mis-routed) traffic. So, if a deliberately malicious speaker must prepend its own AS, it could be motivated or discouraged from inventing an arbitrary AS_PATH. If the BGP speaker need not prepend its own AS, then it could announce a path that begins with the AS of any BGP speaker. Whether such an arbitrary AS_PATH is a vulnerability would depend on whether BGP implementations check the AS_PATH (to see if the first AS is the neighbor) and would catch the error. If there are legitimate situations in which a BGP speaker could pass an AS_PATH to a neighbor without putting its own AS at the head of the AS_PATH, then there is no way for implementations to detect totally bogus AS_PATHs. Originating Routes A special case of announcing a false AS_PATH occurs when the AS_PATH advertises a direct path to a very specific network address. An internal or external source could disrupt routing to the network(s) listed in the NLRI field by falsely advertising a direct path to the network. The NLRI would become unreachable to the portion of the network that accepted this route, unless the BGP speaker undertook to tunnel the packets it was forwarded for this NLRI on toward their destination by a legal path. But even when the BGP speaker tunnels the packets on to the correct destination, the route followed may not be optimal or may not follow the intended policy. Additionally, routing for other networks in the Internet could be affected if the false advertisement fragmented an aggregated address block. Murphy Expires: Jun 1998 [Page 5] INTERNET DRAFT BGP Security Analysis December 1997 NEXT_HOP The NEXT_HOP attribute defines the IP address of the border router that should be used as the next hop when forwarding the NLRI listed in the UPDATE message. If the recipient is an external peer, then the recipient and the NEXT_HOP address must share a subnet. It is clear that an outside source modifying this field could disrupt the forwarding of traffic between the two AS's. In the case that the NEXT_HOP address is an inter-AS peer and the recipient of the message is an inter-AS peer of a different AS (this is one of two forms of "third party" NEXT_HOP), then the BGP speaker advertising the route has the opportunity to direct the recipient to forward traffic to a BGP speaker (the NEXT_HOP peer) that may not be able to continue forwarding the traffic. It is unclear whether this would also require the advertising BGP speaker to construct an AS_PATH mentioning the NEXT_HOP inter-AS peer's AS. MULTI_EXIT_DISC The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an inter-AS peer may be propagated within an AS, it may not be propagated to other AS's. Consequently, this field is only used in making routing decisions internal to one AS. Modifying this field, whether by an external source or an internal source, could influence routing within an AS to be sub-optimal, but the effect should be limited in scope. LOCAL_PREF The LOCAL_PREF attribute must be included in all messages with internal peers and excluded from messages with external peers. Consequently, modification of the LOCAL_PREF could effect the routing process within the AS only. Note that there is no requirement in the BGP RFC that the LOCAL_PREF be consistent among the internal BGP speakers of an AS. As internal sources are free to choose the LOCAL_PREF as they wish, modification of this field is a vulnerability with respect to external sources only. ATOMIC_AGGREGATE The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way has received a more specific and a less specific route to the NLRI and installed the aggregated route. This route cannot be deaggregated because it is not certain that the route to more specific prefixes will follow the listed AS_PATH. Consequently, BGP speakers receiving a route with ATOMIC_AGGREGATE are restricted from making the NLRI any more Murphy Expires: Jun 1998 [Page 6] INTERNET DRAFT BGP Security Analysis December 1997 specific. Removing the ATOMIC_AGGREGATE attribute would remove the restriction, possibly causing traffic intended for the more specific NLRI to be routed incorrectly. Adding the ATOMIC_AGGREGATE attribute when no aggregation was done would have little effect, beyond restricting the un-aggregated NLRI from being made more specific. This vulnerability exists whether the source is internal or external. AGGREGATOR This field may be included by a BGP speaker who has computed the routes represented in the UPDATE message from aggregation of other routes. The field contains the AS number and IP address of the last aggregator of the route. It is not used in making any routing decisions, so it does not represent a vulnerability. 2.4.4. NLRI By modifying or forging this field, either an external or internal source could cause disruption of routing to the announced network, overwhelm a router along the announced route, cause data loss when the announced route will not forward traffic to the announced network, route traffic by a sub-optimal route, etc. 3. Possible Protections 3.1. External sources External sources can be prevented from disrupting routing by providing cryptographic protection of the BGP peer connection. The cryptography chosen should protect the authenticity and integrity of the message and should also protect against replay. As the protection is only of the peer-peer communications, asymmetric cryptography is not needed. The protection could be provided at the IP level by using existing IPSEC mechanisms. If IPSEC is not available, using cryptographic protection within BGP or TCP would be necessary (but is not as yet defined). Note that applying the cryptographic protection within BGP does not provide the same protection as applying it within TCP, as TCP information other than the payload (BGP) data (e.g., the RST field) could still be spoofed in ways that would harm the connection. Prevention of spoofing completely removes any risk associated with bogus OPEN, KEEPALIVE, or NOTIFICATION messages, as the only vulnerabilities from these messages come from external sources. It also protects against all threats from bogus UPDATE messages arising from external sources. Murphy Expires: Jun 1998 [Page 7] INTERNET DRAFT BGP Security Analysis December 1997 3.2. Internal sources Protection of the communication between BGP peers does nothing to protect against errors introduced by the BGP speakers themselves. BGP speakers can introduce bogus routing information, e.g., invalid AS_PATHs, incorrect ORIGINs, etc., at any time. Furthermore, detecting the internal source of bogus information (if and when the bogus-ness is detected) can be difficult if not impossible. There are several possible solutions to prevent a BGP speaker from inserting bogus information in its advertisements to its peers. (1) sign the originating AS. (2) sign the originating AS and predecessor information (3) sign the originating AS, and nest signatures of AS_PATHs to the number of consecutive bad routers you want to prevent from causing damage. (4) rely on a registry to say if AS_PATH and originating AS are valid 3.3. Sign Originating AS It would be beneficial to know which AS has first advertised a route to a NLRI. This could be done by including a new field which would contain the originating AS number and the originating AS's digital signature [3] of that plus the NLRI advertised. A digital signature is required because the number and identities of all eventual recipients could not be known and because non-repudiation would be desired. This field could be verified against an Internet registry, if a complete and accurate registry existed. If routing was disturbed by the presence of this advertisement, then the culprit could be determined. If a structure exists representing ownership of network addresses, then the owner as well as the advertiser could sign. A representation of an owner could be useful when Internet service providers transfer sub- blocks of their owned addresses to smaller ISP's. The ISP's could advertise NLRI but the ownership of the network could still be determined. If routes are aggregated by a BGP speaker and the aggregated route advertised, then the idea of "originator" and "owner" become less useful. There might be several "originators" and "owners" represented among the aggregated routes. We suggest that the AGGREGATOR field Murphy Expires: Jun 1998 [Page 8] INTERNET DRAFT BGP Security Analysis December 1997 become mandatory and that an aggregating BGP speaker append its signature of the AGGREGATOR field and the aggregated NLRI. Unfortunately, aggregation prevents identification of the specific culprit should it be discovered that a network is being originated in error. 3.4. Sign Originating AS and Predecessor Information Reference [2] suggests several different types of cryptographic protection of BGP. The suggested protection against possibly faulty BGP speakers introduces some link state topology information (see [4]) that can be used to verify AS_PATHs. To protect against the need to trust BGP speakers regarding NLRI information not specific to their own AS, [2] suggests adding the following information to the UPDATE message: - the AS originating the information (either the aggregator or the advertiser of a direct route) and - the predecessor of the originating AS (i.e., the neighbor to which the NLRI is first advertised). This field is digitally signed along with the NLRI, the ATOMIC_AGGREGATOR, and other fields of the UPDATE message. The signature and the predecessor information must be included as the route in the UPDATE message propagates across the network, i.e., it is transitive. This information distributes a bit of link state topology information, concerning just the last hop before the destination network's AS, into the usual BGP distance vector (some say "path vector") protocol. Each BGP speaker, even those who are transit only and originate no UPDATE messages with NLRI contained in their own AS, will transmit this "predecessor" information. From all the signed predecessor information received, it would be possible to verify that each of the adjacencies represented in an AS_PATH is legitimate. When a segment of an AS_PATH is a sequence, each adjacent pair in the sequence must correspond to a received signed predecessor tuple. The protection provided by the signed predecessor information becomes more difficult to use past an aggregation point where a BGP speaker advertises a less specific route which includes the NLRI. In particular, the rules for verifying an AS_PATH containing a segment that is a set would be either very lenient or very complex. Murphy Expires: Jun 1998 [Page 9] INTERNET DRAFT BGP Security Analysis December 1997 While this predecessor information assures that each adjacency in a sequence of an AS_PATH is valid, it does not ensure that the AS_PATH as a whole is valid. Each AS's decision regarding routes it will advertise and traffic it will transit is individual and totally unconstrained. The fact that a valid path of ASs exists to a destination does not ensure that the corresponding AS_PATH is valid. This mechanism also does not assure that any information which comes from one router alone (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. A router, then, can still falsely announce that its neighbor should be forwarded the traffic for an NLRI. 3.5. Sign Originating AS and AS_PATH A protection against possibly faulty BGP speakers that does provide some assurance that the AS_PATH is valid involves nested digital signatures of the AS_PATH. Each BGP speaker would receive signed AS_PATH information (including the ATOMIC_AGGREGATOR and NLRI attributes) from its peer. After making its routing decision, it would augment the chosen AS_PATH with its own AS and sign the result. The BGP speaker would pass to its peers the augmented AS_PATH, its signature, and the signature of its peer over the base AS_PATH from which the augmented AS_PATH was formed. The peer receiving this information can verify that the received AS_PATH was indeed constructed with some basis in reality by verifying the signature of the BGP speaker's peer over the tail of the received AS_PATH. The BGP speaker's signature will be passed on by the peer to provide similar assurance that it constructed its advertised AS_PATH legitimately. This procedure as described protects against one consecutive faulty router in the path. If it is desired to protect against more possibly faulty routers in the path, then the procedure can be nested arbitrarily. To protect against n consecutive faulty routers, each router would receive signed AS_PATH information from its neighbor along with n signatures of the preceding n BGP speakers in the path, each successive signature covering a shorter suffix of the path. It would pass on a newly constructed AS_PATH along with its own signature, its neighbor's signature and n-1 of the included nested signatures. A BGP speaker could snip out a suffix of the data it received as well as the associated signatures and pass those on as the proof that its AS_PATH was based on reality. To prevent this, the signatures generated should cover not only the AS_PATH but the intended receiver as well. Murphy Expires: Jun 1998 [Page 10] INTERNET DRAFT BGP Security Analysis December 1997 For example, consider a case where it was decided to protect against only one faulty BGP speaker. Suppose AS1 receives an AS_PATH from AS2 of "AS2 AS3 ... ASk". Then it should also receive AS2's signature of "AS1, 'AS2 AS3 ... ASk'" and AS3's signature of "AS2, 'AS3 ... ASk'". AS1 would compute a path "AS1 AS2 AS3 ... ASk", and pass on to AS0 this path along with its signature of "AS0, 'AS1 AS2 AS3 ... ASk'" and AS2's signature of "AS1, 'AS2 AS3 ... ASk'". Note that this scheme becomes more complicated when one of the BGP speakers performs aggregation of a set of routes. To assure recipients of the validity of the aggregated route, it would be necessary to pass on the text and signatures of each of the aggregated component routes. This means an enormous increase in transmission bandwidth and verification time at each aggregation point, rather than a decrease. This cost would not have to be passed on to further neighbors, but it does violate the spirit of aggregation. Note that this scheme does not assure that the received route is the best route the peer could have computed. In particular, it does not guard against a peer that does not announce the best result of its decision process - a peer that replays previous announcements, perhaps, or does not change its announcements when it receives withdrawn routes. These are a matter for the internal correct operation of the router and cannot be induced by security protection. This mechanism also does not assure that any information which comes from one router alone (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. A router, then, can still falsely announce that its neighbor should be forwarded the traffic for an NLRI. This discussion is predicated on the use of asymmetric cryptography. Each autonomous system would be required to possess an asymmetric key pair. The public key would have to be accessible to all recipients of the digital signature. The private key would have to be available to all BGP speakers in the autonomous system, but protected from exposure. Alternatively, each BGP speaker could possess its own asymmetric key pair, at the cost of further complicating the protocol. The protocol would have to be altered to include the identity of the BGP speaker within the AS who produces the AS_PATH and signature so that the signature verification procedure could choose the correct public key to use. Symmetric cryptography could be used to protect the information by using a keyed cryptographic hash instead of a digital signature. However, in order to provide the same level of protection against faulty routing, each BGP speaker would have to share a different secret key with each of Murphy Expires: Jun 1998 [Page 11] INTERNET DRAFT BGP Security Analysis December 1997 its neighbors and each of its neighbors' neighbors. (In the case that it is desired to protect against n>1 faulty BGP speakers, the number of keys would grow exponentially - a different key with all 1-hop-away neighbors, 2-hop-away neighbors, ..., and n+1-hop-away neighbors.) This is obviously not a scalable solution. It may also require autonomous systems to reveal their peering agreements where they would not wish to do so. 3.6. Rely on Registries The Internet registries can provide data that will help to assure that AS_PATHS and NLRI origination data are correct. If the data registered in the Internet registries can be assumed to be correct, then the peering information in the database can be used to verify each pair of AS's in an AS_PATH sequence segment are truly peers. Depending on the sophistication of the information recorded in the registry, the registries might also be used to verify that the AS_PATH as a whole was valid. The assurance provided by this protection would rely on the completeness of the registry, on the authenticity of the registry data and on the protection it received in storage and transit. The protection is useful if data from the registry is either available locally or retrievable with an acceptable lag time. The assurance provided by this protection also relies on the openness of the data recorded in the registries. To be truly useful, each autonomous system's policy would have to be recorded in the registry, in order that the AS_PATH as a whole can be verified to be valid. Information about policy, however, can be sensitive to an autonomous system and not openly available to every other autonomous system. Any restrictions on the availability of information stored in the registry will restrict its applicability as a protection mechanism. 4. Security Costs Choosing the protection to apply in any situation depends on the perception of the risk of attack, of the damage that can result, of the benefits derived from providing the protection, and of the cost of providing the protection. This section discusses the cost of each of the protection options mentioned above. Murphy Expires: Jun 1998 [Page 12] INTERNET DRAFT BGP Security Analysis December 1997 4.1. Protecting the Peer-Peer Link The cost of this protection is the processing required for the cryptography and the need to establish and manage the cryptographic keys. The cryptography need not be computationally expensive; HMAC or similar algorithms can be used. Shared secret keys are adequate for this protection, as the protection applies only to the communication between peers, so the key management cost is low. Ideally, a separate key should be used for each BGP peering. One key might be used for multiple peerings with a reduction in the level of protection that is provided. However, it is best to remember that apocryphally, the more places know a secret, the more chances it will be exposed. This level of protection is low cost and protects against the vast number of possible adversaries (i.e., any non-BGP speaker in the internet). 4.2. Sign Originating AS The cost of signing the originating AS of each route is the cost of providing a public key infrastructure to generate an asymmetric key pair for each autonomous system and to distribute and maintain the public keys associated with each autonomous system. The Internet registries might be sufficient to serve as an authorization structure for advertising each NLRI, but the authorization of ownership of network addresses would either have to come from the IANA or from some new authorization structure. 4.3. Sign Originating AS and Predecessor Information This scheme requires the same public key infrastructure as is needed if one simply signs the originating AS information. It also requires that each adjacency for a BGP speaker be signed (the "predecessor" information) and transmitted along with an AS_PATH. Essentially, each BGP speaker must announce its peers, something that does not currently occur in the BGP protocol. Each BGP speaker must compute one signature for each UPDATE message transmitted and must verify one signature for each UPDATE message received. (Each UPDATE message must be separately signed because the mechanism described in [2] includes a sequence number, the Withdrawn Routes and the Unfeasible Route Length fields, so the information to be signed changes with each message. These fields are protected from external sources by the peer-peer communication protection and so do not need to be digitally signed. If only the NLRI, ATOMIC_AGGREGATE and predecessor information were signed each time, then the signature might not have to be computed with each new UPDATE message.) The predecessor information in each route must be stored Murphy Expires: Jun 1998 [Page 13] INTERNET DRAFT BGP Security Analysis December 1997 indefinitely. Each route received must be verified by comparison to predecessor information previously received. 4.4. Sign Originating AS and AS_PATH This scheme requires the same public key infrastructure as is needed if one simply signs the originating AS information. For each UPDATE message received, n signatures (the level of protection from consecutive faulty routers) must be verified. For each UPDATE message transmitted, one signature must be computed. Note that the signature includes the recipient, so computing one signature per AS_PATH and NLRI announced is insufficient. 4.5. Rely on Registries The cost of relying on registries would vary considerably depending on the protection provided to the information in storage and in transit. Any latency, above that caused by the use of cryptography, would depend on the mechanism used to protect the registry information (e.g., anything from frequent complete download to real-time query and response). 5. Security Considerations This entire memo is about security considerations. 6. References [1] RFC1771, A Border Gateway Protocol 4 (BGP-4). Y. Rekhter & T. Li. March 1995. [2] B. Smith and J.J. Garcia-Luna-Aceves, ``Securing the Border Gateway Routing Protocol,'' Proc. Global Internet'96, London, UK, 20-21 November 1996. [3] Bruce Schneier. Applied Cryptography Protocols, Algorithms, and Source Code in C, John Wiley & Sons, Inc 1994 [4] John Moy. OSPF Version 2. RFC 1583, March 1994 7. Author's Address Sandra Murphy Trusted Information Systems 3060 Washington Road Murphy Expires: Jun 1998 [Page 14] INTERNET DRAFT BGP Security Analysis December 1997 Glenwood, MD 21738 EMail: Sandy@tis.com Murphy Expires: Jun 1998 [Page 15] INTERNET DRAFT BGP Security Analysis December 1997 Table of Contents Status of this Memo .............................................. 1 Abstract ......................................................... 1 1 Introduction .................................................... 1 2 Specific Vulnerabilities ........................................ 3 2.1 OPEN .......................................................... 3 2.2 KEEPALIVE ..................................................... 3 2.3 NOTIFICATION .................................................. 3 2.4 UPDATE ........................................................ 3 2.4.1 Unfeasible Routes Length, Total Path Attribute Length ....... 3 2.4.2 Withdrawn Routes ............................................ 4 2.4.3 Path Attributes ............................................. 4 Attribute Flags, Attribute Type Codes, Attribute Length .......... 4 ORIGIN ........................................................... 4 AS_PATH .......................................................... 5 Originating Routes ............................................... 5 NEXT_HOP ......................................................... 6 MULTI_EXIT_DISC .................................................. 6 LOCAL_PREF ....................................................... 6 ATOMIC_AGGREGATE ................................................. 6 AGGREGATOR ....................................................... 7 2.4.4 NLRI ........................................................ 7 3 Possible Protections ............................................ 7 3.1 External sources .............................................. 7 3.2 Internal sources .............................................. 8 3.3 Sign Originating AS ........................................... 8 3.4 Sign Originating AS and Predecessor Information ............... 9 3.5 Sign Originating AS and AS_PATH ............................... 10 3.6 Rely on Registries ............................................ 12 4 Security Costs .................................................. 12 4.1 Protecting the Peer-Peer Link ................................. 13 4.2 Sign Originating AS ........................................... 13 4.3 Sign Originating AS and Predecessor Information ............... 13 4.4 Sign Originating AS and AS_PATH ............................... 14 4.5 Rely on Registries ............................................ 14 5 Security Considerations ......................................... 14 6 References ...................................................... 14 7 Author's Address ................................................ 14 Murphy Expires: Jun 1998 [Page 16]