wdiff draft-murphy-bgp-vuln-01.txt draft-murphy-bgp-vuln-02.txt

Network Working Group Sandra Murphy
INTERNET DRAFT NAI Labs
draft-murphy-bgp-vuln-01.txt October 2002
draft-murphy-bgp-vuln-02.txt March 2003

BGP Security Vulnerabilities Analysis

Status of this Memo

This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

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.

Abstract

BGP, along with a host of other infrastructure protocols designed before
the Internet environment became perilous, is was originally designed with
little consideration for protection of the information it carries.
There are no mechanisms in internal to the BGP protocol to protect against
attacks that modify, delete, forge, or replay data, any of which has the
potential to disrupt overall network routing behavior.

This internet draft discusses some of the security issues with BGP
routing data dissemination. A companion work, [5], discusses possible
security solutions and the costs of those solutions. This internet draft does not discuss
security issues with forwarding of packets.

Table of Contents

Status of this Memo .............................................. 1
Specification of Requirements .................................... 1
Abstract ......................................................... 1
1 Introduction .................................................... 3 4
2 Attacks ......................................................... 6
3 Vulnerabilities and Risks ....................................... 5
2.1 7
3.1 Vulnerabilities in BGP messages ............................... 8
3.1.1 Message Header .............................................. 8
3.1.2 OPEN .......................................................... 5
2.2 ........................................................ 8
3.1.3 KEEPALIVE ..................................................... 6
2.3 ................................................... 9
3.1.4 NOTIFICATION .................................................. 6
2.4 ................................................ 9
3.1.5 UPDATE ........................................................ 6
2.4.1 ...................................................... 10
3.1.5.1 Unfeasible Routes Length, Total Path Attribute Length ....... 6
2.4.2 ..... 10
3.1.5.2 Withdrawn Routes ............................................ 6
2.4.3 .......................................... 10
3.1.5.3 Path Attributes ............................................. 7 ........................................... 11
Attribute Flags, Attribute Type Codes, Attribute Length .......... 7 11
ORIGIN ........................................................... 7 11
AS_PATH .......................................................... 7 11
Originating Routes ............................................... 8 12
NEXT_HOP ......................................................... 9 12
MULTI_EXIT_DISC .................................................. 9 13
LOCAL_PREF ....................................................... 9 13
ATOMIC_AGGREGATE ................................................. 9 13
AGGREGATOR ....................................................... 10
2.4.4 14
3.1.5.4 NLRI ........................................................ 10
2.5 BGP Extensions ...................................................... 14
3.2 Vulnerabilities through Other Protocols ....................... 14
3.2.1 TCP messages ................................................ 10
2.5.1 Communities ................................................. 10
2.5.2 Confederations 14
3.2.1.1 TCP SYN ................................................... 14
3.2.1.2 TCP SYN ACK ............................................... 15
3.2.1.3 TCP ACK ................................................... 15
3.2.1.4 TCP RST/FIN/FIN-ACK ....................................... 15
3.2.2 Other supporting protocols .................................. 16
3.2.2.1 Manual stop ............................................... 16
3.2.2.2 Timer events .............................................. 11
3 16
4 Security Considerations ......................................... 11
4 16
4.1 Residual Risk ................................................. 16
5 References ...................................................... 11
5 17
6 Author's Address ................................................ 12 18
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 protocol was not designed with protection against
deliberate or accidental errors causing disruptions of routing behavior.

We here discuss the vulnerabilities of BGP, based on the BGP RFC [1] and
on [2]. Readers are expected to be familiar with the BGP RFC and the
behavior of BGP. A companion work, [5], proposes several different
security solutions to protect these vulnerabilities and discuss the
benefits derived from each solution and its cost.

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.

Under the present BGP design, cryptographic

Cryptographic authentication of the peer-
peer peer-peer communication is not mandated. an
integral part of the BGP protocol. As a TCP/IP protocol, BGP is subject
to all the TCP/IP attacks, like 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 to peer connection. Any break in the peer to peer
communication has a ripple effect on routing that can be wide spread.
Furthermore, outsider sources can also disrupt communications between
BGP peers by breaking their TCP connection with spoofed RST 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
[6]. However, the requirement for support of that authentication
mechanism cannot ensure that the mechanism is configured for use. As
the current BGP specification also allows for implementations that would
accept connections from unconfigured peers ([2] Section 8), the
authentication mechanism of [6] must be a configurable option. This is
necessary because [6] is based on a pre-installed shared secret that
could not be available for an unconfigured peer. The mechanism of [6]
does not have the capability of IPSEC ([5]) to agree on a shared secret
dynamically.

