Border gateway protocol security

Date updated: December 17, 2019

Withdrawn NIST Technical Series Publication

Warning Notice

The attached publication has been withdrawn (archived), and is provided solely for historical purposes.

It may have been superseded by another publication (indicated below).

Withdrawn Publication

Series/Number

NIST Special Publication 800-54

Title

Border Gateway Protocol Security

Publication Date(s)

July 2007

Withdrawal Date

December 17, 2019

Withdrawal Note

SP 800-54 is superseded in its entirety by the publication of SP 800-189

Superseding Publication(s) (if applicable)

The attached publication has been superseded by the following publication(s):

Series/Number

NIST Special Publication 800-189

Title

Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation

Author(s)

Kotikalapudi Sriram; Doug Montgomery

Publication Date(s)

December 2019

URL/DOI

https://doi.org/10.6028/NIST.SP.800-189

Additional Information (if applicable)

Contact

Advanced Network Technologies Division

Latest revision of the

attached publication

Related Information

https://csrc.nist.gov/publications/detail/sp/800-189/final

Withdrawal

Announcement Link

Special Publication 800-54

July 2007

Border Gateway Protocol

Security

Recommendations of the National Institute

of Standards and Technology

Rick Kuhn

Kotikalapudi Sriram

Doug Montgomery

NIST Special Publication 800-54

C O M P U T E R S E C U R I T Y

Computer Security Division

Information Technology Laboratory

National Institute of Standards and Technology

Gaithersburg, MD 20899-8930

July 2007

U.S. Department of Commerce

Carlos M. Gutierrez, Secretary

Technology Administration

Robert C. Cresanti, Under Secretary of Commerce for

Technology

National Institute of Standards and Technology

William Jeffrey, Director

BORDER GATEWAY PROTOCOL SECURITY

Reports on Computer Systems Technology

The Information Technology Laboratory TL) at the National Institute of Standards and Technology

(NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s

measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of

concept implementations, and technical analyses to advance the development and productive use of

information technology. ITL’s responsibilities include the development of technical, physical,

administrative, and management standards and guidelines for the cost-effective security and privacy of

sensitive unclassified information in Federal computer systems. This Special Publication 800-series

reports on ITL’s research, guidance, and outreach efforts in computer security, and its collaborative

activities with industry, government, and academic organizations.

National Institute of Standards and Technology Special Publication 800-54

Natl. Inst. Stand. Technol. Spec. Publ. 800-54, 61 pages (July 2007)

Note to Readers

This document is a publication of the National Institute of Standards and Technology (NIST) and is not

subject to U.S. copyright. Certain commercial entities, equipment, or materials may be identified in this

document in order to describe an experimental procedure or concept adequately. Such identification is not

intended to imply recommendation or endorsement by the National Institute of Standards and

Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best

available for the purpose.

For questions or comments on this document, contact Rick Kuhn, [email protected] or 301-975-3337.

Acknowledgements

The authors (Rick Kuhn, Kotikalapudi Sriram, and Doug Montgomery) wish to thank their colleagues

who reviewed drafts of this document and contributed to its development. The authors also gratefully

acknowledge and appreciate the many contributions from the public and private sectors whose thoughtful

and constructive comments improved the quality and accuracy of this publication, including Tim Grance,

Okhee Kim, Oliver Borchert, Sandy Murphy, Karen Scarfone, Stephen Hamilton, Brian McNamara,

Patrik Fältström, Bruce Potter, Hank Nussbacher, Paul Ferguson, Peiter Zatko, Valdis Kletnicks, Hank

Kilmer, Terry L. Sherald, Jack Harris, Janell Poindexter, and Lovell King II.

Certain commercial entities, equipment, or materials may be identified in this

document in order to describe an experimental procedure or concept adequately.

Such identification is not intended to imply recommendation or endorsement by the

National Institute of Standards and Technology, nor is it intended to imply that the

entities, materials, or equipment are necessarily the best available for the purpose.

BORDER GATEWAY PROTOCOL SECURITY

Table of Contents

1. Introduction ......................................................................................................................1-1

1.1 Authority...................................................................................................................1-1

1.2 Document Scope and Purpose................................................................................1-2

1.3 Audience and Assumptions .....................................................................................1-2

1.4 Document Organization ...........................................................................................1-2

2. Border Gateway Protocol Overview ...............................................................................2-1

2.1 Review of Router Operation.....................................................................................2-1

2.2 Review of IP Addressing Notation ...........................................................................2-1

2.3 How BGP Works......................................................................................................2-2

2.3.1 Path Attributes ..............................................................................................2-5

2.3.2 Finding Paths – the BGP Decision Algorithm ...............................................2-7

2.4 BGP Standards........................................................................................................2-8

3. BGP Risks and Threats ...................................................................................................3-1

3.1 Generic Attacks........................................................................................................3-1

3.2 Potential Attacks on BGP.........................................................................................3-3

3.2.1 Peer Spoofing and TCP Resets ...................................................................3-3

3.2.2 TCP Resets Using ICMP ..............................................................................3-4

3.2.3 Session Hijacking .........................................................................................3-4

3.2.4 Route Flapping .............................................................................................3-5

3.2.5 Route Deaggregation ...................................................................................3-7

3.2.6 Malicious Route Injection..............................................................................3-8

3.2.7 Unallocated Route Injection..........................................................................3-8

3.2.8 Denial of Service via Resource Exhaustion..................................................3-9

3.2.9 Link Cutting Attack......................................................................................3-10

4. Countermeasures and Security Mechanisms ...............................................................4-1

4.1 The Secure BGP Template......................................................................................4-1

4.2 Prefix Filtering..........................................................................................................4-2

4.2.1 Special Use Addresses ................................................................................4-3

4.2.2 “Bogon” Addresses.......................................................................................4-4

4.2.3 IPv4 Filtering Guidelines...............................................................................4-5

4.2.4 Access Control Lists.....................................................................................4-5

4.2.5 Peripheral Traffic Filtering ............................................................................4-6

4.2.6 Reverse Path Source Address Validation ....................................................

4-7

4.3 Sequence Number Randomization..........................................................................4-7

4.4 Generalized TTL Security Mechanism (TTL Hack)..................................................4-8

4.5 MD5 Signature Option .............................................................................................4-9

4.6 IPsec......................................................................................................................4-10

4.7 BGP Protocol Variations and Configuration...........................................................4-10

4.8 Router Protection and Physical Security................................................................4-11

5. Recovery and Restart ......................................................................................................5-1

5.1 Graceful Restart Mechanism for BGP......................................................................5-1

5.2 Virtual Router Redundancy Protocol........................................................................5-4

List of Appendices

Appendix A— References ...................................................................................................... A-1

Appendix B— Acronyms........................................................................................................B-1

Appendix C— Definitions.......................................................................................................C-1

Appendix D— BGP State Transitions ................................................................................... D-1

List of Figures

Figure 2-1. Growth of BGP Routing Tables, 1994 – 2005 ........................................................2-3

Figure 2-2. Routing Table Entries for Paths to NIST’s 129.6.0.0/16 Addresses.......................2-8

Figure 3-1. TCP Reset Attack ...................................................................................................3-3

Figure 3-2. Penalty Accumulation in Route Flap Damping .......................................................3-6

Figure 4-1. TCP Sequence Number Establishment..................................................................4-7

Figure 4-2. TTL Processing ......................................................................................................4-8

Figure 4-3. BGP TTL Hack .......................................................................................................4-9

Figure 5-1. Graceful Restart Message Sequence.....................................................................5-3

Figure 5-2. Attack Rates Needed to Cause RFD Triggered Isolation .......................................5-4

List of Tables

Table 2-1. Common Header and Message Format ..................................................................2-4

Table 2-2. OPEN Message Format...........................................................................................2-4

Table 2-3. UPDATE Message Format ......................................................................................2-5

Table 2-4. KEEPALIVE Message Format .................................................................................2-5

Table 2-5. NOTIFICATION Message Format ...........................................................................2-5

Table 3-1. Peer Spoofing Countermeasures ............................................................................3-4

Table 3-2. TCP Reset Countermeasures..................................................................................3-4

Table 3-3. Session Hijacking Countermeasures.......................................................................3-5

Table 3-4. Route Flap Countermeasures..................................................................................3-6

Table 3-5. Route Deaggregation Countermeasures .................................................................3-7

Table 3-6. Malicious Route Injection Countermeasures ...........................................................3-8

Table 3-7. Unallocated Route Injection Countermeasures .......................................................3-9

BORDER GATEWAY PROTOCOL SECURITY

Table 3-8. Resource Exhaustion Countermeasures .................................................................3-9

Table 3-9. Link Cutting Attack Countermeasures ...................................................................3-10

Table 4-1. BGP Event Handling..............................................................................................4-11

Executive Summary

This document introduces the Border Gateway Protocol (BGP), explains its importance to the Internet,

and provides a set of best practices that can help in protecting BGP. Best practices described here are

intended to be implementable on nearly all currently available BGP routers. While a number of enhanced

protocols for BGP have been proposed, these generally require substantial changes to the protocol and

may not interoperate with current BGP implementations. While the recommendations in this

documentcan contribute to greatly improved BGP security, they are not a complete defense against all

threats. Security administrators and decision makers should select and apply these methods based on their

unique needs. To improve the security of BGP routers, the recommendations listed below are introduced.

 Establish and use access control lists. This feature is available on nearly all routers. (See Section 4.2)

 Use BGP graceful restart, when available with latest manufacturer-recommended default settings (see

Section 5.1).

 Use BGP peer authentication. Authentication is one of the strongest mechanisms for preventing

malicious activity. Use Internet Protocol Security (IPsec) or BGP MD5 authentication mechanisms,

if available (see Section 4.5 and Section 4.6).

 Use prefix limits to avoid filling router tables. Routers should be configured to disable or terminate a

BGP peering session and issue warning messages to administrators when a neighbor sends in excess

of a preset number of prefixes. (see Section 4.2)

 Only allow peers to connect to port 179. The standard port for receiving BGP session OPENs is port

179, so attempts by peers to reach other ports are likely to indicate faulty configuration or potential

malicious activity.

 Configure BGP to allow announcing only designated netblocks. This option will prevent the router

from inadvertently providing transit to networks not listed by the autonomous system (AS) (see

Section 2.3).

 Filter all bogon prefixes. These prefixes (see Section 4.2.2) are invalid, so they should not appear in

routes. Filtering them reduces load and helps reduce the ability of attackers to use forged addresses in

denial of service or other attacks.

 Where feasible, routers should do ingress filtering on peers (see Section 4.2, including 4.2.5).

 Do not allow over-specific prefixes. Requiring routers to maintain large numbers of very specific

prefixes can place excessive load on system resources. Recommendations vary as to what prefixes

should be considered “over-specific”, but a reasonable criterion could be those with prefix addresses

in the range of /24 to /30.

 Turn off fast external failover to avoid major route changes due to transient failures of peers to send

keepalives. The “fast external failover” feature was designed to allow rapid failover to an alternate

system when a link goes down. Without this feature, failover would not occur until BGP keepalive

timers would permit recognition that the line had failed. It is not uncommon for lines to drop BGP

sessions and then return, referred to as route flapping (see Section 3.2.4). Frequent flapping can

trigger flap damping in upstream peers. Due to fast external failovers, flap damping would occur at

upstream routers, which in turn results in prolonged peer-prefix unreachability and system instability.

So turning off fast external failover normally represents a positive tradeoff in today’s Internet.

BORDER GATEWAY PROTOCOL SECURITY

 Tradeoffs are involved with route flap damping (RFD), and current research suggests that it

contributes to a number of problems. It should not be enabled unless the organization has a strong

case for its use. See Section 3.2.4 for a discussion of RFD.

 If route flap damping is used, longer prefixes should be damped more aggressively. Longer prefixes

tend to be less stable, so longer RFD times are preferable. Sample half-time periods of RFD decay

are as follows:

– less than /21 – manufacturer recommendation (conventional default is 15 minutes)

– /21 and shorter prefixes – not more than 30 minutes

– /22 to /23 prefixes – not more than 45 minutes

– /24 and greater prefixes – not more than 60 minutes.

 Do not use route flap damping for netblocks that contain domain name system (DNS) root servers.

These networks are normally the most stable, and can be expected to remain operating in all but the

most exceptional circumstances. Damping these netblocks would therefore be likely to have more

negative results than benefits. DNS root servers are also critical for Internet operations, so degraded

access to them could cause widespread disruption of network operations.

 Use soft reconfiguration, where practical. Normally a change in policy requires BGP sessions to be

cleared before the new policy can be initiated, resulting in a need to rebuild sessions with consequent

impact on routing performance. Thus, spoofed policy changes could be used for a denial of service

attack, even if the policy changes themselves do not violate AS rules. Soft reconfiguration allows

new policies to be initiated without resetting sessions. It is done on a per-peer basis, and can be set

up for either inbound or outbound or both (for updates from and to neighbors, respectively). A

recent improvement to soft reconfiguration is Route Refresh (RFC 2918 [36]). The route refresh

capability allows dynamic exchange of route refresh requests between BGP peers, to obtain a re-

advertisement of Adj-RIB-Out. This capability avoids the need to store unmodified copies of the

routes learned from peers at all times.

 Record peer changes. Log whenever a peer enters or leaves Established state, providing useful

records for debugging or audit trails for investigating possible security problems.

BORDER GATEWAY PROTOCOL SECURITY

1. Introduction

Although not well known among everyday users, the Border Gateway Protocol (BGP) is one of the

critical infrastructure protocols for the Internet. BGP is a routing protocol, whose purpose is to keep

systems on the Internet up to date with information needed to receive and transmit traffic correctly.

Sending and receiving email, viewing Web sites, and performing other Internet activities require the

transmission of messages referred to as packets. Packets sent on the Internet contain source and

destination addresses, much like paper mail sent in envelopes. But packets do not go directly from a

user’s computer to their destination. Many intermediate systems may be involved in the transmission,

and because there are many paths from one point to another, not all packets follow the same path between

source and destination. The systems that packets pass through from one point to another all need to know

where to forward a packet, based on the destination address and information contained in a routing table.

The routing table says, for example, that packets with a destination of A can be sent to system H, which

will then forward the packets to their destination, possibly through other intermediate nodes. (Note that

the terms “routing table” and “forwarding table” are often used interchangeably, although technically the

forwarding table is used to determine where packets will be sent. More on the distinction between these

tables can be found in Section 2.1.) Because the Internet changes continuously, as systems fail or are

replaced or new systems are added, routing tables must be updated constantly. BGP is the protocol that

serves this purpose for the global Internet. When BGP fails, portions of the Internet may become

unusable for a period of time ranging from minutes to hours.

Most of the risk to BGP comes from accidental failures, but there is also a significant risk that attackers

could disable parts or all of network, disrupting communications, commerce, and possibly putting lives

and property in danger. This document discusses the structure and function of BGP, potential attacks,

available countermeasures, and the costs and benefits related to countermeasures. The emphasis in this

publication is on measures that may be applied either immediately or in a short time. A variety of

proposals have been introduced in standards bodies for more comprehensive approaches to BGP security,

but issues are not yet settled as to which, if any, of these proposals will be adopted by the producers and

consumers of routing equipment. The aim of this document is to give decision makers a selection of

measures that can be deployed rapidly, yet provide significant improvements to routing security.

1.1 Authority

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its

statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002,

Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for

providing adequate information security for all agency operations and assets, but such standards and

guidelines shall not apply to national security systems. This guideline is consistent with the requirements

of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency

Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental

information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental

organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and

binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these

guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,

Director of the OMB, or any other Federal official.

1-1

1.2 Document Scope and Purpose

The purpose of this document is to provide agencies with background information on the Border Gateway

Protocol and methods available for improving its security. Agencies are encouraged to tailor the

recommended guidelines and solutions to meet their specific security or business requirements. Many

extensions to BGP have been proposed, and a few have begun to see a degree of acceptance in the market.

Because the aim of this document is to provide information on BGP as it is implemented for most

systems, a number of extensions are out of scope, including several proposed modified BGP protocols for

security, and multicast BGP. If these proposals begin to see widespread adoption, they may be included

in a future draft of this publication.

1.3 Audience and Assumptions

This document assumes that the readers have some minimal operating system, networking, and security

expertise. Because of the constantly changing nature of the information technology industry, readers are

strongly encouraged to take advantage of other resources (including those listed in this document) for

more current and detailed information.

1.4 Document Organization

The document is divided into five sections followed by references. Because BGP may be unfamiliar to

many readers, the next section explains the BGP protocol and its use in networking. Section 3.2 reviews

potential attacks against BGP and lists countermeasures for each attack type. The countermeasures are

explained in more detail in Section 4, followed by a collection of references for extensive information on

the subjects covered in this document.

1-2

BORDER GATEWAY PROTOCOL SECURITY

2. Border Gateway Protocol Overview

Although unknown to most users, the Border Gateway Protocol (BGP) is critical to keeping the Internet

running. BGP is a routing protocol, which means that it is used to update routing information between

major systems. BGP is in fact the primary interdomain routing protocol, and has been in use since the

commercialization of the Internet. Because systems connected to the Internet change constantly, the most

efficient paths between systems must be updated on a regular basis. Otherwise, communications would

quickly slow down or stop. Without BGP, email, Web page transmissions, and other Internet

communications would not reach their intended destinations. Securing BGP against attacks by intruders

is thus critical to keeping the Internet running smoothly.

Many organizations do not need to operate BGP routers because they use Internet service providers (ISP)

that take care of these management functions. But larger organizations with large networks have routers

that run BGP and other routing protocols. The collection of routers, computers, and other components

within a single administrative domain is known as an autonomous system (AS). An ISP typically

represents a single AS. In some cases, corporate networks tied to the ISP may also be part of the ISP’s

AS, even though some aspects of their administration are not under the control of the ISP.

2.1 Review of Router Operation

In a small local area network (LAN), data packets are sent across the wire, typically using Ethernet

hardware, and all hosts on the network see the transmitted packets. Packets addressed to a host are

received and processed, while all others are ignored. Once networks grow beyond a few hosts, though,

communication must occur in a more organized manner. Routers perform the task of communicating

packets among individual LANs or larger networks of hosts.

To make internetworking possible, routers must accomplish these primary functions:

 Parsing address information in received packets

 Forwarding packets to other parts of the network, sometimes filtering out packets that should not be

forwarded

 Maintaining tables of address information for routing packets.

BGP is used in updating routing tables, which are essential in assuring the correct operation of networks.

BGP is a dynamic routing scheme—it updates routing information based on packets that are continually

exchanged between BGP routers on the Internet. Routing information received from other BGP routers

(often called “BGP speakers”) is accumulated in a routing table. The routing process uses this routing

information, plus local policy rules, to determine routes to various network destinations. These routes are

then installed in the router’s forwarding table. The forwarding table is actually used in determining how

to forward packets, although the term routing table is often used to describe this function (particularly in

documentation for home networking routers).

2.2 Review of IP Addressing Notation

In the protocol used throughout today’s Internet, IP version 4, IP addresses are made up of four bytes (8-

bit fields, sometimes called octets), separated by periods, giving a total of 2

addresses. Throughout this

document, IP address blocks are given in the Classless Interdomain Routing (CIDR) format, A/n, where A

is an IP address and n is the prefix length. That is, a block of addresses is indicated by giving the IP

address prefix, followed by the number of bits (in decimal) used to designate the block. For example,

NIST’s IP addresses are in the range 129.6.0.0/16 Thus, NIST’s address block of 129.6.0.0/16 indicates

2-1

that any IP address beginning with “129.6” (addresses between the range 129.6.0.0 - 129.6.255.255)

belongs to NIST. In other words, anything after the leftmost 16 bits can be used in combination with the

leftmost 16 bits to designate an IP address for the NIST network. In binary, 129.6.0.0 is 1000 0001 0000

0110 0000 0000 0000 0000, so if the address block were given as 129.6.0.0/15, then anything after the

first 15 bits would be available, so the range would be 129.6.0.0 – 129.7.255.255, because the second byte

could be either 0000 0110 (decimal 6) or 0000 0111 (decimal 7). The size of an address block A/n is 2

32-n

For example, 129.6.0.0/16 is of size 2

32-16

= 2

= 65,536, so NIST has 65,536 possible addresses.

The significance of address block sizes for routing is that more specific addresses are normally more

efficient because more specific addresses specify a smaller block of addresses. For example, just as if we

are sending a package from Los Angeles to Baltimore, it is better to use a truck going to Maryland than

one that we only know is going somewhere on the East Coast. A “/m” block is 2

n-m

times as large as a

more specific /n block (m<n). For example, suppose one router advertises that it can reach addresses in

the range 129.6.0.0/16, and another announces 129.6.2.0/23. If an address of 129.6.3.164 is sent, the

second router would normally be preferred, because the /16 address space is 2

= 128 times as large as the

/23 space (2

= 2

x 2

). This is one reason why routers are configured to give preference to the most

specific addresses. Normally this practice makes routing more efficient, but when overly specific

addresses are announced by mistake, routers can be overloaded (see for example Section 3.2.5).

2.3 How BGP Works

A set of computers and routers under a single administration, such as a university or company network, is

known as an autonomous system (AS). AS numbers are managed by the Internet Corporation for

Assigned Names and Numbers (ICANN), a non-profit organization established by the U.S. Department of

Commerce, which authorizes Internet registration organizations to assign AS numbers. As of May 2007,

the Internet included more than 25,000 advertised ASes [20]. Packets that make up an Internet

transmission, such as a request for a Web page, are passed from one autonomous system to another until

they reach their destination. BGP’s task is to maintain lists of efficient paths between ASes. The paths

must be as short as possible, and must be loop-free. BGP routers exchange and store tables of

reachability data, which are lists of AS numbers that can be used to reach a particular destination network.

Figure 2-1 reflects the growth of BGP routing tables from 1989 – 2007. Active BGP entries (i.e., the

number of reachable prefixes) in the Forwarding Information Base (FIB) table are currently approaching

300,000. The reachability information sent between ASes is used by each AS to construct graphs of

Internet paths that are loop-free and as short as practical.

Each AS will have many routers for internal communication, and one or more routers for communications

outside the local network. Internal routers use internal BGP (iBGP) to communicate with each other, and

external routers use external BGP (eBGP). (iBGP and eBGP are the same protocol, but use different

routing rules; iBGP does not advertise third-party, outside routes.) Any two routers that have established

a connection for exchanging BGP information are referred to as peers. BGP peers use TCP, the same

protocol used for email and Web page transmissions, to exchange routing information in the form of

address prefixes that the routers know how to reach, plus additional data used in choosing among

available routes. When a BGP router starts, it attempts to establish sessions with its configured peer

routers by opening connections to port 179, the standard (or “well known”) BGP port. The router

attempting to establish the connection receives packets on a random port number greater than 1024

(referred to as an ephemeral port).

Autonomous systems can be categorized as either transit or non-transit. A transit AS is one with

connections to multiple peer ASes, which will pass transit traffic between ASes. Large Internet service

providers typically function as transit ASes. In most cases it will be easier to secure a non-transit AS

because it is connected to only one neighbor AS. A transit AS, with multiple connections, can be more

2-2

BORDER GATEWAY PROTOCOL SECURITY

easily attacked and may require greater care in establishing filtering rules. However, a non-transit AS

must ensure that it is not inadvertently being used for transit. This can be done by configuring BGP to

announce only those networks that the AS specifically lists, and denying all others.

Initially, BGP peers exchange their full routing tables. After that, incremental updates are exchanged as

routing configurations change. Conceptually, each BGP router uses three tables, or routing information

bases (RIBs):

 adj-RIB-In – routes learned from inbound update messages from BGP peers

 loc-RIB – routes selected from the adj-RIB-In table

 adj-RIB-Out – routes that the BGP router will advertise, based on its local policy, to its peers.

In actual operation, these tables may not be physically present. Their function should be supported, but

how this functionality is implemented is a design decision for developers.

As shown in Figure 2-1, routing table entries have grown at a dramatic rate as the Internet achieved

commercial use, and are projected to grow more rapidly in the future [17][21]. The presence of more

entries in the routing tables causes more BGP updates to be propagated. In addition to routing table

updates, KEEPALIVE packets are sent to maintain the connections between peers, in addition to special

packets for various error conditions.

Figure 2-1. Growth of BGP Routing Tables, 1989 – 2007.

BGP messages are at least 19 bytes (8-bit bytes) and no longer than 4096 bytes. The BGP standard

defines four message types:

 OPEN

2-3

 UPDATE

 NOTIFICATION

 KEEPALIVE.

BGP messages are sent over the TCP transport protocol. Once a TCP connection is established, a BGP

OPEN message is sent. If the receiver accepts the OPEN, it returns a KEEPALIVE to acknowledge

receipt of the OPEN. After that, UPDATE, KEEPALIVE, and NOTIFICATION messages are exchanged

according to the needs of the two BGP peers. Appendix D shows the state transitions and message

processing for BGP.

A common header is a prefix of all BGP messages. Table 2-1 shows the common header fields and field

lengths.

Table 2-1. Common Header and Message Format

Field Length (bytes)

Marker 16

Length 2

Type 1

Message 0..4077 bytes

OPEN messages contain values indicating the BGP version number, originating system’s AS number, the

“hold time” (which specifies the maximum time to wait before assuming a connection is down), sender’s

IP address, and optional parameters that may include authentication information. Table 2-2 shows the

fields and field lengths for OPEN messages.

Table 2-2. OPEN Message Format

Field Length (bytes)

BGP version 1

Autonomous system number 2

Hold time 2

BGP identifier (IP address) 4

Optional parameters length 1

Optional parameters variable: 0..255 bytes

UPDATE messages do the real work of BGP: transferring routing information between BGP peers. This

information is used by each AS to construct a routing graph that describes relationships between the

autonomous systems. Each UPDATE message advertises a single route to a prefix (destination), or

withdraws one or more unfeasible routes from service. Routes are described by one or more path

attributes. A path attribute is a variable length triple <attribute type, attribute length, attribute value>.

The next section describes path attributes and their potential values. Table 2-3 shows the fields in an

UPDATE message.

2-4

BORDER GATEWAY PROTOCOL SECURITY

Table 2-3. UPDATE Message Format

Field Length (bytes)

Withdrawn routes length 2

Withdrawn routes variable

Path attributes length 2

Path attributes <type, length, value> variable

Network layer reachability information variable

KEEPALIVE messages are exchanged between peers to indicate that the peers are up and running.

KEEPALIVE messages are normally sent at an interval of one-third of the Hold Time parameter

contained in the OPEN message that opened the connection. Table 2-4 shows the fields in a

KEEPALIVE message.

Table 2-4. KEEPALIVE Message Format

Field Length (bytes)

Marker 16

Length 2

Type 1

NOTIFICATION messages are sent to indicate various error conditions. Table 2-5 shows the fields in

these messages.

Table 2-5. NOTIFICATION Message Format

Field Length (bytes)

Error code 1

Error subcode 1

Length 2

Data Variable

2.3.1 Path Attributes

BGP uses what is known as a path vector algorithm to develop routing information. BGP update

messages provide path information about entire sequences of routers for each destination. The data, or

path attributes, are stored in the routing information base (RIB) of each BGP peer. Path attributes can be

divided into the following categories:

 Well-known mandatory

 Well-known discretionary

 Optional transitive

2-5

 Optional non-transitive.

Well-known attributes are required to be processed by all BGP implementations. Mandatory attributes

must be included in all UPDATE messages, while inclusion of discretionary attributes in UPDATEs is

optional. Well-known attributes also must be forwarded to BGP peers, although they may be updated

first. Important mandatory path attributes include ORIGIN, AS_PATH, and NEXT_HOP.

Path updates may also include optional attributes, which may not be supported by all BGP

implementations. Because an implementation may not recognize some optional attributes, a transitive bit

is used to distinguish those that must be passed along to other BGP peers.

ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is set by the AS that originates the

associated routing information. It is included in UPDATE messages of BGP speakers that propagate this

information to their BGP peers.

AS_PATH is used for preventing loops by having each AS check for its AS number in AS_PATHs sent

from other systems. Requirements for AS_PATH handling are as follows (see RFC 4271 [43]):

After receiving a route in an UPDATE message, a BGP peer propagates it to other BGP speakers,

after first modifying the route’s AS_PATH according to the location of the destination BGP

router.

1. AS_PATH associated with a route being advertised is not modified when the route is

being advertised to another BGP speaker within the same AS.

2. If a route is being advertised to a BGP speaker in a neighboring AS, then the

advertising BGP peer updates AS_PATH according to the following rules:

a. If the initial segment of AS_PATH is an AS_SEQUENCE attribute, then the

local system prepends its own AS number in the leftmost position

b. If the initial segment of AS_PATH is an AS_SET attribute (indicating more

than one AS reachable through this path), then the local system prepends a

new path segment of type AS_SEQUENCE, that includes the speaker’s own

AS number.

If a BGP speaker originates a route, then:

1. The originating BGP peer includes its own AS number in the AS_PATH attribute of

UPDATE messages that are sent to neighboring ASes.

2. The originating BGP peer includes an empty AS_PATH attribute in all UPDATE

messages sent to BGP speakers within the originating speaker’s AS.

NEXT_HOP is maintained as the IP address of the first router in a neighboring AS. Each time a BGP

route advertisement is received, NEXT_HOP is set to the IP address of the sending router if and only if an

autonomous system boundary has been crossed. That is, if the message is received from another router

within an AS, NEXT_HOP is not changed; it is updated only when a boundary router receives the

advertisement from another AS.

2-6

BORDER GATEWAY PROTOCOL SECURITY

The MULTI_EXIT_DISC (multi-exit discriminator [MED]) attribute is used to influence the entry

point to a neighboring used when there are multiple connections with the AS. It is essentially a priority

number, with lower MED values having preference. Because it is only relevant between neighboring peer

ASes, the MED attribute is only propagated to neighboring ASes.

LOCAL_PREF is an attribute used within a single AS to influence exit points to remote destinations.

LOCAL_PREF is a degree of preference for an external route, with higher numbers being preferred.

Procedures for assigning this attribute are left open to individual interpretations by administrators.

2.3.2 Finding Paths – the BGP Decision Algorithm

Traffic in a network can be divided into two categories: local traffic, to be delivered within the AS; and

transit traffic, which is received from outside the AS and is intended to pass through the AS and be passed

off to another external AS. Routers use the information gained from BGP exchanges to determine how to

route traffic destined for outside the network.

The BGP standard specifies that the choice between routes be based on “preconfigured policy

information”, but allows great flexibility in how the policy information is used for route selection.

Typical considerations in route selection include the following:

o Do not consider IBGP path if not synchronized

o Do not consider path if no route to next hop

o Highest weight (local to router)

o Highest local preference (global within AS)

o Shortest AS path

o Lowest origin code IBGP < EBGP < incomplete

o Lowest MED

o Prefer EBGP path over IBGP path

o Path with shortest next-hop metric wins

o Lowest router-id.

The BGP decision procedure applies the routing information in three steps:

1. A preference number is calculated for each of the routes received from BGP peers in other

ASes. Preferred routes are then advertised to other BGP speakers within the AS.

2. The router determines the best route for each destination from the preference levels received,

then updates the local routing information base (RIB).

3. Routes in the RIB are sent to neighboring BGP peers in other ASes.

Figure 2-2 shows example routing table entries for paths to NIST’s 129.6.0.0/16 addresses. Nine routes

are available. Route #5 can reach the NIST address through 64.200.86.153 from 216.66.23.99. The cost

metric for this route (100) is lower than other routes, so it is identified as the best route to the NIST

2-7

system. Note that 100 is the inter-AS metric for this path; a second metric is listed for the interior

gateway protocol (IGP). (IGP is a generic term for routing protocols used within (not between) ASes.)

BGP routing table entry for 129.6.0.0/16, version 8302807

Paths: (9 available, best #5)

Advertised to non peer-group peers:

64.62.142.154 64.71.128.254 128.223.60.102 128.223.60.103 128.223.60.108

206.223.137.126 206.223.137.254 209.51.163.34 216.66.3.10 216.218.185.238

6453 UUNET/ALTERNET (701) 49

63.243.149.105 from 63.243.149.105 (207.45.223.13)

Origin IGP, metric 48, localpref 100, valid, external

Community: 6939:2000

6453 UUNET/ALTERNET (701) 49

195.219.67.201 (metric 180) from 216.218.252.157 (216.218.252.157)

Origin IGP, metric 60, localpref 100, valid, internal

Community: 6939:2000

6453 UUNET/ALTERNET (701) 49

64.86.84.153 (metric 757) from 216.218.252.145 (216.218.252.145)

Origin IGP, metric 60, localpref 100, valid, internal

Community: 6939:2000

6453 UUNET/ALTERNET (701) 49

66.198.97.17 (metric 764) from 216.218.252.146 (216.218.252.146)

Origin IGP, metric 60, localpref 100, valid, internal

Community: 6939:2000

WCG (7911) UUNET/ALTERNET (701) 49

64.200.86.153 (metric 100) from 216.66.23.99 (216.66.23.99)

Origin IGP, metric 47, localpref 100, valid, internal, best

Community: 6939:2000 7911:999 7911:7307

WCG (7911) UUNET/ALTERNET (701) 49

64.200.88.13 from 64.200.88.13 (64.200.95.239)

Origin IGP, metric 48, localpref 100, valid, external

Community: 6939:2000 7911:999 7911:7307

WCG (7911) UUNET/ALTERNET (701) 49

64.200.61.185 (metric 350) from 216.218.252.154 (216.218.252.154)

Origin IGP, metric 60, localpref 100, valid, internal Community: 6939:2000

WCG (7911) UUNET/ALTERNET (701) 49

64.200.104.121 (metric 380) from 216.218.252.155 (216.218.252.155)

Origin IGP, metric 60, localpref 100, valid, internal

Community: 6939:2000

WCG (7911) UUNET/ALTERNET (701) 49

64.200.139.153 (metric 741) from 216.218.252.153 (216.218.252.153)

Origin IGP, metric 60, localpref 100, valid, internal

Community: 6939:2000 7911:999 7911:7303

Figure 2-2. Routing Table Entries for Paths to NIST’s 129.6.0.0/16 Addresses

2.4 BGP Standards

BGP is defined by a number of standards (for historical reasons called Request for Comments [RFC])

maintained by the Internet Engineering Task Force (IETF). BGP protocol version 4, the current BGP

version, plus extensions to this protocol are defined in the following documents:

 RFC 1771, A Border Gateway Protocol 4 (BGP-4) – this is the base document defining the BGP

protocol. It is an Internet standard that is used by all BGP implementations, although it includes

significant flexibility in implementation. (Note: RFC 4271 obsoletes RFC 1771).

2-8

BORDER GATEWAY PROTOCOL SECURITY

 RFC 1772, Application of the Border Gateway Protocol in the Internet – with its companion

document, RFC 1771 (which is now RFC 4271), this publication defines how BGP is to be

implemented in routers.

 RFC 1930, Guidelines for creation, selection, and registration of an Autonomous System (AS) – this

is a guideline explaining when an organization needs and should use an autonomous system. It is an

informative document, rather than a standard.

 RFC 1997, BGP Communities Attribute – establishes an optional path attribute called

COMMUNITIES, designed to simplify the control and distribution of routing information by

allowing routing decisions to be based on the identity of a group.

 RFC 2270, Using a Dedicated AS for Sites Homed to a Single Provider – this is a guideline designed

to resolve problems that arise when a site is homed to a single ISP. It is an informative document,

rather than a standard.

 RFC 2283, Multiprotocol Extensions for BGP-4 – defines extensions to the BGP4 protocol to allow it

to carry routing information for IPv6 and other network layer protocols. Because the extensions are

upwards compatible, a BGP 4 implementation can interoperate with one that supports the extensions.

 RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option – defines a TCP

extension to improve BGP security by specifying an option to include an MD5 signature in a TCP

message. This procedure provides much stronger authentication of BGP messages.

 RFC 2439, BGP Route Flap Damping – defines the route flap damping algorithm, which reduces the

volume of routing traffic between BGP peers. Commercial routers normally implement this

important BGP feature.

 IETF, RFC 2918 – Route Refresh Capability for BGP-4 – defines a BGP capability to allow dynamic

exchange of route refresh information on request between BGP speakers.

 RFC 2545, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain

Routing – specifies how BGP implementations should use the BGP attribute MP_REACH_NLRI and

MP_UNREACH_NLRI, which are used to announce and withdraw reachability information.

 RFC 4456, BGP Route Reflection: An Alternative to Full-Mesh IBGP – obsoletes RFC 2796,

described above.

 RFC 2827 (BCP 38), Network Ingress Filtering: Defeating Denial of Service Attacks which Employ

IP Source Address Spoofing – this is a Best Current Practice document that provides practical

methods to filter incoming traffic to prevent denial of service attacks that use forged IP addresses.

 RFC 3065, Autonomous System Confederations for BGP – defines an extension to BGP that can be

used to create a confederation of multiple autonomous systems. The confederation of systems

appears as a single AS to BGP peers outside of the confederation. This protocol is designed to

remove the “full mesh” requirement of BGP, to reduce administration and maintenance costs for large

autonomous systems.

 RFC 3562, “Key Management Considerations for the TCP MD5 Signature Option,” – The security of

the TCP MD5 Signature Option (RFC 2385) relies heavily on the quality of the keying material used

to compute the MD5 signature. This RFC addresses the security requirements of that keying material.

 RFC 3682, Generalized TTL Security Mechanism (GTSM) – This experimental protocol, often

referred to as the “TTL hack”, sets the TTL to 255 on outgoing packets. Since routers decrement the

2-9

TTL field by one when a packet is forwarded, adjacent peers should see incoming packets with a TTL

of 255. To implement GTSM, routers are set to ignore packets with a TTL of less than 254 (to allow

for some variations in router implementations).

 RFC 3765, NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control –

explains the use of the NOPEER advisory transitive community attribute, which allows an origin AS

to indicate that a route does not need to be advertised across bilateral peer connections.

 RFC 3768, Virtual Router Redundancy Protocol – describes a protocol for establishment and

maintenance of hot-standby routers that can provide continuity of BGP operations if a router is

disabled.

 RFC 4264, BGP Wedgies – BGP Wedgie refers to a stable but unintended (and generally undesirable)

forwarding state. This condition can occur where states other than the intended forwarding state are

equally stable and BGP converges to a stable state in a non-deterministic manner.

 RFC 4271, A Border Gateway Protocol 4 (BGP-4) – provides a set of mechanisms for supporting

Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of

destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also

introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. (RFC

4271 obsoletes RFC 1771).

 RFC 4272, BGP Security Vulnerabilities Analysis – discusses the security issues with BGP routing

data dissemination and vulnerabilities of BGP, based on the BGP specification [RFC4271].

 RFC 4276, BGP-4 Implementation Report – documents BGP implementation details from Alcatel,

Cisco, Laurel, and NextHop and summarizes BGP implementations of Avici, Data Connection, and

Nokia. Useful in understanding how options of the BGP-4 standard (RFC 4271) are handled by

different implementers.

 RFC 4277, Experience with the BGP-4 Protocol – provides an overview of BGP and reports practical

considerations for various aspects of BGP operation such as route flap damping, BGP over IPsec,

MD5 signatures, and others.

 RFC 4301, Security Architecture for the Internet Protocol – specifies the base architecture for IPsec-

compliant systems; describes how to provide a set of security services for traffic at the IP layer in

both the IPv4 and IPv6 environments; describes the security services offered by the IPsec protocols,

and how these services can be employed in the IP environment. (Obsoletes RFC 2401)

 RFC 4302 through 4309 – RFCs supplementary to RFC 4301; describe the Authentication Header

(AH) protocol [RFC 4302] and Encapsulating Security Payload (ESP) protocol [RFC 4303]; describe

cryptographic algorithms for integrity and encryption -- RFC 4305 defines the mandatory, default

cryptographic algorithms for use with AH and ESP, and RFC 4307 defines the mandatory

cryptographic algorithms for use with the Internet Key Exchange (IKEv2) protocol; describe

automatic key management (AKM) procedures -- RFC 4306 describes AKM for the IKEv2 protocol.

 RFC 4456, BGP Route Reflection: An Alternative to Full-Mesh IBGP – defines an experimental

protocol that is designed to alleviate scaling problems that derive from the need to distribute external

routing information to all routers within an AS.

 RFC 4778, Operational Security Current Practices in Internet Service Provider Environments –

documents currently deployed security mechanisms for layer 2 and layer 3 network infrastructure

devices. Although it primarily focused on IPv4, many of the same practices can (and should) apply to

IPv6 networks as well.

2-10

BORDER GATEWAY PROTOCOL SECURITY

 RIPE-229, RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parameters –

specifies route flap damping configuration for ISPs, to reduce the risk of denial of service attacks that

seek to trigger large scale flap damping. RIPE-229 prevents critical routes (such as root DNS servers)

from being damped, and uses a weighting scheme to slow down damping of other important routes.

(RIPE-229 has been obsoleted by RIPE-378.)

 RIPE-378, Recommendations on Route-flap Damping, RIPE Routing Working Group (obsoletes

RIPE-229, RIPE-210, RIPE-178), 11 May 2006. Updates recommendations on route flap damping

based on current research that indicates RFD can contribute to several security problems. RIPE-378

recommends against using RFD, although in certain cases it may be appropriate.

These RFCs and drafts can be found at the IETF Web site at http://www.ietf.org/.

2-11

BORDER GATEWAY PROTOCOL SECURITY

3. BGP Risks, Threats, and Mitigation Techniques

Like many other protocols, BGP was designed long before security became a serious issue for the

Internet. In particular, BGP does not have a built-in authentication mechanism to ensure that a message is

really from the AS that is shown as the source in messages. As a result, BGP retains a number of

vulnerabilities, despite extensions designed to shore up its security. Fortunately, many of the methods

developed over the years to improve BGP’s dependability also contribute to security against outside

attackers. For example, route flap damping and ingress/egress filtering policies have helped to make BGP

both more stable and more secure. In addition, the more precise addressing allowed by classless

interdomain routing (CIDR) makes it possible to refine the handling of prefixes in BGP, providing a

further level of protection from accidental or malicious changes to routing tables. Insider attacks, either

malicious or accidental, are a second concern. Some of the countermeasures discussed in this document

help resist both external and internal attacks, but threats from insiders require extra measures of access

control enforced within an organization.

One of the primary risks from attacks on BGP is loss of connectivity between critical portions of the

Internet; that is, email, e-commerce, and Web accesses would not function. Because of the volume of

commercial transactions conducted over the Internet, plus increasing use of the Internet for voice

communications (voice over IP [VOIP]), such an outage could have a significant impact on the economy,

and possibly interrupt critical functions such as emergency services communications. The outage could

be either widespread, affecting large portions of the Internet, or a targeted denial of service attack against

a particular organization’s network.

A second security concern for BGP is confidentiality, particularly the confidentiality risks arising from

misrouting of packets. Internet communication is not secure unless special measures are taken, such as

encryption, and most users do not encrypt email or other traffic. An eavesdropper could mount an attack

by changing routing tables to redirect traffic through nodes that can be monitored. The attacker could

thus monitor the contents or source and destination of the redirected traffic, or modify it maliciously.

This section explores significant risks to BGP operation and outlines countermeasures that can minimize

these risks. Countermeasures are rated for effectiveness and cost as Low (L), Medium (M), or High (H).

These ratings are necessarily subjective and intended as an approximate guide only. Actual cost and

effectiveness will vary with the installation. Comprehensive BGP security solutions have not yet

emerged and current “best common practices” are somewhat overlapping, confusing in scope and

applicability, and often neglect cost/benefit tradeoffs. The following sections provide more specific

configuration details and checklists of security-related features to assist in procurement of BGP

equipment. For more information on the RFC standards cited in this section, see Section 2.4.

3.1 Generic Attacks

As with other networked devices, routers are subject to denial of service, unauthorized access,

eavesdropping, packet manipulation, session hijacking, and other attacks. Attacks on BGP, detailed in the

next section, are extensions or specializations of these.

 Denial of service, potentially the greatest risk to BGP, occurs when a router is flooded with more

packets than it can handle. The attack often involves a large number of compromised hosts (a

distributed denial of service attack). A denial of service attack could come about through a number of

ways, including:

– Starvation – a node receives fewer packets than it should because traffic is sent to nodes that

cannot deliver it

3-1

– Blackhole – traffic is sent to routers that drop some or all of the packets

– Delay – traffic is forwarded through sub-optimal paths

– Looping – packets enter a looping path, so that the traffic is never delivered

– Network partition – a portion of the network appears to be partitioned from the rest of the

network because of faulty routing information

– Churn – rapid changes in packet forwarding disrupt packet delivery, possibly affecting congestion

control

– Instability – convergence to a single global forwarding state does not occur

– Network overload – the network begins carrying an excessive number of BGP messages,

overloading the router control processors and reducing the bandwidth available for data traffic

– Router resource exhaustion – router resources (storage or processing cycles) are exhausted by

excess BGP messages.

 Inducing a “BGP Wedgie” can be a potential attack vector. BGP wedgie refers to a stable but

unintended (and generally undesirable) forwarding state (see RFC 4264). This condition can occur

where states other than the intended forwarding state are equally stable and BGP converges to a stable

state in a non-deterministic manner. RFC 4264 describes the potential security exploitation of BGP

wedgies as follows. A common theme of BGP wedgies is that starting from an intended or desired

forwarding state, the loss and subsequent restoration of an eBGP peering connection can flip the

network's forwarding configuration into an unintended and potentially undesired state. Significant

administrative effort – based on BGP state and configuration knowledge that may not be locally

available – may be required to shift the BGP forwarding configuration back to the intended or desired

forwarding state. If a hostile third party can deliberately cause the BGP session to reset, thereby

producing the initial conditions that lead to an unintended forwarding state, the network impacts of

the resulting unintended or undesired forwarding state may be long-lived, far outliving the temporary

interruption of connectivity that triggered the condition. If these impacts of BGP wedgie, including

potential issues of increased cost, reduction of available bandwidth, increases in overall latency or

degradation of service reliability, are significant, then disrupting a BGP session could represent an

attractive attack vector to a hostile party.

 Unauthorized access can occur when default passwords and community strings (which control access

to Simple Network Management Protocol [SNMP] services) are not changed, or passwords are

guessed. Social engineering or exploitation of software flaws may also lead to unauthorized access.

 Eavesdropping of BGP packets may occur anywhere on the path between routers, since BGP

messages are not encrypted, or BGP may be exploited to allow eavesdropping on application data

packets.

 Packet manipulation methods include inserting false IP addresses to gain access or inject false data

into routing tables, or rerouting packets for purposes of blackholing, eavesdropping, or traffic

analysis.

 Session hijacking occurs when an intruder uses falsified packets to take over or continue an

authorized session.

3-2

BORDER GATEWAY PROTOCOL SECURITY

3.2 Potential Attacks on BGP

While not an exhaustive list, the attacks discussed in this section are the most common that are likely to

be a concern for BGP. Some, such as spoofing and session hijacking, are variants on common TCP/IP

protocol attacks, while those that involve route manipulation are more specific to BGP and related routing

protocols. Since BGP runs on TCP/IP, any TCP/IP attack can be applied to BGP. As noted, denial of

service and eavesdropping are among the primary risks from BGP attacks, but a number of subsidiary

issues are involved, as detailed in an IETF RFC 4272, BGP Security Vulnerabilities Analysis [44] (terms

explained below are often seen in discussions of BGP vulnerabilities).

3.2.1 Peer Spoofing and TCP Resets

Spoofing attacks are a concern for all network protocols. Spoofing refers to transmission of packets that

are modified to make them appear as if they originate from somewhere other than their true source. With

ordinary TCP connections under IPv4, it is easy to disguise the source address of an IP connection. When

applied to BGP, this means that the spoofed source must be that of one of the BGP speaker’s peer routers.

The goal of the spoofing attack may be to insert false information into a BGP peer’s routing tables. Peer

IP addresses can often be found using the ICMP traceroute function, so BGP implementations should

include countermeasures against this attack.

A special case of peer spoofing, called a reset attack, involves inserting TCP RESET messages into an

ongoing session between two BGP peers [5][66]. BGP is carried over TCP (the same protocol used for

common Internet communications such as Web browsing). By monitoring communication between two

BGP peers, an attacker may gain enough information to send a forged reset message to one of the routers

(see Figure 3-1).

BGP session

TCP reset

Figure 3-1. TCP Reset Attack

When a reset is received, the target router drops the BGP session and both peers withdraw routes

previously learned from each other, thus disrupting network connectivity until recovery, which may take

several minutes to hours, depending on the number of BGP peers affected. This attack is more difficult to

accomplish than spoofing the source of a new session, because in addition to the source IP address, the

source port of the session must be known, and the sequence number must fit into the ongoing connection.

While possible, an attack such as this that relies on knowing sequence numbers is more difficult than

other attacks, and countermeasures are relatively good at defeating it [39][31][5][8].

3-3

Table 3-1. Peer Spoofing Countermeasures

Method Reference

or RFC

Strength Cost Notes

Strong sequence

number

randomization

CERT Advisory

CA-2001-09 [5]

M L Varies with the underlying operating system

See Section 4.3

TTL Hack RFC 3682 M L

Simple configuration option; not effective

against machines one hop away

See Section 4.4

MD5

Signature option

RFC 2385 H M

Widely available option; may be significant

administrative cost

See Section 4.5

3.2.2 TCP Resets Using ICMP

The Internet Control Message Protocol (ICMP) can also be used to produce session resets [53]. This

attack can be substantially easier than the session reset described in Section 3.2.1, because current IETF

specifications do not require checking sequence numbers of received ICMP messages. These attacks

require knowledge of the victim’s IP address and port number, but the nature of BGP requires that they be

known. As a result, it is easy for attackers to send spoofed ICMP hard or soft error messages, which

cause TCP session reset (hard errors) or signal performance/throughput degradation (soft errors). TCP

resets cause loss of BGP peering sessions, forcing a need to rebuild routing tables and possibly causing

route flapping. The primary countermeasure is checking that the TCP sequence number is within the

range of packets sent but not yet acknowledged, i.e., SND.UNA ≤ SEG.SEQ < SND.NXT. This and other

aspects of countermeasures to ICMP-based TCP reset attacks are discussed in [18][53].

Table 3-2. TCP Reset Countermeasures

Method Reference

or RFC

Strength Cost Notes

TCP sequence

number checking

[18][53] M L Varies with the underlying operating

System. Included on Linux, FreeBSD,

OpenBSD.

TTL Hack RFC 3682 M L

Simple configuration option; not effective

against machines one hop away

See Section 4.4

Router access

control

[18] H M

Block packets of ICMP Type 3 codes 2, 3,

and 4

See also NISCC Vulnerability Advisory ICMP

– 532967 [53]

IPsec authentication [45] H M

Widely available; may be significant

administrative cost

See Section 4.6.

3.2.3 Session Hijacking

Like the TCP reset attack, session hijacking involves intrusion into an ongoing BGP session, i.e., the

attacker successfully masquerades as one of the peers in a BGP session, and requires the same

3-4

BORDER GATEWAY PROTOCOL SECURITY

information needed to accomplish the reset attack. The difference is that a session hijacking attack may

be designed to achieve more than simply bringing down a session between BGP peers. For example, the

objective may be to change routes used by the peer, in order to facilitate eavesdropping, blackholing, or

traffic analysis.

Table 3-3. Session Hijacking Countermeasures

Method Reference

or RFC

Strength Cost Notes

Strong sequence

number randomization

CERT Advisory

CA-2001-09 [5]

M L Varies with the underlying operating system

See Section 4.3

TTL Hack RFC 3682 M L Simple configuration option; not effective

against machines one hop away

MD5

Signature option

RFC 2385 H M

Widely available option; may be significant

administrative cost

See Section 4.5

IPsec

RFC 4301, plus

many related

RFCs (RFCs

4302-4309)

H H See Section 4.6

3.2.4 Route Flapping

Route flapping refers to repetitive changes to the BGP routing table, often several times a minute. A

“route flap” occurs when a route is withdrawn and then re-advertised. High-rate route flapping can cause

a serious problem for routers, because every flap causes route changes or withdrawals that propagate

through the network of ASes. If route flaps happen fast enough – e.g., 30 to 50 times per second – the

router becomes overloaded, eventually preventing convergence on valid routes. The potential impact for

Internet users is a slowdown in message delivery, and in some cases packets may not be received at all.

In other words, route flapping can result in a denial of service, either accidental or from an intentional

attack [32][61].

Route flap damping is a method of reducing route flaps by implementing an algorithm that ignores the

router sending flapping updates for a configurable period of time [32]. Each time a flapping event occurs,

peer routers add a penalty value to a total for the flapping router. The penalty decays exponentially over

−

(t'−t)

time, according to the equation

P(t') = P(t)2

, where P(t) is the penalty at time t, t’ is a future

time (t’ > t), and

is a configurable parameter (1/

= half-time of the decay). If route flaps persist often

enough, the total exceeds a configurable cutoff threshold (see Figure 3-2). At this point, routes learned

from the flapping router are withdrawn, and peers recompute their route table entries and updates are

propagated across the network. As time passes, the penalty value decays gradually; if no further flaps are

seen, it will reach a reuse threshold, at which time the peer will resume accepting routes from the

previously flapping router.

3-5

Figure 3-2. Penalty Accumulation in Route Flap Damping

While this mechanism helps to reduce instability caused by spontaneous faults in the network, it can be

misused by an attacker. If a router can be disabled, even temporarily, its BGP sessions will be disrupted

and peer routers will begin routing around it, assuming it is down. This process can trigger changes

throughout the network, leading to increased load, and possibly causing traffic to slow down as routing

changes result in less optimal forwarding. By this means, a compromised router that is disabled

repeatedly can cause disruption that might extend beyond what would occur if the router were simply shut

down. (If the router were permanently disabled, other routers would quickly find paths around it.)

Repeated BGP peering session attacks (e.g., via TCP resets or spoofed ICMP error messages) can also be

used to cause route flapping and withdrawal of routes to parts of the network. The RFD mechanism is

exploited in this attack mode to amplify the route outages drastically [61].

Table 3-4. Route Flap Countermeasures

Method

Reference

or RFC

Strength Cost Notes

Graceful Restart [58] M M

Both performance and security

benefits; must be supported by both

peers; effective up to very high attack

rates [61]

See Section 5.1

BGP Route Flap Damping w/

recommended parameters

and

RIPE Routing-WG

Recommendations for

Coordinated Route-Flap

Damping Parameters

RFC 2439

RIPE-229

M L

RFD can mitigate effects of route

flapping in certain limited scenarios,

but one should heed cautions about

potential RFD problems and abuses.

See Section5.1, RIPE-378 [59], and

[61] .

RIPE-229 specifies a “graded

damping” approach; used in

association with RFC 2439

Because of the potential problems described above, and the fact that faster processors in routers have

obviated some of the original need for RFD, network administrators should be cautious about enabling

RFD. Some current guidance (see in particular RIPE-378 [59]) recommends against using RFD, but in

3-6

BORDER GATEWAY PROTOCOL SECURITY

selected situations it may be useful. For example, RFD may help in isolating parts of the network where

attacks are in progress, limiting the spread of damage. BGP administrators should weigh the potential

risks carefully before enabling RFD. Recommendations may change as additional research is completed.

3.2.5 Route Deaggregation

Route deaggregation occurs when more specific (i.e., longer prefix) routes are advertised by BGP peers.

For example, if prefixes 129.0.0.0/8 and 129.0.0.0/16 are both advertised, BGP algorithms will select the

second (for any addresses within 129.0.0.0/16) because it is more specific. In some cases this is normal

and appropriate operation as a result of configuration changes, but it can occur as a result of error or

malicious activity. The primary impact of such an event is a degradation of service that, in some cases,

can be widespread. In 1997, a configuration error at one AS caused it to deaggregate routes, i.e.,

announce more specific routes (/24 paths) for most of the Internet. In other words, it was effectively

announcing that it had optimal paths to all destinations. Because BGP gives preference to the most

specific routes, a huge number of updates with thousands of new routes spread quickly, causing router

crashes and shutting down major ISPs for two hours.

Route deaggregation could also occur as a result of malicious activity. If a BGP peer receives a prefix

that is more specific (for a particular address block) than those in its routing table, it will update the table

with the more specific prefix, and propagate the new route to other peers. A situation similar to the 1997

route deaggregation failure mentioned above could be triggered if an AS were compromised and more

specific routes sent out to its peers. Alternatively, BGP updates could be forged to appear to come from a

valid AS.

Avoiding compromise of a router is a basic requirement to prevent attackers from causing a malicious

route deaggregation. Thus, ordinary steps required to secure an individual router are an essential first step

(see Section 4.8). A secondary requirement is to prevent the spread of deaggregated prefixes through the

Internet.

One available approach is to establish a maximum prefix limit [63]. A limit can be pre-set that causes the

router to disable or terminate a session and issue warning messages when a neighbor sends in excess of a

preset number of prefixes. Deaggregation of routes would trigger the prefix limiting feature, and the

session with that peer would be disabled until it was manually restored, giving operators an opportunity to

detect the problem and prevent it from spreading through the Internet. As with most security features,

however, there is a tradeoff between defenses for types of possible attacks. Using prefix limiting could

allow a denial of service attack if a stream of deaggregated prefix messages can be forged to come from

the victim router. Its peers would then disable connections to the victim router. However, the disruption

would be temporary, and operators would be able to intervene to restore connections.

Table 3-5. Route Deaggregation Countermeasures

Method

Ref.

or RFC

Strength Cost Notes

Max Prefix-Limit feature [63] M L Configuration option on some routers

Route filtering [35] M M See Section 4.2

Secure router administration M L See Section 4.8

3-7

3.2.6 Malicious Route Injection

BGP exists to spread routing information across the Internet. Routers tell each other what prefixes they

can reach and provide data on how efficiently they can reach addresses within these prefixes. In a benign,

cooperative environment this works well, but a malicious party could begin sending out updates with

incorrect routing information. For example, NIST’s address space is 129.6.0.0/16 (see Section 2.2).

Suppose that NIST announces 129.6.0.0/16 through BGP. An attacker who announces a more specific

route, such as a /24 address in NIST’s IP address space, would be able to divert packets that should be

sent to NIST. This would occur because other routers would view the /24 as a more direct route (see

Section 2.2) to some of the addresses within NIST, so packets would be routed to the attacker’s machine,

which could observe and record the packets’ data and address information. NIST would have no control

over the routes announced by the attacker, other than contacting the attacker’s service provider to request

a correction, and it would be difficult to prove whether the mis-routing was malicious or accidental. In

fact, NIST may not even see the attacker’s route announcement, since it would be discarded locally by

BGP to prevent route loops. Note that a similar risk occurs when an attacker gains control of a BGP router

and forces it to announce a less specific route, such as a /15. In this case, traffic would flow to

neighboring BGP routers that are announcing more specific (/16 or longer) paths, possibly overloading

these routers.

Consequences could include eavesdropping – causing other nodes to route information through the

attacker’s node; and denial of service – traffic that otherwise would be forwarded efficiently is sent via

slower routes or disappears entirely. Malicious route injection of this kind is possible because standard

BGP has no authentication to guarantee the identity of BGP peers, and no authorization mechanism to

ensure that a BGP peer has the authority to update routes to particular prefixes. Route filtering and MD5

authentication primarily address the first of these issues.

A variety of research projects have been initiated to address these problems. Most solutions are based

either on cryptographic techniques that can guarantee the authenticity of announcements [2], or on data-

driven approaches that track BGP traffic for a period of time so that faulty or fraudulent announcements

can be detected by comparing with historical data [47]. These methods are often difficult to apply on a

large scale, so they have not seen significant adoption. Until one or more of these proposed solutions are

adopted widely, basic mechanisms described in this document can add to the security of BGP.

Table 3-6. Malicious Route Injection Countermeasures

Method

Reference

or RFC

Strength Cost Notes

Route filtering [34] M M Configuration option

See Section 4.2

MD5

Signature option

RFC 2385 H M

Widely available option; may be significant

administrative cost

See Section 4.5

3.2.7 Unallocated Route Injection

A particular variety of malicious route injection involves the transmission of routes to unallocated

prefixes. These prefixes specify sets of IP addresses that have not been assigned yet, i.e., no one should

be using these addresses, so no traffic should be routed to them. Therefore, any route information for

these prefixes is clearly faulty or malicious, and should be dropped.

3-8

BORDER GATEWAY PROTOCOL SECURITY

Table 3-7. Unallocated Route Injection Countermeasures

Method

Reference

or RFC

Strength Cost Notes

Drop unallocated

prefixes

[22][62] M M Prefix list must be continually updated

See Section 4.2.2

Route filtering [35] M M See Section 4.2

MD5

Signature option

RFC 2385 H M

Widely available option; may be significant

administrative cost

See Section 4.5

Additional notes: Drop unallocated (“bogon”) prefixes – Care must be taken to ensure that valid prefixes

are not denied. As the Internet grows, prefixes are allocated to new nodes, so unallocated route lists

become obsolete quickly. In addition, some allocated prefixes may be returned, thus becoming

unallocated. Reserved address blocks may also change. A list of assigned IPv4 blocks is maintained by

the Internet Assigned Number Authority (IANA) [22]. A list of bogon prefixes is maintained by Team-

Cymru [62]. This list should be consulted regularly as part of the BGP administrative process. See the

Secure BGP Template (Section 4.1) for more information on keeping route lists up to date.

3.2.8 Denial of Service via Resource Exhaustion

Like all computers, routers have a finite amount of storage and processing cycles available. One of the

most common attacks of this type is known as a “SYN flood”, in which a large number of TCP/IP

communication sessions are started using the SYN (synchronization) packet, without follow-up by the

appropriate next packet type. This causes the receiving host to reserve storage space for the session.

With enough SYN packets, space is eventually exhausted on the host. Since BGP is implemented on

TCP/IP, BGP processing can be affected by this attack. In addition to storage needed by the underlying

TCP/IP processing, routers use a large amount of storage for path prefixes. These resources can be

exhausted if updates are received too rapidly or if there are too many path prefixes to store due to

malicious prefix announcements. A variety of countermeasures are available for these attacks. An

Internet Draft that describes SYN flood mitigation methods is available at the IETF web site (see [15]).

Table 3-8. Resource Exhaustion Countermeasures

Method

Reference

or RFC

Strength Cost Notes

Rate limit syn

processing

[12][15] M L May be a configurable option on some routers

Increase queue

length

L L May be a configurable option on some routers

Route filtering L M See Section 4.2

TTL Hack RFC 3682 M L

Simple configuration option; helps prevent DoS

floods on port 179

See Section 4.4; not effective against machines

one hop away

3-9

3.2.9 Link Cutting Attack

An inherent vulnerability in routing protocols is their potential for manipulation by cutting links in the

network [3]. By removing links, either through denial of service or physical attacks, an attacker can

divert traffic to allow for eavesdropping, blackholing, or traffic analysis. Because routing protocols are

designed to find paths around broken links, these attacks are particularly hard to defend against.

Table 3-9. Link Cutting Attack Countermeasures

Method

Reference

or RFC

Strength Cost Notes

Encryption IPsec H H

Not fully effective against traffic

analysis; not effective against

blackholing

See Section 4.6

Intrusion detection systems [3] M H

Experimental for this attack; not

widely used

Redundant backup paths to

make it difficult to divert traffic to

nodes not under your control

M H

Very expensive to maintain; not

available to most organizations

See Section 4.8

In a link-cutting attack, the attacker owns, or has compromised, one or more ASes. With knowledge of

routes in the network, the attacker can determine what links need to be cut to force traffic through the

compromised node. In effect, the attacker wants to create a situation where the compromised node is the

only path from one point in the network to others, allowing the observation of packets forced through this

node.

3-10

BORDER GATEWAY PROTOCOL SECURITY

4. Details of Countermeasures and Security Mechanisms

As originally designed, BGP has no built-in security functionality. Several alternative BGP protocols

have been proposed, but none widely implemented. Alternatively, one practical approach today to

securing BGP is to adopt countermeasures listed in the previous section. This section describes these

options in more detail, and provides references for additional information.

4.1 The Secure BGP Template

The Secure BGP Template is a useful collection of BGP configuration settings for Cisco routers, made

available by Team-Cymru [63]. It is widely used and should be considered during the procurement and

configuration of BGP. This section provides a non-vendor specific discussion of the secure BGP

template; following sections cover many of the topics noted here, and other security mechanisms, in

greater depth.

 Do not require synchronization with IBGP. BGP synchronization refers to a requirement that BGP

wait until the IGP propagates a newly learned route within the AS before advertising the route to

external peers. This feature is generally deprecated and not supported by all vendors as Internet

routing tables are now extremely large and can consume excessive resources, in addition to placing

unnecessary stress on the IGP as a result of the need to carry extra routes.