idnits 2.17.1 draft-ietf-idr-bgp-vuln-00.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 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 2003) is 7615 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) -- Looks like a reference, but probably isn't: 'RFC2119' on line 33 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2401 (ref. '4') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2385 (ref. '5') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 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-ietf-idr-bgp-vuln-00.txt June 2003 6 BGP Security Vulnerabilities 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 Specification of Requirements 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC2119 [RFC2119]. 34 Abstract 36 BGP, along with a host of other infrastructure protocols designed before 37 the Internet environment became perilous, was originally designed with 38 little consideration for protection of the information it carries. 39 There are no mechanisms internal to the BGP protocol to protect against 40 attacks that modify, delete, forge, or replay data, any of which has the 41 potential to disrupt overall network routing behavior. 43 This internet draft discusses some of the security issues with BGP 44 routing data dissemination. This internet draft does not discuss 45 security issues with forwarding of packets. 47 Table of Contents 49 Status of this Memo .............................................. 1 50 Specification of Requirements .................................... 1 51 Abstract ......................................................... 1 52 1 Introduction .................................................... 4 53 2 Attacks ......................................................... 6 54 3 Vulnerabilities and Risks ....................................... 8 55 3.1 Vulnerabilities in BGP messages ............................... 8 56 3.1.1 Message Header .............................................. 8 57 3.1.2 OPEN ........................................................ 9 58 3.1.3 KEEPALIVE ................................................... 10 59 3.1.4 NOTIFICATION ................................................ 10 60 3.1.5 UPDATE ...................................................... 10 61 3.1.5.1 Unfeasible Routes Length, Total Path Attribute Length ..... 10 62 3.1.5.2 Withdrawn Routes .......................................... 11 63 3.1.5.3 Path Attributes ........................................... 11 64 Attribute Flags, Attribute Type Codes, Attribute Length .......... 11 65 ORIGIN ........................................................... 11 66 AS_PATH .......................................................... 12 67 Originating Routes ............................................... 12 68 NEXT_HOP ......................................................... 13 69 MULTI_EXIT_DISC .................................................. 13 70 LOCAL_PREF ....................................................... 13 71 ATOMIC_AGGREGATE ................................................. 14 72 AGGREGATOR ....................................................... 14 73 3.1.5.4 NLRI ...................................................... 14 74 3.2 Vulnerabilities through Other Protocols ....................... 15 75 3.2.1 TCP messages ................................................ 15 76 3.2.1.1 TCP SYN ................................................... 15 77 3.2.1.2 TCP SYN ACK ............................................... 15 78 3.2.1.3 TCP ACK ................................................... 15 79 3.2.1.4 TCP RST/FIN/FIN-ACK ....................................... 16 80 3.2.1.5 DoS and DDos .............................................. 16 81 3.2.2 Other supporting protocols .................................. 16 82 3.2.2.1 Manual stop ............................................... 16 83 3.2.2.2 Timer events .............................................. 16 84 4 Security Considerations ......................................... 17 85 4.1 Residual Risk ................................................. 17 86 4.2 Operational Protections ....................................... 17 87 5 References ...................................................... 19 88 6 Author's Address ................................................ 19 89 1. Introduction 91 The inter-domain routing protocol BGP was created when the Internet 92 environment had not yet reached the present contentious state. 93 Consequently, the BGP protocol was not designed with protection against 94 deliberate or accidental errors causing disruptions of routing behavior. 96 We here discuss the vulnerabilities of BGP, based on the BGP 97 specification [1]. Readers are expected to be familiar with the BGP RFC 98 and the behavior of BGP. 100 It is clear that the Internet is vulnerable to attack through its 101 routing protocols and BGP is no exception. Faulty, misconfigured or 102 deliberately malicious sources can disrupt overall Internet behavior by 103 injecting bogus routing information into the BGP distributed routing 104 database (by modifying, forging, or replaying BGP packets). The same 105 methods can also be used to disrupt local and overall network behavior 106 by breaking the distributed communication of information between BGP 107 peers. The sources of bogus information can be either outsiders or true 108 BGP peers. 110 Cryptographic authentication of the peer-peer communication is not an 111 integral part of the BGP protocol. As a TCP/IP protocol, BGP is subject 112 to all the TCP/IP attacks, like IP spoofing, session stealing, etc. Any 113 outsider can inject believable BGP messages into the communication 114 between BGP peers and thereby inject bogus routing information or break 115 the peer to peer connection. Any break in the peer to peer 116 communication has a ripple effect on routing that can be wide spread. 117 Furthermore, outsider sources can also disrupt communications between 118 BGP peers by breaking their TCP connection with spoofed packets. 119 Outsider sources of bogus BGP information can reside anywhere in the 120 world. 122 Consequently, the current BGP specification requires that a BGP 123 implementation must support the authentication mechanism specified in 124 [5]. However, the requirement for support of that authentication 125 mechanism cannot ensure that the mechanism is configured for use. The 126 mechanism of [5] is based on a pre-installed shared secret; it does not 127 have the capability of IPSEC [4] to agree on a shared secret 128 dynamically. Consequently, the use of [5] msut be a deliberate 129 decision, not an automatic feature or default. 131 The current BGP specification also allows for implementations that would 132 accept connections from "un-configured peers" ([1] Section 8), however, 133 the specification is not clear as to what an unconfigured peer might be 134 or how the protections of [5] would apply in such a case. It is 135 therefore not possible to include an analysis of the security issues of 136 this feature. When a specification is released that describes this 137 feature more fully, a security analysis should be part of that same 138 specification. 140 BGP speakers themselves can inject bogus routing information, either by 141 masquerading as any other legitimate BGP speaker, or by distributing 142 unauthorized routing information as themselves. Historically, 143 misconfigured and faulty routers have been responsible for widespread 144 disruptions in the Internet. The legitimate BGP peers have the context 145 and information to produce believable bogus routing information and 146 therefore have the opportunity to cause great damage. The cryptographic 147 protections of [5] and operational protections cannot exclude the bogus 148 information arising from a legitimate peer. The risk of disruptions 149 caused by legitimate BGP speakers is real and cannot be ignored. 151 Bogus routing information can have many different effects on routing 152 behavior. If the bogus information removes routing information for a 153 particular network, that network can become unreachable for the portion 154 of the Internet that accepts the bogus information. If the bogus 155 information changes the route to a network, then packets destined for 156 that network may be forwarded by a sub-optimal path, or a path that does 157 not follow the expected policy, or a path that will not forward the 158 traffic. As a consequence, traffic to that network could be delayed by 159 a longer than necessary path. The network could become unreachable from 160 areas where the bogus information is accepted. Traffic might also be 161 forwarded along a path that permits some adversary a view of the data. 162 If the bogus information makes it appear that an autonomous system 163 originates a network when it does not, then packets for that network may 164 not be deliverable for the portion of the Internet that accepts the 165 bogus information. A false announcement that an autonomous systems 166 originates a network may also fragment aggregated address blocks in 167 other parts of the Internet and cause routing problems for other 168 networks. 170 The damage that might result from these attacks are: 172 starvation: data traffic destined for a node is forwarded to a part 173 of the network that cannot deliver it, 175 network congestion: more data traffic is forwarded through some 176 portion of the network than would otherwise need to carry the 177 traffic, 178 blackhole: large amounts of traffic are directed to be forwarded 179 through one router that cannot handle the increased level of 180 traffic and drops many/most/all packets, 182 delay: data traffic destined for a node is forwarded along a path 183 that is in some way inferior to the path it would otherwise take, 185 looping: data traffic is forwarded along a path that loops, so that 186 the data is never delivered, 188 eavesdrop: data traffic is forwarded through some router or network 189 that would otherwise not see the traffic, affording an opportunity 190 to see the data, 192 partition: some portion of the network believes that it is 193 partitioned from the rest of the network when it is not, 195 cut: some portion of the network believes that it has no route to 196 some network that is in fact connected, 198 churn: the forwarding in the network changes at a rapid pace, 199 resulting in large variations in the data delivery patterns (and 200 adversely affecting congestion control techniques), 202 instability: BGP become unstable so that convergence on a global 203 forwarding state is not achieved, and 205 overload: the BGP messages themselves become a significant portion 206 of the traffic the network carries. 208 resource exhaustion: the BGP messages themselves cause exhaustion 209 of critical router resources, such as table space. 211 These consequences can fall exclusively on one end system prefix or may 212 effect the operation of the network as a whole. 214 2. Attacks 216 The BGP protocol, in and of itself, is subject to the following attacks 217 (list taken from the IAB Internet-Draft providing guideline for the 218 security considerations section of Internet-Drafts [8]): 220 eavesdropping: The routing data carried in BGP is carried in 221 cleartext, so eavesdropping is a possible attack against routing 222 data confidentiality. (Routing data confidentiality is not a 223 common requirement.) 225 replay: BGP does not provide for replay protection of its messages. 227 message insertion: BGP does not provide protection against 228 insertion of messages. However, because BGP uses TCP, when the 229 connection is fully established, message insertion by an outsider 230 would require accurate sequence number prediction (not entirely out 231 of the question, but more difficult with mature TCP 232 implementations) or session stealing attacks. 234 message deletion: BGP does not provide protection against deletion 235 of messages. Again, more difficult against a mature TCP 236 implementation but not entirely out of the question 238 message modification: BGP does not provide protection against 239 modification of messages. A modification that did not change the 240 length of the TCP payload would in general not be detectable. 242 man-in-the-middle: BGP does not provide protection agains man-in- 243 the-middle attacks. As BGP does no peer entity authentication, a 244 man-in-the-middle attack is childs-play. 246 denial of service: While bogus routing data can present a denial 247 of service attack on the end systems that are trying to transmit 248 data through the network and on the network infrastructure itself, 249 certain bogus information can represent a denial of service on the 250 BGP routing protocol. For example, advertising large numbers of 251 more specific routes (longer prefixes) can cause BGP traffic and 252 router table size to increase, even explode. 254 The mandatory-to-support mechanism of [5] will counter the message 255 insertion, deletion, and modification, man-in-the-middle attacks and the 256 denial of service attacks from outsiders. The use of [5] does not 257 protect against eavesdropping attacks, but routing data confidentiality 258 is not a goal of BGP. The mechanism of [5] does not protect against 259 replay attacks, so the only protection against replay is provided by the 260 TCP sequence number processing. The mechanism of [5] cannot protect 261 against bogus routing information originating with an insider. A replay 262 attack could be mounted against a BGP connection protected with [5] but 263 only in very carefully timed circumstances. 265 3. Vulnerabilities and Risks 267 The risks in BGP arise from three fundamental vulnerabilities: 269 BGP has no internal mechanism that provides strong protection of 270 the integrity, freshness and peer entity authenticity of the 271 messages in peer-peer BGP communications. 273 no mechanism has been specified within BGP to validate the 274 authority of an AS to announce NLRI information. 276 no mechanism has been specified within BGP to ensure the 277 authenticity of the path attributes announced by an AS. 279 The first fundamental vulnerability motivated the mandated support of 280 [5] in the BGP specification. When that is employed, message integrity 281 and peer entity authentication is provided. The mechanism of [5] 282 assumes that the MD5 algorithm is secure and that the shared secret is 283 protected and chosen to be difficult to guess. 285 3.1. Vulnerabilities in BGP messages 287 There are four different BGP message types - OPEN, KEEPALIVE, 288 NOTIFICATION, and UPDATE. This section contains a discussion of the 289 vulnerabilities arising from each message and the ability of outsiders 290 or BGP peers to exploit the vulnerabilities. To summarize, outsiders 291 can use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the 292 BGP peer-peer connections and can use bogus UPDATE messages to disrupt 293 routing. Outsiders can also disrupt BGP peer-peer connections by 294 inserting bogus TCP packets. BGP peers themselves are permitted to 295 break peer-peer connections at any time, and so they cannot be said to 296 be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages. However, 297 BGP peers can disrupt routing by issuing bogus UPDATE messages. In 298 particular, bogus ATOMIC_AGGREGATE, NEXT_HOP and AS_PATH attributes and 299 bogus NLRI in UPDATE messages can disrupt routing. 301 Each message introduces certain different vulnerabilities and risks. 303 3.1.1. Message Header 305 Event 21: Each BGP message starts with a standard header. In all cases, 306 syntactic errors in the message header will cause the BGP speaker to 307 close the connection, release all associated BGP resources, delete all 308 routes learned through that connection and run its decision process to 309 decide on new routes. 311 3.1.2. OPEN 313 Event 19: Receipt of an OPEN message in state Connect, Active or 314 Established will cause the cause the BGP speaker to bring down the 315 connection, release all associated BGP resources, delete all associated 316 routes, run its decision process and cause the state to return to Idle. 317 The deletion of routes can cause a cascading effect of routing changes 318 propogating through other peers. Also, optionally, an implementation 319 specific peer oscillation damping may be performed. The peer 320 oscillation damping process can affect how soon the connection can be 321 restarted. In state OpenSent, the arrival of an OPEN message will cause 322 the BGP speaker to transition to the OpenConfirm state. The later 323 arrival of the legitimate peer's OPEN message will lead the BGP speaker 324 to declare a connection collision. The collision detection procedure 325 may cause the legitimate connection to be dropped. Consequently, the 326 ability to spoof this message can lead to a severe disruption of routing 327 over a wide area. 329 Event 20: If an OPEN message arrives when the OpenDelay timer is running 330 when the connection is in state OpenSent or Established, the BGP speaker 331 will bring down the connection, release all associated BGP resources, 332 delete all associated routes, run its decision process and cause the 333 state to return to Idle. The deletion of routes can cause a cascading 334 effect of routing changes propogating through other peers. Also, 335 optionally, an implementation specific peer oscillation damping may 336 performed. The peer oscillation damping process can affect how soon the 337 connection can be restarted. However, as the OpenDelay timer should 338 never be running in the state OpenSent, this could only be caused by an 339 error in the implementation (which is why the error code is "Finite 340 State Machine Error"). It would be difficult, if not impossible, for an 341 outsider to induce this error. 343 Event 22: Errors in the OPEN message (e.g., unacceptable Hold state, 344 malformed Optional Parameter, unsupported version, etc.) will cause the 345 BGP speaker to bring down the connection, release all associated BGP 346 resources, delete all associated routes, run its decision process and 347 cause the state to return to Idle. The deletion of routes can cause a 348 cascading effect of routing changes propogating through other peers. 349 Also, optionally, an implementation specific peer oscillation damping 350 may performed. The peer oscillation damping process can affect how soon 351 the connection can be restarted. Consequently, the ability to spoof 352 this message can lead to a severe disruption of routing over a wide 353 area. 355 3.1.3. KEEPALIVE 357 Event 26: Receipt of a KEEPALIVE message when the peering connection is 358 in the Connect, Active, and OpenSent states would cause the BGP speaker 359 to transition to the Idle state and fail to establish a connection. The 360 ability to spoof this message is a vulnerability. To exploit this 361 vulnerability deliberately, the KEEPALIVE must be carefully timed in the 362 sequence of messages exchanged between the peers; otherwise, it causes 363 no damage. 365 3.1.4. NOTIFICATION 367 Event 25: Receipt of a NOTIFICATION message in any state will cause the 368 BGP speaker to bring down the connection, release all associated BGP 369 resources, delete all associated routes, run its decision process and 370 cause the state to return to Idle. The deletion of routes can cause a 371 cascading effect of routing changes propogating through other peers. 372 Also, optionally, an implementation specific peer oscillation damping 373 may performed. The peer oscillation damping process can affect how soon 374 the connection can be restarted. Consequently, the ability to spoof 375 this message can lead to a severe disruption of routing over a wide 376 area. 378 Event 24: A NOTIFICATION message carrying an error code of "Version 379 Error" behaves the same as in Event 25, with the exception that the 380 optional peer oscillation damping is not performed (in states Connect 381 and Active, only when the OpenDelay timer is running). The damage 382 caused is therefore one small bit less, in that restarting the 383 connection is not affected. 385 3.1.5. UPDATE 387 Event 27: The Update message carries the routing information. The 388 ability to spoof any part of this message can lead to a disruption of 389 routing. 391 3.1.5.1. Unfeasible Routes Length, Total Path Attribute Length 393 There is a vulnerability arising from the ability to modify these 394 fields. If a length is modified, the message is not likely to parse 395 properly, resulting in an error, the transmission of a NOTIFICATION 396 message and the close of the connection (see Event 28, below). As a 397 true BGP speaker is always able to close a connection at any time, this 398 vulnerability represents an additional risk only when the source is not 399 the configured BGP peer, i.e., it presents no additional risk from BGP 400 sources. 402 3.1.5.2. Withdrawn Routes 404 An outsider could cause the elimination of existing legitimate routes by 405 forging or modifying this field. An outsider could also cause the 406 elimination of reestablished routes by replaying this withdrawal 407 information from earlier packets. 409 A BGP speaker could "falsely" withdraw feasible routes using this field. 410 However, as the BGP speaker is authoritative for the routes it will 411 announce, it is allowed to withdraw any previously announced routes that 412 it wants. As the receiving BGP speaker will only withdraw routes 413 associated with the sending BGP speaker, there is no opportunity for a 414 BGP speaker to withdraw another BGP speaker's routes. Therefore, there 415 is no additional risk from BGP peers via this field. 417 3.1.5.3. Path Attributes 419 The path attributes present many different vulnerabilities and risks. 421 Attribute Flags, Attribute Type Codes, Attribute Length 423 A BGP peer or an outsider could modify the attribute length or attribute 424 type (flags and type codes) so they did not reflect the attribute values 425 that followed. If the flags were modified, the flags and type code 426 could become incompatible (i.e., a mandatory attribute marked as 427 partial), or a optional attribute could be interpreted as a mandatory 428 attribute or vice versa. If the type code were modified, the attribute 429 value could be interpreted as if it were the data type and value of a 430 different attribute. 432 The most likely result from modifying the attribute length, flags, or 433 type code would be a parse error of the UPDATE message. A parse error 434 would cause the transmission of a NOTIFICATION message and the close of 435 the connection (see Event 28, below). As a true BGP speaker is always 436 able to close a connection at any time, this vulnerability represents an 437 additional risk only when the source is an outsider, i.e., it presents 438 no additional risk from a BGP peer. 440 ORIGIN 442 This field indicates whether the information was learned from IGP or EGP 443 information. This field is used in making routing decisions, so there 444 is some small vulnerability in being able to affect the receiving BGP 445 speaker's routing decision by modifying this field. 447 AS_PATH 449 A BGP peer or outsider could announce an AS_PATH that was not accurate 450 for the associated NLRI. 452 As it is legitimate for a BGP peer not to verify that a received AS_PATH 453 begins with the AS number of its peer, a malicious BGP peer could 454 announce a path that begins with the AS of any BGP speaker with little 455 impact on itself. This could affect the receiving BGP speaker's 456 decision procedure and choice of installed route. The malicious peer 457 could considerably shorten the AS_PATH, which will increase that route's 458 chances of being chosen, possibly giving the malicious peer access to 459 traffic it would otherwise not receive. The shortened AS_PATH also 460 could result in routing loops, as it does not contain the information 461 needed to prevent loops. 463 It is possible for a BGP speaker to be configured to accept routes with 464 its own AS number in the AS path. Such operational considerations are 465 defined to be "outside the scope" of the BGP specification, but the fact 466 that AS_PATHs can have loops means that implementations cannot 467 automatically reject routes with loops. Each BGP speaker verifies only 468 that its own AS number does not appear in the AS_PATH. 470 Coupled with the ability to use any value for the NEXT_HOP, this gives a 471 malicious BGP speaker considerable control over the path traffic will 472 take. 474 Originating Routes 476 A special case of announcing a false AS_PATH occurs when the AS_PATH 477 advertises a direct connection to a specific network address. An BGP 478 peer or outsider could disrupt routing to the network(s) listed in the 479 NLRI field by falsely advertising a direct connection to the network. 480 The NLRI would become unreachable to the portion of the network that 481 accepted this false route, unless the ultimate AS on the AS_PATH 482 undertook to tunnel the packets it was forwarded for this NLRI on toward 483 their true destination AS by a valid path. But even when the packets 484 are tunneled to the correct destination AS, the route followed may not 485 be optimal or may not follow the intended policy. Additionally, routing 486 for other networks in the Internet could be affected if the false 487 advertisement fragmented an aggregated address block, forcing the 488 routers to handle (issue UPDATES, store, manage) the multiple fragments 489 rather than the single aggregate. False originations for multiple 490 addresses can result in routers and transit networks along the announced 491 route to become flooded with mis-directed traffic. 493 NEXT_HOP 495 The NEXT_HOP attribute defines the IP address of the border router that 496 should be used as the next hop when forwarding the NLRI listed in the 497 UPDATE message. If the recipient is an external peer, then the 498 recipient and the NEXT_HOP address must share a subnet. It is clear 499 that an outsider modifying this field could disrupt the forwarding of 500 traffic between the two AS's. 502 In the case that the recipient of the message is an external peer of an 503 AS and the route was learned from another peer AS (this is one of two 504 forms of "third party" NEXT_HOP), then the BGP speaker advertising the 505 route has the opportunity to direct the recipient to forward traffic to 506 a BGP speaker at the NEXT_HOP address. This affords the opportunity to 507 direct traffic at a router that may not be able to continue forwarding 508 the traffic. A malicious BGP speaker can also use this technique to 509 force another AS to carry traffic it would otherwise not have to carry. 510 In some cases, this could be to the malicious BGP speaker's benefit, as 511 it could cause traffic to be carried long-haul by the victim AS to some 512 other peering point it shared with the victim. 514 MULTI_EXIT_DISC 516 The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted 517 between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an 518 inter-AS peer may be propagated within an AS, it may not be propagated 519 to other AS's. Consequently, this field is only used in making routing 520 decisions internal to one AS. Modifying this field, whether by an 521 outsider or an BGP peer, could influence routing within an AS to be sub- 522 optimal, but the effect should be limited in scope. 524 LOCAL_PREF 526 The LOCAL_PREF attribute must be included in all messages with internal 527 peers and excluded from messages with external peers. Consequently, 528 modification of the LOCAL_PREF could effect the routing process within 529 the AS only. Note that there is no requirement in the BGP RFC that the 530 LOCAL_PREF be consistent among the internal BGP speakers of an AS. As 531 BGP peers are free to choose the LOCAL_PREF as they wish, modification 532 of this field is a vulnerability with respect to outsiders only. 534 ATOMIC_AGGREGATE 536 The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way 537 has aggregated several routes and advertised the aggregate NLRI without 538 the AS_SET formed as usual from the AS's in the aggregated routes' 539 AS_PATHs. BGP speakers receiving a route with ATOMIC_AGGREGATE are 540 restricted from making the NLRI any more specific. Removing the 541 ATOMIC_AGGREGATE attribute would remove the restriction, possibly 542 causing traffic intended for the more specific NLRI to be routed 543 incorrectly. Adding the ATOMIC_AGGREGATE attribute when no aggregation 544 was done would have little effect, beyond restricting the un-aggregated 545 NLRI from being made more specific. This vulnerability exists whether 546 the source is a BGP peer or an outsider. 548 AGGREGATOR 550 This field may be included by a BGP speaker who has computed the routes 551 represented in the UPDATE message from aggregation of other routes. The 552 field contains the AS number and IP address of the last aggregator of 553 the route. It is not used in making any routing decisions, so it does 554 not represent a vulnerability. 556 3.1.5.4. NLRI 558 By modifying or forging this field, either an outsider or BGP peer 559 source could cause disruption of routing to the announced network, 560 overwhelm a router along the announced route, cause data loss when the 561 announced route will not forward traffic to the announced network, route 562 traffic by a sub-optimal route, etc. 564 Event 28: If the UPDATE message is mal-formed (Withdrawn Routes Length, 565 Total Attribute Length, or Attribute Length that are improper, missing 566 mandatory well-known attributes, Attribute Flags that conflict with the 567 Attribute Type Codes, syntactic errors in the ORIGIN, NEXT_HOP or 568 AS_PATH, etc.), then the BGP speaker will bring down the connection, 569 release all associated BGP resources, delete all associated routes, run 570 its decision process and cause the state to return to Idle. The 571 deletion of routes can cause a cascading effect of routing changes 572 propogating through other peers. Also, optionally, an implementation 573 specific peer oscillation damping may be performed. The peer 574 oscillation damping process can affect how soon the connection can be 575 restarted. Consequently, the ability of an outsider to spoof this 576 message could cause wide-spread disruption of routing. As a BGP speaker 577 has the authority to close a connection whenver it wants, this message 578 gives BGP speakers no opportunity to cause damage than they already had. 580 3.2. Vulnerabilities through Other Protocols 582 3.2.1. TCP messages 584 BGP runs over TCP, listening on port 179. Therefore, BGP is subject to 585 attack through attacks on TCP. 587 3.2.1.1. TCP SYN 589 SYN flooding: BGP is as subject to the effects on the TCP implementation 590 of SYN flooding attacks as other protocols, and must rely on the 591 implementation's protections against this attack. 593 Event 14: If an attacker were able to send a SYN to the BGP speaker, 594 then the legitimate peer's SYN would appear to be a second connection. 595 If the attacker were able to continue with a sequence of packets 596 resulting in a BGP connection (guessing the BGP speaker's choice for 597 sequence number on the SYN ACK, for example), then, the attacker's 598 connection and the legitimate peer's connection would appear to be a 599 connection collision. Depending on the outcome of the collision 600 detection (i.e., the attacker chose a BGP identifier so as to win the 601 race), the legitimate peer's true connection could be destroyed. The 602 use of [5] will counter this attack. 604 3.2.1.2. TCP SYN ACK 606 Event 16: If an attacker were able to respond to a BGP speaker's SYN 607 before the legitimate peer, then the legitimate peer's SYN-ACK would 608 receive a empty ACK reply, causing the legitimate peer to issue a RST 609 that would break the connection. The BGP speaker would bring down the 610 connection, release all associated BGP resources, delete all associated 611 routes and run its decision process. This attack requires that the 612 attacker be able to predict the sequence number used in the SYN. The 613 use of [5] will counter this attack. 615 This attack has no corollary from the legitimate BGP peer. 617 3.2.1.3. TCP ACK 619 Event 17: If an attacker were able to spoof an ACK at the appropriate 620 time, then the BGP speaker would consider the connection complete, send 621 an OPEN (Event 17) and transition to the OpenSent state. The arrival of 622 the legitimate peer's ACK would not be delivered to the BGP process, as 623 it would look like a duplicate packet. This message, then, presents no 624 particular vulnerability to BGP. 626 3.2.1.4. TCP RST/FIN/FIN-ACK 628 Event 18: If an attacker were able to spoof a RST, the BGP speaker would 629 bring down the connection, release all associated BGP resources, delete 630 all associated routes and run its decision process. If an attacker were 631 able to spoof a FIN, then data could still be transmitted, but any 632 attempt to receive would receive a notification that the connection is 633 closing. In most cases, this results in the connection being placed in 634 an Idle state, but if the connection is in the OpenSent state at the 635 time, the connection returns to an Active state. Spoofing a RST in this 636 situation requires an attacker to guess a sequence number that is in the 637 proper half of the sending window, generally an easier task than 638 guessing the exact sequence number so as to spoof a FIN. The use of [5] 639 will counter this attack. 641 3.2.1.5. DoS and DDos 643 Because the packet directed to TCP port 179 are passed to the BGP 644 process, that potentially resides on a slower processor in the router, 645 flooding a router with TCP port 179 packets is an avenue for DoS attacks 646 against the router. No BGP protocol mechanism can defeat such attacks; 647 other mechanisms must be employed. 649 3.2.2. Other supporting protocols 651 3.2.2.1. Manual stop 653 Event 2: A manual stop event causes the BGP speaker to bring down the 654 connection, release all associated BGP resources, delete all associated 655 routes and run its decision process. If the mechanism by which a BGP 656 speaker was informed of a manual stop were not carefully protected, the 657 BGP connection could be destroyed by an attacker. Consequently, BGP 658 security is secondarily dependent on the security of whatever protocols 659 are used to operate the platform. 661 3.2.2.2. Timer events 663 Events 9-13: The Keepalive, Hold, and Open Delay timers are critical to 664 BGP operation. For example, if the Hold timer value were changed, the 665 remote peer might consider the connection unresponsive and bring the 666 connection down, releasing resources, deleting associated routes, etc. 667 Consequently, BGP security is secondarily dependent on the security of 668 the protocols by which the platform is managed and configured. 670 4. Security Considerations 672 This entire memo is about security, describing an analysis of the 673 vulnerabilities that exist in the BGP protocol. 675 Use of the mandatory-to-support mechanisms of [5] counter the message 676 insertion, deletion, and modification attacks and man-in-the-middle 677 attacks from outsiders. If routing data confidentiality were desired 678 (there being some contraversy as to whether that is a desirable security 679 service), the use of IPSEC ESP could provide that service. 681 4.1. Residual Risk 683 As cryptographic-based mechanisms, both [5] and IPSEC assume that the 684 cyrptographic algorithms are secure, that secrets used are protected 685 from exposure and are chosen well so as not to be guessable, that the 686 platforms are securely managed and operated to prevent break-ins, etc. 688 These mechanisms do not prevent attacks that arise from a router's 689 legitimate BGP peers. There are several possible solutions to prevent a 690 BGP speaker from inserting bogus information in its advertisements to 691 its peers, i.e., from mounting an attack on a network's origination or 692 AS-PATH. 694 (1) Origination Protection: sign the originating AS. 696 (2) Origination and Adjacency Protection: sign the originating AS and 697 predecessor information ([2]) 699 (3) Origination and Route Protection: sign the originating AS, and 700 nest signatures of AS_PATHs to the number of consecutive bad 701 routers you want to prevent from causing damage. ([6]) 703 (4) Filtering: rely on a registry to verify the AS_PATH and NLRI 704 originating AS ([3]). 706 Filtering is in use near some customer attachment points, but is not 707 effective near the Internet center. The other mechanisms are still 708 controversial and are not yet in common use. 710 4.2. Operational Protections 712 The primary usage of BGP is as a means to provide reachability 713 information to Autonomous Systems (AS) and to distribute external 714 reachability internally within an AS. BGP is the routing protocol used 715 to distribute global routing information in the Internet. BGP is 716 therefore used by all major Internet Service Providers (ISP) and many 717 smaller providers and other organizations. 719 The role which BGP plays in the Internet puts BGP implementations in 720 unique conditions and places unique security requirements on BGP. BGP 721 is operated over interprovider interfaces in which traffic levels push 722 the state of the art in specialized packet forwarding hardware and 723 exceed the performace capabilities of hardware implementation of 724 decryption by many orders of magnitude. The capability of an attacker 725 using a single workstation with high speed interface to generate false 726 traffic for denial of service (DoS) far exceeds the capability of 727 software based decryption or appropriately priced cryptographic hardware 728 to detect the false traffic. One means to protect the network elements 729 from DoS attacks under such conditions is to use packet based filtering 730 techniques based on relatively simple inspections of packets. As a 731 result, for an ISP carrying large volumes of traffic, the ability to 732 packet filter on the basis of port numbers is an important protection 733 against DoS attacks, and a necessary adjunct to cryptographic strength 734 in encapsulation. 736 Current practice in ISP operation is to use certain common filtering 737 techniques to reduce the exposure to attacks from outside the ISP. To 738 protect Internal BGP (IBGP) sessions, filters are applied at all borders 739 to an ISP network which remove all traffic destined for addresses of 740 network elements internal addresses (typically contained within a single 741 prefix) and the BGP port number (179). Packets from within an ISP are 742 not forwarded from an internal interface to the BGP speaker's address on 743 which External BGP (EBGP) sessions are supported, or to a peer's EBGP 744 address if the BGP port number is found. With appropriate consideration 745 in router design, in the event of failure of a BGP peer to provide the 746 equivalent filtering, the risk of compromise can be limited to the 747 peering session on which filtering is not performed by the peer or the 748 interface or line card on which the peering is supported. There is 749 substantial motivation and little effort for ISPs to maintain such 750 filters. 752 These operational practices can considerably raise the difficulty for an 753 outsider to launch a DoS attack against an ISP. Prevented from 754 injecting sufficient traffic from outside a network to effect a DoS 755 attack, the attacker would have to undertake much more difficult tasks, 756 such as compromise of the ISP network elements or undetected tapping 757 into physical media. 759 5. References 761 [1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work 762 in progress, March 2003. available as 763 <> at Internet-Draft shadow sites. 765 [2] B. Smith and J.J. Garcia-Luna-Aceves, "Securing the Border Gateway 766 Routing Protocol", Proc. Global Internet'96, London, UK, 20-21 767 November 1996. 769 [3] C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange, 770 "Routing Policy System Security", RFC 2725, December, 1999. 772 [4] S. Kent and R.Atkinson, "Security Architecture for the Internet 773 Protocol", RFC2401, November 1998. 775 [5] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature 776 Option", RFC2385, August 1998. 778 [6] S.Kent, C.Lynn, and K. Seo, "Secure Border Gateway Protocol 779 (Secure-BGP)", IEEE Journal on Selected Areas in Communications, 780 Vol. 18, No. 4, April 2000, pp. 582-592. 782 [8] E. Rescorla and B. Korver, "Guidelines for Writing RFC Text on 783 Security Considerations", work in progress, January 2003. 784 available as 785 <> at Internet-Draft shadow sites. 787 6. Author's Address 789 Sandra Murphy 790 Network Associates, Inc. 791 NAI Labs 792 3060 Washington Road 793 Glenwood, MD 21738 794 EMail: Sandy@tislabs.com