idnits 2.17.1 draft-murphy-bgp-secr-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8192 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '9' is mentioned on line 377, but not defined ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1583 (ref. '4') (Obsoleted by RFC 2178) ** Obsolete normative reference: RFC 2401 (ref. '7') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2385 (ref. '8') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sandra Murphy 3 INTERNET DRAFT NAI Labs 4 draft-murphy-bgp-secr-04.txt November 2001 6 BGP Security Analysis 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions of 11 Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Abstract 30 BGP, along with a host of other infrastructure protocols designed before 31 the Internet environment became perilous, is designed with little 32 consideration for protection of the information it carries. There are 33 no mechanisms in BGP to protect against attacks that modify, delete, 34 forge, or replay data, any of which has the potential to disrupt overall 35 network routing behavior. 37 This internet draft discusses some of the security issues with BGP 38 routing data dissemination, and possible security solutions and the 39 costs of those solutions. This internet draft does not discuss security 40 issues with forwarding of packets. 42 Table of Contents 44 Status of this Memo .............................................. 1 45 Abstract ......................................................... 1 46 1 Introduction .................................................... 4 47 2 Vulnerabilities and Risks ....................................... 6 48 3 Possible Protections ............................................ 6 49 3.1 Threats from outsiders ........................................ 6 50 3.1.1 IP level protection ......................................... 7 51 3.1.2 TCP level protection ........................................ 7 52 3.2 Threats from BGP peers ........................................ 8 53 3.3 Origination Protection ........................................ 8 54 3.4 Origination and Adjacency Protection .......................... 9 55 3.5 Sign Originating AS and AS_PATH ............................... 10 56 3.5.1 Remaining Issues ............................................ 11 57 3.6 Filtering ..................................................... 13 58 4 Security Costs .................................................. 14 59 4.1 Protecting the Peer-Peer Link ................................. 14 60 4.2 Origination Protection ........................................ 14 61 4.3 Origination and Adjacency Protection .......................... 15 62 4.4 Origination and AS_PATH Protection ............................ 15 63 4.5 Rely on Registries ............................................ 16 64 5 Security Considerations ......................................... 16 65 6 References ...................................................... 16 66 7 Author's Address ................................................ 17 67 A Appendix A - Vulnerabilities and Risks .......................... 18 68 A.1 OPEN .......................................................... 18 69 A.2 KEEPALIVE ..................................................... 18 70 A.3 NOTIFICATION .................................................. 18 71 A.4 UPDATE ........................................................ 18 72 A.4.1 Unfeasible Routes Length, Total Path Attribute Length ....... 18 73 A.4.2 Withdrawn Routes ............................................ 19 74 A.4.3 Path Attributes ............................................. 19 75 Attribute Flags, Attribute Type Codes, Attribute Length .......... 19 76 ORIGIN ........................................................... 19 77 AS_PATH .......................................................... 20 78 Originating Routes ............................................... 20 79 NEXT_HOP ......................................................... 21 80 MULTI_EXIT_DISC .................................................. 21 81 LOCAL_PREF ....................................................... 21 82 ATOMIC_AGGREGATE ................................................. 22 83 AGGREGATOR ....................................................... 22 84 A.4.4 NLRI ........................................................ 22 85 1. Introduction 87 The inter-domain routing protocol BGP was created when the Internet 88 environment had not yet reached the present contentious state. 89 Consequently, the BGP protocol was not designed with protection against 90 deliberate or accidental errors causing disruptions of routing behavior. 92 We here discuss the vulnerabilities of BGP, based on the BGP RFC [1] and 93 on [2]. Readers are expected to be familiar with the BGP RFC and the 94 behavior of BGP. We propose several different security solutions to 95 protect these vulnerabilities and discuss the benefits derived from each 96 solution and its cost. 98 It is clear that the Internet is vulnerable to attack through its 99 routing protocols. BGP is no exception. Faulty, misconfigured or 100 deliberately malicious sources can disrupt overall Internet behavior by 101 injecting bogus routing information into the BGP distributed routing 102 database (by modifying, forging, or replaying BGP packets). The same 103 methods can also be used to disrupt local and overall network behavior 104 by breaking the distributed communication of information between BGP 105 peers. The sources of bogus information can be either outsiders or true 106 BGP peers. 108 Under the present BGP design, cryptographic authentication of the peer- 109 peer communication is not mandated. As a TCP/IP protocol, BGP is 110 subject to all the TCP/IP attacks, like IP spoofing, session stealing, 111 etc. Any outsider can inject believable BGP messages into the 112 communication between BGP peers and thereby inject bogus routing 113 information or break the peer to peer connection. Any break in the peer 114 to peer communication has a ripple effect on routing that can be wide 115 spread. Furthermore, outsider sources can also disrupt communications 116 between BGP peers by breaking their TCP connection with spoofed RST 117 packets. Outsider sources of bogus BGP information can reside anywhere 118 in the world. 120 BGP speakers themselves can inject bogus routing information, either by 121 masquerading as information from any other legitimate BGP speaker, or by 122 distributing unauthentic routing information as themselves. 123 Historically, misconfigured and faulty routers have been responsible for 124 widespread disruptions in the Internet. 126 Bogus routing information can have many different effects on routing 127 behavior. If the bogus information removes routing information for a 128 particular network, that network can become unreachable for the portion 129 of the Internet that accepts the bogus information. If the bogus 130 information changes the route to a network, then packets destined for 131 that network may be forwarded by a sub-optimal path, or a path that does 132 not follow the expected policy, or a path that will not forward the 133 traffic. As a consequence, traffic to that network could be delayed by 134 a longer than necessary path. The network could become unreachable from 135 areas where the bogus information is accepted. Traffic might also be 136 forwarded along a path that permits some adversary a view of the data. 137 If the bogus information makes it appear that an autonomous system 138 originates a network when it does not, then packets for that network may 139 not be deliverable for the portion of the Internet that accepts the 140 bogus information. A false announcement that an autonomous systems 141 originates a network may also fragment aggregated address blocks in 142 other parts of the Internet and cause routing problems for other 143 networks. 145 The damage that might result from these attacks are: 147 starvation: data traffic destined for a node is forwarded to a part 148 of the network that cannot deliver it, 150 network congestion: more data traffic is forwarded through some 151 portion of the network than would otherwise need to carry the 152 traffic, 154 blackhole: large amounts of traffic are directed to be forwarded 155 through one router that cannot handle the increased level of 156 traffic and drops many/most/all packets, 158 delay: data traffic destined for a node is forwarded along a path 159 that is in some way inferior to the path it would otherwise take, 161 looping: data traffic is forwarded along a path that loops, so that 162 the data is never delivered, 164 eavesdrop: data traffic is forwarded through some router or network 165 that would otherwise not see the traffic, affording an opportunity 166 to see the data, 168 partition: some portion of the network believes that it is 169 partitioned from the rest of the network when it is not, 171 cut: some portion of the network believes that it has no route to 172 some network that is in fact connected, 173 churn: the forwarding in the network changes at a rapid pace, 174 resulting in large variations in the data delivery patterns (and 175 adversely affecting congestion control techniques), 177 instability: BGP become unstable so that convergence on a global 178 forwarding state is not achieved, and 180 overload: the BGP messages themselves become a significant portion 181 of the traffic the network carries. 183 2. Vulnerabilities and Risks 185 The risks in BGP arise from three fundamental vulnerabilities: 187 no mechanism has been mandated that provides strong protection of 188 the integrity, freshness and source authenticity of the messages in 189 peer-peer BGP communications. 191 no mechanism has been specified to validate the authority of an AS 192 to announce NLRI information. 194 no mechanism has been specified to ensure the authenticity of the 195 AS_PATH announced by an AS. 197 There are four different BGP message types - OPEN, KEEPALIVE, 198 NOTIFICATION, and UPDATE. A discussion of the vulnerabilities arising 199 from each message and the ability of outsiders or BGP peers to exploit 200 the vulnerabilities is contained in Appendix A. To summarize, outsiders 201 can use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the 202 BGP peer-peer connections and can use bogus UPDATE messages to disrupt 203 routing. Outsiders can also disrupt BGP peer-peer connections by 204 inserting bogus TCP RST packets. BGP peers themselves are permitted to 205 break peer-peer connections at any time, and so they cannot be said to 206 be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages. However, 207 BGP peers can disrupt routing by issuing bogus UPDATE messages. In 208 particular, bogus ATOMIC_AGGREGATE and AS_PATH attributes and bogus NLRI 209 in UPDATE messages can disrupt routing. 211 3. Possible Protections 213 3.1. Threats from outsiders 215 Outsiders can be prevented from disrupting routing by providing 216 cryptographic protection of the BGP peer-peer connection. The 217 cryptography chosen should protect the source authenticity and integrity 218 of the message and should also protect against replay. As the 219 protection is only of the peer-peer communications, asymmetric 220 cryptography is not needed. Two different protection against spoofing 221 in the peer-peer connection have been suggested: 223 IP level protection as defined by IPSEC [7] 225 TCP level protection as defined by [8] 227 Prevention of IP spoofing completely removes any risk associated with 228 bogus OPEN, KEEPALIVE, or NOTIFICATION messages, as the only 229 vulnerabilities from these messages come from outsiders. It also 230 protects against all threats from bogus UPDATE messages and from bogus 231 TCP messages arising from outsiders. 233 3.1.1. IP level protection 235 Protection as specified for the IPSEC [7] can be used to provide 236 connectionless integrity, data origin authentication, and a anti-replay 237 service. 239 3.1.2. TCP level protection 241 It is possible to protect the peer-peer connection by applying 242 cryptographic protection at the TCP level to provide connectionless 243 integrity and data origin authentication. This has been in use with 244 some vendors for some time as specified in [8]. Note, however, that the 245 protections specified in [8] were put in place some time ago. The IPSEC 246 protections have advanced since that time. In particular, the 247 protections of [8] use MD5 directly, where the IPSEC protections mandate 248 the use of HMAC-MD5 because of recently publicized concerns of 249 collisions in MD5. Also, [8] does not have the provisions for anti- 250 reply found in IPSEC. The TCP sequence numbers do provide some 251 protection against replay. But as some packets, notably a RST packet, 252 need only be within the receive window to be accepted, the TCP sequence 253 number protection is not complete. Finally, [8] has no provisions for 254 multiple keys to be used in rekeying. As these are pairwise keys used 255 for long-lived sessions, the inability to specify multiple keys may not 256 cause operational difficulties. 258 Although the TCP level protection specified in [8] has deficiencies when 259 compared with the protection of IPSEC [7], it is vastly preferable to a 260 unprotected connection. If IPSEC is not available, then the TCP level 261 protection of [8] should definitely be used. When IPSEC is available, 262 IPSEC is preferable. One or the other must be used. 264 3.2. Threats from BGP peers 266 Protection of the communication between BGP peers does nothing to 267 protect against errors introduced by the BGP speakers themselves. BGP 268 speakers can introduce bogus routing information, e.g., invalid 269 AS_PATHs, false origination announcements of NLRI, etc., at any time. 270 Furthermore, detecting the BGP source of bogus information (if and when 271 the bogus-ness is detected) can be difficult if not impossible. 273 There are several possible solutions to prevent a BGP speaker from 274 inserting bogus information in its advertisements to its peers. 276 (1) Origination Protection: sign the originating AS. 278 (2) Origination and Adjacency Protection: sign the originating AS and 279 predecessor information. 281 (3) Origination and Route Protection: sign the originating AS, and 282 nest signatures of AS_PATHs to the number of consecutive bad 283 routers you want to prevent from causing damage. 285 (4) Filtering: rely on a registry to verify the AS_PATH and NLRI 286 originating AS. 288 The first three solutions are implemented within the protocol exchanges. 289 The last solution is an operational protection and leaves the protocol 290 messages unchanged. 292 3.3. Origination Protection 294 It would be beneficial to authenticate the AS that first advertises a 295 route to a NLRI. This could be done by including a new path attribute 296 which would contain the originating AS number and the originating AS's 297 digital signature [4] of the AS number plus the NLRI advertised. A 298 digital signature (as opposed to a message integrity check using a 299 shared secret) is preferable because the number and identities of all 300 eventual recipients are not known and because non-repudiation would be 301 desired. If routing was disturbed by the presence of this 302 advertisement, then the culprit could be determined. 304 If an infra-structure exists representing ownership of network 305 addresses, then the owner as well as the originator could sign. This 306 signature would indicate that the AS was authorized by the owner to 307 originate the network. A BGP speaker receiving a protected origination 308 could verify taht the origination was legitimate. 310 If routes are aggregated by a BGP speaker and the aggregated route 311 advertised, then the idea of "originator" and "owner" become less 312 useful. There might be several "originators" and "owners" represented 313 among the aggregated routes. The AGGREGATOR field should be mandatory 314 and an aggregating BGP speaker should append its signature of the 315 AGGREGATOR field and the aggregated NLRI. Unfortunately, aggregation 316 prevents identification of the specific culprit should it be discovered 317 that a network is being originated incorrectly. 319 This protection does not ensure that the AS_PATH is authentic or 320 current. 322 3.4. Origination and Adjacency Protection 324 Reference [3] suggests several different types of cryptographic 325 protection of BGP. The suggested protection against possibly faulty BGP 326 speakers introduces some link state topology information (as in OSPF 327 [5]) that can be used to verify AS_PATHs. 329 To obviate the need to trust BGP speakers regarding NLRI information not 330 specific to their own AS, [3] suggests adding the following information 331 to the UPDATE message in new path attributes: 333 - a sequence number for the UPDATE 335 - the AS originating the information (either the aggregator or the 336 originator of a direct route) and 338 - the "predecessor" of the originating AS (i.e., the neighbor to 339 which the NLRI is first advertised). 341 This information is digitally signed by the BGP originator along with 342 the NLRI, the ATOMIC_AGGREGATE, the ORIGIN, and the AGGREGATOR fields of 343 the UPDATE message. The signature and the predecessor information must 344 be included as the route in the UPDATE message propagates across the 345 network, i.e., it is transitive. 347 This information distributes a bit of link state topology information, 348 concerning just the last hop before the destination network's AS, into 349 the usual BGP distance vector (some say "path vector") protocol. Each 350 BGP speaker will propogate this "predecessor" information. Any BGP 351 speaker could use the signed predecessor information received to verify 352 that each of the adjacencies represented in an AS_PATH is legitimate. 353 That is, when a segment of an AS_PATH is a sequence, each adjacent pair 354 in the sequence could be verified to correspond to a received signed 355 predecessor tuple. 357 The protection provided by the signed predecessor information becomes 358 more difficult to use past an aggregation point where a BGP speaker 359 advertises a less specific route which includes the originated NLRI. In 360 particular, the rules for verifying an AS_PATH containing a segment that 361 is a set would be either very lenient or very complex. 363 While this predecessor information assures that each adjacency in a 364 sequence of an AS_PATH is valid, it does not ensure that the AS_PATH as 365 a whole is valid. Each AS's decision regarding routes it will advertise 366 and traffic it will transit is individual and totally unconstrained. 367 The fact that a valid path of ASs exists to a destination does not 368 ensure that the corresponding AS_PATH is valid. This mechanism also 369 does not assure that any information which comes from one router alone 370 (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. A router, then, 371 can still falsely announce that its neighbor should be forwarded the 372 traffic for an NLRI. 374 3.5. Sign Originating AS and AS_PATH 376 A protection against possibly faulty BGP speakers that does provide some 377 assurance that the AS_PATH is valid is described in [9]. The protection 378 requires digital signatures of nested prefixes of the AS_PATH, carried 379 in a transitive path attribute. 381 Each BGP speaker would receive signed route information (including the 382 AS_PATH, the ATOMIC_AGGREGATE attribute and NLRI) from its peer. The 383 signature represents permission from the peer for the speaker to 384 advertise the route. After making its routing decision, the BGP speaker 385 would augment the chosen AS_PATH with its own AS and sign the resulting 386 route (NLRI + AS_PATH) and ATOMIC_AGGREGATE. The BGP speaker would pass 387 to its peers the augmented AS_PATH, its signature, and the signature it 388 received from its peer which covers the received AS_PATH. The neighbor 389 receiving this information can verify that the received AS_PATH was 390 indeed constructed from an authorized path, by verifying the signature 391 of the BGP speaker's peer over the tail of the received AS_PATH. The 392 BGP speaker's signature will be passed on by the neighbor to provide 393 similar assurance that it constructed its advertised AS_PATH 394 legitimately. 396 A BGP speaker could snip out a suffix of the data it received as well as 397 the associated signatures and pass those on as the proof that its 398 AS_PATH was based on reality. To prevent this, the signatures generated 399 must cover not only the route information but the intended receiver as 400 well. 402 This procedure as described protects against one consecutive faulty 403 router in the path. If it is desired to protect against more than one 404 possibly faulty routers in the path, then the procedure can be nested 405 arbitrarily. To protect against K consecutive faulty routers, each 406 router would receive signed AS_PATH information from its neighbor along 407 with K signatures of the preceding K BGP speakers in the path, each 408 successive signature covering a shorter suffix of the AS_PATH. It would 409 pass on a newly constructed AS_PATH along with its own signature, its 410 neighbor's signature and K-1 of the included nested signatures. 412 For example, consider a case where it was decided to protect against two 413 faulty BGP speakers. Suppose AS1 receives an AS_PATH from AS2 of 'AS2 414 AS3 AS4 ... ASk'. (In this discussion as well as the next, 415 ATOMIC_AGGREGATE would be included in the signature, but is omitted for 416 brevity.) Then AS1 should also receive AS2's signature of "AS1, 'AS2 417 AS3 ... ASk', NLRI" as well as AS3's signature of "AS2, 'AS3 ... ASk', 418 NLRI" and AS4's signature of "AS3, 'AS4 ... ASk', NLRI". AS1 would 419 verify the authenticity of AS2's route by verifying the authorizing 420 signatures from AS3 and AS4. 422 AS1 uses AS2's signature in authorizing its own announcements. AS1 423 would compute a path as 'AS1 AS2 AS3 ... ASk', and pass to its neighbor 424 AS0 this path along with its signature of "AS0, 'AS1 AS2 AS3 ... ASk', 425 NLRI" and the authorizing signatures of AS2 and AS3. 427 Because the intended recipient is included in the signature, each BGP 428 speaker with N peers generates N signatures for each route announced, 429 one for each peer. 431 This discussion is predicated on the use of asymmetric cryptography. 432 Each autonomous system would be required to possess an asymmetric key 433 pair. The public key would have to be accessible to all recipients of 434 the digital signature. The private key would have to be available to 435 all BGP speakers in the autonomous system, but protected from exposure. 437 3.5.1. Remaining Issues 439 This scheme becomes more complicated when one of the BGP speakers 440 performs aggregation of a set of routes. To assure recipients of the 441 validity of the aggregated route, it would be necessary to pass on the 442 text and signatures of each of the aggregated component routes. This 443 means an enormous increase in transmission bandwidth at each aggregation 444 point and a similar increase in verification time at each verification 445 point's peers. This cost would not have to be passed on to further 446 neighbors further than K (the nesting level of signatures) hops away, 447 but it does violate the spirit of aggregation. Alternatively, an 448 aggregation point could be treated as another type of origination point, 449 and signatures and verification would stop at that point. 450 Unfortunately, that provides a mechanism for malicious BGP peers to 451 announce bogus routes, simply by claiming to have aggregated the 452 information. Aggregation also prevents identification of the specific 453 culprit should it be discovered that a network is being originated in 454 error. 456 Neither this scheme nor the Origination and Adjacency Protection assures 457 that the received route is the best route the peer could have computed. 458 In particular, it does not guard against a peer that does not announce 459 the best result of its decision process - for example, a peer that 460 replays previous updates instead of forwarding a withdrawal, or does not 461 change its announcements when it receives withdrawn routes, or replays 462 withdrawal information after a route is reestablished, or replays an 463 update after having forwarded a withdrawal. These are a matter for the 464 internal correct operation of the router and cannot be precluded by 465 authentication or authorization protection. This mechanism also does 466 not assure that any information which comes from one router alone 467 (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. With these 468 fields, a router can still falsely announce that its neighbor should be 469 forwarded the traffic for an NLRI. 471 The verification process chooses the key to use based on the AS's 472 mentioned in the AS_PATH. If implementations do not verify that the 473 peer BGP speaker prepended its own AS to the AS_PATH, i.e. if a BGP 474 speaker might pass on an AS_PATH in which it's own AS is not the first 475 in the PATH, then the AS's mentioned in the AS_PATH are not necessarily 476 the AS's that produced the signature. In that case, this verification 477 process could be using the wrong key. This signature scheme would have 478 to be complicated by requiring either 480 - that the sender's AS be included in the UPDATE message and the 481 signature (so that the verification process could find the 482 appropriate key for the signature) 484 - or that each sender know the private key of the first AS in the 485 AS_PATH (so that the signature and verification processes would be 486 using the same key). 488 Sharing keys between AS's makes those AS's indistinguishable to the 489 cryptography; the second alternative design should only be chosen with 490 that caution clearly understood. 492 3.6. Filtering 494 The Internet registries can provide data that will help to assure that 495 AS_PATHS and NLRI origination data are authorized. If the data 496 registered in the Internet registries is available, then an NLRI 497 origination can be verified against the registry. Also, peering 498 information in the registry can be used to verify that the AS_PATH as a 499 whole was valid. 501 The assurance provided by this protection would rely on the registry 502 data being: 504 complete: AS's that do not register their peering relationships or 505 assigned networks would hamper the ability to protect the BGP data. 507 accurate: AS's must register peering relationships that exactly 508 match their policies. If the peering relationships are described 509 too broadly, bogus routes will pass the filter. If the peering 510 relationships are described too narrowly, legitimate routes will 511 fail. 513 timely: Additions and changes to the registry data must be 514 communicated to the AS's in a timely manner. 516 secure: The registries must be known to ensure the authenticity, 517 integrity and authorization of provided information while in 518 storage and in transmission to an AS. 520 The assurance provided by this protection relies on the openness of the 521 data recorded in the registries. To be truly useful, each autonomous 522 system's policy would have to be recorded in the registry, in order that 523 the AS_PATH as a whole can be verified to be valid. Information about 524 policy, however, can be sensitive to an autonomous system and not openly 525 available to every other autonomous system. Any restrictions on the 526 availability of information stored in the registry will restrict its 527 applicability as a protection mechanism. 529 Filtering based on the registries can also not ensure the authenticity 530 of the received routes. The registries currently contain permitted 531 routes, not necessarily the current forwarding routes. If, for example, 532 an AS will accept the same network from multiple peer, with one route to 533 serve as a backup, filtering based on the registry would not be able to 534 distinguish which is the route currently in use. 536 4. Security Costs 538 Choosing the protection to apply in any situation depends on the 539 perception of the risk of attack, of the damage that can result, of the 540 benefits derived from providing the protection, and of the cost of 541 providing the protection. This section discusses the cost of each of 542 the protection options mentioned above. 544 4.1. Protecting the Peer-Peer Link 546 The cost of this protection is the processing required for the 547 cryptography and the need to establish and manage the cryptographic 548 keys. The cryptography need not be computationally expensive; HMAC or 549 similar algorithms can be used. Shared secret keys are adequate for 550 this protection, as the protection applies only to the communication 551 between peers, so the key management cost is low. A separate key must 552 be used for each BGP peering. Using one key for multiple peerings even 553 at a peering point reduces the level of protection that is provided. 555 This level of protection is low cost and protects against the vast 556 number of outsiders who pose a threat. 558 4.2. Origination Protection 560 The cost of signing the originating AS of each route is the cost of the 561 processing required for the cryptography -- generating and verifying 562 digital signatures -- as well as the need to establish and manage the 563 cryptographic keys. For digital signatures, establishing and managing 564 the cryptographic keys means providing a public key infrastructure to 565 generate an asymmetric key pair for each autonomous system and to 566 distribute and maintain certifications of the public keys associated 567 with each autonomous system. 569 While the key distribution and signature generation and verification 570 provides for authentication and integrity of the messages, there is also 571 a need to ensure the authorization of the origination. This requires 572 another infrastructure that would provide certifications of the 573 authority of an AS to originate a route to a network. 575 The infrastructures required for authentication of AS messages and for 576 authorization of origination information might be colocated. The 577 establishment and secure operation of the security infrastructure as 578 well as the cost of secure communication with the infrastructure are 579 additional costs of this technique. 581 4.3. Origination and Adjacency Protection 583 This scheme requires the same public key infrastructure and origination 584 infrastructure as is needed for Origination Protection It also requires 585 that each adjacency for a BGP speaker be signed (the "predecessor" 586 information) and transmitted along with an AS_PATH. Essentially, each 587 BGP speaker must announce its peers, something that does not currently 588 occur in the BGP protocol. 590 Each BGP speaker must compute one signature for each NLRI in each UPDATE 591 message transmitted and must verify one signature for each NLRI in each 592 UPDATE message received. Each UPDATE message must be separately signed 593 because the mechanism described in [3] includes a sequence number, the 594 Withdrawn Routes and the Unfeasible Route Length fields, so the 595 information to be signed changes with each message. (These fields are 596 protected from outsiders by the peer-peer communication protection and 597 so do not need to be digitally signed. If only the NLRI, 598 ATOMIC_AGGREGATE and predecessor information were signed each time, then 599 the signature might not have to be computed with each new UPDATE 600 message, i.e., AS_PATH changes would not induce new signature 601 computations.) 603 The signed predecessor information in each route must be stored by the 604 recipient indefinitely. Each route received must be verified by 605 comparison to the store of predecessor information previously received 606 in UPDATE messages from all AS sources. 608 4.4. Origination and AS_PATH Protection 610 The operational cost of this scheme is described in detail in [10]. 612 This scheme requires the same public key infrastructure and origination 613 infrastructure as is needed for Origination Protection. 615 For each UPDATE message received, K signatures (where K is the level of 616 protection desired from consecutive faulty routers) must be verified. 618 For each UPDATE message transmitted, one signature must be computed for 619 each NLRI per recipient. As discussed before, prevention of cut and 620 paste attacks requires that the signature include the recipient, so 621 computing one signature per AS_PATH and NLRI announced is insufficient. 623 The signatures contained in an UPDATE must be retained for all received 624 routes in case the route is ever chosen and announced to the peers. 625 This increases the size of the routing tables. 627 For efficiency in situations where route flapping is occuring, withdrawn 628 AS_PATHs and their signatures could be retained. This would mean that 629 new announcements of flapped routes still retained would not require new 630 signature verifications. 632 4.5. Rely on Registries 634 The cost of relying on registries would vary considerably depending on 635 the protection provided to the information in storage and in transit. 636 Any latency, above that caused by the use of cryptography, would depend 637 on the mechanism used to transmit the registry information (e.g., 638 anything from frequent complete download to real-time query and 639 response). 641 5. Security Considerations 643 This entire memo is about security considerations. 645 6. References 647 [1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 648 RFC1771, March 1995. 650 [2] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work 651 in progress, November 2001. available as 652 <> at Internet-Draft shadow sites. 654 [2] B. Smith and J.J. Garcia-Luna-Aceves, "Securing the Border Gateway 655 Routing Protocol", Proc. Global Internet'96, London, UK, 20-21 656 November 1996. 658 [3] Bruce Schneier. Applied Cryptography Protocols, Algorithms, and 659 Source Code in C, John Wiley & Sons, Inc 1994. 661 [4] John Moy, "OSPF Version 2", RFC 1583, March 1994. 663 [5] C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange, 664 "Routing Policy System Security", RFC 2725, December, 1999. 666 [7] S. Kent and R.Atkinson, "Security Architecture for the Internet 667 Protocol", RFC2401, November 1998. 669 [8] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature 670 Option", RFC2385, August 1998. 672 [10] S.Kent, C.Lynn, and K. Seo, "Secure Border Gateway Protocol 673 (Secure-BGP)", IEEE Journal on Selected Areas in Communications, 674 Vol. 18, No. 4, April 2000, pp. 582-592. 676 [10] S. Kent, C. Lynn, J. Mikkelson, and K. Seo, "Secure Border Gateway 677 Protocol (S-BGP) -- Real World Performance and Deployment Issues", 678 Proceedings of the IEEE Network and Distributed System Security 679 Symposium (NDSS 2000), February 2000. 681 7. Author's Address 683 Sandra Murphy 684 Network Associates, Inc. 685 NAI Labs 686 3060 Washington Road 687 Glenwood, MD 21738 688 EMail: Sandy@tislabs.com 689 A. Appendix A - Vulnerabilities and Risks 691 Each message introduces certain different vulnerabilities and risks: 693 A.1. OPEN 695 Because receipt of a new OPEN message in the Established state will 696 cause the close of the BGP peering session and thereby induce the 697 release of all resources and deletion of all associated routes, the 698 ability to spoof this message can lead to a severe disruption of 699 routing. 701 A.2. KEEPALIVE 703 Receipt of a KEEPALIVE message when the peering connection is in the 704 OpenSent state can lead to a failure to establish a connection. The 705 ability to spoof this message is a vulnerability. To exploit this 706 vulnerability deliberately, the KEEPALIVE must be carefully timed in the 707 sequence of messages exchanged between the peers; otherwise, it causes 708 no damage. 710 A.3. NOTIFICATION 712 Receipt of a NOTIFICATION message will cause the close of the BGP 713 peering session and thereby induce the release of all resources and 714 deletion of all associated routes. Therefore, the ability to spoof this 715 message can lead to a severe disruption of routing. 717 A.4. UPDATE 719 The Update message carries the routing information. The ability to 720 spoof any part of this message can lead to a disruption of routing. 722 A.4.1. Unfeasible Routes Length, Total Path Attribute Length 724 There is a vulnerability arising from the ability to modify these 725 fields. If a length is modified, the message is not likely to parse 726 properly, resulting in an error, the transmission of a NOTIFICATION 727 message and the close of the connection. As a true BGP speaker is 728 always able to close a connection at any time, this vulnerability 729 represents an additional risk only when the source is a non-BGP speaker, 730 i.e., it presents no additional risk from BGP sources. 732 A.4.2. Withdrawn Routes 734 An outsider could cause the elimination of existing legitimate routes by 735 forging or modifying this field. An outsider could also cause the 736 elimination of reestablished routes by replaying this withdrawal 737 information from earlier packets. 739 A BGP speaker could "falsely" withdraw feasible routes using this field. 740 However, as the BGP speaker is authoritative for the routes it will 741 announce, it is allowed to withdraw any previously announced routes that 742 it wants. As the receiving BGP speaker will only withdraw routes 743 associated with the sending BGP speaker, there is no opportunity for a 744 BGP speaker to withdraw another BGP speaker's routes. Therefore, there 745 is no additional risk from BGP peers via this field. 747 A.4.3. Path Attributes 749 The path attributes present many different vulnerabilities and risks. 751 Attribute Flags, Attribute Type Codes, Attribute Length 753 A BGP peer or an outsider could modify the attribute length or attribute 754 type (flags and type codes) so they did not reflect the attribute values 755 that followed. If the flags were modified, the flags and type code 756 could become incompatible (i.e., a mandatory attribute marked as 757 partial), or a optional attribute could be interpreted as a mandatory 758 attribute or vice versa. If the type code were modified, the attribute 759 value could be interpreted as if it were the data type and value of a 760 different attribute. 762 The most likely result from modifying the attribute length, flags, or 763 type code would be a parse error of the UPDATE message. A parse error 764 would cause the transmission of a NOTIFICATION message and the close of 765 the connection. As a true BGP speaker is always able to close a 766 connection at any time, this vulnerability represents an additional risk 767 only when the source is an outsider, i.e., it presents no additional 768 risk from a BGP peer. 770 ORIGIN 772 This field indicates whether the information was learned from IGP or EGP 773 information. If the route is used in inter-AS multicast routing, a 774 value of INCOMPLETE may be used. This field is not used in making 775 routing decisions, so there are no vulnerabilities arising from this 776 field, either from BGP peers or outsiders. 778 AS_PATH 780 A BGP peer or outsider could announce an AS_PATH that was not accurate 781 for the associated NLRI. Forwarding for the NLRI associated with the 782 AS_PATH could potentially be induced to follow a sub-optimal path, a 783 path that did not follow some intended policy, or even a path that would 784 not forward the traffic. If the path would not forward the traffic, the 785 NLRI would become unreachable for that portion of the Internet that 786 accepted the false path. If much traffic is mis-directed, some routers 787 and transit networks along the announced route could become flooded with 788 the mis-directed traffic. 790 It is not clear how far an inaccurate AS_PATH could deviate from the 791 true AS_PATH. It may be that the first AS in the AS_PATH, at least, 792 must be a legal hop. The RFC states that a BGP speaker prepends its own 793 AS to an AS_PATH before announcing it to a neighbor. If the BGP speaker 794 must prepend its own AS, then a BGP speaker that produced a bogus 795 AS_PATH could end up receiving the traffic for the associated NLRI. 796 This could be desirable if the error was deliberate and the intent was 797 to receive traffic that would not otherwise be received. Receiving the 798 mis-routed traffic could be undesirable for the faulty BGP speaker if it 799 were not prepared to handle the extra (mis-routed) traffic. So, 800 requiring a BGP peer to prepend its own AS to the AS_PATH, might 801 encourage or discourage it from inventing an arbitrary AS_PATH, 802 depending on its resources and intent. 804 If BGP peers need not prepend its own AS (or implementations do not 805 ensure that this is done), then a malicious BGP peer could announce a 806 path that begins with the AS of any BGP speaker with little impact on 807 itself. 809 Whether such an arbitrary AS_PATH is a vulnerability would depend on 810 whether BGP implementations check the AS_PATH (to see if the first AS is 811 the neighbor) and would catch the error. If there are legitimate 812 situations in which a BGP speaker could pass an AS_PATH to a neighbor 813 without putting its own AS at the head of the AS_PATH, then there is no 814 way for implementations to detect totally bogus AS_PATHs. 816 Originating Routes 818 A special case of announcing a false AS_PATH occurs when the AS_PATH 819 advertises a direct connection to a specific network address. An BGP 820 peer or outsider could disrupt routing to the network(s) listed in the 821 NLRI field by falsely advertising a direct connection to the network. 822 The NLRI would become unreachable to the portion of the network that 823 accepted this false route, unless the ultimate AS on the AS_PATH 824 undertook to tunnel the packets it was forwarded for this NLRI on toward 825 their true destination AS by a valid path. But even when the packets 826 are tunneled to the correct destination AS, the route followed may not 827 be optimal or may not follow the intended policy. Additionally, routing 828 for other networks in the Internet could be affected if the false 829 advertisement fragmented an aggregated address block, forcing the 830 routers to handle (issue UPDATES, store, manage) the multiple fragments 831 rather than the single aggregate. False originations for multiple 832 addresses can result in routers and transit networks along the announced 833 route to become flooded with mis-directed traffic. 835 NEXT_HOP 837 The NEXT_HOP attribute defines the IP address of the border router that 838 should be used as the next hop when forwarding the NLRI listed in the 839 UPDATE message. If the recipient is an external peer, then the 840 recipient and the NEXT_HOP address must share a subnet. It is clear 841 that an outsider modifying this field could disrupt the forwarding of 842 traffic between the two AS's. 844 In the case that the recipient of the message is an external peer of an 845 AS and the route was learned from another peer AS (this is one of two 846 forms of "third party" NEXT_HOP), then the BGP speaker advertising the 847 route has the opportunity to direct the recipient to forward traffic to 848 a BGP speaker at the NEXT_HOP addresss. This affords the opportunity to 849 direct traffic at a router that may not be able to continue forwarding 850 the traffic. It is unclear whether this would also require the 851 advertising BGP speaker to construct an AS_PATH mentioning the NEXT_HOP 852 external peer's AS. 854 MULTI_EXIT_DISC 856 The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted 857 between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an 858 inter-AS peer may be propagated within an AS, it may not be propagated 859 to other AS's. Consequently, this field is only used in making routing 860 decisions internal to one AS. Modifying this field, whether by an 861 outsider or an BGP peer, could influence routing within an AS to be sub- 862 optimal, but the effect should be limited in scope. 864 LOCAL_PREF 866 The LOCAL_PREF attribute must be included in all messages with internal 867 peers and excluded from messages with external peers. Consequently, 868 modification of the LOCAL_PREF could effect the routing process within 869 the AS only. Note that there is no requirement in the BGP RFC that the 870 LOCAL_PREF be consistent among the internal BGP speakers of an AS. As 871 BGP peers are free to choose the LOCAL_PREF as they wish, modification 872 of this field is a vulnerability with respect to outsiders only. 874 ATOMIC_AGGREGATE 876 The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way 877 has received a more specific and a less specific route to the NLRI and 878 installed the aggregated route. This route cannot be de-aggregated 879 because it is not certain that the route to more specific prefixes will 880 follow the listed AS_PATH. Consequently, BGP speakers receiving a route 881 with ATOMIC_AGGREGATE are restricted from making the NLRI any more 882 specific. Removing the ATOMIC_AGGREGATE attribute would remove the 883 restriction, possibly causing traffic intended for the more specific 884 NLRI to be routed incorrectly. Adding the ATOMIC_AGGREGATE attribute 885 when no aggregation was done would have little effect, beyond 886 restricting the un-aggregated NLRI from being made more specific. This 887 vulnerability exists whether the source is a BGP peer or an outsider. 889 AGGREGATOR 891 This field may be included by a BGP speaker who has computed the routes 892 represented in the UPDATE message from aggregation of other routes. The 893 field contains the AS number and IP address of the last aggregator of 894 the route. It is not used in making any routing decisions, so it does 895 not represent a vulnerability. 897 A.4.4. NLRI 899 By modifying or forging this field, either an outsider or BGP peer 900 source could cause disruption of routing to the announced network, 901 overwhelm a router along the announced route, cause data loss when the 902 announced route will not forward traffic to the announced network, route 903 traffic by a sub-optimal route, etc.