BGP speakers themselves can inject bogus routing information, either by
masquerading as information from any other legitimate BGP speaker, or by distributing
unauthentic routing information as themselves. Historically,
misconfigured and faulty routers have been responsible for widespread
disruptions in the Internet.

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 a path that does
not follow the expected policy, or a path that will not forward the
traffic. As a consequence, traffic to that network could be delayed by
a longer than necessary path. 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 a view of 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 damage that might result from these attacks are:

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 it is not,

cut: some portion of the network believes that it has no route to
some network that 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 become unstable so that convergence on a global
forwarding state is not achieved, and

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.

These consequences can fall exclusively on one end system prefix or may
effect the operation of the network as a whole.

2. Attacks

The BGP protocol, in and of itself, is subject to the following attacks
(list taken from the IAB Internet-Draft providing guideline for the
security considerations section of Internet-Drafts [8]):

eavesdropping: 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, more difficult against a mature TCP
implementation but not entirely out of the question

message modification: BGP does not provide protection against
modification of messages. A modification that did not change the
length of the TCP payload would in general not be detectable.

man-in-the-middle: BGP does not provide protection agains man-in-
the-middle attacks. As BGP does no peer entity authentication, a
man-in-the-middle attack is childs-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 (longer prefixes) can cause BGP traffic and
router table size to increase, even explode.

The mandatory-to-support mechanism of [6] will counter the message
insertion, deletion, and modification, man-in-the-middle attacks and the
denial of service attacks from outsiders. The use of [6] does not
protect against eavesdropping attacks, but routing data confidentiality
is not a goal of BGP. The mechanism of [6] does not protect against
replay attacks, so the only protection against replay is provided by the
TCP sequence number processing. A replay attack could be mounted
against a BGP connection protected with [6] but only in very carefully
timed circumstances.

3. Vulnerabilities and Risks

The risks in BGP arise from three fundamental vulnerabilities:

BGP has no internal mechanism has been mandated that provides strong protection of
the integrity, freshness and source peer entity authenticity of the
messages in peer-peer BGP communications.

no mechanism has been specified within BGP to validate the
authority of an AS to announce NLRI information.

no mechanism has been specified within BGP to ensure the
authenticity of the
AS_PATH path attributes announced by an AS.

The first basic vulnerability motivated the mandated support of [6] in
the BGP specification. When that is employed, message integrity and
peer entity authentication is provided. The mechanism of [6] assumes
that the MD5 algorithm is secure and that the shared secret is protected
and chosen to be difficult to guess.

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, or NOTIFICATION messages to disrupt the
BGP peer-peer connections and can use bogus UPDATE messages to disrupt
routing. Outsiders can also disrupt BGP peer-peer connections by
inserting bogus TCP RST packets. BGP peers themselves are permitted to
break peer-peer connections at any time, and so they cannot be said to
be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages. However,
BGP peers can disrupt routing by issuing bogus UPDATE messages. In
particular, bogus ATOMIC_AGGREGATE ATOMIC_AGGREGATE, NEXT_HOP and AS_PATH attributes and
bogus NLRI in UPDATE messages can disrupt routing.

Each message introduces certain different vulnerabilities and risks.

2.1. OPEN

Because receipt of

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 and run its decision process to
decide on new routes.

3.1.2. OPEN

Event 19: Receipt of an OPEN message in the state Connect, Active or
Established will cause the 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 of routing changes
propogating 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 OpenSent, the arrival of an OPEN message will cause
the close BGP speaker to transition to the OpenConfirm state. The later
arrival of the legitimate peer's OPEN message will lead the BGP peering session and thereby induce speaker
to declare a connection collision. The collision detection procedure
may cause the
release legitimate connection to be dropped. Consequently, the
ability 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 OpenDelay timer is running
when the connection is in state OpenSent or Established, the BGP speaker
will bring down the connection, release all resources 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 of routing changes propogating through other peers. Also,
optionally, an implementation specific peer oscillation damping may
performed. The peer oscillation damping process can affect how soon the
connection can be restarted. However, as the OpenDelay timer should
never be running in the state OpenSent, this could only be caused by an
error in the implementation (which is why the error code is "Finite
State Machine Error"). It would be difficult, if not impossible, for an
outsider to induce this error.

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 of routing changes propogating through other peers.
Also, optionally, an implementation specific peer oscillation damping
may performed. The peer oscillation damping process can affect how soon
the connection can be restarted. Consequently, the ability to spoof
this message can lead to a severe disruption of
routing.

2.2. 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 state can lead states would cause the BGP speaker
to a failure transition to the Idle state and fail to establish a connection. The
ability to spoof this message is a vulnerability. 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.

2.3.

3.1.4. NOTIFICATION

Event 25: Receipt of a NOTIFICATION message in any state will cause the close of the
BGP
peering session and thereby induce speaker to bring down the connection, release of all resources associated BGP
resources, delete all associated routes, run its decision process and
cause the state to return to Idle. The deletion of all associated routes. Therefore, routes can cause a
cascading effect of routing changes propogating through other peers.
Also, optionally, an implementation specific peer oscillation damping
may performed. The peer oscillation damping process can affect how soon
the connection can be restarted. Consequently, the ability to spoof
this message can lead to a severe disruption of routing.

2.4. 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 Connect
and Active, only when the OpenDelay timer is running). The damage
caused is therefore one small bit less, in that restarting the
connection is not affected.

