Request for Comments: 4272 Sparta, Inc.
Category: Informational January 2006
BGP Security Vulnerabilities Analysis
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Border Gateway Protocol 4 (BGP-4), along with a host of other
infrastructure protocols designed before the Internet environment
became perilous, was originally designed with little consideration
for protection of the information it carries. There are no
mechanisms internal to BGP that protect against attacks that modify,
delete, forge, or replay data, any of which has the potential to
disrupt overall network routing behavior.
This document discusses some of the security issues with BGP routing
data dissemination. This document does not discuss security issues
with forwarding of 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
The inter-domain routing protocol BGP was created when the Internet
environment had not yet reached the present, contentious state.
Consequently, the BGP design did not include protections against
deliberate or accidental errors that could cause disruptions of
routing behavior.
This document discusses the vulnerabilities of BGP, based on the BGP
specification [RFC4271]. Readers are expected to be familiar with
the BGP RFC and the behavior of BGP.
It is clear that the Internet is vulnerable to attack through its
routing protocols and BGP is no exception. Faulty, misconfigured, or
deliberately malicious sources can disrupt overall Internet behavior
by injecting bogus routing information into the BGP-distributed
routing database (by modifying, forging, or replaying BGP packets).
The same methods can also be used to disrupt local and overall
network behavior by breaking the distributed communication of
information between BGP peers. The sources of bogus information can
be either outsiders or true BGP peers.
Cryptographic authentication of peer-peer communication is not an
integral part of BGP. As a TCP/IP protocol, BGP is subject to all
TCP/IP attacks, e.g., IP spoofing, session stealing, etc. Any
outsider can inject believable BGP messages into the communication
between BGP peers, and thereby inject bogus routing information or
break the peer-peer connection. Any break in the peer-peer
communication has a ripple effect on routing that can be widespread.
Furthermore, outsider sources can also disrupt communications between
BGP peers by breaking their TCP connection with spoofed packets.
Outsider sources of bogus BGP information can reside anywhere in the
world.
Consequently, the current BGP specification requires that a BGP
implementation must support the authentication mechanism specified in
[TCPMD5]. However, the requirement for support of that
authentication mechanism cannot ensure that the mechanism is
configured for use. The mechanism of [TCPMD5] is based on a pre-
installed, shared secret; it does not have the capability of IPsec
[IPsec] to agree on a shared secret dynamically. Consequently, the
use of [TCPMD5] must be a deliberate decision, not an automatic
feature or a default.
The current BGP specification also allows for implementations that
would accept connections from "unconfigured peers" ([RFC4271] Section
8). However, the specification is not clear as to what an
unconfigured peer might be, or how the protections of [TCPMD5] would
apply in such a case. Therefore, it is not possible to include an
analysis of the security issues of this feature. When a
specification that describes this feature more fully is released, a
security analysis should be part of that specification.
BGP speakers themselves can inject bogus routing information, either
by masquerading as any other legitimate BGP speaker, or by
distributing unauthorized routing information as themselves.
Historically, misconfigured and faulty routers have been responsible
for widespread disruptions in the Internet. The legitimate BGP peers
have the context and information to produce believable, yet bogus,
routing information, and therefore have the opportunity to cause
great damage. The cryptographic protections of [TCPMD5] and
operational protections cannot exclude the bogus information arising
from a legitimate peer. The risk of disruptions caused by legitimate
BGP speakers is real and cannot be ignored.
Bogus routing information can have many different effects on routing
behavior. If the bogus information removes routing information for a
particular network, that network can become unreachable for the
portion of the Internet that accepts the bogus information. If the
bogus information changes the route to a network, then packets
destined for that network may be forwarded by a sub-optimal path, or
by a path that does not follow the expected policy, or by a path that
will not forward the traffic. Consequently, traffic to that network
could be delayed by a path that is longer than necessary. The
network could become unreachable from areas where the bogus
information is accepted. Traffic might also be forwarded along a
path that permits some adversary to view or modify the data. If the
bogus information makes it appear that an autonomous system
originates a network when it does not, then packets for that network
may not be deliverable for the portion of the Internet that accepts
the bogus information. A false announcement that an autonomous
systems originates a network may also fragment aggregated address
blocks in other parts of the Internet and cause routing problems for
other networks.
The damages that might result from these attacks include:
starvation: Data traffic destined for a node is forwarded to a
part of the network that cannot deliver it.
network congestion: More data traffic is forwarded through some
portion of the network than would otherwise need to carry the
traffic.
blackhole: Large amounts of traffic are directed to be forwarded
through one router that cannot handle the increased level of
traffic and drops many/most/all packets.
delay: Data traffic destined for a node is forwarded along a path
that is in some way inferior to the path it would otherwise take.
looping: Data traffic is forwarded along a path that loops, so
that the data is never delivered.
eavesdrop: Data traffic is forwarded through some router or
network that would otherwise not see the traffic, affording an
opportunity to see the data.
partition: Some portion of the network believes that it is
partitioned from the rest of the network, when, in fact, it is
not.
cut: Some portion of the network believes that it has no route to
some network to which it is, in fact, connected.
churn: The forwarding in the network changes at a rapid pace,
resulting in large variations in the data delivery patterns (and
adversely affecting congestion control techniques).
instability: BGP becomes unstable in such a way that convergence
on a global forwarding state is not achieved.
overload: The BGP messages themselves become a significant portion
of the traffic the network carries.
resource exhaustion: The BGP messages themselves cause exhaustion
of critical router resources, such as table space.
address-spoofing: Data traffic is forwarded through some router or
network that is spoofing the legitimate address, thus enabling an
active attack by affording the opportunity to modify the data.
These consequences can fall exclusively on one end-system prefix or
may effect the operation of the network as a whole.
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
BGP, in and of itself, is subject to the following attacks. (The
list is taken from the IAB RFC that provides guidelines for the
"Security Considerations" section of RFCs [SecCons].)
confidentiality violations: The routing data carried in BGP is
carried in cleartext, so eavesdropping is a possible attack
against routing data confidentiality. (Routing data
confidentiality is not a common requirement.)
replay: BGP does not provide for replay protection of its
messages.
message insertion: BGP does not provide protection against
insertion of messages. However, because BGP uses TCP, when the
connection is fully established, message insertion by an outsider
would require accurate sequence number prediction (not entirely
out of the question, but more difficult with mature TCP
implementations) or session-stealing attacks.
message deletion: BGP does not provide protection against
deletion of messages. Again, this attack is more difficult
against a mature TCP implementation, but is not entirely out of
the question.
message modification: BGP does not provide protection against
modification of messages. A modification that was syntactically
correct and did not change the length of the TCP payload would in
general not be detectable.
man-in-the-middle: BGP does not provide protection against man-
in-the-middle attacks. As BGP does not perform peer entity
authentication, a man-in-the-middle attack is child’s play.
denial of service: While bogus routing data can present a denial
of service attack on the end systems that are trying to transmit
data through the network and on the network infrastructure itself,
certain bogus information can represent a denial of service on the
BGP routing protocol. For example, advertising large numbers of
more specific routes (i.e., longer prefixes) can cause BGP traffic
and router table size to 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. The use of [TCPMD5] does not
protect against eavesdropping attacks, but routing data
confidentiality is not a goal of BGP. The mechanism of [TCPMD5] does
not protect against replay attacks, so the only protection against
replay is provided by the TCP sequence number processing. Therefore,
a replay attack could be mounted against a BGP connection protected
with [TCPMD5] but only in very carefully timed circumstances. The
mechanism of [TCPMD5] cannot protect against bogus routing
information that originates from an insider.
3. Vulnerabilities and Risks
The risks in BGP arise from three fundamental vulnerabilities:
(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 motivated the mandated support of
[TCPMD5] in the BGP specification. When the support of [TCPMD5] is
employed, 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. The events 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 different BGP message types - OPEN, KEEPALIVE,
NOTIFICATION, and UPDATE. This section contains a discussion of the
vulnerabilities arising from each message and the ability of
outsiders or BGP peers to exploit the vulnerabilities. To summarize,
outsiders can use bogus OPEN, KEEPALIVE, NOTIFICATION, or UPDATE
messages to disrupt the BGP peer-peer connections. They can use
bogus UPDATE messages to disrupt routing without breaking the peer-
peer connection. Outsiders can also disrupt BGP peer-peer
connections by inserting bogus TCP packets that disrupt the TCP
connection processing. In general, the ability of outsiders to use
bogus BGP and TCP messages is limited, but not eliminated, by the TCP
sequence number processing. The use of [TCPMD5] can counter these
outsider attacks. BGP peers themselves are permitted to break peer-
peer connections, at any time, using NOTIFICATION messages. Thus,
there is no additional risk of broken connections through their use
of OPEN, KEEPALIVE, or UPDATE messages. However, BGP peers can
disrupt routing (in impermissible ways) by issuing UPDATE messages
that contain bogus routing information. In particular, bogus
ATOMIC_AGGREGATE, NEXT_HOP and AS_PATH attributes and bogus NLRI in
UPDATE messages can disrupt routing. The use of [TCPMD5] will not
counter these attacks from BGP peers.
Each message introduces certain vulnerabilities and risks, which are
discussed in the following sections.
3.1.1. Message Header
Event 21: Each BGP message starts with a standard header. In all
cases, syntactic errors in the message header will cause the BGP
speaker to 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 cause the state to
return to Idle. Also, optionally, an implementation-specific peer
oscillation damping may be performed. The peer oscillation damping
process can affect how soon the connection can be restarted. An
outsider who could spoof messages with message header errors could
cause disruptions in routing over a wide area.
3.1.2. OPEN
Event 19: Receipt of an OPEN message in states Connect or Active
will cause the BGP speaker to bring down the connection, release all
associated BGP resources, delete all associated routes, run its
decision process, and cause the state to return to Idle. The
deletion of routes can cause a cascading effect in which routing
changes propagate through other peers. Also, optionally, an
implementation-specific peer oscillation damping may be performed.
The peer oscillation damping process can affect how soon the
connection can be restarted.
In state OpenConfirm or Established, the arrival of an OPEN may
indicate a connection collision has occurred. If this connection is
to be dropped, then Event 23 will be issued. (Event 23, discussed
below, results in the same set of disruptive actions as mentioned
above for states Connect or Active.)
In state OpenSent, the arrival of an OPEN message will cause the BGP
speaker to transition to the OpenConfirm state. If an outsider was
able to spoof an OPEN message (requiring very careful timing), then
the later arrival of the legitimate peer’s OPEN message might lead
the BGP speaker to declare a connection collision. The collision
detection procedure may cause the legitimate connection to be
dropped.
Consequently, the ability of an outsider to spoof this message can
lead to a severe disruption of routing over a wide area.
Event 20: If an OPEN message arrives when the DelayOpen timer is
running when the connection is in state OpenSent, OpenConfirm or
Established, the BGP speaker will bring down the connection, release
all associated BGP resources, delete all associated routes, run its
decision process, and cause the state to return to Idle. The
deletion of routes can cause a cascading effect in which routing
changes propagate through other peers. Also, optionally, an
implementation-specific peer oscillation damping may be performed.
The peer oscillation damping process can affect how soon the
connection can be restarted. However, because the OpenDelay timer
should never be running in these states, 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 states Connect and Active, this event will cause a transition to
the OpenConfirm state. As in Event 19, if an outsider were able to
spoof an OPEN, which arrived while the DelayOpen timer was running,
then a later arriving OPEN (from the legitimate peer) might be
considered a connection collision and the legitimate connection could
be dropped.
Consequently, the ability of an outsider 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.) will cause
the BGP speaker to bring down the connection, release all associated
BGP resources, delete all associated routes, run its decision
process, and cause the state to return to Idle. The deletion of
routes can cause a cascading effect in which routing changes
propagate through other peers. Also, optionally, an implementation-
specific peer oscillation damping may be performed. The peer
oscillation damping process can affect how soon the connection can be
restarted. Consequently, the ability of an outsider to spoof this
message can lead to a severe disruption of routing over a wide area.
3.1.3. KEEPALIVE
Event 26: Receipt of a KEEPALIVE message, when the peering
connection is in the Connect, Active, and OpenSent states, would
cause the BGP speaker to transition to the Idle state and fail to
establish a connection. Also, optionally, an implementation-specific
peer oscillation damping may be performed. The peer oscillation
damping process can affect how soon the connection can be restarted.
The ability of an outsider to spoof this message can lead to a
disruption of routing. To exploit this vulnerability deliberately,
the KEEPALIVE must be carefully timed in the sequence of messages
exchanged between the peers; otherwise, it causes no damage.
3.1.4. NOTIFICATION
Event 25: Receipt of a NOTIFICATION message in any state will cause
the BGP speaker to bring down the connection, release all associated
BGP resources, delete all associated routes, run its decision
process, and cause the state to return to Idle. The deletion of
routes can cause a cascading effect in which routing changes
propagate through other peers. Also, optionally, in any state but
Established, an implementation-specific peer oscillation damping may
be performed. The peer oscillation damping process can affect how
soon the connection can be restarted. Consequently, the ability of
an outsider to spoof this message can lead to a severe disruption of
routing over a wide area.
Event 24: A NOTIFICATION message carrying an error code of "Version
Error" behaves the same as in Event 25, with the exception that the
optional peer oscillation damping is not performed in states OpenSent
or OpenConfirm, or in states Connect or Active if the DelayOpen timer
is running. Therefore, the damage caused is one small bit less,
because restarting the connection is not affected.
3.1.5. UPDATE
Event 8: A BGP speaker may optionally choose to automatically
disconnect a BGP connection if the total number of prefixes exceeds a
configured maximum. In such a case, an UPDATE may carry a number of
prefixes that would result in that maximum being exceeded. The BGP
speaker would disconnect the connection, release all associated BGP
resources, delete all associated routes, run its decision process,
and cause the state to return to Idle. The deletion of routes can
cause a cascading effect in which routing changes propagate through
other peers. Also, optionally, an implementation-specific peer
oscillation damping may be performed. The peer oscillation damping
process can affect how soon the connection can be restarted.
Consequently, the ability of an outsider to spoof this message can
lead to a severe disruption of routing over a wide area.
Event 28: If the UPDATE message is malformed, then the BGP speaker
will bring down the connection, release all associated BGP resources,
delete all associated routes, run its decision process, and cause the
state to return to Idle. (Here, "malformed" refers to improper
Withdrawn Routes Length, Total Attribute Length, or Attribute Length,
missing mandatory well-known attributes, Attribute Flags that
conflict with the Attribute Type Codes, syntactic errors in the