RFC 4272

BGP Security Vulnerabilities Analysis

📅 published January 2006, from ietf

RFC 4272 🦋 BGP Security Vulnerabilities Analysis (Part 1 of 5) 💖

Okay bestie, so this is RFC 4272, and it's all about BGP Security Vulnerabilities Analysis 🔥 It's a real main-character doc about how the Internet's routing protocol (BGP) can get hacked, messed up, or just break on its own. 💅

Here's the title block tea ☕:

  • Network Working Group is the group that published it 🌸
  • Request for Comments: 4272 is its number, so you can look it up 🧚
  • Author: S. Murphy, from Sparta, Inc. ✨
  • Category: Informational, which means it gives info to the Internet community and doesn't set any official standard 🎀
  • Date: January 2006 📅
  • The header doesn't list anything it obsoletes or updates 🙈

Status of This Memo

This memo is giving info to the Internet community 💜 It is NOT a standard of any kind, and anyone can share it freely with no limits 🌈

Copyright (C) The Internet Society (2006).

Abstract

Okay, so BGP-4 (Border Gateway Protocol 4) is the main protocol for routing across the Internet 🌐 It was made way back before the Internet got sketchy, so it doesn't really protect the info it carries 😭 Nothing inside BGP stops attackers from modifying, deleting, forging, or replaying data, and any of those could mess up how the whole network routes traffic 💀

This doc talks about some of the security problems with how BGP routing data gets shared 🫶 It does not cover security problems with forwarding packets 🙅‍♀️

Table of Contents

   1. Introduction ....................................................3
      1.1. Specification of Requirements ..............................5
   2. Attacks .........................................................6
   3. Vulnerabilities and Risks .......................................7
      3.1. Vulnerabilities in BGP Messages ............................8
           3.1.1. Message Header ......................................9
           3.1.2. OPEN ................................................9
           3.1.3. KEEPALIVE ..........................................11
           3.1.4. NOTIFICATION .......................................11
           3.1.5. UPDATE .............................................11
                  3.1.5.1. Unfeasible Routes Length, Total
                           Path Attribute Length .....................12
                  3.1.5.2. Withdrawn Routes ..........................13
                  3.1.5.3. Path Attributes ...........................13
                  3.1.5.4. NLRI ......................................16
      3.2. Vulnerabilities through Other Protocols ...................16
           3.2.1. TCP Messages .......................................16
                  3.2.1.1. TCP SYN ...................................16
                  3.2.1.2. TCP SYN ACK ...............................17
                  3.2.1.3. TCP ACK ...................................17
                  3.2.1.4. TCP RST/FIN/FIN-ACK .......................17
                  3.2.1.5. DoS and DDos ..............................18
           3.2.2. Other Supporting Protocols .........................18
                  3.2.2.1. Manual Stop ...............................18
                  3.2.2.2. Open Collision Dump .......................18
                  3.2.2.3. Timer Events ..............................18
   4. Security Considerations ........................................19
      4.1. Residual Risk .............................................19
      4.2. Operational Protections ...................................19
   5. References .....................................................21
      5.1. Normative References ......................................21
      5.2. Informative References ....................................21

1. Introduction 🌸

BGP was created back when the Internet wasn't the messy, drama-filled place it is now 🙃 So the BGP design didn't really include protections against mistakes or deliberate attacks that could mess up routing 😬

This doc looks at the vulnerabilities of BGP, and it's based on the BGP spec in [RFC4271] ✨ You're expected to already know the BGP RFC and how BGP behaves, so this isn't a beginner's read 📚

It's super clear that the Internet can be attacked through its routing protocols, and BGP is no exception 💀 Faulty, misconfigured, or straight-up malicious sources can wreck the Internet's behaviour by injecting bogus routing info into the BGP-distributed routing database. They do this by modifying, forging, or replaying BGP packets 🙈 The same tricks can also break local and global network behaviour by messing up how BGP peers talk to each other. And the bogus info can come from outsiders or from actual BGP peers 👀

BGP doesn't have built-in cryptographic authentication for peer-to-peer communication 🔓 Since it runs over TCP/IP, it gets hit by all the usual TCP/IP attacks, like IP spoofing and session stealing 🕵️‍♀️ Any outsider can slip believable BGP messages into the conversation between peers, which lets them inject bogus routing info or break the connection entirely 💔 Any break in peer-to-peer communication can ripple out into routing problems that spread really far 🌊 Outsiders can also disrupt peers by breaking their TCP connection with spoofed packets 😤 And bogus BGP info can come from literally anywhere in the world 🌍