3.1.5. UPDATE

Event 27: The Update message carries the routing information. The
ability to spoof any part of this message can lead to a disruption of
routing.

2.4.1.

3.1.5.1. Unfeasible Routes Length, Total Path Attribute Length

There is a vulnerability arising from the ability to modify these
fields. If a length is modified, the message is not likely to parse
properly, resulting in an error, the transmission of a NOTIFICATION
message and the close of the connection. connection (see Event 28, below). As a
true BGP speaker is always able to close a connection at any time, this
vulnerability represents an additional risk only when the source is a non-BGP speaker, not
the configured BGP peer, i.e., it presents no additional risk from BGP
sources.

2.4.2.

3.1.5.2. Withdrawn Routes

An outsider could cause the elimination of existing legitimate routes by
forging or modifying this field. An outsider could also cause the
elimination of reestablished routes by replaying this withdrawal
information from earlier packets.

A BGP speaker could "falsely" withdraw feasible routes using this field.
However, as the BGP speaker is authoritative for the routes it will
announce, it is allowed to withdraw any previously announced routes that
it wants. As the receiving BGP speaker will only withdraw routes
associated with the sending BGP speaker, there is no opportunity for a
BGP speaker to withdraw another BGP speaker's routes. Therefore, there
is no additional risk from BGP peers via this field.

2.4.3.

3.1.5.3. Path Attributes

The path attributes present many different 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 they did not reflect the attribute values
that followed. If the flags were modified, the flags and type code
could become incompatible (i.e., a mandatory attribute marked as
partial), or a optional attribute could be interpreted as a mandatory
attribute or vice versa. If the type code were modified, the attribute
value could be interpreted as if it were the data type and value of a
different attribute.

The most likely result from modifying the attribute length, flags, or
type code would be a parse error of the UPDATE message. A parse error
would cause the transmission of a NOTIFICATION message and the close of
the connection. connection (see Event 28, below). As a true BGP speaker is always
able to close a connection at any time, this vulnerability represents an
additional risk only when the source is an outsider, i.e., it presents
no additional risk from a BGP peer.

ORIGIN

This field indicates whether the information was learned from IGP or EGP
information. If the route is used in inter-AS multicast routing, a
value of INCOMPLETE may be used. This field is not used in making routing decisions, so there are no vulnerabilities arising from this
field, either from
is some small vulnerability in being able to affect the receiving BGP peers or outsiders.
speaker's routing decision by modifying this field.

AS_PATH

A BGP peer or outsider could announce an AS_PATH that was not accurate
for the associated NLRI. Forwarding for the NLRI associated with the
AS_PATH could potentially be induced to follow a sub-optimal path, a
path that did not follow some intended policy, or even a path that would
not forward the traffic. If the path would not forward the traffic, the
NLRI would become unreachable for that portion of the Internet that
accepted the false path. If much traffic is mis-directed, some routers
and transit networks along the announced route could become flooded with
the mis-directed traffic.

As it is not clear how far an inaccurate AS_PATH could deviate from the
true AS_PATH. It may be that the first AS in the AS_PATH, at least,
must be a legal hop. The RFC states that legitimate for a BGP speaker prepends its own
AS to an AS_PATH before announcing it peer not to a neighbor. If the BGP speaker
must prepend its own AS, then a BGP speaker verify that produced a bogus received AS_PATH could end up receiving the traffic for the associated NLRI.
This could be desirable if the error was deliberate and the intent was
to receive traffic that would not otherwise be received. Receiving the
mis-routed traffic could be undesirable for the faulty BGP speaker if it
were not prepared to handle
begins with the extra (mis-routed) traffic. So,
requiring a BGP peer to prepend its own AS to the AS_PATH, might
encourage or discourage it from inventing an arbitrary AS_PATH,
depending on its resources and intent.

