draft-ietf-idr-bgp-vuln-00.txt   draft-ietf-idr-bgp-vuln-01.txt 
none Sandra Murphy
INTERNET-DRAFT Sparta, Inc
Expires: April 13, 2005 October 2004
Network Working Group Sandra Murphy
INTERNET DRAFT NAI Labs
BGP Security Vulnerabilities Analysis BGP Security Vulnerabilities Analysis
draft-ietf-idr-bgp-vuln-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions of This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026. section 3 of RFC 3667. By submitting this Internet-Draft, each author
represents that any applicable patent or other IPR claims of which he or
she is aware have been or will be disclosed, and any of which he or she
become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Specification of Requirements Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
Abstract Abstract
BGP, along with a host of other infrastructure protocols designed before Border Gateway Protocol 4 (BGP-4), along with a host of other
the Internet environment became perilous, was originally designed with infrastructure protocols designed before the Internet environment became
little consideration for protection of the information it carries. perilous, was originally designed with little consideration for
There are no mechanisms internal to the BGP protocol to protect against protection of the information it carries. There are no mechanisms
attacks that modify, delete, forge, or replay data, any of which has the internal to the BGP protocol to protect against attacks that modify,
potential to disrupt overall network routing behavior. 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 This internet draft discusses some of the security issues with BGP
routing data dissemination. This internet draft does not discuss routing data dissemination. This internet draft does not discuss
security issues with forwarding of packets. security issues with forwarding of packets.
Table of Contents Table of Contents
Status of this Memo .............................................. 1 Abstract ........................................................ 2
Specification of Requirements .................................... 1
Abstract ......................................................... 1
1 Introduction .................................................... 4 1 Introduction .................................................... 4
2 Attacks ......................................................... 6 2 Attacks ......................................................... 6
3 Vulnerabilities and Risks ....................................... 8 3 Vulnerabilities and Risks ....................................... 8
3.1 Vulnerabilities in BGP messages ............................... 8 3.1 Vulnerabilities in BGP messages ............................... 9
3.1.1 Message Header .............................................. 8 3.1.1 Message Header .............................................. 10
3.1.2 OPEN ........................................................ 9 3.1.2 OPEN ........................................................ 10
3.1.3 KEEPALIVE ................................................... 10 3.1.3 KEEPALIVE ................................................... 12
3.1.4 NOTIFICATION ................................................ 10 3.1.4 NOTIFICATION ................................................ 12
3.1.5 UPDATE ...................................................... 10 3.1.5 UPDATE ...................................................... 12
3.1.5.1 Unfeasible Routes Length, Total Path Attribute Length ..... 10 3.1.5.1 Unfeasible Routes Length, Total Path Attribute Length ..... 13
3.1.5.2 Withdrawn Routes .......................................... 11 3.1.5.2 Withdrawn Routes .......................................... 14
3.1.5.3 Path Attributes ........................................... 11 3.1.5.3 Path Attributes ........................................... 14
Attribute Flags, Attribute Type Codes, Attribute Length .......... 11 Attribute Flags, Attribute Type Codes, Attribute Length .......... 14
ORIGIN ........................................................... 11 ORIGIN ........................................................... 14
AS_PATH .......................................................... 12 AS_PATH .......................................................... 15
Originating Routes ............................................... 12 Originating Routes ............................................... 15
NEXT_HOP ......................................................... 13 NEXT_HOP ......................................................... 16
MULTI_EXIT_DISC .................................................. 13 MULTI_EXIT_DISC .................................................. 16
LOCAL_PREF ....................................................... 13 LOCAL_PREF ....................................................... 16
ATOMIC_AGGREGATE ................................................. 14 ATOMIC_AGGREGATE ................................................. 17
AGGREGATOR ....................................................... 14 AGGREGATOR ....................................................... 17
3.1.5.4 NLRI ...................................................... 14 3.1.5.4 NLRI ...................................................... 17
3.2 Vulnerabilities through Other Protocols ....................... 15 3.2 Vulnerabilities through Other Protocols ....................... 17
3.2.1 TCP messages ................................................ 15 3.2.1 TCP messages ................................................ 17
3.2.1.1 TCP SYN ................................................... 15 3.2.1.1 TCP SYN ................................................... 17
3.2.1.2 TCP SYN ACK ............................................... 15 3.2.1.2 TCP SYN ACK ............................................... 18
3.2.1.3 TCP ACK ................................................... 15 3.2.1.3 TCP ACK ................................................... 18
3.2.1.4 TCP RST/FIN/FIN-ACK ....................................... 16 3.2.1.4 TCP RST/FIN/FIN-ACK ....................................... 18
3.2.1.5 DoS and DDos .............................................. 16 3.2.1.5 DoS and DDos .............................................. 19
3.2.2 Other supporting protocols .................................. 16 3.2.2 Other supporting protocols .................................. 19
3.2.2.1 Manual stop ............................................... 16 3.2.2.1 Manual stop ............................................... 19
3.2.2.2 Timer events .............................................. 16 3.2.2.2 Open Collision Dump ....................................... 19
4 Security Considerations ......................................... 17 3.2.2.3 Timer events .............................................. 19
4.1 Residual Risk ................................................. 17 4 Security Considerations ......................................... 20
4.2 Operational Protections ....................................... 17 4.1 Residual Risk ................................................. 20
5 References ...................................................... 19 4.2 Operational Protections ....................................... 21
6 Author's Address ................................................ 19 5 IANA Considerations ............................................. 22
6 References ...................................................... 22
6.1 Normative ..................................................... 22
6.2 Informative ................................................... 22
7 Author's Address ................................................ 23
1. Introduction 1. Introduction
The inter-domain routing protocol BGP was created when the Internet The inter-domain routing protocol BGP was created when the Internet
environment had not yet reached the present contentious state. environment had not yet reached the present contentious state.
Consequently, the BGP protocol was not designed with protection against Consequently, the BGP protocol was not designed with protection against
deliberate or accidental errors causing disruptions of routing behavior. deliberate or accidental errors causing disruptions of routing behavior.
We here discuss the vulnerabilities of BGP, based on the BGP We here discuss the vulnerabilities of BGP, based on the BGP
specification [1]. Readers are expected to be familiar with the BGP RFC specification [BGP]. Readers are expected to be familiar with the BGP
and the behavior of BGP. RFC and the behavior of BGP.
It is clear that the Internet is vulnerable to attack through its It is clear that the Internet is vulnerable to attack through its
routing protocols and BGP is no exception. Faulty, misconfigured or routing protocols and BGP is no exception. Faulty, misconfigured or
deliberately malicious sources can disrupt overall Internet behavior by deliberately malicious sources can disrupt overall Internet behavior by
injecting bogus routing information into the BGP distributed routing injecting bogus routing information into the BGP distributed routing
database (by modifying, forging, or replaying BGP packets). The same database (by modifying, forging, or replaying BGP packets). The same
methods can also be used to disrupt local and overall network behavior methods can also be used to disrupt local and overall network behavior
by breaking the distributed communication of information between BGP by breaking the distributed communication of information between BGP
peers. The sources of bogus information can be either outsiders or true peers. The sources of bogus information can be either outsiders or true
BGP peers. BGP peers.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
between BGP peers and thereby inject bogus routing information or break between BGP peers and thereby inject bogus routing information or break
the peer to peer connection. Any break in the peer to peer the peer to peer connection. Any break in the peer to peer
communication has a ripple effect on routing that can be wide spread. communication has a ripple effect on routing that can be wide spread.
Furthermore, outsider sources can also disrupt communications between Furthermore, outsider sources can also disrupt communications between
BGP peers by breaking their TCP connection with spoofed packets. BGP peers by breaking their TCP connection with spoofed packets.
Outsider sources of bogus BGP information can reside anywhere in the Outsider sources of bogus BGP information can reside anywhere in the
world. world.
Consequently, the current BGP specification requires that a BGP Consequently, the current BGP specification requires that a BGP
implementation must support the authentication mechanism specified in implementation must support the authentication mechanism specified in
[5]. However, the requirement for support of that authentication [TCPMD5]. However, the requirement for support of that authentication
mechanism cannot ensure that the mechanism is configured for use. The mechanism cannot ensure that the mechanism is configured for use. The
mechanism of [5] is based on a pre-installed shared secret; it does not mechanism of [TCPMD5] is based on a pre-installed shared secret; it does
have the capability of IPSEC [4] to agree on a shared secret not have the capability of IPsec [IPsec] to agree on a shared secret
dynamically. Consequently, the use of [5] msut be a deliberate dynamically. Consequently, the use of [TCPMD5] must be a deliberate
decision, not an automatic feature or default. decision, not an automatic feature or default.
The current BGP specification also allows for implementations that would The current BGP specification also allows for implementations that would
accept connections from "un-configured peers" ([1] Section 8), however, accept connections from "unconfigured peers" ([BGP] Section 8).
the specification is not clear as to what an unconfigured peer might be However, the specification is not clear as to what an unconfigured peer
or how the protections of [5] would apply in such a case. It is might be or how the protections of [TCPMD5] would apply in such a case.
therefore not possible to include an analysis of the security issues of It is therefore not possible to include an analysis of the security
this feature. When a specification is released that describes this issues of this feature. When a specification is released that describes
feature more fully, a security analysis should be part of that same this feature more fully, a security analysis should be part of that same
specification. specification.
BGP speakers themselves can inject bogus routing information, either by BGP speakers themselves can inject bogus routing information, either by
masquerading as any other legitimate BGP speaker, or by distributing masquerading as any other legitimate BGP speaker, or by distributing
unauthorized routing information as themselves. Historically, unauthorized routing information as themselves. Historically,
misconfigured and faulty routers have been responsible for widespread misconfigured and faulty routers have been responsible for widespread
disruptions in the Internet. The legitimate BGP peers have the context disruptions in the Internet. The legitimate BGP peers have the context
and information to produce believable bogus routing information and and information to produce believable bogus routing information and
therefore have the opportunity to cause great damage. The cryptographic therefore have the opportunity to cause great damage. The cryptographic
protections of [5] and operational protections cannot exclude the bogus protections of [TCPMD5] and operational protections cannot exclude the
information arising from a legitimate peer. The risk of disruptions bogus information arising from a legitimate peer. The risk of
caused by legitimate BGP speakers is real and cannot be ignored. disruptions caused by legitimate BGP speakers is real and cannot be
ignored.
Bogus routing information can have many different effects on routing Bogus routing information can have many different effects on routing
behavior. If the bogus information removes routing information for a behavior. If the bogus information removes routing information for a
particular network, that network can become unreachable for the portion particular network, that network can become unreachable for the portion
of the Internet that accepts the bogus information. If the bogus of the Internet that accepts the bogus information. If the bogus
information changes the route to a network, then packets destined for 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 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 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 traffic. As a consequence, traffic to that network could be delayed by
a longer than necessary path. The network could become unreachable from a longer than necessary path. The network could become unreachable from
areas where the bogus information is accepted. Traffic might also be areas where the bogus information is accepted. Traffic might also be
forwarded along a path that permits some adversary a view of the data. forwarded along a path that permits some adversary a view of the data or
If the bogus information makes it appear that an autonomous system a chance to modify the data. If the bogus information makes it appear
originates a network when it does not, then packets for that network may that an autonomous system originates a network when it does not, then
not be deliverable for the portion of the Internet that accepts the packets for that network may not be deliverable for the portion of the
bogus information. A false announcement that an autonomous systems Internet that accepts the bogus information. A false announcement that
originates a network may also fragment aggregated address blocks in an autonomous systems originates a network may also fragment aggregated
other parts of the Internet and cause routing problems for other address blocks in other parts of the Internet and cause routing problems
networks. for other networks.
The damage that might result from these attacks are: The damages that might result from these attacks include:
starvation: data traffic destined for a node is forwarded to a part starvation: Data traffic destined for a node is forwarded to a part
of the network that cannot deliver it, of the network that cannot deliver it.
network congestion: more data traffic is forwarded through some network congestion: More data traffic is forwarded through some
portion of the network than would otherwise need to carry the portion of the network than would otherwise need to carry the
traffic, traffic.
blackhole: large amounts of traffic are directed to be forwarded
blackhole: Large amounts of traffic are directed to be forwarded
through one router that cannot handle the increased level of through one router that cannot handle the increased level of
traffic and drops many/most/all packets, traffic and drops many/most/all packets.
delay: data traffic destined for a node is forwarded along a path 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, 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 looping: Data traffic is forwarded along a path that loops, so that
the data is never delivered, the data is never delivered.
eavesdrop: data traffic is forwarded through some router or network eavesdrop: Data traffic is forwarded through some router or network
that would otherwise not see the traffic, affording an opportunity that would otherwise not see the traffic, affording an opportunity
to see the data, to see the data.
partition: some portion of the network believes that it is partition: Some portion of the network believes that it is
partitioned from the rest of the network when it is not, partitioned from the rest of the network when it is not.
cut: some portion of the network believes that it has no route to cut: Some portion of the network believes that it has no route to
some network that is in fact connected, some network that is in fact connected.
churn: the forwarding in the network changes at a rapid pace, churn: The forwarding in the network changes at a rapid pace,
resulting in large variations in the data delivery patterns (and resulting in large variations in the data delivery patterns (and
adversely affecting congestion control techniques), adversely affecting congestion control techniques).
instability: BGP become unstable so that convergence on a global instability: BGP become unstable so that convergence on a global
forwarding state is not achieved, and forwarding state is not achieved.
overload: the BGP messages themselves become a significant portion overload: The BGP messages themselves become a significant portion
of the traffic the network carries. of the traffic the network carries.
resource exhaustion: the BGP messages themselves cause exhaustion resource exhaustion: The BGP messages themselves cause exhaustion
of critical router resources, such as table space. 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, enabling an active
attack by affording the opportunity to modify the data.
These consequences can fall exclusively on one end system prefix or may These consequences can fall exclusively on one end system prefix or may
effect the operation of the network as a whole. effect the operation of the network as a whole.
2. Attacks 2. Attacks
The BGP protocol, in and of itself, is subject to the following 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 (list taken from the IAB RFC providing guidelines for the security
security considerations section of Internet-Drafts [8]): considerations section of Internet-Drafts and RFCs [SecCons]):
eavesdropping: The routing data carried in BGP is carried in confidentiality violations: The routing data carried in BGP is
cleartext, so eavesdropping is a possible attack against routing carried in cleartext, so eavesdropping is a possible attack against
data confidentiality. (Routing data confidentiality is not a routing data confidentiality. (Routing data confidentiality is not
common requirement.) a common requirement.)
replay: BGP does not provide for replay protection of its messages. replay: BGP does not provide for replay protection of its
messages.
message insertion: BGP does not provide protection against message insertion: BGP does not provide protection against
insertion of messages. However, because BGP uses TCP, when the insertion of messages. However, because BGP uses TCP, when the
connection is fully established, message insertion by an outsider connection is fully established, message insertion by an outsider
would require accurate sequence number prediction (not entirely out would require accurate sequence number prediction (not entirely out
of the question, but more difficult with mature TCP of the question, but more difficult with mature TCP
implementations) or session stealing attacks. implementations) or session stealing attacks.
message deletion: BGP does not provide protection against deletion message deletion: BGP does not provide protection against deletion
of messages. Again, more difficult against a mature TCP of messages. Again, this attack is more difficult against a mature
implementation but not entirely out of the question TCP implementation but is not entirely out of the question.
message modification: BGP does not provide protection against message modification: BGP does not provide protection against
modification of messages. A modification that did not change the modification of messages. A modification that was syntactically
length of the TCP payload would in general not be detectable. 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 agains man-in- man-in-the-middle: BGP does not provide protection against
the-middle attacks. As BGP does no peer entity authentication, a man-in-the-middle attacks. As BGP does no peer entity
man-in-the-middle attack is childs-play. authentication, a man-in-the-middle attack is childs-play.
denial of service: While bogus routing data can present a denial denial of service: While bogus routing data can present a denial
of service attack on the end systems that are trying to transmit of service attack on the end systems that are trying to transmit
data through the network and on the network infrastructure itself, data through the network and on the network infrastructure itself,
certain bogus information can represent a denial of service on the certain bogus information can represent a denial of service on the
BGP routing protocol. For example, advertising large numbers of BGP routing protocol. For example, advertising large numbers of
more specific routes (longer prefixes) can cause BGP traffic and more specific routes (longer prefixes) can cause BGP traffic and
router table size to increase, even explode. router table size to increase, even explode.
The mandatory-to-support mechanism of [5] will counter the message The mandatory-to-support mechanism of [TCPMD5] will counter the message
insertion, deletion, and modification, man-in-the-middle attacks and the insertion, deletion, and modification, man-in-the-middle attacks and the
denial of service attacks from outsiders. The use of [5] does not denial of service attacks from outsiders. The use of [TCPMD5] does not
protect against eavesdropping attacks, but routing data confidentiality protect against eavesdropping attacks, but routing data confidentiality
is not a goal of BGP. The mechanism of [5] does not protect against is not a goal of BGP. The mechanism of [TCPMD5] does not protect
replay attacks, so the only protection against replay is provided by the against replay attacks, so the only protection against replay is
TCP sequence number processing. The mechanism of [5] cannot protect provided by the TCP sequence number processing. Therefore, a replay
against bogus routing information originating with an insider. A replay attack could be mounted against a BGP connection protected with [TCPMD5]
attack could be mounted against a BGP connection protected with [5] but but only in very carefully timed circumstances. The mechanism of
only in very carefully timed circumstances.
[TCPMD5] cannot protect against bogus routing information originating
with an insider.
3. Vulnerabilities and Risks 3. Vulnerabilities and Risks
The risks in BGP arise from three fundamental vulnerabilities: The risks in BGP arise from three fundamental vulnerabilities:
BGP has no internal mechanism that provides strong protection of BGP has no internal mechanism that provides strong protection of
the integrity, freshness and peer entity authenticity of the the integrity, freshness and peer entity authenticity of the
messages in peer-peer BGP communications. messages in peer-peer BGP communications.
no mechanism has been specified within BGP to validate the no mechanism has been specified within BGP to validate the
authority of an AS to announce NLRI information. authority of an AS to announce NLRI information.
no mechanism has been specified within BGP to ensure the no mechanism has been specified within BGP to ensure the
authenticity of the path attributes announced by an AS. authenticity of the path attributes announced by an AS.
The first fundamental vulnerability motivated the mandated support of The first fundamental vulnerability motivated the mandated support of
[5] in the BGP specification. When that is employed, message integrity [TCPMD5] in the BGP specification. When that is employed, message
and peer entity authentication is provided. The mechanism of [5] integrity and peer entity authentication is provided. The mechanism of
assumes that the MD5 algorithm is secure and that the shared secret is [TCPMD5] assumes that the MD5 algorithm is secure and that the shared
protected and chosen to be difficult to guess. 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 where the message
processing occurs. The events are defined and discussed in section 8 of
[BGP]. 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 3.1. Vulnerabilities in BGP messages
There are four different BGP message types - OPEN, KEEPALIVE, There are four different BGP message types - OPEN, KEEPALIVE,
NOTIFICATION, and UPDATE. This section contains a discussion of the NOTIFICATION, and UPDATE. This section contains a discussion of the
vulnerabilities arising from each message and the ability of outsiders vulnerabilities arising from each message and the ability of outsiders
or BGP peers to exploit the vulnerabilities. To summarize, outsiders or BGP peers to exploit the vulnerabilities. To summarize, outsiders
can use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the can use bogus OPEN, KEEPALIVE, NOTIFICATION, or UPDATE messages to
BGP peer-peer connections and can use bogus UPDATE messages to disrupt disrupt the BGP peer-peer connections and can use bogus UPDATE messages
routing. Outsiders can also disrupt BGP peer-peer connections by to disrupt routing without breaking the peer-peer connection. Outsiders
inserting bogus TCP packets. BGP peers themselves are permitted to can also disrupt BGP peer-peer connections by inserting bogus TCP
break peer-peer connections at any time, and so they cannot be said to packets that disrupt the TCP connection processing. In general, the
be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages. However,
BGP peers can disrupt routing by issuing bogus UPDATE messages. In
particular, bogus 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. 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, so 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 different vulnerabilities and risks and
is discussed in the following sections.
3.1.1. Message Header 3.1.1. Message Header
Event 21: Each BGP message starts with a standard header. In all cases, Event 21: Each BGP message starts with a standard header. In all
syntactic errors in the message header will cause the BGP speaker to cases, syntactic errors in the message header will cause the BGP speaker
close the connection, release all associated BGP resources, delete all to close the connection, release all associated BGP resources, delete
routes learned through that connection and run its decision process to all routes learned through that connection, run its decision process to
decide on new routes. 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 3.1.2. OPEN
Event 19: Receipt of an OPEN message in state Connect, Active or Event 19: Receipt of an OPEN message in state Connect or Active will
Established will cause the cause the BGP speaker to bring down the cause the BGP speaker to bring down the connection, release all
connection, release all associated BGP resources, delete all associated associated BGP resources, delete all associated routes, run its decision
routes, run its decision process and cause the state to return to Idle. process and cause the state to return to Idle. The deletion of routes
The deletion of routes can cause a cascading effect of routing changes can cause a cascading effect of routing changes propagating through
propogating through other peers. Also, optionally, an implementation other peers. Also, optionally, an implementation specific peer
specific peer oscillation damping may be performed. The peer oscillation damping may be performed. The peer oscillation damping
oscillation damping process can affect how soon the connection can be process can affect how soon the connection can be restarted.
restarted. In state OpenSent, the arrival of an OPEN message will cause
the BGP speaker to transition to the OpenConfirm state. The later In state OpenConfirm or Established, the arrival of an OPEN may indicate
arrival of the legitimate peer's OPEN message will lead the BGP speaker 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 to declare a connection collision. The collision detection procedure
may cause the legitimate connection to be dropped. Consequently, the may cause the legitimate connection to be dropped.
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 Consequently, the ability of an outsider to spoof this message can lead
when the connection is in state OpenSent or Established, the BGP speaker to a severe disruption of routing over a wide area.
will bring down the connection, release all associated BGP resources,
delete all associated routes, run its decision process and cause the Event 20: If an OPEN message arrives when the DelayOpen timer is
state to return to Idle. The deletion of routes can cause a cascading running when the connection is in state OpenSent, OpenConfirm or
effect of routing changes propogating through other peers. Also, Established, the BGP speaker will bring down the connection, release all
optionally, an implementation specific peer oscillation damping may associated BGP resources, delete all associated routes, run its decision
performed. The peer oscillation damping process can affect how soon the process and cause the state to return to Idle. The deletion of routes
connection can be restarted. However, as the OpenDelay timer should can cause a cascading effect of routing changes propagating through
never be running in the state OpenSent, this could only be caused by an other peers. Also, optionally, an implementation specific peer
error in the implementation (which is why the error code is "Finite oscillation damping may be performed. The peer oscillation damping
State Machine Error"). It would be difficult, if not impossible, for an process can affect how soon the connection can be restarted. However,
outsider to induce this error. as the OpenDelay timer should never be running in these states, this
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 FSM 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 for 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, Event 22: Errors in the OPEN message (e.g., unacceptable Hold state,
malformed Optional Parameter, unsupported version, etc.) will cause the malformed Optional Parameter, unsupported version, etc.) will cause the
BGP speaker to bring down the connection, release all associated BGP BGP speaker to bring down the connection, release all associated BGP
resources, delete all associated routes, run its decision process and resources, delete all associated routes, run its decision process and
cause the state to return to Idle. The deletion of routes can cause a cause the state to return to Idle. The deletion of routes can cause a
cascading effect of routing changes propogating through other peers. cascading effect of routing changes propagating through other peers.
Also, optionally, an implementation specific peer oscillation damping Also, optionally, an implementation specific peer oscillation damping
may performed. The peer oscillation damping process can affect how soon may be performed. The peer oscillation damping process can affect how
the connection can be restarted. Consequently, the ability to spoof soon the connection can be restarted. Consequently, the ability of an
this message can lead to a severe disruption of routing over a wide outsider to spoof this message can lead to a severe disruption of
area. routing over a wide area.
3.1.3. KEEPALIVE 3.1.3. KEEPALIVE
Event 26: Receipt of a KEEPALIVE message when the peering connection is Event 26: Receipt of a KEEPALIVE message when the peering connection is
in the Connect, Active, and OpenSent states would cause the BGP speaker in the Connect, Active, and OpenSent states would cause the BGP speaker
to transition to the Idle state and fail to establish a connection. The to transition to the Idle state and fail to establish a connection.
ability to spoof this message is a vulnerability. To exploit this 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 vulnerability deliberately, the KEEPALIVE must be carefully timed in the
sequence of messages exchanged between the peers; otherwise, it causes sequence of messages exchanged between the peers; otherwise, it causes
no damage. no damage.
3.1.4. NOTIFICATION 3.1.4. NOTIFICATION
Event 25: Receipt of a NOTIFICATION message in any state will cause the Event 25: Receipt of a NOTIFICATION message in any state will cause the
BGP speaker to bring down the connection, release all associated BGP BGP speaker to bring down the connection, release all associated BGP
resources, delete all associated routes, run its decision process and resources, delete all associated routes, run its decision process and
cause the state to return to Idle. The deletion of routes can cause a cause the state to return to Idle. The deletion of routes can cause a
cascading effect of routing changes propogating through other peers. cascading effect of routing changes propagating through other peers.
Also, optionally, an implementation specific peer oscillation damping Also, optionally, in any state but Established, an implementation
may performed. The peer oscillation damping process can affect how soon specific peer oscillation damping may be performed. The peer
the connection can be restarted. Consequently, the ability to spoof oscillation damping process can affect how soon the connection can be
this message can lead to a severe disruption of routing over a wide restarted. Consequently, the ability of an outsider to spoof this
area. message can lead to a severe disruption of routing over a wide area.
Event 24: A NOTIFICATION message carrying an error code of "Version Event 24: A NOTIFICATION message carrying an error code of "Version
Error" behaves the same as in Event 25, with the exception that the Error" behaves the same as in Event 25, with the exception that the
optional peer oscillation damping is not performed (in states Connect optional peer oscillation damping is not performed in states OpenSent or
and Active, only when the OpenDelay timer is running). The damage OpenConfirm, or in state Connect or Active if the DelayOpen timer is
caused is therefore one small bit less, in that restarting the running. The damage caused is therefore one small bit less, because
connection is not affected. restarting the connection is not affected.
3.1.5. UPDATE 3.1.5. UPDATE
Event 27: The Update message carries the routing information. The Event 8: A BGP speaker may optionally choose to automatically
ability to spoof any part of this message can lead to a disruption of disconnect a BGP connection if the total number of prefixes exceeds a
routing. configured maximum. If 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 of routing changes propagating 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 (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 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 of routing changes
propagating 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 could cause widespread disruption of routing. As a BGP speaker
has the authority to close a connection whenever it wants, this message
gives BGP speakers no more opportunity to cause damage than they already
had.
Event 27: An Update message that arrives in any state but Established
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 propagating 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.
In the Established state, the Update message carries the routing
information. The ability to spoof any part of this message can lead to
a disruption of routing, whether the source of the message is an
outsider or a legitimate BGP speaker.
3.1.5.1. Unfeasible Routes Length, Total Path Attribute Length 3.1.5.1. Unfeasible Routes Length, Total Path Attribute Length
There is a vulnerability arising from the ability to modify these There is a vulnerability arising from the ability to modify these
fields. If a length is modified, the message is not likely to parse fields. If a length is modified, the message is not likely to parse
properly, resulting in an error, the transmission of a NOTIFICATION properly, resulting in an error, the transmission of a NOTIFICATION
message and the close of the connection (see Event 28, below). As a message and the close of the connection (see Event 28, above). As a
true BGP speaker is always able to close a connection at any time, this true BGP speaker is always able to close a connection at any time, this
vulnerability represents an additional risk only when the source is not vulnerability represents an additional risk only when the source is not
the configured BGP peer, i.e., it presents no additional risk from BGP
sources. the configured BGP peer, i.e., it presents no additional risk from BGP
speakers.
3.1.5.2. Withdrawn Routes 3.1.5.2. Withdrawn Routes
An outsider could cause the elimination of existing legitimate routes by An outsider could cause the elimination of existing legitimate routes by
forging or modifying this field. An outsider could also cause the forging or modifying this field. An outsider could also cause the
elimination of reestablished routes by replaying this withdrawal elimination of reestablished routes by replaying this withdrawal
information from earlier packets. information from earlier packets.
A BGP speaker could "falsely" withdraw feasible routes using this field. A BGP speaker could "falsely" withdraw feasible routes using this field.
However, as the BGP speaker is authoritative for the routes it will However, as the BGP speaker is authoritative for the routes it will
skipping to change at page 11, line 40 skipping to change at page 14, line 41
that followed. If the flags were modified, the flags and type code that followed. If the flags were modified, the flags and type code
could become incompatible (i.e., a mandatory attribute marked as could become incompatible (i.e., a mandatory attribute marked as
partial), or a optional attribute could be interpreted as a mandatory partial), or a optional attribute could be interpreted as a mandatory
attribute or vice versa. If the type code were modified, the attribute 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 value could be interpreted as if it were the data type and value of a
different attribute. different attribute.
The most likely result from modifying the attribute length, flags, or 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 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 would cause the transmission of a NOTIFICATION message and the close of
the connection (see Event 28, below). As a true BGP speaker is always the connection (see Event 28, above). As a true BGP speaker is always
able to close a connection at any time, this vulnerability represents an 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 additional risk only when the source is an outsider, i.e., it presents
no additional risk from a BGP peer. no additional risk from a BGP peer.
ORIGIN ORIGIN
This field indicates whether the information was learned from IGP or EGP This field indicates whether the information was learned from IGP or EGP
information. This field is used in making routing decisions, so there information. This field is used in making routing decisions, so there
is some small vulnerability in being able to affect the receiving BGP
is some small vulnerability in being able to affect the receiving BGP
speaker's routing decision by modifying this field. speaker's routing decision by modifying this field.
AS_PATH AS_PATH
A BGP peer or outsider could announce an AS_PATH that was not accurate A BGP peer or outsider could announce an AS_PATH that was not accurate
for the associated NLRI. for the associated NLRI.
As it is legitimate for a BGP peer not to verify that a received AS_PATH As it is possible for a BGP peer not to verify that a received AS_PATH
begins with the AS number of its peer, a malicious BGP peer could begins with the AS number of its peer, a malicious BGP peer could
announce a path that begins with the AS of any BGP speaker with little announce a path that begins with the AS of any BGP speaker with little
impact on itself. This could affect the receiving BGP speaker's impact on itself. This could affect the receiving BGP speaker's
decision procedure and choice of installed route. The malicious peer decision procedure and choice of installed route. The malicious peer
could considerably shorten the AS_PATH, which will increase that route's could considerably shorten the AS_PATH, which will increase that route's
chances of being chosen, possibly giving the malicious peer access to chances of being chosen, possibly giving the malicious peer access to
traffic it would otherwise not receive. The shortened AS_PATH also traffic it would otherwise not receive. The shortened AS_PATH also
could result in routing loops, as it does not contain the information could result in routing loops, as it does not contain the information
needed to prevent loops. needed to prevent loops.
skipping to change at page 12, line 37 skipping to change at page 15, line 38
automatically reject routes with loops. Each BGP speaker verifies only automatically reject routes with loops. Each BGP speaker verifies only
that its own AS number does not appear in the AS_PATH. that its own AS number does not appear in the AS_PATH.
Coupled with the ability to use any value for the NEXT_HOP, this gives a Coupled with the ability to use any value for the NEXT_HOP, this gives a
malicious BGP speaker considerable control over the path traffic will malicious BGP speaker considerable control over the path traffic will
take. take.
Originating Routes Originating Routes
A special case of announcing a false AS_PATH occurs when the AS_PATH 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 advertises a direct connection to a specific network address. A BGP
peer or outsider could disrupt routing to the network(s) listed in the peer or outsider could disrupt routing to the network(s) listed in the
NLRI field by falsely advertising a direct connection to the network. NLRI field by falsely advertising a direct connection to the network.
The NLRI would become unreachable to the portion of the network that The NLRI would become unreachable to the portion of the network that
accepted this false route, unless the ultimate AS on the AS_PATH 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 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 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 are tunneled to the correct destination AS, the route followed may not
be optimal or may not follow the intended policy. Additionally, routing be optimal or may not follow the intended policy. Additionally, routing
for other networks in the Internet could be affected if the false for other networks in the Internet could be affected if the false
advertisement fragmented an aggregated address block, forcing the advertisement fragmented an aggregated address block, forcing the
routers to handle (issue UPDATES, store, manage) the multiple fragments routers to handle (issue UPDATES, store, manage) the multiple fragments
rather than the single aggregate. False originations for multiple
rather than the single aggregate. False originations for multiple
addresses can result in routers and transit networks along the announced addresses can result in routers and transit networks along the announced
route to become flooded with mis-directed traffic. route to become flooded with mis-directed traffic.
NEXT_HOP NEXT_HOP
The NEXT_HOP attribute defines the IP address of the border router that 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 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 UPDATE message. If the recipient is an external peer, then the
recipient and the NEXT_HOP address must share a subnet. It is clear recipient and the NEXT_HOP address must share a subnet. It is clear
that an outsider modifying this field could disrupt the forwarding of that an outsider modifying this field could disrupt the forwarding of
skipping to change at page 13, line 36 skipping to change at page 16, line 37
it could cause traffic to be carried long-haul by the victim AS to some it could cause traffic to be carried long-haul by the victim AS to some
other peering point it shared with the victim. other peering point it shared with the victim.
MULTI_EXIT_DISC MULTI_EXIT_DISC
The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted
between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an 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 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 to other AS's. Consequently, this field is only used in making routing
decisions internal to one AS. Modifying this field, whether by an 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- outsider or a BGP peer, could influence routing within an AS to be
optimal, but the effect should be limited in scope. sub-optimal, but the effect should be limited in scope.
LOCAL_PREF LOCAL_PREF
The LOCAL_PREF attribute must be included in all messages with internal The LOCAL_PREF attribute must be included in all messages with internal
peers and excluded from messages with external peers. Consequently, peers and excluded from messages with external peers. Consequently,
modification of the LOCAL_PREF could effect the routing process within 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 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 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 BGP peers are free to choose the LOCAL_PREF as they wish, modification
of this field is a vulnerability with respect to outsiders only. of this field is a vulnerability with respect to outsiders only.
skipping to change at page 14, line 35 skipping to change at page 17, line 35
not represent a vulnerability. not represent a vulnerability.
3.1.5.4. NLRI 3.1.5.4. NLRI
By modifying or forging this field, either an outsider or BGP peer By modifying or forging this field, either an outsider or BGP peer
source could cause disruption of routing to the announced network, source could cause disruption of routing to the announced network,
overwhelm a router along the announced route, cause data loss when the overwhelm a router along the announced route, cause data loss when the
announced route will not forward traffic to the announced network, route announced route will not forward traffic to the announced network, route
traffic by a sub-optimal route, etc. traffic by a sub-optimal route, etc.
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 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 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. Consequently, the ability of an outsider to spoof this
message could cause wide-spread disruption of routing. As a BGP speaker
has the authority to close a 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. Vulnerabilities through Other Protocols
3.2.1. TCP messages 3.2.1. TCP messages
BGP runs over TCP, listening on port 179. Therefore, BGP is subject to BGP runs over TCP, listening on port 179. Therefore, BGP is subject to
attack through attacks on TCP. attack through attacks on TCP.
3.2.1.1. TCP SYN 3.2.1.1. TCP SYN
SYN flooding: BGP is as subject to the effects on the TCP implementation SYN flooding: BGP is as subject to the effects on the TCP
of SYN flooding attacks as other protocols, and must rely on the implementation of SYN flooding attacks as other protocols, and must rely
implementation's protections against this attack. on the implementation's protections against this attack.
Event 14: If an attacker were able to send a SYN to the BGP speaker, Event 14: If an outsider were able to send a SYN to the BGP speaker at
then the legitimate peer's SYN would appear to be a second connection. the appropriate time during connection establishment, then the
If the attacker were able to continue with a sequence of packets
resulting in a BGP connection (guessing the BGP speaker's choice for legitimate peer's SYN would appear to be a second connection. If the
sequence number on the SYN ACK, for example), then, the attacker's outsider were able to continue with a sequence of packets resulting in a
connection and the legitimate peer's connection would appear to be a BGP connection (guessing the BGP speaker's choice for sequence number on
connection collision. Depending on the outcome of the collision the SYN ACK, for example), then, the outsider's connection and the
detection (i.e., the attacker chose a BGP identifier so as to win the legitimate peer's connection would appear to be a connection collision.
race), the legitimate peer's true connection could be destroyed. The Depending on the outcome of the collision detection (i.e., the outsider
use of [5] will counter this attack. chose a BGP identifier so as 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 3.2.1.2. TCP SYN ACK
Event 16: If an attacker were able to respond to a BGP speaker's SYN Event 16: If an outsider were able to respond to a BGP speaker's SYN
before the legitimate peer, then the legitimate peer's SYN-ACK would 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 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 that would break the connection. The BGP speaker would bring down the
connection, release all associated BGP resources, delete all associated connection, release all associated BGP resources, delete all associated
routes and run its decision process. This attack requires that the routes and run its decision process. This attack requires that the
attacker be able to predict the sequence number used in the SYN. The outsider be able to predict the sequence number used in the SYN. The
use of [5] will counter this attack. use of [TCPMD5] can counter this attack.
This attack has no corollary from the legitimate BGP peer.
3.2.1.3. TCP ACK 3.2.1.3. TCP ACK
Event 17: If an attacker were able to spoof an ACK at the appropriate Event 17: If an outsider were able to spoof an ACK at the appropriate
time, then the BGP speaker would consider the connection complete, send time during connection establishment, then the BGP speaker would
an OPEN (Event 17) and transition to the OpenSent state. The arrival of consider the connection complete, send an OPEN (Event 17) and transition
the legitimate peer's ACK would not be delivered to the BGP process, as to the OpenSent state. The arrival of the legitimate peer's ACK would
it would look like a duplicate packet. This message, then, presents no not be delivered to the BGP process, as it would look like a duplicate
particular vulnerability to BGP. packet. This message, then, presents no particular vulnerability to BGP
during connection establishment. Spoofing an ACK after connection
establishment requires knowledge of the sequence numbers in use, and is
in general a very difficult task. The use of [TCPMD5] can counter this
attack.
3.2.1.4. TCP RST/FIN/FIN-ACK 3.2.1.4. TCP RST/FIN/FIN-ACK
Event 18: If an attacker were able to spoof a RST, the BGP speaker would Event 18: If an outsider were able to spoof a RST, the BGP speaker
bring down the connection, release all associated BGP resources, delete would bring down the connection, release all associated BGP resources,
all associated routes and run its decision process. If an attacker were delete all associated routes and run its decision process. If an
able to spoof a FIN, then data could still be transmitted, but any outsider were able to spoof a FIN, then data could still be transmitted,
attempt to receive would receive a notification that the connection is but any attempt to receive would receive a notification that the
closing. In most cases, this results in the connection being placed in connection is closing. In most cases, this results in the connection
an Idle state, but if the connection is in the OpenSent state at the being placed in an Idle state, but if the connection is in the OpenSent
time, the connection returns to an Active state. Spoofing a RST in this state at the time, the connection returns to an Active state. Spoofing
situation requires an attacker to guess a sequence number that is in the a RST in this situation requires an outsider to guess a sequence number
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 [5] that need only be within the receive window [Watson04], generally an
will counter this attack. easier task than guessing the exact sequence number so as to spoof a
FIN. The use of [TCPMD5] can counter this attack.
3.2.1.5. DoS and DDos 3.2.1.5. DoS and DDos
Because the packet directed to TCP port 179 are passed to the BGP Because the packet directed to TCP port 179 are passed to the BGP
process, that potentially resides on a slower processor in the router, process, that potentially resides on a slower processor in the router,
flooding a router with TCP port 179 packets is an avenue for DoS attacks flooding a router with TCP port 179 packets is an avenue for DoS attacks
against the router. No BGP protocol mechanism can defeat such attacks; against the router. No BGP protocol mechanism can defeat such attacks;
other mechanisms must be employed. other mechanisms must be employed.
3.2.2. Other supporting protocols 3.2.2. Other supporting protocols
3.2.2.1. Manual stop 3.2.2.1. Manual stop
Event 2: A manual stop event causes the BGP speaker to bring down the Event 2: A manual stop event causes the BGP speaker to bring down the
connection, release all associated BGP resources, delete all associated connection, release all associated BGP resources, delete all associated
routes and run its decision process. If the mechanism by which a BGP routes and run its decision process. If the mechanism by which a BGP
speaker was informed of a manual stop were not carefully protected, the speaker was informed of a manual stop were not carefully protected, the
BGP connection could be destroyed by an attacker. Consequently, BGP BGP connection could be destroyed by an outsider. Consequently, BGP
security is secondarily dependent on the security of whatever protocols security is secondarily dependent on the security of the protocols by
are used to operate the platform. which the platform is managed and configured that might signal this
event.
3.2.2.2. Timer events 3.2.2.2. Open Collision Dump
Events 9-13: The Keepalive, Hold, and Open Delay timers are critical to Event 23: The OpenCollisionDump event may be generated administratively
when a connection collision event is detected and this connection has
been selected to be disconnected. When this event occurs in any state,
the BGP connection is dropped, the BGP resources are released, the
associated routes are deleted, etc. Consequently, BGP security is
secondarily dependent on the security of the protocols by which the
platform is managed and configured that might signal this event.
3.2.2.3. Timer events
Events 9-13: BGP employs five timers (ConnectRetry, Hold, Keepalive,
MinASOrigination-Interval, and MinRouteAdvertisementInterval) and two
optional timers (DelayOpen and IdleHold). These timers are critical to
BGP operation. For example, if the Hold timer value were changed, the BGP operation. For example, if the Hold timer value were changed, the
remote peer might consider the connection unresponsive and bring the remote peer might consider the connection unresponsive and bring the
connection down, releasing resources, deleting associated routes, etc. connection down, releasing resources, deleting associated routes, etc.
Consequently, BGP security is secondarily dependent on the security of Consequently, BGP security is secondarily dependent on the security of
the protocols by which the platform is managed and configured. the protocols by which the platform is operated, managed and configured
that might modify these timers.
4. Security Considerations 4. Security Considerations
This entire memo is about security, describing an analysis of the This entire memo is about security, describing an analysis of the
vulnerabilities that exist in the BGP protocol. vulnerabilities that exist in the BGP protocol.
Use of the mandatory-to-support mechanisms of [5] counter the message Use of the mandatory-to-support mechanisms of [TCPMD5] counters the
insertion, deletion, and modification attacks and man-in-the-middle message insertion, deletion, and modification attacks and
attacks from outsiders. If routing data confidentiality were desired man-in-the-middle attacks from outsiders. If routing data
(there being some contraversy as to whether that is a desirable security confidentiality were desired (there being some controversy as to whether
service), the use of IPSEC ESP could provide that service. that is a desirable security service), the use of IPsec ESP could
provide that service.
4.1. Residual Risk 4.1. Residual Risk
As cryptographic-based mechanisms, both [5] and IPSEC assume that the As cryptographic-based mechanisms, both [TCPMD5] and IPsec [IPsec]
cyrptographic algorithms are secure, that secrets used are protected assume that the cryptographic algorithms are secure, that secrets used
from exposure and are chosen well so as not to be guessable, that the are protected from exposure and are chosen well so as not to be
platforms are securely managed and operated to prevent break-ins, etc. 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 These mechanisms do not prevent attacks that arise from a router's
legitimate BGP peers. There are several possible solutions to prevent a legitimate BGP peers. There are several possible solutions to prevent a
BGP speaker from inserting bogus information in its advertisements to BGP speaker from inserting bogus information in its advertisements to
its peers, i.e., from mounting an attack on a network's origination or its peers, i.e., from mounting an attack on a network's origination or
AS-PATH. AS-PATH.
(1) Origination Protection: sign the originating AS. (1) Origination Protection: sign the originating AS.
(2) Origination and Adjacency Protection: sign the originating AS and (2) Origination and Adjacency Protection: sign the originating AS and
predecessor information ([2]) predecessor information ([Smith96])
(3) Origination and Route Protection: sign the originating AS, and (3) Origination and Route Protection: sign the originating AS, and
nest signatures of AS_PATHs to the number of consecutive bad nest signatures of AS_PATHs to the number of consecutive bad
routers you want to prevent from causing damage. ([6]) routers you want to prevent from causing damage. ([SBGP00])
(4) Filtering: rely on a registry to verify the AS_PATH and NLRI (4) Filtering: rely on a registry to verify the AS_PATH and NLRI
originating AS ([3]). originating AS ([RPSL]).
Filtering is in use near some customer attachment points, but is not Filtering is in use near some customer attachment points, but is not
effective near the Internet center. The other mechanisms are still effective near the Internet center. The other mechanisms are still
controversial and are not yet in common use. controversial and are not yet in common use.
4.2. Operational Protections 4.2. Operational Protections
The primary usage of BGP is as a means to provide reachability The primary usage of BGP is as a means to provide reachability
information to Autonomous Systems (AS) and to distribute external information to Autonomous Systems (AS) and to distribute external
reachability internally within an AS. BGP is the routing protocol used reachability internally within an AS. BGP is the routing protocol used
skipping to change at page 18, line 4 skipping to change at page 21, line 10
Filtering is in use near some customer attachment points, but is not Filtering is in use near some customer attachment points, but is not
effective near the Internet center. The other mechanisms are still effective near the Internet center. The other mechanisms are still
controversial and are not yet in common use. controversial and are not yet in common use.
4.2. Operational Protections 4.2. Operational Protections
The primary usage of BGP is as a means to provide reachability The primary usage of BGP is as a means to provide reachability
information to Autonomous Systems (AS) and to distribute external information to Autonomous Systems (AS) and to distribute external
reachability internally within an AS. BGP is the routing protocol used reachability internally within an AS. BGP is the routing protocol used
to distribute global routing information in the Internet. BGP is to distribute global routing information in the Internet. BGP is
therefore used by all major Internet Service Providers (ISP) and many therefore used by all major Internet Service Providers (ISP) and many
smaller providers and other organizations. smaller providers and other organizations.
The role which BGP plays in the Internet puts BGP implementations in The role which BGP plays in the Internet puts BGP implementations in
unique conditions and places unique security requirements on BGP. BGP unique conditions and places unique security requirements on BGP. BGP
is operated over interprovider interfaces in which traffic levels push is operated over interprovider interfaces in which traffic levels push
the state of the art in specialized packet forwarding hardware and the state of the art in specialized packet forwarding hardware and
exceed the performace capabilities of hardware implementation of exceed the performance capabilities of hardware implementation of
decryption by many orders of magnitude. The capability of an attacker decryption by many orders of magnitude. The capability of an attacker
using a single workstation with high speed interface to generate false using a single workstation with high speed interface to generate false
traffic for denial of service (DoS) far exceeds the capability of traffic for denial of service (DoS) far exceeds the capability of
software based decryption or appropriately priced cryptographic hardware software based decryption or appropriately priced cryptographic hardware
to detect the false traffic. One means to protect the network elements to detect the false traffic. One means to protect the network elements
from DoS attacks under such conditions is to use packet based filtering from DoS attacks under such conditions is to use packet based filtering
techniques based on relatively simple inspections of packets. As a techniques based on relatively simple inspections of packets. As a
result, for an ISP carrying large volumes of traffic, the ability to result, for an ISP carrying large volumes of traffic, the ability to
packet filter on the basis of port numbers is an important protection packet filter on the basis of port numbers is an important protection
against DoS attacks, and a necessary adjunct to cryptographic strength against DoS attacks, and a necessary adjunct to cryptographic strength
skipping to change at page 18, line 45 skipping to change at page 22, line 4
in router design, in the event of failure of a BGP peer to provide the in router design, in the event of failure of a BGP peer to provide the
equivalent filtering, the risk of compromise can be limited to the equivalent filtering, the risk of compromise can be limited to the
peering session on which filtering is not performed by the peer or the peering session on which filtering is not performed by the peer or the
interface or line card on which the peering is supported. There is interface or line card on which the peering is supported. There is
substantial motivation and little effort for ISPs to maintain such substantial motivation and little effort for ISPs to maintain such
filters. filters.
These operational practices can considerably raise the difficulty for an These operational practices can considerably raise the difficulty for an
outsider to launch a DoS attack against an ISP. Prevented from outsider to launch a DoS attack against an ISP. Prevented from
injecting sufficient traffic from outside a network to effect a DoS injecting sufficient traffic from outside a network to effect a DoS
attack, the attacker would have to undertake much more difficult tasks, attack, the attacker would have to undertake much more difficult tasks,
such as compromise of the ISP network elements or undetected tapping such as compromise of the ISP network elements or undetected tapping
into physical media. into physical media.
5. References 5. IANA Considerations This document has no actions for IANA.
[1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work 6. References
in progress, March 2003. available as
<<draft-ietf-idr-bgp4-20.txt>> at Internet-Draft shadow sites.
[2] B. Smith and J.J. Garcia-Luna-Aceves, "Securing the Border Gateway 6.1. Normative
Routing Protocol", Proc. Global Internet'96, London, UK, 20-21
November 1996.
[3] C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy and C. Orange, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
"Routing Policy System Security", RFC 2725, December, 1999. Requirement Levels", RFC 2119, BCP 14, March 1997.
[4] S. Kent and R.Atkinson, "Security Architecture for the Internet [TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Protocol", RFC2401, November 1998. Signature Option", RFC2385, August 1998.
[5] A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature [BGP] Rekhter, Y. and Li, T., "A Border Gateway Protocol 4 (BGP-
Option", RFC2385, August 1998. 4)", work in progress, September 2004. available as
<<draft-ietf-idr-bgp4-25.txt>> at Internet-Draft shadow
sites.
[6] S.Kent, C.Lynn, and K. Seo, "Secure Border Gateway Protocol 6.2. Informative
(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 [IPsec] Kent, S. and Atkinson, R., "Security Architecture for the
Security Considerations", work in progress, January 2003. Internet Protocol", RFC2401, November 1998.
available as
<<draft-iab-sec-cons-03.txt>> at Internet-Draft shadow sites.
6. Author's Address [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 Korver, B., "Guidelines for Writing RFC Text
on Security Considerations", RFC3552, BCP72, 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., Murphy, S. and
Orange, C., "Routing Policy System Security", RFC 2725,
December 1999.
[Watson04] Watson, P., "Slipping In The Window: TCP Reset Attacks",
CanSecWest 2004, April 2004.
7. Author's Address
Sandra Murphy Sandra Murphy
Network Associates, Inc. Sparta, Inc.
NAI Labs 7075 Samuel Morse Drive
3060 Washington Road Columbia, MD 21046
Glenwood, MD 21738
EMail: Sandy@tislabs.com EMail: Sandy@tislabs.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line 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 that may be required to implement this
standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/