Here's the thing, the current BGP spec says a BGP implementation MUST support the authentication mechanism in [TCPMD5] 🔐 But just supporting it doesn't mean it's actually turned on 😭 The [TCPMD5] mechanism relies on a pre-installed, shared secret, and it can't do what [IPsec] does, which is agreeing on a shared secret dynamically 🙅‍♀️ So using [TCPMD5] has to be a deliberate choice, not something that happens automatically or by default 💅

The current BGP spec also lets implementations accept connections from "unconfigured peers" (see [RFC4271] Section 8) 🤷‍♀️ But the spec isn't clear about what an unconfigured peer even is, or how the protections of [TCPMD5] would work in that case 🫠 So this doc can't analyse the security issues of that feature. When a spec that describes the feature more fully comes out, a security analysis should be part of it ✨

BGP speakers can also inject bogus routing info, either by pretending to be some other legitimate BGP speaker or by sharing unauthorised routing info as themselves 😱 Misconfigured and faulty routers have caused huge Internet disruptions before, historically speaking 📉 Legitimate BGP peers have the context and info to make routing info that looks totally real but is actually bogus, so they have the chance to do serious damage 💀 The protections in [TCPMD5] and operational protections can't rule out bogus info coming from a legit peer 🚨 That risk is real and can't be ignored 🫶

Bogus routing info can cause all kinds of chaos 🌪️ If it removes routing info for a particular network, that network can become unreachable for the part of the Internet that accepts the fake info 🙈 If it changes the route to a network, packets for that network might take a sub-optimal path, a path that doesn't follow the expected policy, or a path that won't actually forward the traffic 🛣️ That means traffic can get delayed by a path way longer than it needs to be, and the network can become unreachable from places that accept the bogus info 😩 Traffic might also get sent along a path where some adversary can view or modify the data 👀 If the bogus info makes it look like an autonomous system originates a network when it really doesn't, packets for that network may not get delivered in the parts of the Internet that accept the fake info 📦 A false claim that an autonomous system originates a network can also break up aggregated address blocks in other parts of the Internet, causing routing problems for other networks too 🧩

These attacks can lead to some pretty serious damage 🥀 Here's the list:

  • starvation: Data traffic headed for a node gets sent to a part of the network that can't actually deliver it 🥺
  • network congestion: More data traffic gets pushed through some part of the network than it really needs to carry 🚗🚗🚗
  • blackhole: Tons of traffic gets sent through one router that can't handle the extra load, so it drops many, most, or all of the packets 🕳️
  • delay: Data traffic headed for a node takes a path that's somehow worse than the one it would normally take 🐢
  • looping: Data traffic goes around in a loop, so it never gets delivered 🔁
  • eavesdrop: Data traffic gets routed through a router or network that wouldn't normally see it, giving someone a chance to read the data 👂
  • partition: Part of the network thinks it's cut off from the rest of the network, even though it totally isn't 🏝️
  • cut: Part of the network thinks it has no route to some network it's actually connected to 🔌
  • churn: Forwarding in the network changes super fast, causing big swings in how data gets delivered (and messing with congestion control) 🌀
  • instability: BGP gets so unstable that the network never settles on one global forwarding state 🫨
  • overload: BGP messages themselves end up being a big chunk of the traffic the network carries 📬
  • resource exhaustion: BGP messages cause critical router resources, like table space, to run out 🪫
  • address-spoofing: Data traffic gets forwarded through a router or network that's faking a legit address, which lets an active attacker modify the data 🎭

These consequences could land on just one end-system prefix, or they could mess with how the whole network operates 🌐 Big yikes energy 😭

1.1. Specification of Requirements 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119] 🎀

2. Attacks ✨