If BGP peers need not prepend number of its own AS (or implementations do not
ensure that this is done), then peer, a malicious BGP peer could
announce a path that begins with the AS of any BGP speaker with little
impact on itself.

Whether such an arbitrary AS_PATH is a vulnerability would depend on
whether BGP implementations check This could affect the AS_PATH (to see if receiving BGP speaker's
decision procedure and choice of installed route. The malicious peer
could considerably shorten the first AS is AS_PATH, which will increase that route's
chances of being chosen, possibly giving the neighbor) and malicious peer access to
traffic it would catch the error. If there are legitimate
situations otherwise not receive. The shortened AS_PATH also
could result in which routing loops, as it does not contain the information
needed to prevent loops.

It is possible for a BGP speaker could pass an AS_PATH to a neighbor
without putting be configured to accept routes with
its own AS at number in the head AS path. Such operational considerations are
defined to be "outside the scope" of the AS_PATH, then there is no
way for BGP specification, but the fact
that AS_PATHs can have loops means that implementations cannot
automatically reject routes with loops. Each BGP speaker verifies only
that its own AS number does not appear in the AS_PATH.

Coupled with the ability to detect totally bogus AS_PATHs. use any value for the NEXT_HOP, this gives a
malicious BGP speaker considerable control over the path traffic will
take.

Originating Routes

A special case of announcing a false AS_PATH occurs when the AS_PATH
advertises a direct connection to a specific network address. An BGP
peer or outsider could disrupt routing to the network(s) listed in the
NLRI field by falsely advertising a direct connection to the network.
The NLRI would become unreachable to the portion of the network that
accepted this false route, unless the ultimate AS on the AS_PATH
undertook to tunnel the packets it was forwarded for this NLRI on toward
their true destination AS by a valid path. But even when the packets
are tunneled to the correct destination AS, the route followed may not
be optimal or may not follow the intended policy. Additionally, routing
for other networks in the Internet could be affected if the false
advertisement fragmented an aggregated address block, forcing the
routers to handle (issue UPDATES, store, manage) the multiple fragments
rather than the single aggregate. False originations for multiple
addresses can result in routers and transit networks along the announced
route to become flooded with mis-directed 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 is clear
that an outsider modifying this field could disrupt the forwarding of
traffic between the two AS's.

In the case that the recipient of the message 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 has the opportunity to direct the recipient to forward traffic to
a BGP speaker at the NEXT_HOP address. This affords the opportunity to
direct traffic at a router that may not be able to continue forwarding
the traffic. It is unclear whether A malicious BGP speaker can also use this technique to
force another AS to carry traffic it would also require otherwise not have to carry.
In some cases, this could be to the
advertising malicious BGP speaker speaker's benefit, as
it could cause traffic to construct an AS_PATH mentioning be carried long-haul by the NEXT_HOP
external peer's AS. victim AS to some
other peering point it shared with the victim.

MULTI_EXIT_DISC

The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted
between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an
inter-AS peer may be propagated within an AS, it may not be propagated
to other AS's. Consequently, this field is only used in making routing
decisions internal to one AS. Modifying this field, whether by an
outsider or an BGP peer, could influence routing within an AS to be sub-
optimal, but the effect should be 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. Consequently,
modification of the LOCAL_PREF could effect the routing process within
the AS only. Note that there is no requirement in the BGP RFC that the
LOCAL_PREF be consistent among the internal BGP speakers of an AS. As
BGP peers are free to choose the LOCAL_PREF as they wish, modification
of this field is a vulnerability with respect to outsiders only.

ATOMIC_AGGREGATE

The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way
has received a more specific aggregated several routes and a less specific route to advertised the aggregate NLRI and
installed without
the aggregated route. This route cannot be de-aggregated
because it is not certain that AS_SET formed as usual from the route to more specific prefixes will
follow AS's in the listed AS_PATH. Consequently, aggregated routes'
AS_PATHs. BGP speakers receiving a route with ATOMIC_AGGREGATE are
restricted from making the NLRI any more specific. Removing the
ATOMIC_AGGREGATE attribute would remove the restriction, possibly
causing traffic intended for the more specific NLRI to be routed
incorrectly. Adding the ATOMIC_AGGREGATE attribute 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 who has computed the routes
represented in the UPDATE message from aggregation of other routes. The
field contains the AS number and IP address of the last aggregator of
the route. It is not used in making any routing decisions, so it does
not represent a vulnerability.

