ITL Bulletin for July 2007

[InfoSec News <alerts () infosecnews org>]

Forwarded from: Elizabeth Lennon <elizabeth.lennon (at) nist.gov>

ITL BULLETIN FOR JULY 2007

BORDER GATEWAY PROTOCOL SECURITY

Shirley Radack, Editor
Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
Technology Administration
U.S. Department of Commerce

The Border Gateway Protocol (BGP) may not be familiar to the average 
user, but it plays a critical role in the effective operation of the 
Internet. BGP has been used since the commercialization of the Internet 
to update routing information between major systems. This routing 
function makes it possible for systems connected to the Internet to 
receive and transmit traffic correctly, and to deliver electronic mail 
and web page transmissions efficiently to users.

Because BGP performs a vital task in keeping the Internet running 
smoothly, the security of BGP routers is a high-priority concern for 
organizations. Many organizations do not directly operate BGP 
routers­the organizations use Internet service providers (ISPs) to 
handle the routing functions­but other large organizations with 
extensive networks operate their own routers that run BGP and other 
routing protocols.

A new guide that provides information on BGP and the methods available 
to improve the security of BGP routers was recently issued by the 
Information Technology Laboratory at the National Institute of Standards 
and Technology (NIST). While primarily directed toward helping federal 
agencies carry out their responsibilities under the Federal Information 
Security Management Act (FISMA) of 2002 (Public Law 107-347), the new 
guide is also available to private sector organizations that wish to use 
it.

NIST Special Publication (SP) 800-54, Border Gateway Protocol Security

Issued in June 2007, NIST SP 800-54, Border Gateway Protocol Security: 
Recommendations of the National Institute of Standards and Technology, 
was written by Rick Kuhn, Kotikalapudi Sriram, and Doug Montgomery. The 
publication explains the structure and the functions of BGP in terms 
that will enable those who are not familiar with the protocol to 
understand its use in networking. Potential attacks that threaten the 
security of BGP functions, the countermeasures that are available to 
thwart attacks, and their associated costs and benefits are discussed in 
detail in the guide. The emphasis is on countermeasures that can be 
applied without significant additions or changes to equipment. NIST SP 
800-54 identifies specific recommendations that help decision makers 
select the measures that can be deployed rapidly and that will 
significantly improve routing security.

The appendices to NIST SP 800-54 contain an extensive reference list of 
in-print and online resources, including references to the voluntary 
industry standards that have been developed primarily by the Internet 
Engineering Task Force (IETF) to define BGP. Also included in the 
appendices are an acronym list, definitions of the terms used in the 
publication, and a table summarizing BGP state transitions.

NIST SP 800-54 is available from NIST’s website at 
http://csrc.nist.gov/publications/nistpubs/index.html.

BGP Security

BGP, a routing protocol, has an important role in enabling the systems 
that are connected to the Internet to receive and transmit traffic 
correctly. Each network communication, such as sending and receiving 
mail and viewing websites, is accomplished through messages called 
packets. These packets contain the source and destination addresses for 
the transactions, but the packets do not go directly from a user’s 
computer to their destination. Many intermediate systems may be involved 
in the transmission of the packets, and not all of the packets follow 
the same path from source to destination. The packets pass through 
systems and are forwarded to other systems, based on the destination 
address and information contained in a routing table. For example, the 
routing table could state 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.

The routers, computers, and other components within a single 
administrative domain compose an autonomous system (AS). A university, a 
company network, and an ISP are examples of a single AS. In some cases, 
corporate networks tied to the ISP may also be part of the ISP’s AS, 
although some aspects of the network administration are not under the 
control of the ISP. AS numbers are managed by the Internet Corporation 
for Assigned Names and Numbers (ICANN), a nonprofit 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 registered autonomous 
systems.

Because the systems connected to the Internet change frequently, the 
most efficient paths between systems and the routing tables must be 
updated on a regular basis. The information in the routing tables has 
also increased considerably with the growth of the Internet.

Each AS has many routers for internal communication and one or more 
routers for communications outside the local network. Internal routers 
use interior BGP (IBGP) to communicate with each other, and external 
routers use external BGP (EBGP). Two routers that have established a 
connection for exchanging BGP information are referred to as peers. BGP 
peers use the Transmission Control Protocol (TCP), the same protocol 
used for e-mail and web page transmissions, to exchange routing 
information in the form of address prefixes that the routers recognize, 
as well as additional data that is used to select the best route for the 
information.

Risks and Attacks

If BGP fails to carry out the routing function, portions of the Internet 
may become unusable for periods 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 
networks, disrupting communications, commerce, and possibly putting 
lives and property in danger.