okay so BGP, all on its own, is open to the following attacks 🙈 (this list is borrowed from the IAB RFC that gives guidance for "Security Considerations" sections, [SecCons] 💅)

  • confidentiality violations: the routing data in BGP is sent in cleartext, so eavesdropping is a possible attack on routing data confidentiality 👀 (routing data confidentiality isn't a common requirement, fr)
  • replay: BGP doesn't provide replay protection for its messages 🙃
  • message insertion: BGP doesn't protect against messages being inserted 💀 but since BGP runs over TCP, once the connection is fully established, an outsider inserting messages would need accurate sequence number prediction (not entirely out of the question, but way harder with mature TCP implementations) or session-stealing attacks 🧠
  • message deletion: BGP doesn't protect against messages being deleted 😭 again, this one is harder against a mature TCP implementation, but it's not entirely out of the question
  • message modification: BGP doesn't protect against messages being modified 🫠 a modification that was syntactically correct and didn't change the length of the TCP payload would generally go undetected
  • man-in-the-middle: BGP doesn't protect against man-in-the-middle attacks, and since BGP doesn't do peer entity authentication, a man-in-the-middle attack is child's play 🥴
  • denial of service: bogus routing data can be a denial of service attack on the end systems trying to send data through the network and on the network infrastructure itself 🚨 certain bogus information can also be a denial of service on the BGP routing protocol. for example, advertising large numbers of more specific routes (i.e., longer prefixes) can make BGP traffic and router table size increase, even explode 💥

The mandatory-to-support mechanism of [TCPMD5] will counter message insertion, deletion, and modification, man-in-the-middle and denial of service attacks from outsiders 🛡️ using [TCPMD5] doesn't protect against eavesdropping attacks, but routing data confidentiality isn't a goal of BGP, so that's the vibe 🤷‍♀️ the mechanism of [TCPMD5] doesn't protect against replay attacks either, so the only replay protection comes from TCP sequence number processing. that means a replay attack could still be pulled off against a BGP connection protected with [TCPMD5], but only in very carefully timed circumstances ⏱️ and the mechanism of [TCPMD5] can't protect against bogus routing information that comes from an insider 😤

3. Vulnerabilities and Risks 🔥

the risks in BGP come from three fundamental vulnerabilities, bestie:

  • (1) BGP has no internal mechanism that provides strong protection of the integrity, freshness, and peer entity authenticity of the messages in peer-peer BGP communications 🥺
  • (2) no mechanism has been specified within BGP to validate the authority of an AS to announce NLRI information 🙅‍♀️
  • (3) no mechanism has been specified within BGP to ensure the authenticity of the path attributes announced by an AS 🙅‍♀️

the first fundamental vulnerability is the reason [TCPMD5] support was mandated in the BGP specification 🎀 when [TCPMD5] support is used, message integrity and peer entity authentication are provided ✨ the mechanism of [TCPMD5] assumes that the MD5 algorithm is secure and that the shared secret is protected and chosen to be difficult to guess 🔐

in the discussion that follows, the vulnerabilities are described in terms of the BGP Finite State Machine events. these are defined and discussed in section 8 of [RFC4271]. the events mentioned here are:

[Administrative Events]

     Event 2: ManualStop

     Event 8: AutomaticStop

[Timer Events]

     Event 9: ConnectRetryTimer_Expires

     Event 10: HoldTimer_Expires

     Event 11: KeepaliveTimer_Expires

     Event 12: DelayOpenTimer_Expires
     Event 13: IdleHoldTimer_Expires

[TCP Connection based Events]

     Event 14: TcpConnection_Valid

     Event 16: Tcp_CR_Acked

     Event 17: TcpConnectionConfirmed

     Event 18: TcpConnectionFails

[BGP Messages based Events]

     Event 19: BGPOpen

     Event 20: BGPOpen with DelayOpenTimer running

     Event 21: BGPHeaderErr

     Event 22: BGPOpenMsgErr

     Event 23: OpenCollisionDump

     Event 24: NotifMsgVerErr

     Event 25: NotifMsg

     Event 26: KeepAliveMsg

     Event 27: UpdateMsg

     Event 28: UpdateMsgErr

3.1. Vulnerabilities in BGP Messages 💖

there are four BGP message types: OPEN, KEEPALIVE, NOTIFICATION, and UPDATE 🦋 this section talks about the vulnerabilities from each message and how outsiders or BGP peers can exploit them. the quick version: outsiders can use bogus OPEN, KEEPALIVE, NOTIFICATION, or UPDATE messages to disrupt BGP peer-peer connections, and they can use bogus UPDATE messages to disrupt routing without breaking the peer-peer connection 😩 outsiders can also disrupt peer-peer connections by inserting bogus TCP packets that mess with TCP connection processing. generally, outsiders' ability to use bogus BGP and TCP messages is limited, but not eliminated, by TCP sequence number processing, and [TCPMD5] can counter these outsider attacks 🛡️

BGP peers are allowed to break peer-peer connections at any time using NOTIFICATION messages 👑 so there's no extra risk of broken connections from their use of OPEN, KEEPALIVE, or UPDATE messages. however, BGP peers can disrupt routing (in impermissible ways) by sending UPDATE messages with bogus routing information 😤 in particular, bogus ATOMIC_AGGREGATE, NEXT_HOP and AS_PATH attributes and bogus NLRI in UPDATE messages can disrupt routing. [TCPMD5] won't counter these attacks from BGP peers 🙅‍♀️

each message brings its own vulnerabilities and risks, which we'll get into in the following sections 🧚

3.1.1. Message Header 🎀

Event 21: every BGP message starts with a standard header. in all cases, syntactic errors in the message header make the BGP speaker close the connection, release all associated BGP resources, delete all routes learned through that connection, run its decision process to decide on new routes, and return the state to Idle 🔄 also, optionally, an implementation-specific peer oscillation damping may be performed, and that process can affect how soon the connection can be restarted ⏳ an outsider who could spoof messages with message header errors could cause routing disruptions over a wide area 🌍💀

3.1.2. OPEN 🌸

Event 19: receiving an OPEN message in the Connect or Active states makes the BGP speaker bring down the connection, release all associated BGP resources, delete all associated routes, run its decision process, and return the state to Idle 😵 deleting routes can cascade, with routing changes spreading through other peers 🌊 also, optionally, an implementation-specific peer oscillation damping may be performed, which can affect how soon the connection can be restarted.

in the OpenConfirm or Established state, an arriving OPEN may mean a connection collision has happened 💅 if this connection is going to be dropped, then Event 23 will be issued. (Event 23, discussed below, causes the same set of disruptive actions as listed above for the Connect or Active states.)

in the OpenSent state, an arriving OPEN message makes the BGP speaker move to the OpenConfirm state. if an outsider managed to spoof an OPEN message (which requires very careful timing), then the legitimate peer's OPEN message arriving later might lead the BGP speaker to declare a connection collision 😱 the collision detection procedure might drop the legitimate connection.

so yeah, an outsider's ability to spoof this message can seriously disrupt routing over a wide area 🥀

Event 20: if an OPEN message arrives while the DelayOpen timer is running and the connection is in the OpenSent, OpenConfirm, or Established state, the BGP speaker brings down the connection, releases all associated BGP resources, deletes all associated routes, runs its decision process, and returns the state to Idle 🫨 deleting routes can cascade through other peers, and optionally, an implementation-specific peer oscillation damping may be performed, which can affect how soon the connection can be restarted. but the OpenDelay timer should never be running in these states, so this effect could only be caused by an error in the implementation (a NOTIFICATION is sent with the error code "Finite State Machine Error") 🤓 it would be difficult, if not impossible, for an outsider to induce this Finite State Machine error 🙅‍♀️

in the Connect and Active states, this event causes a transition to the OpenConfirm state. as with Event 19, if an outsider could spoof an OPEN that arrived while the DelayOpen timer was running, a later arriving OPEN from the legitimate peer might be seen as a connection collision, and the legitimate connection could be dropped 😭

so once again, an outsider's ability to spoof this message can lead to a severe disruption of routing over a wide area 🌪️

Event 22: errors in the OPEN message (e.g., unacceptable Hold state, malformed Optional Parameter, unsupported version, etc.) make the BGP speaker bring down the connection, release all associated BGP resources, delete all associated routes, run its decision process, and return the state to Idle 🙃 deleting routes can cascade, with routing changes propagating through other peers. also, optionally, an implementation-specific peer oscillation damping may be performed, which can affect how soon the connection can be restarted. so yeah, an outsider who spoofs this message can cause a severe disruption of routing over a wide area 🥺

3.1.3. KEEPALIVE 🍓

Event 26: receiving a KEEPALIVE message while the peering connection is in the Connect, Active, or OpenSent state makes the BGP speaker move to the Idle state and fail to establish a connection 💔 also, optionally, an implementation-specific peer oscillation damping may be performed, which can affect how soon the connection can be restarted. an outsider spoofing this message can cause a disruption of routing ⚠️ to exploit this deliberately, the KEEPALIVE has to be carefully timed in the sequence of messages exchanged between the peers. otherwise, it does no damage 🫶

3.1.4. NOTIFICATION 🚨

Event 25 💅 okay so, if a BGP speaker gets a NOTIFICATION message in any state, it hangs up the connection, releases all its BGP resources, deletes all the routes tied to that peer, runs its decision process, and goes back to Idle. 😭 The deleted routes can set off a chain reaction where routing changes ripple out through other peers, which is giving domino effect. Optionally, in any state except Established, the speaker can also do an implementation-specific peer oscillation damping. That damping can change how soon the connection is allowed to restart. So if an outsider can fake this message, they can seriously wreck routing across a wide area. 💀

Event 24 🫶 this one is almost the same as Event 25, with a twist: a NOTIFICATION carrying a Version Error error code gets handled the same way, except the optional peer oscillation damping is skipped in the OpenSent and OpenConfirm states, and also in the Connect or Active states when the DelayOpen timer is running. 🎀 So the damage is one tiny bit smaller, since restarting the connection isn't affected. Still not a vibe, though. 🙈

3.1.5. UPDATE 📦

Event 8 ✨ a BGP speaker can optionally decide to automatically disconnect a BGP connection if the total number of prefixes goes over a configured maximum. In that case, an UPDATE might carry enough prefixes to push it over that limit. The speaker then disconnects, releases all its associated BGP resources, deletes all its associated routes, runs its decision process, and returns to Idle. 🌊 Those deleted routes can cascade into routing changes across other peers. Optionally, an implementation-specific peer oscillation damping may also be performed, and that can affect how soon the connection can restart. Same story as before: if an outsider can spoof this message, that's a serious disruption of routing over a wide area. 😬

Event 28 🧚 if the UPDATE message is malformed, the BGP speaker brings the connection down, releases its BGP resources, deletes the associated routes, runs its decision process, and goes back to Idle. (Here, "malformed" means things like a bad Withdrawn Routes Length, Total Attribute Length, or Attribute Length, missing mandatory well-known attributes, Attribute Flags that don't match the Attribute Type Codes, or syntax errors in the ORIGIN, NEXT_HOP or AS_PATH, and so on. 🙃) The route deletion can cascade through other peers too. Optionally, an implementation-specific peer oscillation damping may be performed, which can change how soon the connection can restart. Because an outsider spoofing this message could cause widespread routing disruption, it's a real concern. 💜 BUT, and this is the iconic part, a BGP speaker already has the authority to close a connection whenever it wants, so this message doesn't hand BGP speakers any extra chance to cause damage. 🌸

Event 27 🔥 an UPDATE message that shows up in any state other than Established makes the BGP speaker bring down the connection, release its BGP resources, delete its associated routes, run its decision process, and return to Idle. The deleted routes can cascade through other peers. Optionally, an implementation-specific peer oscillation damping may be performed, and it can affect how soon the connection can restart. Again, if an outsider can spoof this message, it can lead to a severe disruption of routing over a wide area. 🌍

In the Established state, the UPDATE message carries the actual routing information. 👑 So being able to spoof any part of it can disrupt routing, whether the sender is an outsider or a legit BGP speaker. Literally the main character of the whole protocol. 🎬

3.1.5.1. Unfeasible Routes Length, Total Path Attribute Length 🧮

There's a vulnerability when these fields can be modified. 🙈 If someone changes a length, the message probably won't parse properly, which causes an error, a NOTIFICATION message to be sent, and the connection to close (see Event 28, above). A true BGP speaker can close a connection at any time anyway, so this only adds risk when the source isn't the configured BGP peer. In other words, it doesn't add any extra risk from BGP speakers themselves. ✨

3.1.5.2. Withdrawn Routes 🗑️

An outsider could eliminate existing legitimate routes by forging or modifying this field. 😤 They could also knock out routes that had been re-established by replaying old withdrawal information from earlier packets. Yikes. 💀

A BGP speaker could "falsely" withdraw feasible routes using this field. 🤔 BUT, since a BGP speaker is authoritative for the routes it announces, it's allowed to withdraw any previously announced routes it wants. And because the receiving BGP speaker will only withdraw routes associated with the sending BGP speaker, nobody can withdraw another BGP speaker's routes through this field. So there's no additional risk from BGP peers here. 🫶

3.1.5.3. Path Attributes ✨

Okay bestie, the path attributes are where things get seriously spicy 🌶️ They come with a whole buffet of vulnerabilities and risks 💅

  • Attribute Flags, Attribute Type Codes, Attribute Length 🎀

A BGP peer or an outsider could modify the attribute length or attribute type (flags and type codes) so it no longer matches the attribute values that follow. If the flags get changed, they and the type code could become incompatible (e.g., a mandatory attribute marked as partial), or an optional attribute could get read as a mandatory one, or the other way around. If the type code gets changed, the attribute value could be read as the data type and value of a totally different attribute 🙈

The most likely result of messing with the attribute length, flags, or type code is a parse error in the UPDATE message. A parse error would trigger a NOTIFICATION message and the connection closing (see Event 28, above). Since a true BGP speaker can close a connection at any time anyway, this is only an extra risk when the source is an outsider. It's giving nothing new when it comes from a BGP peer 💀

  • ORIGIN 🌸

This field says whether the information was learned from IGP or EGP information. It gets used when making routing decisions, so there's a small vulnerability where someone could affect the receiving BGP speaker's routing decision by changing this field ✨

  • AS_PATH 🦋

A BGP peer or outsider could announce an AS_PATH that isn't accurate for the associated NLRI. Yikes 😭

Here's the tea: a BGP peer might not check that a received AS_PATH starts with the AS number of its peer. So a malicious BGP peer could announce a path that starts with the AS of any BGP speaker, and it wouldn't cost them much. This could mess with the receiving BGP speaker's decision procedure and which route it installs. The malicious peer could also seriously shorten the AS_PATH, which makes that route more likely to get chosen, and that might give the malicious peer access to traffic it wouldn't otherwise get 👀 A shortened AS_PATH could also cause routing loops, since it no longer holds the info needed to prevent them.

A BGP speaker can be configured to accept routes with its own AS number in the AS path. Those operational considerations are defined to be "outside the scope" of the BGP specification. But because AS_PATHs can legitimately have loops, implementations can't just automatically reject routes with loops. Each BGP speaker only checks that its own AS number doesn't appear in the AS_PATH 🧐

Pair this with the ability to use any value for the NEXT_HOP, and a malicious BGP speaker gets a lot of control over the path traffic will take. Iconic villain behavior, honestly 👑

  • Originating Routes 🧚

A special case of announcing a false AS_PATH happens when the AS_PATH advertises a direct connection to a specific network address. A BGP peer or outsider could disrupt routing to the network(s) listed in the NLRI field by falsely advertising a direct connection to that network. The NLRI would become unreachable to the part of the network that accepted this false route, unless the ultimate AS on the AS_PATH agreed to tunnel the packets it was forwarded for this NLRI toward their true destination AS by a valid path. Even when the packets do get tunneled to the correct destination AS, the route followed may not be optimal, or may not follow the intended policy 🙃

It gets worse. Routing for other networks on the Internet could be affected if the false advertisement fragmented an aggregated address block. Then the routers have to handle (issue UPDATES, store, manage) the multiple fragments instead of the single aggregate. False originations for multiple addresses can also flood routers and transit networks along the announced route with misdirected traffic 😭🌊

  • NEXT_HOP 🍓

The NEXT_HOP attribute defines the IP address of the border router that should be used as the next hop when forwarding the NLRI listed in the UPDATE message. If the recipient is an external peer, then the recipient and the NEXT_HOP address must share a subnet. It's super clear that an outsider who changed this field could disrupt traffic forwarding between the two ASes 💥

If the recipient is an external peer of an AS and the route was learned from another peer AS (this is one of two forms of "third party" NEXT_HOP), then the BGP speaker advertising the route gets to direct the recipient to forward traffic to a BGP speaker at the NEXT_HOP address. This makes it possible to aim traffic at a router that might not be able to keep forwarding it. A malicious BGP speaker can also use this trick to force another AS to carry traffic it otherwise wouldn't have to carry. Sometimes that's to the malicious speaker's benefit, since it could make the victim AS haul traffic long-haul to some other peering point they shared 🚚

  • MULTI_EXIT_DISC 🌈

The MULTI_EXIT_DISC attribute gets used in UPDATE messages sent between inter-AS BGP peers. A MULTI_EXIT_DISC received from an inter-AS peer may be passed around within an AS, but it may not be passed on to other ASes. So this field is only used for routing decisions inside one AS. Changing it, whether as an outsider or a BGP peer, could make routing within an AS sub-optimal, but the effect should stay pretty limited in scope 🧸

  • LOCAL_PREF 💜

The LOCAL_PREF attribute must be included in all messages with internal peers, and excluded from messages with external peers. So messing with LOCAL_PREF could only affect the routing process within the AS. There's no requirement in the BGP RFC that LOCAL_PREF be consistent among the internal BGP speakers of an AS, which is a whole mood 🤷‍♀️ BGP peers are free to choose the LOCAL_PREF, so changing this field is a vulnerability only with respect to outsiders.

  • ATOMIC_AGGREGATE 🎀

The ATOMIC_AGGREGATE field says that an AS somewhere along the way aggregated several routes and advertised the aggregate NLRI without the AS_SET being formed the usual way from the ASes in the aggregated routes' AS_PATHs. BGP speakers that receive a route with ATOMIC_AGGREGATE are restricted from making the NLRI any more specific. Removing the ATOMIC_AGGREGATE attribute would lift that restriction, which could make traffic meant for the more specific NLRI get routed incorrectly. Adding ATOMIC_AGGREGATE when no aggregation was done would have little effect, beyond restricting the un-aggregated NLRI from being made more specific. This vulnerability exists whether the source is a BGP peer or an outsider 🙌

  • AGGREGATOR 🌸

This field may be included by a BGP speaker that has computed the routes in the UPDATE message by aggregating other routes. The field contains the AS number and IP address of the last aggregator of the route. It isn't used in making any routing decisions, so it's not a vulnerability. Honestly a chill little field 😌

3.1.5.4. NLRI 🦋

By modifying or forging this field, either an outsider or a BGP peer could cause disruption of routing to the announced network, overwhelm a router along the announced route, cause data loss when the announced route won't forward traffic to the announced network, route traffic by a sub-optimal route, and so on. Chaotic energy 🌪️

3.2. Vulnerabilities through Other Protocols 🧚‍♀️

3.2.1. TCP Messages

BGP runs over TCP, listening on port 179. Therefore, BGP is subject to attack through attacks on TCP. Bestie, it's all connected 🔗

3.2.1.1. TCP SYN 🌊

SYN flooding: Like other protocols, BGP is subject to the effects of SYN flooding attacks on the TCP implementation, and it must rely on the implementation's protections against these attacks.

Event 14: If an outsider could send a SYN to the BGP speaker at the right moment during connection establishment, the legitimate peer's SYN would look like a second connection. If the outsider could then continue with a sequence of packets that results in a BGP connection (guessing the BGP speaker's choice for sequence number on the SYN ACK, for example), the outsider's connection and the legitimate peer's connection would look like a connection collision. Depending on how the collision detection goes (i.e., if the outsider picks a BGP identifier to win the race), the legitimate peer's true connection could be destroyed 😱 The use of [TCPMD5] can counter this attack.

3.2.1.2. TCP SYN ACK 🎀

Event 16: If an outsider could respond to a BGP speaker's SYN before the legitimate peer does, the legitimate peer's SYN-ACK would get an empty ACK reply, which makes the legitimate peer issue a RST that breaks the connection. The BGP speaker would bring down the connection, release all associated BGP resources, delete all associated routes, and run its decision process. This attack requires the outsider to be able to predict the sequence number used in the SYN. The use of [TCPMD5] can counter this attack.

3.2.1.3. TCP ACK 🫧

Event 17: If an outsider could spoof an ACK at the right moment during connection establishment, the BGP speaker would consider the connection complete, send an OPEN (Event 17), and move to the OpenSent state. The arrival of the legitimate peer's ACK wouldn't be delivered to the BGP process, since it would look like a duplicate packet. So this message doesn't present a vulnerability to BGP during connection establishment ✅ Spoofing an ACK after connection establishment requires knowledge of the sequence numbers in use, and that's, in general, a very difficult task. The use of [TCPMD5] can counter this attack.

3.2.1.4. TCP RST/FIN/FIN-ACK 💅

Event 18: If an outsider could spoof a RST, the BGP speaker would bring down the connection, release all associated BGP resources, delete all associated routes, and run its decision process. If an outsider could spoof a FIN, data could still be transmitted, but any attempt to receive it would trigger a notification that the connection is closing. In most cases, this puts the connection in an Idle state. But if the connection is in the Connect state or the OpenSent state at the time, the connection will return to an Active state.

Spoofing a RST in this situation requires an outsider to guess a sequence number that only needs to be within the receive window [Watson04]. That's generally an easier task than guessing the exact sequence number required to spoof a FIN. The use of [TCPMD5] can counter this attack 🛡️

3.2.1.5. DoS and DDos 💀

Because the packets directed to TCP port 179 are passed to the BGP process, which potentially lives on a slower processor in the router, flooding a router with TCP port 179 packets is a way to launch DoS attacks against the router. No BGP mechanism can defeat such attacks, so other mechanisms have to be employed 🚨

3.2.2. Other Supporting Protocols 🌈

3.2.2.1. Manual Stop

Okay bestie, Event 2 is the manual stop 🛑. When it fires, the BGP speaker brings the connection down, releases all its associated BGP resources, deletes all its associated routes, and runs its decision process. ngl, if the mechanism that tells a speaker about a manual stop isn't carefully protected, an outsider could destroy the BGP connection 💀. So BGP security is secondarily dependent on the security of the management and configuration protocols that are used to signal this event. Lock those signals down, periodt 🔒.

3.2.2.2. Open Collision Dump

Event 23 is the OpenCollisionDump event 🌸. It may be generated administratively when a connection collision event is detected and the connection has been selected to be disconnected. When it happens in any state, the BGP connection is dropped, the BGP resources are released, the associated routes are deleted, etc. The main character energy here is that BGP security is secondarily dependent on the security of the management and configuration protocols that are used to signal this event 👑.

3.2.2.3. Timer Events

Events 9-13 are all about timers ⏰. BGP employs five timers (ConnectRetry, Hold, Keepalive, MinASOrigination-Interval, and MinRouteAdvertisementInterval) and two optional timers (DelayOpen and IdleHold). These are critical to BGP operation 😭. For example, if the Hold timer value were changed, the remote peer might decide the connection is unresponsive and bring it down, which releases resources, deletes associated routes, and so on 💀. So BGP security is secondarily dependent on the security of the operation, management, and configuration protocols that are used to modify the timers 🧚.

4. Security Considerations 🔐

Okay, this entire memo is literally about security 🦋. It describes an analysis of the vulnerabilities that exist in BGP, so buckle up.

Using the mandatory-to-support mechanisms of [TCPMD5] counters message insertion, deletion, and modification attacks, as well as man-in-the-middle attacks by outsiders 🛡️. If routing data confidentiality is desired (there is some controversy as to whether it is a desirable security service), IPsec ESP could provide that service 🤔.

4.1. Residual Risk

As cryptographic-based mechanisms, both [TCPMD5] and IPsec [IPsec] assume that the cryptographic algorithms are secure. They also assume that the secrets used are protected from exposure and chosen well so they can't be guessed, and that the platforms are securely managed and operated to prevent break-ins, etc. 🔑

These mechanisms do not prevent attacks that come from a router's legitimate BGP peers 😬. There are several possible solutions to stop a BGP speaker from inserting bogus information into its advertisements to its peers (i.e., from mounting an attack on a network's origination or AS-PATH):

