ORIGIN, NEXT_HOP or AS_PATH, etc.) The deletion of routes can cause
a cascading effect in which routing changes propagate through other
peers. Also, optionally, an implementation-specific peer oscillation
damping may be performed. The peer oscillation damping process can
affect how soon the connection can be restarted. Consequently, the
ability of an outsider to spoof this message 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
additional opportunity to cause damage.
Event 27: An Update message that arrives in any state except
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 in which routing
changes propagate through other peers. Also, optionally, an
implementation-specific peer oscillation damping may be performed.
The peer oscillation damping process can affect how soon the
connection can be restarted. Consequently, the ability of an
outsider to spoof this message can lead to a severe disruption of
routing over a wide area.
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
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 (see Event 28, above). As a
true BGP speaker is able to close a connection at any time, this
vulnerability represents an additional risk only when the source is
not the configured BGP peer, i.e., it presents no additional risk
from BGP speakers.
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.
3.1.5.3. Path Attributes
The path attributes present many different vulnerabilities and risks.
o 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) not to 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 an 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 (see Event 28, above). As a true
BGP speaker is 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.
o ORIGIN
This field indicates whether the information was learned from IGP
or EGP information. This field is used in making routing
decisions, so there is some small vulnerability of being able to
affect the receiving BGP speaker’s routing decision by modifying
this field.
o AS_PATH
A BGP peer or outsider could announce an AS_PATH that was not
accurate for the associated NLRI.
Because a BGP peer might not verify that a received AS_PATH 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 impact on itself. This could affect the receiving BGP
speaker’s decision procedure and choice of installed route. The
malicious peer could considerably shorten the AS_PATH, which will
increase that route’s chances of being chosen, possibly giving the
malicious peer access to traffic it would otherwise not receive.
The shortened AS_PATH also could result in routing loops, as it
does not contain the information needed to prevent loops.
It is possible for a BGP speaker to be configured to accept routes
with its own AS number in the AS path. Such operational
considerations are defined to be "outside the scope" of the BGP
specification. But because AS_PATHs can legitimately have loops,
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 use any value for the NEXT_HOP, this
provides a malicious BGP speaker considerable control over the
path traffic will take.
o 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. A 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 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
misdirected traffic.
o 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 who modified this field
could disrupt the forwarding of traffic between the two ASes.
If 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. A malicious BGP speaker can
also use this technique to force another AS to carry traffic it
would otherwise not have to carry. In some cases, this could be
to the malicious BGP speaker’s benefit, as it could cause traffic
to be carried long-haul by the victim AS to some other peering
point it shared with the victim.
o 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 ASes. Consequently, this field is
only used in making routing decisions internal to one AS.
Modifying this field, whether by an outsider or a BGP peer, could
influence routing within an AS to be sub-optimal, but the effect
should be limited in scope.
o 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. Because BGP peers are free to
choose the LOCAL_PREF, modification of this field is a
vulnerability with respect to outsiders only.
o ATOMIC_AGGREGATE
The ATOMIC_AGGREGATE field indicates that an AS somewhere along
the way has aggregated several routes and advertised the aggregate
NLRI without the AS_SET being formed as usual from the ASes in the
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.
o AGGREGATOR
This field may be included by a BGP speaker who has computed the
routes represented in the UPDATE message by aggregating other
routes. The field contains the AS number and IP address of the
last aggregator of the route. It is not used in making any
routing decisions, so it does not represent a vulnerability.
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.
3.2. Vulnerabilities through Other Protocols
3.2.1. TCP Messages
BGP runs over TCP, listening on port 179. Therefore, BGP is subject
to attack through attacks on TCP.
3.2.1.1. TCP SYN
SYN flooding: Like other protocols, BGP is subject to the effects on
the TCP implementation of SYN flooding attacks, and must rely on the
implementation’s protections against these attacks.
Event 14: If an outsider were able to send a SYN to the BGP speaker
at the appropriate time during connection establishment, then the
legitimate peer’s SYN would appear to be a second connection. If the
outsider were able to continue with a sequence of packets resulting
in a BGP connection (guessing the BGP speaker’s choice for sequence
number on the SYN ACK, for example), then the outsider’s connection
and the legitimate peer’s connection would appear to be a connection
collision. Depending on the outcome of the collision detection
(i.e., if the outsider chooses 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
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
receive an 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 decision process. This attack
requires that the outsider be able to predict the sequence number
used in the SYN. The use of [TCPMD5] can counter this attack.
3.2.1.3. TCP ACK
Event 17: If an outsider were able to spoof an ACK at the
appropriate time during connection establishment, then the BGP
speaker would consider the 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 duplicate packet. Thus, this message does not
present a 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
Event 18: If an outsider were able to spoof a RST, the BGP speaker
would bring down the connection, release all associated BGP
resources, delete all associated routes, and run its decision
process. If an outsider were able to spoof a FIN, then data could
still be transmitted, but any attempt to receive it would trigger a
notification that the connection is closing. In most cases, this
results in the connection being placed in an Idle state. But if the
connection is in the Connect state or the OpenSent state at the time,
the connection will return to an Active state.
Spoofing a RST in this situation requires an outsider to guess a
sequence number that need only be within the receive window
[Watson04]. This is generally an easier task than guessing the exact
sequence number required to spoof a FIN. The use of [TCPMD5] can
counter this attack.
3.2.1.5. DoS and DDos
Because the packets directed to TCP port 179 are passed to the BGP
process, which potentially resides on a slower processor in the
router, flooding a router with TCP port 179 packets is an avenue for
DoS attacks against the router. No BGP mechanism can defeat such
attacks; other mechanisms must be employed.
3.2.2. Other Supporting Protocols
3.2.2.1. Manual Stop
Event 2: A manual stop event causes the BGP speaker to bring down
the connection, release all associated BGP resources, delete all
associated routes, and run its decision process. If the mechanism by
which a BGP speaker was informed of a manual stop is not carefully
protected, the BGP connection could be destroyed by an outsider.
Consequently, BGP security is secondarily dependent on the security
of the management and configuration protocols that are used to signal
this event.
3.2.2.2. Open Collision Dump
Event 23: The OpenCollisionDump event may be generated
administratively when a connection collision event is detected and
the 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
management and configuration protocols that are used to 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 remote peer might consider the connection unresponsive and bring
the connection down, thus releasing resources, deleting associated
routes, etc. Consequently, BGP security is secondarily dependent on
the security of the operation, management, and configuration
protocols that are used to modify the timers.
4. Security Considerations
This entire memo is about security, describing an analysis of the
vulnerabilities that exist in BGP.
Use of the mandatory-to-support mechanisms of [TCPMD5] counters the
message insertion, deletion, and modification attacks, as well as
man-in-the-middle attacks by outsiders. If routing data
confidentiality is desired (there is some controversy as to whether
it is a desirable security service), the use of IPsec ESP could
provide that service.
4.1. Residual Risk
As cryptographic-based mechanisms, both [TCPMD5] and IPsec [IPsec]
assume that the cryptographic algorithms are secure, 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 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 Adjacency Protection: sign the originating AS
and predecessor information ([Smith96])
(3) Origination and Route Protection: sign the originating AS, and
nest signatures of AS_PATHs to the number of consecutive bad
routers you want to prevent from causing damage. ([SBGP00])
(4) Filtering: rely on a registry to verify the AS_PATH and NLRI
originating AS ([RPSL]).
Filtering is in use near some customer attachment points, but is not
effective near the Internet center. The other mechanisms are still
controversial and are not yet in common use.
4.2. Operational Protections
BGP is primarily used as a means to provide reachability information
to Autonomous Systems (AS) and to distribute external reachability
internally within an AS. BGP is the routing protocol used to
distribute global routing information in the Internet. Therefore,
BGP is used by all major Internet Service Providers (ISP), as well as
many smaller providers and other organizations.
BGP’s role in the Internet puts BGP implementations in unique
conditions, and places unique security requirements on BGP. BGP is
operated over interprovider interfaces in which traffic levels push
the state of the art in specialized packet forwarding hardware and
exceed the performance capabilities of hardware implementation of
decryption by many orders of magnitude. The capability of an
attacker using a single workstation with high speed interface to
generate false traffic for denial of service (DoS) far exceeds the
capability of software-based decryption or appropriately-priced
cryptographic hardware to detect the false traffic. Under such
conditions, one means to protect the network elements from DoS
attacks is to use packet-based filtering techniques based on
relatively simple inspections of packets. As a result, for an ISP
carrying large volumes of traffic, the ability to packet filter on
the basis of port numbers is an important protection against DoS
attacks, and a necessary adjunct to cryptographic strength in
encapsulation.
Current practice in ISP operation is to use certain common filtering
techniques to reduce the exposure to attacks from outside the ISP.
To protect Internal BGP (IBGP) sessions, filters are applied at all
borders to an ISP network. This removes all traffic destined for
network elements’ internal addresses (typically contained within a
single prefix) and the BGP port number (179). If the BGP port number
is found, packets from within an ISP are not forwarded from an
internal interface to the BGP speaker’s address (on which External
BGP (EBGP) sessions are supported), or to a peer’s EBGP address.
Appropriate router design can limit the risk of compromise when a BGP
peer fails to provide adequate filtering. The risk can be limited to
the peering session on which filtering is not performed by the peer,
or to the interface or line card on which the peering is supported.
There is substantial motivation, and little effort is required, for
ISPs to maintain such filters.
These operational practices can considerably raise the difficulty for
an outsider to launch a DoS attack against an ISP. Prevented from
injecting sufficient traffic from outside a network to effect a DoS
attack, the attacker would have to undertake more difficult tasks,
such as compromising the ISP network elements or undetected tapping
into physical media.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[TCPMD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, Eds., "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
5.2. Informative References
[IPsec] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[SBGP00] Kent, S., Lynn, C. and Seo, K., "Secure Border Gateway
Protocol (Secure-BGP)", IEEE Journal on Selected Areas in
Communications, Vol. 18, No. 4, April 2000, pp. 582-592.
[SecCons] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[Smith96] Smith, B. and Garcia-Luna-Aceves, J.J., "Securing the
Border Gateway Routing Protocol", Proc. Global Internet
’96, London, UK, 20-21 November 1996.
[RPSL] Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
Murphy, "Routing Policy System Security", RFC 2725,
December 1999.
[Watson04] Watson, P., "Slipping In The Window: TCP Reset Attacks",
CanSecWest 2004, April 2004.
Author’s Address
Sandra Murphy
Sparta, Inc.
7075 Samuel Morse Drive
Columbia, MD 21046
EMail: Sandy@tislabs.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
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.