2.4.4.

3.1.5.4. NLRI

By modifying or forging this field, either an outsider or BGP peer
source could cause disruption of routing to the announced network,
overwhelm a router along the announced route, cause data loss when the
announced route will not forward traffic to the announced network, route
traffic by a sub-optimal route, etc.

2.5.

Event 28: If the UPDATE message is mal-formed (Withdrawn Routes Length,
Total Attribute Length, or Attribute Length that are improper, missing
mandatory well-known attributes, Attribute Flags that conflict with the
Attribute Type Codes, syntactic errors in the ORIGIN, NEXT_HOP or
AS_PATH, etc.), then the BGP Extensions

Several standards track extensions have been defined for BGP, e.g., [3],
[4]. Some have present additional vulnerabilities.

2.5.1. Communities

An optional transitive path attribute called COMMUNITIES, [3], provides
for more flexible speaker will bring down the connection,
release all associated BGP resources, delete all associated routes, run
its decision process and scalable configuration cause the state to return to Idle. The
deletion of routes can cause a cascading effect of routing policies and for
control changes
propogating 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 configuration by an outsider to spoof this
message could cause wide-spread disruption of routing. As a BGP speaker
has the service provider customer. Routing
UPDATEs may now include authority to close a communities attribute that connection whenver it wants, this message
gives BGP speakers no opportunity to cause damage than they already had.

3.2. Vulnerabilities through Other Protocols

3.2.1. TCP messages

BGP runs over TCP, listening on port 179. Therefore, BGP is used by the
receiver in deciding subject to
attack through attacks on TCP.

3.2.1.1. TCP SYN

SYN flooding: BGP is as subject to accept, prefer, or distribute the UPDATE route.

An outsider could forge values in effects on the TCP implementation
of SYN flooding attacks as other protocols, and must rely on the
implementation's protections against this field attack.

Event 14: If an attacker were able to send a SYN to affect the routing
behavior BGP speaker,
then the legitimate peer's SYN would appear to be a second connection.
If the attacker were able to continue with a sequence of packets
resulting in a BGP connection (guessing the receiver. In particular, BGP speaker's choice for
sequence number on the defined values SYN ACK, for this
attribute of NO_EXPORT, NO_ADVERTISE, example), then, the attacker's
connection and NO_EXPORT_SUBCONFED offer the
opportunity legitimate peer's connection would appear to affect the distribution of those routes. be a
connection collision. Depending on the use the receiver makes outcome of the communities attribute, collision
detection (i.e., the attacker chose a BGP peer who had knowledge of identifier so as to win the routing decision process of
race), the
receiver legitimate peer's true connection could misuse communities be destroyed. The
use of [6] will counter this attack.

3.2.1.2. TCP SYN ACK

Event 16: If an attacker were able to which it was not authorized respond to a BGP speaker's SYN
before the legitimate peer, then the legitimate peer's SYN-ACK would
receive a empty ACK reply, causing the legitimate peer to issue a RST
that would break the connection. The BGP speaker would bring down the
connection, release all associated BGP resources, delete all associated
routes and run its
own benefit or decision process. This attack requires that the
attacker be able to predict the harm of others.

2.5.2. Confederations

New types for AS_PATH segments called AS_CONFED_SEQUENCE and
AS_CONFED_SET, [4], offer an alternative to ful mesh IBGP sessions. A
confederation is a collection sequence number used in the SYN. The
use of autonomous systems advertised [6] will counter this attack.

This attack has no corollary from the legitimate BGP peer.

3.2.1.3. TCP ACK

Event 17: If an attacker were able to spoof an ACK at the appropriate
time, then the BGP speaker outside would consider the confederation connection complete, send
an OPEN (Event 17) and transition to the OpenSent state. The arrival of
the legitimate peer's ACK would not be delivered to the BGP process, as
it would look like a single AS but within duplicate packet. This message, then, presents no
particular vulnerability to BGP.

3.2.1.4. TCP RST/FIN/FIN-ACK

Event 18: If an attacker were able to spoof a RST, the
confederation as if they BGP speaker would
bring down the connection, release all associated BGP resources, delete
all associated routes and run its decision process. If an attacker were distinct AS's.