(1) Origination Protection: sign the originating AS. ✍️

(2) Origination and Adjacency Protection: sign the originating AS and predecessor information ([Smith96])

(3) Origination and Route Protection: sign the originating AS, and nest signatures of AS_PATHs to the number of consecutive bad routers you want to prevent from causing damage. ([SBGP00])

(4) Filtering: rely on a registry to verify the AS_PATH and NLRI originating AS ([RPSL]).

Filtering is in use near some customer attachment points, but it is not effective near the Internet center. The other mechanisms are still controversial and are not yet in common use 🧐.

4.2. Operational Protections

BGP is primarily used to provide reachability information to Autonomous Systems (AS), and to distribute external reachability internally within an AS 🌐. It's the routing protocol used to distribute global routing information across the Internet. That means BGP is used by all major Internet Service Providers (ISP), as well as many smaller providers and other organizations 👑.

BGP's role on the Internet puts BGP implementations in unique conditions and places unique security requirements on BGP 💅. It operates over interprovider interfaces where traffic levels push the state of the art in specialized packet forwarding hardware, and they exceed the performance of hardware-implemented decryption by many orders of magnitude 🔥. A single attacker with a workstation and a high-speed interface can generate false traffic for denial of service (DoS) far faster than software decryption, or reasonably priced cryptographic hardware, can detect it 💀. In those conditions, one way to protect network elements from DoS attacks is packet-based filtering based on relatively simple inspections of packets. So for an ISP carrying large volumes of traffic, the ability to packet filter by port number is an important protection against DoS attacks, and a necessary companion to cryptographic strength in encapsulation 🛡️.

