idnits 2.17.1 draft-ietf-idr-bgp-vuln-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 992. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 969. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 982. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 9) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (October 2004) is 7126 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) ** Obsolete normative reference: RFC 2385 (ref. 'TCPMD5') (Obsoleted by RFC 5925) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP' -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPsec') (Obsoleted by RFC 4301) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 none Sandra Murphy 2 INTERNET-DRAFT Sparta, Inc 3 Expires: April 13, 2005 October 2004 5 BGP Security Vulnerabilities Analysis 6 draft-ietf-idr-bgp-vuln-01.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions of 11 section 3 of RFC 3667. By submitting this Internet-Draft, each author 12 represents that any applicable patent or other IPR claims of which he or 13 she is aware have been or will be disclosed, and any of which he or she 14 become aware will be disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 13, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). 37 Specification of Requirements 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC2119 [RFC2119]. 43 Abstract 45 Border Gateway Protocol 4 (BGP-4), along with a host of other 46 infrastructure protocols designed before the Internet environment became 47 perilous, was originally designed with little consideration for 48 protection of the information it carries. There are no mechanisms 49 internal to the BGP protocol to protect against attacks that modify, 50 delete, forge, or replay data, any of which has the potential to disrupt 51 overall network routing behavior. 53 This internet draft discusses some of the security issues with BGP 54 routing data dissemination. This internet draft does not discuss 55 security issues with forwarding of packets. 57 Table of Contents 59 Abstract ........................................................ 2 60 1 Introduction .................................................... 4 61 2 Attacks ......................................................... 6 62 3 Vulnerabilities and Risks ....................................... 8 63 3.1 Vulnerabilities in BGP messages ............................... 9 64 3.1.1 Message Header .............................................. 10 65 3.1.2 OPEN ........................................................ 10 66 3.1.3 KEEPALIVE ................................................... 12 67 3.1.4 NOTIFICATION ................................................ 12 68 3.1.5 UPDATE ...................................................... 12 69 3.1.5.1 Unfeasible Routes Length, Total Path Attribute Length ..... 13 70 3.1.5.2 Withdrawn Routes .......................................... 14 71 3.1.5.3 Path Attributes ........................................... 14 72 Attribute Flags, Attribute Type Codes, Attribute Length .......... 14 73 ORIGIN ........................................................... 14 74 AS_PATH .......................................................... 15 75 Originating Routes ............................................... 15 76 NEXT_HOP ......................................................... 16 77 MULTI_EXIT_DISC .................................................. 16 78 LOCAL_PREF ....................................................... 16 79 ATOMIC_AGGREGATE ................................................. 17 80 AGGREGATOR ....................................................... 17 81 3.1.5.4 NLRI ...................................................... 17 82 3.2 Vulnerabilities through Other Protocols ....................... 17 83 3.2.1 TCP messages ................................................ 17 84 3.2.1.1 TCP SYN ................................................... 17 85 3.2.1.2 TCP SYN ACK ............................................... 18 86 3.2.1.3 TCP ACK ................................................... 18 87 3.2.1.4 TCP RST/FIN/FIN-ACK ....................................... 18 88 3.2.1.5 DoS and DDos .............................................. 19 89 3.2.2 Other supporting protocols .................................. 19 90 3.2.2.1 Manual stop ............................................... 19 91 3.2.2.2 Open Collision Dump ....................................... 19 92 3.2.2.3 Timer events .............................................. 19 93 4 Security Considerations ......................................... 20 94 4.1 Residual Risk ................................................. 20 95 4.2 Operational Protections ....................................... 21 96 5 IANA Considerations ............................................. 22 97 6 References ...................................................... 22 98 6.1 Normative ..................................................... 22 99 6.2 Informative ................................................... 22 100 7 Author's Address ................................................ 23 101 1. Introduction 103 The inter-domain routing protocol BGP was created when the Internet 104 environment had not yet reached the present contentious state. 105 Consequently, the BGP protocol was not designed with protection against 106 deliberate or accidental errors causing disruptions of routing behavior. 108 We here discuss the vulnerabilities of BGP, based on the BGP 109 specification [BGP]. Readers are expected to be familiar with the BGP 110 RFC and the behavior of BGP. 112 It is clear that the Internet is vulnerable to attack through its 113 routing protocols and BGP is no exception. Faulty, misconfigured or 114 deliberately malicious sources can disrupt overall Internet behavior by 115 injecting bogus routing information into the BGP distributed routing 116 database (by modifying, forging, or replaying BGP packets). The same 117 methods can also be used to disrupt local and overall network behavior 118 by breaking the distributed communication of information between BGP 119 peers. The sources of bogus information can be either outsiders or true 120 BGP peers. 122 Cryptographic authentication of the peer-peer communication is not an 123 integral part of the BGP protocol. As a TCP/IP protocol, BGP is subject 124 to all the TCP/IP attacks, like IP spoofing, session stealing, etc. Any 125 outsider can inject believable BGP messages into the communication 126 between BGP peers and thereby inject bogus routing information or break 127 the peer to peer connection. Any break in the peer to peer 128 communication has a ripple effect on routing that can be widespread. 129 Furthermore, outsider sources can also disrupt communications between 130 BGP peers by breaking their TCP connection with spoofed packets. 131 Outsider sources of bogus BGP information can reside anywhere in the 132 world. 134 Consequently, the current BGP specification requires that a BGP 135 implementation must support the authentication mechanism specified in 136 [TCPMD5]. However, the requirement for support of that authentication 137 mechanism cannot ensure that the mechanism is configured for use. The 138 mechanism of [TCPMD5] is based on a pre-installed shared secret; it does 139 not have the capability of IPsec [IPsec] to agree on a shared secret 140 dynamically. Consequently, the use of [TCPMD5] must be a deliberate 141 decision, not an automatic feature or default. 143 The current BGP specification also allows for implementations that would 144 accept connections from "unconfigured peers" ([BGP] Section 8). 145 However, the specification is not clear as to what an unconfigured peer 146 might be or how the protections of [TCPMD5] would apply in such a case. 147 It is therefore not possible to include an analysis of the security 148 issues of this feature. When a specification is released that describes 149 this feature more fully, a security analysis should be part of that same 150 specification. 152 BGP speakers themselves can inject bogus routing information, either by 153 masquerading as any other legitimate BGP speaker, or by distributing 154 unauthorized routing information as themselves. Historically, 155 misconfigured and faulty routers have been responsible for widespread 156 disruptions in the Internet. The legitimate BGP peers have the context 157 and information to produce believable bogus routing information and 158 therefore have the opportunity to cause great damage. The cryptographic 159 protections of [TCPMD5] and operational protections cannot exclude the 160 bogus information arising from a legitimate peer. The risk of 161 disruptions caused by legitimate BGP speakers is real and cannot be 162 ignored. 164 Bogus routing information can have many different effects on routing 165 behavior. If the bogus information removes routing information for a 166 particular network, that network can become unreachable for the portion 167 of the Internet that accepts the bogus information. If the bogus 168 information changes the route to a network, then packets destined for 169 that network may be forwarded by a sub-optimal path, or a path that does 170 not follow the expected policy, or a path that will not forward the 171 traffic. As a consequence, traffic to that network could be delayed by 172 a longer than necessary path. The network could become unreachable from 173 areas where the bogus information is accepted. Traffic might also be 174 forwarded along a path that permits some adversary a view of the data or 175 a chance to modify the data. If the bogus information makes it appear 176 that an autonomous system originates a network when it does not, then 177 packets for that network may not be deliverable for the portion of the 178 Internet that accepts the bogus information. A false announcement that 179 an autonomous systems originates a network may also fragment aggregated 180 address blocks in other parts of the Internet and cause routing problems 181 for other networks. 183 The damages that might result from these attacks include: 185 starvation: Data traffic destined for a node is forwarded to a part 186 of the network that cannot deliver it. 188 network congestion: More data traffic is forwarded through some 189 portion of the network than would otherwise need to carry the 190 traffic. 192 blackhole: Large amounts of traffic are directed to be forwarded 193 through one router that cannot handle the increased level of 194 traffic and drops many/most/all packets. 196 delay: Data traffic destined for a node is forwarded along a path 197 that is in some way inferior to the path it would otherwise take. 199 looping: Data traffic is forwarded along a path that loops, so that 200 the data is never delivered. 202 eavesdrop: Data traffic is forwarded through some router or network 203 that would otherwise not see the traffic, affording an opportunity 204 to see the data. 206 partition: Some portion of the network believes that it is 207 partitioned from the rest of the network when it is not. 209 cut: Some portion of the network believes that it has no route to 210 some network that is in fact connected. 212 churn: The forwarding in the network changes at a rapid pace, 213 resulting in large variations in the data delivery patterns (and 214 adversely affecting congestion control techniques). 216 instability: BGP become unstable so that convergence on a global 217 forwarding state is not achieved. 219 overload: The BGP messages themselves become a significant portion 220 of the traffic the network carries. 222 resource exhaustion: The BGP messages themselves cause exhaustion 223 of critical router resources, such as table space. 225 address-spoofing: Data traffic is forwarded through some router or 226 network that is spoofing the legitimate address, enabling an active 227 attack by affording the opportunity to modify the data. 229 These consequences can fall exclusively on one end system prefix or may 230 effect the operation of the network as a whole. 232 2. Attacks 234 The BGP protocol, in and of itself, is subject to the following attacks 235 (list taken from the IAB RFC providing guidelines for the security 236 considerations section of Internet-Drafts and RFCs [SecCons]): 238 confidentiality violations: The routing data carried in BGP is 239 carried in cleartext, so eavesdropping is a possible attack against 240 routing data confidentiality. (Routing data confidentiality is not 241 a common requirement.) 243 replay: BGP does not provide for replay protection of its 244 messages. 246 message insertion: BGP does not provide protection against 247 insertion of messages. However, because BGP uses TCP, when the 248 connection is fully established, message insertion by an outsider 249 would require accurate sequence number prediction (not entirely out 250 of the question, but more difficult with mature TCP 251 implementations) or session stealing attacks. 253 message deletion: BGP does not provide protection against deletion 254 of messages. Again, this attack is more difficult against a mature 255 TCP implementation but is not entirely out of the question. 257 message modification: BGP does not provide protection against 258 modification of messages. A modification that was syntactically 259 correct and did not change the length of the TCP payload would in 260 general not be detectable. 262 man-in-the-middle: BGP does not provide protection against 263 man-in-the-middle attacks. As BGP does no peer entity 264 authentication, a man-in-the-middle attack is childs-play. 266 denial of service: While bogus routing data can present a denial 267 of service attack on the end systems that are trying to transmit 268 data through the network and on the network infrastructure itself, 269 certain bogus information can represent a denial of service on the 270 BGP routing protocol. For example, advertising large numbers of 271 more specific routes (longer prefixes) can cause BGP traffic and 272 router table size to increase, even explode. 274 The mandatory-to-support mechanism of [TCPMD5] will counter the message 275 insertion, deletion, and modification, man-in-the-middle attacks and the 276 denial of service attacks from outsiders. The use of [TCPMD5] does not 277 protect against eavesdropping attacks, but routing data confidentiality 278 is not a goal of BGP. The mechanism of [TCPMD5] does not protect 279 against replay attacks, so the only protection against replay is 280 provided by the TCP sequence number processing. Therefore, a replay 281 attack could be mounted against a BGP connection protected with [TCPMD5] 282 but only in very carefully timed circumstances. The mechanism of 283 [TCPMD5] cannot protect against bogus routing information originating 284 with an insider. 286 3. Vulnerabilities and Risks 288 The risks in BGP arise from three fundamental vulnerabilities: 290 BGP has no internal mechanism that provides strong protection of 291 the integrity, freshness and peer entity authenticity of the 292 messages in peer-peer BGP communications. 294 no mechanism has been specified within BGP to validate the 295 authority of an AS to announce NLRI information. 297 no mechanism has been specified within BGP to ensure the 298 authenticity of the path attributes announced by an AS. 300 The first fundamental vulnerability motivated the mandated support of 301 [TCPMD5] in the BGP specification. When that is employed, message 302 integrity and peer entity authentication is provided. The mechanism of 303 [TCPMD5] assumes that the MD5 algorithm is secure and that the shared 304 secret is protected and chosen to be difficult to guess. 306 In the discussion that follows, the vulnerabilities are described in 307 terms of the BGP Finite State Machine events where the message 308 processing occurs. The events are defined and discussed in section 8 of 309 [BGP]. The events mentioned here are: 311 [Administrative Events] 313 Event 2: ManualStop 315 Event 8: AutomaticStop 317 [Timer Events] 319 Event 9: ConnectRetryTimer_Expires 321 Event 10: HoldTimer_Expires 323 Event 11: KeepaliveTimer_Expires 325 Event 12: DelayOpenTimer_Expires 326 Event 13: IdleHoldTimer_Expires 328 [TCP Connection based Events] 330 Event 14: TcpConnection_Valid 332 Event 16: Tcp_CR_Acked 334 Event 17: TcpConnectionConfirmed 336 Event 18: TcpConnectionFails 338 [BGP Messages based Events] 340 Event 19: BGPOpen 342 Event 20: BGPOpen with DelayOpenTimer running 344 Event 21: BGPHeaderErr 346 Event 22: BGPOpenMsgErr 348 Event 23: OpenCollisionDump 350 Event 24: NotifMsgVerErr 352 Event 25: NotifMsg 354 Event 26: KeepAliveMsg 356 Event 27: UpdateMsg 358 Event 28: UpdateMsgErr 360 3.1. Vulnerabilities in BGP messages 362 There are four different BGP message types - OPEN, KEEPALIVE, 363 NOTIFICATION, and UPDATE. This section contains a discussion of the 364 vulnerabilities arising from each message and the ability of outsiders 365 or BGP peers to exploit the vulnerabilities. To summarize, outsiders 366 can use bogus OPEN, KEEPALIVE, NOTIFICATION, or UPDATE messages to 367 disrupt the BGP peer-peer connections and can use bogus UPDATE messages 368 to disrupt routing without breaking the peer-peer connection. Outsiders 369 can also disrupt BGP peer-peer connections by inserting bogus TCP 370 packets that disrupt the TCP connection processing. In general, the 371 ability of outsiders to use bogus BGP and TCP messages is limited, but 372 not eliminated, by the TCP sequence number processing. The use of 373 [TCPMD5] can counter these outsider attacks. BGP peers themselves are 374 permitted to break peer-peer connections at any time using NOTIFICATION 375 messages, so there is no additional risk of broken connections through 376 their use of OPEN, KEEPALIVE, or UPDATE messages. However, BGP peers 377 can disrupt routing (in impermissible ways) by issuing UPDATE messages 378 that contain bogus routing information. In particular, bogus 379 ATOMIC_AGGREGATE, NEXT_HOP and AS_PATH attributes and bogus NLRI in 380 UPDATE messages can disrupt routing. The use of [TCPMD5] will not 381 counter these attacks from BGP peers. 383 Each message introduces certain different vulnerabilities and risks and 384 is discussed in the following sections. 386 3.1.1. Message Header 388 Event 21: Each BGP message starts with a standard header. In all 389 cases, syntactic errors in the message header will cause the BGP speaker 390 to close the connection, release all associated BGP resources, delete 391 all routes learned through that connection, run its decision process to 392 decide on new routes and cause the state to return to Idle. Also, 393 optionally, an implementation specific peer oscillation damping may be 394 performed. The peer oscillation damping process can affect how soon the 395 connection can be restarted. An outsider who could spoof messages with 396 message header errors could cause disruptions in routing over a wide 397 area. 399 3.1.2. OPEN 401 Event 19: Receipt of an OPEN message in state Connect or Active will 402 cause the BGP speaker to bring down the connection, release all 403 associated BGP resources, delete all associated routes, run its decision 404 process and cause the state to return to Idle. The deletion of routes 405 can cause a cascading effect of routing changes propagating through 406 other peers. Also, optionally, an implementation specific peer 407 oscillation damping may be performed. The peer oscillation damping 408 process can affect how soon the connection can be restarted. 410 In state OpenConfirm or Established, the arrival of an OPEN may indicate 411 a connection collision has occurred. If this connection is to be 412 dropped, then Event 23 will be issued. (Event 23, discussed below, 413 results in the same set of disruptive actions as mentioned above for 414 states Connect or Active.) 415 In state OpenSent, the arrival of an OPEN message will cause the BGP 416 speaker to transition to the OpenConfirm state. If an outsider was able 417 to spoof an OPEN message (requiring very careful timing), then the later 418 arrival of the legitimate peer's OPEN message might lead the BGP speaker 419 to declare a connection collision. The collision detection procedure 420 may cause the legitimate connection to be dropped. 422 Consequently, the ability of an outsider to spoof this message can lead 423 to a severe disruption of routing over a wide area. 425 Event 20: If an OPEN message arrives when the DelayOpen timer is 426 running when the connection is in state OpenSent, OpenConfirm or 427 Established, the BGP speaker will bring down the connection, release all 428 associated BGP resources, delete all associated routes, run its decision 429 process and cause the state to return to Idle. The deletion of routes 430 can cause a cascading effect of routing changes propagating through 431 other peers. Also, optionally, an implementation specific peer 432 oscillation damping may be performed. The peer oscillation damping 433 process can affect how soon the connection can be restarted. However, 434 as the OpenDelay timer should never be running in these states, this 435 could only be caused by an error in the implementation (a NOTIFICATION 436 is sent with the error code "Finite State Machine Error"). It would be 437 difficult, if not impossible, for an outsider to induce this FSM error. 439 In states Connect and Active, this event will cause a transition to the 440 OpenConfirm state. As in Event 19, if an outsider were able to spoof an 441 OPEN which arrived while the DelayOpen timer was running, then a later 442 arriving OPEN from the legitimate peer might be considered a connection 443 collision and the legitimate connection could be dropped. 445 Consequently, the ability for an outsider to spoof this message can lead 446 to a severe disruption of routing over a wide area. 448 Event 22: Errors in the OPEN message (e.g., unacceptable Hold state, 449 malformed Optional Parameter, unsupported version, etc.) will cause the 450 BGP speaker to bring down the connection, release all associated BGP 451 resources, delete all associated routes, run its decision process and 452 cause the state to return to Idle. The deletion of routes can cause a 453 cascading effect of routing changes propagating through other peers. 454 Also, optionally, an implementation specific peer oscillation damping 455 may be performed. The peer oscillation damping process can affect how 456 soon the connection can be restarted. Consequently, the ability of an 457 outsider to spoof this message can lead to a severe disruption of 458 routing over a wide area. 460 3.1.3. KEEPALIVE 462 Event 26: Receipt of a KEEPALIVE message when the peering connection is 463 in the Connect, Active, and OpenSent states would cause the BGP speaker 464 to transition to the Idle state and fail to establish a connection. 465 Also, optionally, an implementation specific peer oscillation damping 466 may be performed. The peer oscillation damping process can affect how 467 soon the connection can be restarted. The ability of an outsider to 468 spoof this message can lead to a disruption of routing. To exploit this 469 vulnerability deliberately, the KEEPALIVE must be carefully timed in the 470 sequence of messages exchanged between the peers; otherwise, it causes 471 no damage. 473 3.1.4. NOTIFICATION 475 Event 25: Receipt of a NOTIFICATION message in any state will cause the 476 BGP speaker to bring down the connection, release all associated BGP 477 resources, delete all associated routes, run its decision process and 478 cause the state to return to Idle. The deletion of routes can cause a 479 cascading effect of routing changes propagating through other peers. 480 Also, optionally, in any state but Established, an implementation 481 specific peer oscillation damping may be performed. The peer 482 oscillation damping process can affect how soon the connection can be 483 restarted. Consequently, the ability of an outsider to spoof this 484 message can lead to a severe disruption of routing over a wide area. 486 Event 24: A NOTIFICATION message carrying an error code of "Version 487 Error" behaves the same as in Event 25, with the exception that the 488 optional peer oscillation damping is not performed in states OpenSent or 489 OpenConfirm, or in state Connect or Active if the DelayOpen timer is 490 running. The damage caused is therefore one small bit less, because 491 restarting the connection is not affected. 493 3.1.5. UPDATE 495 Event 8: A BGP speaker may optionally choose to automatically 496 disconnect a BGP connection if the total number of prefixes exceeds a 497 configured maximum. If such a case, an UPDATE may carry a number of 498 prefixes that would result in that maximum being exceeded. The BGP 499 speaker would disconnect the connection, release all associated BGP 500 resources, delete all associated routes, run its decision process and 501 cause the state to return to Idle. The deletion of routes can cause a 502 cascading effect of routing changes propagating through other peers. 503 Also, optionally, an implementation specific peer oscillation damping 504 may be performed. The peer oscillation damping process can affect how 505 soon the connection can be restarted. Consequently, the ability of an 506 outsider to spoof this message can lead to a severe disruption of 507 routing over a wide area. 509 Event 28: If the UPDATE message is malformed (Withdrawn Routes Length, 510 Total Attribute Length, or Attribute Length that are improper, missing 511 mandatory well-known attributes, Attribute Flags that conflict with the 512 Attribute Type Codes, syntactic errors in the ORIGIN, NEXT_HOP or 513 AS_PATH, etc.), then the BGP speaker will bring down the connection, 514 release all associated BGP resources, delete all associated routes, run 515 its decision process and cause the state to return to Idle. The 516 deletion of routes can cause a cascading effect of routing changes 517 propagating through other peers. Also, optionally, an implementation 518 specific peer oscillation damping may be performed. The peer 519 oscillation damping process can affect how soon the connection can be 520 restarted. Consequently, the ability of an outsider to spoof this 521 message could cause widespread disruption of routing. As a BGP speaker 522 has the authority to close a connection whenever it wants, this message 523 gives BGP speakers no more opportunity to cause damage than they already 524 had. 526 Event 27: An Update message that arrives in any state but Established 527 will cause the BGP speaker to bring down the connection, release all 528 associated BGP resources, delete all associated routes, run its decision 529 process and cause the state to return to Idle. The deletion of routes 530 can cause a cascading effect of routing changes propagating through 531 other peers. Also, optionally, an implementation specific peer 532 oscillation damping may be performed. The peer oscillation damping 533 process can affect how soon the connection can be restarted. 534 Consequently, the ability of an outsider to spoof this message can lead 535 to a severe disruption of routing over a wide area. 537 In the Established state, the Update message carries the routing 538 information. The ability to spoof any part of this message can lead to 539 a disruption of routing, whether the source of the message is an 540 outsider or a legitimate BGP speaker. 542 3.1.5.1. Unfeasible Routes Length, Total Path Attribute Length 544 There is a vulnerability arising from the ability to modify these 545 fields. If a length is modified, the message is not likely to parse 546 properly, resulting in an error, the transmission of a NOTIFICATION 547 message and the close of the connection (see Event 28, above). As a 548 true BGP speaker is always able to close a connection at any time, this 549 vulnerability represents an additional risk only when the source is not 550 the configured BGP peer, i.e., it presents no additional risk from BGP 551 speakers. 553 3.1.5.2. Withdrawn Routes 555 An outsider could cause the elimination of existing legitimate routes by 556 forging or modifying this field. An outsider could also cause the 557 elimination of reestablished routes by replaying this withdrawal 558 information from earlier packets. 560 A BGP speaker could "falsely" withdraw feasible routes using this field. 561 However, as the BGP speaker is authoritative for the routes it will 562 announce, it is allowed to withdraw any previously announced routes that 563 it wants. As the receiving BGP speaker will only withdraw routes 564 associated with the sending BGP speaker, there is no opportunity for a 565 BGP speaker to withdraw another BGP speaker's routes. Therefore, there 566 is no additional risk from BGP peers via this field. 568 3.1.5.3. Path Attributes 570 The path attributes present many different vulnerabilities and risks. 572 Attribute Flags, Attribute Type Codes, Attribute Length 574 A BGP peer or an outsider could modify the attribute length or attribute 575 type (flags and type codes) so they did not reflect the attribute values 576 that followed. If the flags were modified, the flags and type code 577 could become incompatible (i.e., a mandatory attribute marked as 578 partial), or a optional attribute could be interpreted as a mandatory 579 attribute or vice versa. If the type code were modified, the attribute 580 value could be interpreted as if it were the data type and value of a 581 different attribute. 583 The most likely result from modifying the attribute length, flags, or 584 type code would be a parse error of the UPDATE message. A parse error 585 would cause the transmission of a NOTIFICATION message and the close of 586 the connection (see Event 28, above). As a true BGP speaker is always 587 able to close a connection at any time, this vulnerability represents an 588 additional risk only when the source is an outsider, i.e., it presents 589 no additional risk from a BGP peer. 591 ORIGIN 593 This field indicates whether the information was learned from IGP or EGP 594 information. This field is used in making routing decisions, so there 595 is some small vulnerability in being able to affect the receiving BGP 596 speaker's routing decision by modifying this field. 598 AS_PATH 600 A BGP peer or outsider could announce an AS_PATH that was not accurate 601 for the associated NLRI. 603 As it is possible for a BGP peer not to verify that a received AS_PATH 604 begins with the AS number of its peer, a malicious BGP peer could 605 announce a path that begins with the AS of any BGP speaker with little 606 impact on itself. This could affect the receiving BGP speaker's 607 decision procedure and choice of installed route. The malicious peer 608 could considerably shorten the AS_PATH, which will increase that route's 609 chances of being chosen, possibly giving the malicious peer access to 610 traffic it would otherwise not receive. The shortened AS_PATH also 611 could result in routing loops, as it does not contain the information 612 needed to prevent loops. 614 It is possible for a BGP speaker to be configured to accept routes with 615 its own AS number in the AS path. Such operational considerations are 616 defined to be "outside the scope" of the BGP specification, but the fact 617 that AS_PATHs can have loops means that implementations cannot 618 automatically reject routes with loops. Each BGP speaker verifies only 619 that its own AS number does not appear in the AS_PATH. 621 Coupled with the ability to use any value for the NEXT_HOP, this gives a 622 malicious BGP speaker considerable control over the path traffic will 623 take. 625 Originating Routes 627 A special case of announcing a false AS_PATH occurs when the AS_PATH 628 advertises a direct connection to a specific network address. A BGP 629 peer or outsider could disrupt routing to the network(s) listed in the 630 NLRI field by falsely advertising a direct connection to the network. 631 The NLRI would become unreachable to the portion of the network that 632 accepted this false route, unless the ultimate AS on the AS_PATH 633 undertook to tunnel the packets it was forwarded for this NLRI on toward 634 their true destination AS by a valid path. But even when the packets 635 are tunneled to the correct destination AS, the route followed may not 636 be optimal or may not follow the intended policy. Additionally, routing 637 for other networks in the Internet could be affected if the false 638 advertisement fragmented an aggregated address block, forcing the 639 routers to handle (issue UPDATES, store, manage) the multiple fragments 640 rather than the single aggregate. False originations for multiple 641 addresses can result in routers and transit networks along the announced 642 route to become flooded with mis-directed traffic. 644 NEXT_HOP 646 The NEXT_HOP attribute defines the IP address of the border router that 647 should be used as the next hop when forwarding the NLRI listed in the 648 UPDATE message. If the recipient is an external peer, then the 649 recipient and the NEXT_HOP address must share a subnet. It is clear 650 that an outsider modifying this field could disrupt the forwarding of 651 traffic between the two AS's. 653 In the case that the recipient of the message is an external peer of an 654 AS and the route was learned from another peer AS (this is one of two 655 forms of "third party" NEXT_HOP), then the BGP speaker advertising the 656 route has the opportunity to direct the recipient to forward traffic to 657 a BGP speaker at the NEXT_HOP address. This affords the opportunity to 658 direct traffic at a router that may not be able to continue forwarding 659 the traffic. A malicious BGP speaker can also use this technique to 660 force another AS to carry traffic it would otherwise not have to carry. 661 In some cases, this could be to the malicious BGP speaker's benefit, as 662 it could cause traffic to be carried long-haul by the victim AS to some 663 other peering point it shared with the victim. 665 MULTI_EXIT_DISC 667 The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted 668 between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an 669 inter-AS peer may be propagated within an AS, it may not be propagated 670 to other AS's. Consequently, this field is only used in making routing 671 decisions internal to one AS. Modifying this field, whether by an 672 outsider or a BGP peer, could influence routing within an AS to be 673 sub-optimal, but the effect should be limited in scope. 675 LOCAL_PREF 677 The LOCAL_PREF attribute must be included in all messages with internal 678 peers and excluded from messages with external peers. Consequently, 679 modification of the LOCAL_PREF could effect the routing process within 680 the AS only. Note that there is no requirement in the BGP RFC that the 681 LOCAL_PREF be consistent among the internal BGP speakers of an AS. As 682 BGP peers are free to choose the LOCAL_PREF as they wish, modification 683 of this field is a vulnerability with respect to outsiders only. 685 ATOMIC_AGGREGATE 687 The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way 688 has aggregated several routes and advertised the aggregate NLRI without 689 the AS_SET formed as usual from the AS's in the aggregated routes' 690 AS_PATHs. BGP speakers receiving a route with ATOMIC_AGGREGATE are 691 restricted from making the NLRI any more specific. Removing the 692 ATOMIC_AGGREGATE attribute would remove the restriction, possibly 693 causing traffic intended for the more specific NLRI to be routed 694 incorrectly. Adding the ATOMIC_AGGREGATE attribute when no aggregation 695 was done would have little effect, beyond restricting the un-aggregated 696 NLRI from being made more specific. This vulnerability exists whether 697 the source is a BGP peer or an outsider. 699 AGGREGATOR 701 This field may be included by a BGP speaker who has computed the routes 702 represented in the UPDATE message from aggregation of other routes. The 703 field contains the AS number and IP address of the last aggregator of 704 the route. It is not used in making any routing decisions, so it does 705 not represent a vulnerability. 707 3.1.5.4. NLRI 709 By modifying or forging this field, either an outsider or BGP peer 710 source could cause disruption of routing to the announced network, 711 overwhelm a router along the announced route, cause data loss when the 712 announced route will not forward traffic to the announced network, route 713 traffic by a sub-optimal route, etc. 715 3.2. Vulnerabilities through Other Protocols 717 3.2.1. TCP messages 719 BGP runs over TCP, listening on port 179. Therefore, BGP is subject to 720 attack through attacks on TCP. 722 3.2.1.1. TCP SYN 724 SYN flooding: BGP is as subject to the effects on the TCP 725 implementation of SYN flooding attacks as other protocols, and must rely 726 on the implementation's protections against this attack. 728 Event 14: If an outsider were able to send a SYN to the BGP speaker at 729 the appropriate time during connection establishment, then the 730 legitimate peer's SYN would appear to be a second connection. If the 731 outsider were able to continue with a sequence of packets resulting in a 732 BGP connection (guessing the BGP speaker's choice for sequence number on 733 the SYN ACK, for example), then, the outsider's connection and the 734 legitimate peer's connection would appear to be a connection collision. 735 Depending on the outcome of the collision detection (i.e., the outsider 736 chose a BGP identifier so as to win the race), the legitimate peer's 737 true connection could be destroyed. The use of [TCPMD5] can counter 738 this attack. 740 3.2.1.2. TCP SYN ACK 742 Event 16: If an outsider were able to respond to a BGP speaker's SYN 743 before the legitimate peer, then the legitimate peer's SYN-ACK would 744 receive a empty ACK reply, causing the legitimate peer to issue a RST 745 that would break the connection. The BGP speaker would bring down the 746 connection, release all associated BGP resources, delete all associated 747 routes and run its decision process. This attack requires that the 748 outsider be able to predict the sequence number used in the SYN. The 749 use of [TCPMD5] can counter this attack. 751 3.2.1.3. TCP ACK 753 Event 17: If an outsider were able to spoof an ACK at the appropriate 754 time during connection establishment, then the BGP speaker would 755 consider the connection complete, send an OPEN (Event 17) and transition 756 to the OpenSent state. The arrival of the legitimate peer's ACK would 757 not be delivered to the BGP process, as it would look like a duplicate 758 packet. This message, then, presents no particular vulnerability to BGP 759 during connection establishment. Spoofing an ACK after connection 760 establishment requires knowledge of the sequence numbers in use, and is 761 in general a very difficult task. The use of [TCPMD5] can counter this 762 attack. 764 3.2.1.4. TCP RST/FIN/FIN-ACK 766 Event 18: If an outsider were able to spoof a RST, the BGP speaker 767 would bring down the connection, release all associated BGP resources, 768 delete all associated routes and run its decision process. If an 769 outsider were able to spoof a FIN, then data could still be transmitted, 770 but any attempt to receive would receive a notification that the 771 connection is closing. In most cases, this results in the connection 772 being placed in an Idle state, but if the connection is in the OpenSent 773 state at the time, the connection returns to an Active state. Spoofing 774 a RST in this situation requires an outsider to guess a sequence number 775 that need only be within the receive window [Watson04], generally an 776 easier task than guessing the exact sequence number so as to spoof a 777 FIN. The use of [TCPMD5] can counter this attack. 779 3.2.1.5. DoS and DDos 781 Because the packet directed to TCP port 179 are passed to the BGP 782 process, that potentially resides on a slower processor in the router, 783 flooding a router with TCP port 179 packets is an avenue for DoS attacks 784 against the router. No BGP protocol mechanism can defeat such attacks; 785 other mechanisms must be employed. 787 3.2.2. Other supporting protocols 789 3.2.2.1. Manual stop 791 Event 2: A manual stop event causes the BGP speaker to bring down the 792 connection, release all associated BGP resources, delete all associated 793 routes and run its decision process. If the mechanism by which a BGP 794 speaker was informed of a manual stop were not carefully protected, the 795 BGP connection could be destroyed by an outsider. Consequently, BGP 796 security is secondarily dependent on the security of the protocols by 797 which the platform is managed and configured that might signal this 798 event. 800 3.2.2.2. Open Collision Dump 802 Event 23: The OpenCollisionDump event may be generated administratively 803 when a connection collision event is detected and this connection has 804 been selected to be disconnected. When this event occurs in any state, 805 the BGP connection is dropped, the BGP resources are released, the 806 associated routes are deleted, etc. Consequently, BGP security is 807 secondarily dependent on the security of the protocols by which the 808 platform is managed and configured that might signal this event. 810 3.2.2.3. Timer events 812 Events 9-13: BGP employs five timers (ConnectRetry, Hold, Keepalive, 813 MinASOrigination-Interval, and MinRouteAdvertisementInterval) and two 814 optional timers (DelayOpen and IdleHold). These timers are critical to 815 BGP operation. For example, if the Hold timer value were changed, the 816 remote peer might consider the connection unresponsive and bring the 817 connection down, releasing resources, deleting associated routes, etc. 818 Consequently, BGP security is secondarily dependent on the security of 819 the protocols by which the platform is operated, managed and configured 820 that might modify these timers. 822 4. Security Considerations 824 This entire memo is about security, describing an analysis of the 825 vulnerabilities that exist in the BGP protocol. 827 Use of the mandatory-to-support mechanisms of [TCPMD5] counters the 828 message insertion, deletion, and modification attacks and 829 man-in-the-middle attacks from outsiders. If routing data 830 confidentiality were desired (there being some controversy as to whether 831 that is a desirable security service), the use of IPsec ESP could 832 provide that service. 834 4.1. Residual Risk 836 As cryptographic-based mechanisms, both [TCPMD5] and IPsec [IPsec] 837 assume that the cryptographic algorithms are secure, that secrets used 838 are protected from exposure and are chosen well so as not to be 839 guessable, that the platforms are securely managed and operated to 840 prevent break-ins, etc. 842 These mechanisms do not prevent attacks that arise from a router's 843 legitimate BGP peers. There are several possible solutions to prevent a 844 BGP speaker from inserting bogus information in its advertisements to 845 its peers, i.e., from mounting an attack on a network's origination or 846 AS-PATH. 848 (1) Origination Protection: sign the originating AS. 850 (2) Origination and Adjacency Protection: sign the originating AS and 851 predecessor information ([Smith96]) 853 (3) Origination and Route Protection: sign the originating AS, and 854 nest signatures of AS_PATHs to the number of consecutive bad 855 routers you want to prevent from causing damage. ([SBGP00]) 857 (4) Filtering: rely on a registry to verify the AS_PATH and NLRI 858 originating AS ([RPSL]). 860 Filtering is in use near some customer attachment points, but is not 861 effective near the Internet center. The other mechanisms are still 862 controversial and are not yet in common use. 864 4.2. Operational Protections 866 The primary usage of BGP is as a means to provide reachability 867 information to Autonomous Systems (AS) and to distribute external 868 reachability internally within an AS. BGP is the routing protocol used 869 to distribute global routing information in the Internet. BGP is 870 therefore used by all major Internet Service Providers (ISP) and many 871 smaller providers and other organizations. 873 The role which BGP plays in the Internet puts BGP implementations in 874 unique conditions and places unique security requirements on BGP. BGP 875 is operated over interprovider interfaces in which traffic levels push 876 the state of the art in specialized packet forwarding hardware and 877 exceed the performance capabilities of hardware implementation of 878 decryption by many orders of magnitude. The capability of an attacker 879 using a single workstation with high speed interface to generate false 880 traffic for denial of service (DoS) far exceeds the capability of 881 software based decryption or appropriately priced cryptographic hardware 882 to detect the false traffic. One means to protect the network elements 883 from DoS attacks under such conditions is to use packet based filtering 884 techniques based on relatively simple inspections of packets. As a 885 result, for an ISP carrying large volumes of traffic, the ability to 886 packet filter on the basis of port numbers is an important protection 887 against DoS attacks, and a necessary adjunct to cryptographic strength 888 in encapsulation. 890 Current practice in ISP operation is to use certain common filtering 891 techniques to reduce the exposure to attacks from outside the ISP. To 892 protect Internal BGP (IBGP) sessions, filters are applied at all borders 893 to an ISP network which remove all traffic destined for addresses of 894 network elements internal addresses (typically contained within a single 895 prefix) and the BGP port number (179). Packets from within an ISP are 896 not forwarded from an internal interface to the BGP speaker's address on 897 which External BGP (EBGP) sessions are supported, or to a peer's EBGP 898 address if the BGP port number is found. With appropriate consideration 899 in router design, in the event of failure of a BGP peer to provide the 900 equivalent filtering, the risk of compromise can be limited to the 901 peering session on which filtering is not performed by the peer or the 902 interface or line card on which the peering is supported. There is 903 substantial motivation and little effort for ISPs to maintain such 904 filters. 906 These operational practices can considerably raise the difficulty for an 907 outsider to launch a DoS attack against an ISP. Prevented from 908 injecting sufficient traffic from outside a network to effect a DoS 909 attack, the attacker would have to undertake much more difficult tasks, 910 such as compromise of the ISP network elements or undetected tapping 911 into physical media. 913 5. IANA Considerations This document has no actions for IANA. 915 6. References 917 6.1. Normative 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", RFC 2119, BCP 14, March 1997. 922 [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 923 Signature Option", RFC2385, August 1998. 925 [BGP] Rekhter, Y. and Li, T., "A Border Gateway Protocol 4 (BGP- 926 4)", work in progress, September 2004. available as 927 <> at Internet-Draft shadow 928 sites. 930 6.2. Informative 932 [IPsec] Kent, S. and Atkinson, R., "Security Architecture for the 933 Internet Protocol", RFC2401, November 1998. 935 [SBGP00] Kent, S., Lynn, C. and Seo, K., "Secure Border Gateway 936 Protocol (Secure-BGP)", IEEE Journal on Selected Areas in 937 Communications, Vol. 18, No. 4, April 2000, pp. 582-592. 939 [SecCons] Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text 940 on Security Considerations", RFC3552, BCP72, July 2003. 942 [Smith96] Smith, B. and Garcia-Luna-Aceves, J.J., "Securing the Border 943 Gateway Routing Protocol", Proc. Global Internet'96, London, 944 UK, 20-21 November 1996. 946 [RPSL] Villamizar, C., Alaettinoglu, C., Meyer, D., Murphy, S. and 947 Orange, C., "Routing Policy System Security", RFC 2725, 948 December 1999. 950 [Watson04] Watson, P., "Slipping In The Window: TCP Reset Attacks", 951 CanSecWest 2004, April 2004. 953 7. Author's Address 955 Sandra Murphy 956 Sparta, Inc. 957 7075 Samuel Morse Drive 958 Columbia, MD 21046 959 EMail: Sandy@tislabs.com 960 Intellectual Property Statement 962 The IETF takes no position regarding the validity or scope of any 963 Intellectual Property Rights or other rights that might be claimed to 964 pertain to the implementation or use of the technology described in this 965 document or the extent to which any license under such rights might or 966 might not be available; nor does it represent that it has made any 967 independent effort to identify any such rights. Information on the 968 procedures with respect to rights in RFC documents can be found in BCP 969 78 and BCP 79. 971 Copies of IPR disclosures made to the IETF Secretariat and any 972 assurances of licenses to be made available, or the result of an attempt 973 made to obtain a general license or permission for the use of such 974 proprietary rights by implementers or users of this specification can be 975 obtained from the IETF on-line IPR repository at 976 http://www.ietf.org/ipr. 978 The IETF invites any interested party to bring to its attention any 979 copyrights, patents or patent applications, or other proprietary rights 980 that may cover technology that may be required to implement this 981 standard. Please address the information to the IETF at 982 ietf-ipr@ietf.org. 984 Disclaimer of Validity 986 This document and the information contained herein are provided on an 987 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 988 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 989 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 990 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 991 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 992 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 994 Copyright Statement 996 Copyright (C) The Internet Society (2004). This document is subject to 997 the rights, licenses and restrictions contained in BCP 78, and except as 998 set forth therein, the authors retain all their rights. 1000 Acknowledgment 1002 Funding for the RFC Editor function is currently provided by the 1003 Internet Society.