An outsider who was
able to forge this segment type spoof a FIN, then data could affect routing
within still be transmitted, but any
attempt to receive would receive a notification that the confederation and consequently routing with peers as well.

The specification [4] makes no distinction between connection is
closing. In most cases, this results in the values for
Member-AS numbers used within connection being placed in
an Idle state, but if the connection is in the OpenSent state at the
time, the connection returns to an Active state. Spoofing a confederation and AS numbers used
outside RST in this
situation requires an attacker to guess a confederation. The possibility exists for sequence number that is in the
proper half of the sending window, generally an easier task than
guessing the exact sequence number so as to spoof a FIN. The use of [6]
will counter this attack.

3.2.2. Other supporting protocols

3.2.2.1. Manual stop

Event 2: A manual stop event causes the BGP speaker to
include bring down the
connection, release all associated BGP resources, delete all associated
routes and run its decision process. If the mechanism by which a segment type BGP
speaker was informed of AS_CONFED_SEQUENCE or AS_CONFED_SET and use a manual stop were not carefully protected, the same Member-AS value as used in its peer's own confederation. This
presents
BGP connection could be destroyed by an opportunity attacker. Consequently, BGP
security is secondarily dependent on the security of whatever protocols
are used to considerably affect routing between operate the two
confederations platform.

3.2.2.2. Timer events

Events 9-13: The Keepalive, Hold, and inside Open Delay timers are critical to
BGP operation. For example, if the peer's confederation.

3. Hold timer value were changed, the
remote peer might consider the connection unresponsive and bring the
connection down, releasing resources, deleting associated routes, etc.
Consequently, BGP security is secondarily dependent on the security of
the protocols by which the platform is managed and configured.

4. Security Considerations

This entire memo is about security, describing an analysis of the
vulnerabilities that exist in the BGP protocol. A companion work, [5],
describes

Use of the mandatory-to-support mechanisms of [6] counter the message
insertion, deletion, and modification attacks and man-in-the-middle
attacks from outsiders. In cases where a BGP implementation accepts
connections from unconfigured hosts, the use of IPSEC AH would couter
these threats as well as replay attacks and would permit key agreement
and roll-over. If routing data confidentiality were desired, IPSEC ESP
would provide that service.

4.1. Residual Risk

As cryptographic-based mechanisms, both [6] and IPSEC assume that the
cyrptographic algorithms are secure, that secrets used are protected
from exposure and are chosen well so as not to be guessable, that the
platforms are securely managed and operated to prevent break-ins, etc.

These mechanisms do not prevent attacks that arise from a router's
legitimate BGP peers. There are several possible security solutions to prevent a
BGP speaker from inserting bogus information in 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 their costs.

4. Adjacency Protection: sign the originating AS and
predecessor information ([3])

(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. ([7])

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

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

5. References

[1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995.

[2] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work
in progress, November 2001. March 2003. available as
<<draft-ietf-idr-bgp4-17.txt>>
<<draft-ietf-idr-bgp4-19.txt>> at Internet-Draft shadow sites.

[3] R. Chandra, P. Traina, B. Smith and T. Li, "BGP Communities Attribute",
RFC1997, August J.J. Garcia-Luna-Aceves, "Securing the Border Gateway
Routing Protocol", Proc. Global Internet'96, London, UK, 20-21
November 1996.

[4] P. Traina, C. Villamizar, C. Alaettinoglu, D. McPherson, Meyer, S. Murphy and J. Scudder, "Autonomous C. Orange,
"Routing Policy System
Confederations for BGP", RFC3065, February 2001. Security", RFC 2725, December, 1999.

[5] S. Murphy, "BGP Kent and R.Atkinson, "Security Architecture for the Internet
Protocol", RFC2401, November 1998.

[6] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature
Option", RFC2385, August 1998.

[7] S.Kent, C.Lynn, and K. Seo, "Secure Border Gateway Protocol
(Secure-BGP)", IEEE Journal on Selected Areas in Communications,
Vol. 18, No. 4, April 2000, pp. 582-592.

[8] E. Rescorla and B. Korver, "Guidelines for Writing RFC Text on
Security Protections", Considerations", work in progress, October,
2002. January 2003.
available as
<<draft-murphy-bgp-protect-01.txt>>
<<draft-iab-sec-cons-03.txt>> at Internet-Draft shadow sites.

6. Author's Address

Sandra Murphy
Network Associates, Inc.
NAI Labs
3060 Washington Road
Glenwood, MD 21738
EMail: Sandy@tislabs.com