Current ISP practice uses certain common filtering techniques to reduce exposure to attacks from outside the ISP 🧱. To protect Internal BGP (IBGP) sessions, filters are applied at all borders of an ISP network. This removes all traffic destined for network elements' internal addresses (typically contained within a single prefix) and the BGP port number (179). If the BGP port number is found, packets from inside an ISP are not forwarded from an internal interface to the BGP speaker's address (where External BGP (EBGP) sessions are supported), or to a peer's EBGP address 🚧. Good router design can limit the risk of compromise when a BGP peer fails to provide adequate filtering. The risk can be limited to the peering session where the peer doesn't filter, or to the interface or line card where the peering is supported 🎀. There is substantial motivation, and little effort is required, for ISPs to maintain these filters 💖.

These operational practices can considerably raise the difficulty for an outsider trying to launch a DoS attack against an ISP 🙈. If the attacker can't inject enough traffic from outside the network to pull off a DoS attack, they'd have to take on harder tasks, like compromising the ISP's network elements or undetected tapping into physical media 😈.

5. References 📚

5.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
  • [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
  • [RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

5.2. Informative References

  • [IPsec] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
  • [SBGP00] Kent, S., Lynn, C. and Seo, K., "Secure Border Gateway Protocol (Secure-BGP)", IEEE Journal on Selected Areas in Communications, Vol. 18, No. 4, April 2000, pp. 582-592.
  • [SecCons] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
  • [Smith96] Smith, B. and Garcia-Luna-Aceves, J.J., "Securing the Border Gateway Routing Protocol", Proc. Global Internet '96, London, UK, 20-21 November 1996.
  • [RPSL] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, "Routing Policy System Security", RFC 2725, December 1999.
  • [Watson04] Watson, P., "Slipping In The Window: TCP Reset Attacks", CanSecWest 2004, April 2004.

Author's Address 🎀

Sandra Murphy
Sparta, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046

EMail: Sandy@tislabs.com

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors keep all their rights 💜.

This document and the information in it are provided on an "AS IS" basis. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 🙏.

Intellectual Property 🌈

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology described in this document. It also takes no position on whether any license under those rights might be available. It doesn't claim to have made any independent effort to identify such rights 🤷‍♀️. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use these proprietary rights, can be obtained from the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement 🫶

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 💖.

📦 where this page comes from