BGP, which was developed before security became a serious issue for the 
Internet, 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 may be vulnerable to attacks, despite 
extensions that have been developed to improve its security. Many of the 
methods developed over the years to improve the dependability of BGP 
also contribute to security against outside attackers. Attacks on BGP 
could cause a loss of connectivity between critical portions of the 
Internet; that is, e-mail, 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.

Another security concern is the potential loss of confidentiality of 
information if packets are misrouted. Internet communication is not 
secure unless special measures are taken, such as encryption, and most 
users do not encrypt e-mail 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. Insider attacks, either malicious or accidental, are 
another concern. Threats from insiders require extra measures of access 
control enforced within an organization.

Countermeasures

When developed originally, BGP had no built-in security functionality. 
However, the security of BGP can be improved through the application of 
countermeasures, which are described in NIST SP 800-54. NIST provides 
approximate ratings of countermeasures for effectiveness and cost as Low 
(L), Medium (M), or High (H). These ratings are 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 
trade-offs.

Recovery and Restart

Improving the dependability of some systems subject to denial of service 
attacks can be done by increasing the difficulty of an attack or 
reducing the time needed to recover from such an attack. In terms of 
system availability, the first option corresponds to increasing system 
uptime, U, while attack recovery corresponds to reducing downtime, D 
(ignoring other sources of downtime). Availability is calculated as U/(U 
+ D). For example, a system with uptime of 1000 hours (over a 
measurement period) and a downtime of 1 hour has availability of 
1000/1001 = 99.9%. If recovery time can be reduced to 0.1 hours, 
availability improves significantly, to 99.99%. By contrast, if recovery 
time remains at 1 hour, defenses would have to be strengthened to hold 
off attacks for 10,000 hours to achieve the same 99.99% availability. 
Reducing the time needed to recover from a denial of service attack can 
improve BGP availability and, for some attacks, may be a more 
cost-effective strategy than hardening defenses. Quicker recovery also 
means less disruption to other parts of the network.

NIST Recommendations for the Security of BGP Routers

NIST recommends that organizations adopt a program of best practices to 
help protect BGP routers. The recommendations, which are detailed in 
NIST SP 800-54, can be implemented on current BGP routers to improve 
security.

Following is a summary of NIST’s technical recommendations; in some 
cases, references are provided to specific sections of the BGP guide, 
which explains in more detail the rationale for the actions and the 
recommended steps to be taken. These steps alone are not a complete 
defense against all threats, and security administrators and decision 
makers should select and apply these methods based on their unique 
needs.

* Establish and use access control lists. This feature is available on 
 nearly all routers (see Section 4.2 of the publication).

* 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 (an address that is reserved but not yet registered) 
 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 (filtering of 
 incoming prefixes) 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.  (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.)

* 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.  This is 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 trade-off in today's Internet.

* Trade-offs 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; and
-  /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).

* 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.

Future Activities

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. When the extensions become more 
widely accepted, NIST will consider developing updated recommendations 
for BGP security.

More Information

NIST publications assist organizations in planning and implementing a 
comprehensive approach to information security, including basic planning 
functions, the risk management process, and the selection, 
implementation, and assessment of security controls.

Publications dealing specifically with network protocol issues include:

NIST SP 800-77, Guide to IPsec VPNs, by Sheila Frankel, Karen Kent, Ryan 
Lewkowski, Angela D. Orebaugh, Ronald W. Ritchey, and Steven R. Shama, 
explains security controls that can be implemented to protect 
Transmission Control Protocol/Internet Protocol (TCP/IP) network 
communications.

NIST SP 800-52, Guidelines for the Selection and Use of Transport Layer 
Security (TLS) Implementations, by C. Michael Chernick, Charles Edington 
III, Matthew J. Fanto, and Rob Rosenthal, discusses computer 
communications architectural concepts and the foundations of 
communications security.

These publications and other security-related publications, including 
Federal Information Processing Standards (FIPS), are available from 
NIST’s website http://csrc.nist.gov/publications/nistpubs/index.html.

Disclaimer

Any mention of commercial products or reference to commercial 
organizations is for information only; it does not imply recommendation 
or endorsement by NIST nor does it imply that the products mentioned are 
necessarily the best available for the purpose.


Elizabeth B. Lennon
Writer/Editor
Information Technology Laboratory
National Institute of Standards and Technology
100 Bureau Drive, Stop 8900
Gaithersburg, MD 20899-8900
Telephone (301) 975-2832
Fax (301) 975-2378

_____________________________________________________
Attend Black Hat USA, July 28-August 2 in Las Vegas, 
the world's premier technical event for ICT security 
experts. Featuring 30 hands-on training courses and 
90 Briefings presentations with lots of new content 
and new tools. Network with 4,000 delegates from 
70 nations.   Visit product displays by 30 top
sponsors in a relaxed setting. Rates increase on 
June 1 so register today. http://www.blackhat.com