Protecting Border Gateway Protocol for the Enterprise

Summary of Border Gateway Protocol

The Border Gateway Protocol (BGP), which is defined in RFC 1163 and RFC 1267, is an Exterior Gateway Protocol (EGP) that is most often associated with the Internet and with Service Provider (SP) networks. Because many networks utilize static routing and a single connection for Internet access, BGP is unnecessary. However, as organizations increase their web presence and reliance on the Internet for revenue, the need for reliable and geographically diverse Internet connectivity has become more common. These needs are often met through multi-home configurations that require BGP for connectivity to an SP's BGP-speaking routers. This emerging trend requires organizations to obtain a high level of BGP and BGP Security expertise that is typically found in SPs. This document is intended to assist enterprise administrators who are using or investigating the use of BGP as a routing protocol in their network.

Summary of BGP Threats

Administrators must understand many important aspects of BGP as a protocol to assess where it may be susceptible to various forms of attack and where it must be protected. First, unlike other routing protocols that typically provide their own transport layer (Layer 4) protocol, BGP relies on TCP as its transport protocol. BGP is susceptible to the same attacks that target any TCP-based protocol, and it must be protected similarly. Additionally, because BGP as an application is vulnerable to various threats, administrators must mitigate the risk and potential impact of associated exploit attempts. Some of these threats include the following:

  • BGP Route Manipulation– This scenario occurs when a malicious device alters the contents of the BGP routing table, which can, among other impacts, prevent traffic from reaching its intended destination without acknowledgement or notification.
  • BGP Route Hijacking– This scenario occurs when a rogue BGP peer maliciously announces a victim's prefixes in an effort to reroute some or all traffic to itself for untoward purposes (for example, to view contents of traffic that the router would otherwise not be able to read).
  • BGP Denial of Service (DoS)– This scenario occurs when a malicious host sends unexpected or undesirable BGP traffic to a victim in an attempt to expend all available BGP or CPU resources, which results in a lack of resources for valid BGP traffic processing.

Finally, inadvertent mistakes (or non-malicious actions) among BGP peers can also have a disruptive impact on a router's BGP process. Thus, security techniques should be applied to mitigate any impacts from these kinds of events as well.

This document will not cover all details of the BGP protocol itself, nor is it intended to detail the various forms of possible attacks against BGP or BGP processes; however, the References section of this document does provide additional resources on these topics. This paper will highlight several of the most important BGP security techniques that are used by SPs and show their applicability in non-SP environments. No single security measure can adequately protect BGP. Like any security approach, applying several mechanisms to provide a "defense-in-depth" approach is the best method to help secure this protocol.

BGP Baseline Configurations

The following Cisco IOS router configurations will be used as the baselines to demonstrate the various BGP security techniques that are described in this document:

Figure 1. BGP Peering Network Diagram

BGP Peering Network Diagram

 

Enterprise Edge BGP Router (Autonomous System (AS) 65000)

!
interface Loopback0
 description Loopback Interface used for non-BGP purposes
 ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/0
 description Interface to Service Provider BGP Router
 ip address 192.0.2.1 255.255.255.0 
!
interface Ethernet0/1
 description Interface to Enterprise Internal Network 
 ip address 192.168.200.1 255.255.255.0 
!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 network 192.168.200.0
 neighbor 192.0.2.2 remote-as 65100
 no auto-summary
!
Service Provider BGP Peer Router (AS 65100)
!
interface Loopback0
 description Link to source a prefix
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback1
 description Link to source a prefix
 ip address 10.10.10.10 255.255.255.0
!
interface Loopback2
 description Link to source a prefix
 ip address 10.20.20.20 255.255.255.0
!
interface Loopback3
 description Link to source a prefix
 ip address 10.30.30.30 255.255.255.0
!
interface Loopback4
 description Link to source a prefix
 ip address 10.40.40.40 255.255.255.0
!
interface Ethernet0/0
 description Link to Enterprise BGP Router 
 ip address 192.0.2.2 255.255.255.0
!
interface Ethernet0/1
 description Link to source a prefix 
 ip address 192.168.210.1 255.255.255.0
!
router bgp 65100
 no synchronization
 bgp log-neighbor-changes
 network 10.10.10.0 mask 255.255.255.0
 network 10.20.20.0 mask 255.255.255.0
 network 10.30.30.0 mask 255.255.255.0
 network 10.40.40.0 mask 255.255.255.0
 network 192.168.1.0
 network 192.168.210.0
 neighbor 192.0.2.1 remote-as 65000
 neighbor 192.0.2.1 default-originate
 no auto-summary
!

Baseline IP BGP Routing Tables

The following examples are the baseline BGP routing tables for each of the two BGP routing peers:

Enterprise Edge BGP Router (AS 65000)

R200#show ip bgp
 BGP table version is 11, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          192.0.2.2                0             0 65100 i
*> 10.10.10.0/24    192.0.2.2                0             0 65100 i
*> 10.20.20.0/24    192.0.2.2                0             0 65100 i
*> 10.30.30.0/24    192.0.2.2                0             0 65100 i
*> 10.40.40.0/24    192.0.2.2                0             0 65100 i
*> 192.168.1.0      192.0.2.2                0             0 65100 i
*> 192.168.200.0    0.0.0.0                  0         32768 i
*> 192.168.210.0    192.0.2.2                0             0 65100 i
R200#

Service Provider BGP Peer Router (AS 65100)

R201#show ip bgp 
BGP table version is 28, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.10.0/24    0.0.0.0                  0         32768 i
*> 10.20.20.0/24    0.0.0.0                  0         32768 i
*> 10.30.30.0/24    0.0.0.0                  0         32768 i
*> 10.40.40.0/24    0.0.0.0                  0         32768 i
*> 192.168.1.0      0.0.0.0                  0         32768 i
*> 192.168.200.0    192.0.2.1                0             0 65000 i
*> 192.168.210.0    0.0.0.0                  0         32768 i
R201#

BGP Threat Mitigations

BGP Neighbor Authentication with MD5

Overview

One attack scenario described at the beginning of this document is the route information manipulation attack. BGP neighbor sessions are established between two peers and then routes are exchanged between each other. By enabling the MD5-based neighbor authentication mechanism, administrators can ensure that only authorized peers can establish this BGP neighbor relationship, and that the routing information exchanged between these two devices has not been altered en-route. The BGP neighbor authentication process is illustrated in the figure below. Because BGP neighbor authentication is a symmetric technique, it must be enabled on both sides of the peering session at the same time. As illustrated in the figure, neighbor authentication using MD5 creates an MD5 hash for each packet that is sent as part of a BGP session. Specifically, the sending router uses portions of the IP and TCP headers, TCP payload (including the BGP route advertisements), and a shared secret to generate the MD5 hash. The MD5 hash is then stored in TCP option Kind 19, which is created specifically for this purpose by RFC 2385. The receiving BGP neighbor uses the same algorithm and shared secret to compute its own version of the MD5 hash. It then compares its own version with the one it received; if the MD5 hash values are not identical, the receiving BGP neighbor discards the packet. In any other circumstance, the packet is accepted and processed by BGP.

Figure 1. BGP MD5 Neighbor Authentication

BGP MD5 Neighbor Authentication

 

Operationally, BGP neighbor authentication can be added to existing BGP sessions. The shared secret may also be changed on existing sessions without terminating and re-establishing these sessions, as long as both sides of the BGP session are modified within the BGP session timeout window, which has a default of 180 seconds. Note that Cisco IOS Software Releases prior to Cisco Bug ID CSCdx23494 automatically reset the BGP session when the shared secret is changed. This behavior was modified by CSCdx23494 to allow the shared secret to change without resetting the BGP session. Although the BGP session will not be reset, BGP updates will not be processed until the same MD5 key (shared secret) is configured on both sides. Once the MD5 shared secret is configured, it is considered a best practice to change it periodically. Both the guidelines for choosing the MD5 shared secret as well as the frequency for change of these passwords must fit within an organization's security policy.

Configuration Example

MD5 authentication for BGP is enabled using the password <password text> option for the neighbor BGP router configuration command. The following example illustrates the configuration of this feature:

Enterprise Edge BGP Router (AS 65000)

!
interface Loopback0
 description Loopback Interface used for non-BGP purposes
 ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/0
 description Interface to Service Provider BGP Router
 ip address 192.0.2.1 255.255.255.0
!
interface Ethernet0/1
 description Interface to Enterprise Internal Network
 ip address 192.168.200.1 255.255.255.0
!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 network 192.168.200.0
 neighbor 192.0.2.2 remote-as 65100
 neighbor 192.0.2.2 password C!SC)
 no auto-summary
!

Service Provider BGP Peer Router (AS 65100)

!
interface Loopback0
 description Link to source a prefix
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback1
 description Link to source a prefix
 ip address 10.10.10.10 255.255.255.0
!
interface Loopback2
 description Link to source a prefix
 ip address 10.20.20.20 255.255.255.0
!
interface Loopback3
 description Link to source a prefix
 ip address 10.30.30.30 255.255.255.0
!
interface Loopback4
 description Link to source a prefix
 ip address 10.40.40.40 255.255.255.0
!
interface Ethernet0/0
 description Link to Enterprise BGP Router 
 ip address 192.0.2.2 255.255.255.0
!
interface Ethernet0/1
 description Link to source a prefix
 ip address 192.168.210.1 255.255.255.0
!
router bgp 65100
 no synchronization
 bgp log-neighbor-changes
 network 10.10.10.0 mask 255.255.255.0
 network 10.20.20.0 mask 255.255.255.0
 network 10.30.30.0 mask 255.255.255.0
 network 10.40.40.0 mask 255.255.255.0
 network 192.168.1.0
 network 192.168.210.0
 neighbor 192.0.2.1 remote-as 65000
 neighbor 192.0.2.1 password C!SC)
 neighbor 192.0.2.1 default-originate
 no auto-summary
!

Verification Example

As the following examples show, a network administrator can examine the output of the TCP Transmission Control Block (TCB) address to verify that a BGP neighbor session is using MD5 authentication.

BGP Neighbor Authentication When MD5 is Enabled

R200#show tcp brief

TCB       Local Address               Foreign Address             (state)
05E29840  192.0.2.1.13297             192.0.2.2.179               ESTAB


R200#show tcp tcb 05E29840
Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 254, Outgoing TTL 255
Local host: 192.0.2.1, Local port: 13297 Foreign host: 192.0.2.2, Foreign port: 179
---output removed for brevity---
SRTT: 300 ms, RTTO: 303 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 368 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle, path mtu capable, md5
---output truncated---

The presence of md5 in the preceding Option Flags output indicates that BGP neighbor authentication with MD5 is now enabled between these two BGP peers.

BGP Neighbor Authentication When MD5 is Not Enabled

R200#show tcp brief

TCB       Local Address               Foreign Address             (state)
04F852C0  192.0.2.1.55407             192.0.2.2.179               ESTAB

R200#show tcp tcb 04F852C0
Connection state is ESTAB, I/O status: 1, unread input bytes: 0 
Connection is ECN Disabled, Mininum incoming TTL 254, Outgoing TTL 255
Local host: 192.0.2.1, Local port: 55407 Foreign host: 192.0.2.2, Foreign port: 179
---output removed for brevity---
SRTT: 99 ms, RTTO: 1539 ms, RTV: 1440 ms, KRTT: 0 ms
minRTT: 4 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: active open
Option Flags: nagle, path mtu capable
---output truncated---

The absence of the md5 flag in the preceding Option Flags output indicates that BGP neighbor authentication with MD5 is not currently enabled between these two BGP peers.

Troubleshooting Examples

If BGP neighbor authentication is incorrectly configured (for example, it is either configured on only one peer or the MD5 shared secret (password) does not match on both peers), the following types of syslog messages will be generated:

No Password Set on Remote Peer

Dec 3 15:01:52: %TCP-6-BADAUTH: 
No MD5 digest from 192.0.2.2(179) to 192.0.2.1(51954)

Incorrect Password Set on Remote Peer

Dec 3 15:01:57: %TCP-6-BADAUTH: 
Invalid MD5 digest from 192.0.2.2(22285) to 192.0.2.1(179)

Refer to Neighbor Router Authentication for more information about BGP peer authentication with MD5.

BGP Time To Live Security Check

Overview

Another BGP attack scenario that is listed at the beginning of this document is a Denial of Service (DoS) attack against the BGP process. The BGP Time To Live (TTL) security check is designed to protect the BGP process from these kinds of CPU-utilization-based attacks and route manipulation attempts. The BGP protocol must be examined in greater detail to understand how this protection technique works.

The BGP protocol defines two types of sessions: internal BGP sessions (iBGP), which are established between peers within the same Autonomous System (AS), and external BGP sessions (eBGP), which are established between peers in two different ASs. eBGP sessions are the BGP sessions that are established between an Enterprise and its upstream SP.

By default and per the RFC, when eBGP is configured, the IP header TTL for all neighbor session packets is set to 1. This setting was originally assumed to be useful because it prevents the establishment of an eBGP session beyond a single hop. However, an attacker could be located up to 255 hops away and still send spoofed packets to the BGP-speaking router successfully. For example, an attacker could send large amounts of TCP SYN packets to the BGP peer in hopes of overwhelming the BGP process. The BGP MD5 neighbor authentication technique described earlier in this document does not protect against this kind of attack and can actually exacerbate its effects by causing the router CPU to expend resources while it attempts to compute MD5 hashes on large numbers of attack packets. Therefore, another mechanism was required to defend against BGP DoS attacks. The BGP TTL check uses a clever modification to the original BGP RFC to accomplish this goal.

The BGP TTL security check leverages the fact that the vast majority of Internet SP eBGP peering sessions are established between routers that are adjacent to each other (for example, either between directly connected interfaces or possibly between loopbacks). Because successful TTL spoofing is considered nearly impossible, a mechanism that is based on an expected TTL value was developed to provide a simple, robust defense from infrastructure attacks that are based on forged BGP packets. The concept was originally defined and subsequently modified in the following documents: BGP TTL Security Hack (BTSH) and BGP in The Generalized TTL Security Mechanism (GTSM).

When the BGP TTL security check is enabled, the initial TTL value for an eBGP packet is set to 255 rather than 1, and a "minimum TTL-value" is enforced on all BGP packets that are associated with that eBGP session. Because the IP header TTL value is decremented by each router hop along its path to its final destination, the diameter from which an attacker could possibly source packets is restricted to those routers that are directly connected.

The BGP TTL security check is not required nor is it considered useful for iBGP sessions. The BGP TTL security check was first introduced in Cisco IOS Software Releases 12.0(27)S, 12.3(7)T, and 12.2(25)S.
Refer to BGP Support for TTL Security Check for more information.

Configuration Example

BGP TTL security check is enabled using the ttl-security option for the neighbor BGP router configuration command. The following example illustrates the configuration of this feature:

Enterprise Edge BGP Router (AS 65000)

!
interface Loopback0
 description Loopback Interface used for non-BGP purposes
 ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/0
 description Interface to Service Provider BGP Router
 ip address 192.0.2.1 255.255.255.0
!         
interface Ethernet0/1
 description Interface to Enterprise Internal Network
 ip address 192.168.200.1 255.255.255.0
!       
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 network 192.168.200.0
 neighbor 192.0.2.2 remote-as 65100
 neighbor 192.0.2.2 ttl-security hops 1
 no auto-summary
!  

Service Provider BGP Peer Router (AS 65100)
!
interface Loopback0
 description Link to source a prefix
 ip address 192.168.1.1 255.255.255.0
!
interface Loopback1
 description Link to source a prefix
 ip address 10.10.10.10 255.255.255.0
!
interface Loopback2
 description Link to source a prefix
 ip address 10.20.20.20 255.255.255.0
!         
interface Loopback3
 description Link to source a prefix
 ip address 10.30.30.30 255.255.255.0
!
interface Loopback4
 description Link to source a prefix
 ip address 10.40.40.40 255.255.255.0
!
interface Ethernet0/0
 description Link to Enterprise BGP Router
 ip address 192.0.2.2 255.255.255.0
!
interface Ethernet0/1
 description Link to source a prefix
 ip address 192.168.210.1 255.255.255.0
!
router bgp 65100
 no synchronization
 bgp log-neighbor-changes
 network 10.10.10.0 mask 255.255.255.0
 network 10.20.20.0 mask 255.255.255.0
 network 10.30.30.0 mask 255.255.255.0
 network 10.40.40.0 mask 255.255.255.0
 network 192.168.1.0
 network 192.168.210.0
 neighbor 192.0.2.1 remote-as 65000
 neighbor 192.0.2.1 ttl-security hops 1
 neighbor 192.0.2.1 default-originate
 no auto-summary
!

In the preceding example, when BGP packets are received by the BGP peer at 192.0.2.1 from the eBGP peer at 192.0.2.2, the TTL must be greater than or equal to 254 to be accepted. The minimum TTL value of 254 is calculated by subtracting the specified hop-count of 1 from the initial TTL of 255. If the TTL value is less than 254, the BGP peer router at 192.0.2.1 will silently drop the BGP packets from the eBGP peer at 192.0.2.2. The BGP TTL security check does not necessarily need to be configured on the remote (Service Provider BGP Peer Router (AS 65100)) end. If it is not, the SP Peer Router must have the neighbor 192.0.2.1 ebgp-multihop 255 command configured. Regardless, it is highly recommended that administrators use BGP TTL security check on both ends of the BGP peering connection unless there are extenuating circumstances (for example, due to multi-vendor or Cisco IOS Software differences, or if only one side supports the use of the BGP TTL security check).

Verification and Troubleshooting Examples

To verify that the BGP TTL security check is configured for a particular neighbor, the most straightforward approach is to review the BGP neighbor details:

R200#show ip bgp neighbors 192.0.2.2
BGP neighbor is 192.0.2.2,  remote AS 65100, external link
  BGP version 4, remote router ID 192.168.1.1
  BGP state = Established, up for 03:28:41
  Last read 00:00:11, last write 00:00:14, hold time is 180, 
  keepalive interval is 60 seconds
---output removed for brevity---
External BGP neighbor may be up to 1 hop away.
  Transport(tcp) path-mtu-discovery is enabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0            
Connection is ECN Disabled, Mininum incoming TTL 254, Outgoing TTL 255
Local host: 192.0.2.1, Local port: 55407
Foreign host: 192.0.2.2, Foreign port: 179
---output truncated---

Refer to BGP Support for TTL Security Check for more information.

Configuring Maximum Prefixes

Overview

Another BGP concern addressed at the beginning of this document is the inadvertent misconfiguration of BGP neighbors, which can have potentially unintended consequences to existing BGP sessions. The previous mitigation techniques are intended to prevent unauthorized packets from affecting the BGP process; however, when a legitimate eBGP peer is misconfigured, neither technique will prevent the BGP process from being disrupted. BGP may cause a disruption by attempting to install too many routes in its routing table.

BGP prefixes are stored in router memory, and the more BGP prefixes that a router must store, the more memory is consumed. In some BGP configurations, a subset of all Internet prefixes can be stored, such as when only a default route or routes for a provider's customer networks are required. In other cases, the entire Internet routing table may be needed. (The January 2009 version of the CIDR Report recorded 284,121 prefixes in the Internet Routing Table.) In many cases, due to CPU or memory limitations, a Cisco IOS device cannot accept the amount of prefixes that is contained in the Internet routing table. In addition, inadvertent configurations have been known to cause route de-aggregation, which can cause a rapid increase in the number of prefixes that the BGP process encounters. To prevent CPU or memory exhaustion, administrators are advised to consider configuring the maximum number of prefixes that can be accepted on a per-neighbor basis.

The BGP maximum prefix feature allows administrators to control the number of prefixes that can be installed from a neighbor. When configured, this feature will terminate a neighbor relationship when the number of received prefixes from the peer exceeds the configured maximum prefix limit. Although this feature is commonly used for external BGP peers, it can also be applied to internal BGP peers.

To effectively configure this feature, the normal maximum expected number of routes should be well known and understood. Typically, the maximum prefix threshold would be set slightly higher to accommodate unexpected changes. In addition, it may be useful to modify the default behavior of resetting the eBGP session because it can be disruptive to traffic flow. Another option involves logging a warning message when the threshold is exceeded.

Note: An enhancement to this feature that was introduced in Cisco IOS Software Releases 12.0(22)S and 12.2(15)T allows the automatic reestablishment of a peering session that was terminated when the configured maximum prefix limit was exceeded. No intervention from the network operator is required when this feature is enabled.

Configuration Example

When configuring this feature by using the neighbor maximum-prefix BGP router configuration command, at least one argument is required, which is the maximum number of prefixes that are accepted before a peer is shutdown. In addition, the following optional parameters can be configured after the number of maximum prefixes to be accepted.

  • Threshold Value– the percentage at which to generate a warning message, which ranges between 1–100 %
  • Restart Interval– the amount of time in minutes (between 1–65535) after which the terminated BGP connection will be restarted
  • Warning-only– a syslog warning message that will be generated once the prefix limit is exceeded (the BGP connection will not be terminated)

The following maximum-prefix command will set a limit of five prefixes to be received from the BGP peer at 192.0.2.2. Once four prefixes are received (for example, greater than 70 percent of five), a warning message will be issued. Once the limit of five prefixes has been reached, the BGP session will be terminated and restarted in 30 minutes.

 neighbor 192.0.2.2 maximum-prefix 5 70 restart 30

In the following configuration, the maximum number of prefixes that will be accepted by the Local BGP Router is five. Once the number of prefixes that are received from the BGP peer at 192.0.2.2 exceeds five, a log message will be generated, and the BGP neighbor relationship will be terminated.

Enterprise Edge BGP Router (AS 65000)
!
interface Loopback0
 description Loopback Interface used for non-BGP purposes
 ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/0
 description Interface to Service Provider BGP Router
 ip address 192.0.2.1 255.255.255.0
!
interface Ethernet0/1
 description Interface to Enterprise Internal Network
 ip address 192.168.200.1 255.255.255.0
!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 network 192.168.200.0
 neighbor 192.0.2.2 remote-as 65100
 neighbor 192.0.2.2 maximum-prefix 5
 no auto-summary
!

No additional configurations are required on the Service Provider BGP peer because this BGP security mechanism does not require symmetric configuration. It only applies to the router on which it is configured.

Verification and Troubleshooting Examples

The following are examples of the types of syslog messages that will be generated when using the maximum-prefix command:

BGP router has received an amount of prefixes that exceed the warning threshold but not the maximum limit:

Jan  7 15:15:39: %BGP-4-MAXPFX: 
Number of prefixes received from 192.0.2.2 (afi 0) reaches 4, max 5

BGP router has received the maximum amount of prefixes allowed:

Nov 21 13:20:56: %BGP-4-MAXPFX: 
Number of prefixes received from 192.0.2.2 (afi 0) reaches 5, max 5

Received prefixes have surpassed the configured limit:

Nov 21 13:20:56: %BGP-3-MAXPFXEXCEED: 
Number of prefixes received from 192.0.2.2 (afi 0): 6 exceeds limit 5

After too many prefixes have been received, the BGP connection has been terminated with the peer:

Nov 21 13:20:56: %BGP-5-ADJCHANGE: neighbor 192.0.2.2 Down BGP Notification sent

The following output of the show ip bgp summary command displays an example of a BGP peer that has been terminated because the number of prefixes has exceeded the maximum limit. Note the PfxCt tag at the end of the last output line.

R200#show ip bgp summary
BGP router identifier 10.1.1.1, local AS number 65000
BGP table version is 26, main routing table version 26
1 network entries using 132 bytes of memory
1 path entries using 52 bytes of memory
2/1 BGP path/bestpath attribute entries using 296 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 28 bytes of memory
BGP using 508 total bytes of memory
BGP activity 24/23 prefixes, 24/23 paths, scan interval 60 secs
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.0.2.2       4 65100   20335   20329        0    0    0 00:02:04 Idle (PfxCt)
R200#

Refer to Configuring the BGP Maximum-Prefix Feature for more information about per-peer maximum prefixes.

Filtering BGP Prefixes with Prefix Lists

Overview

In addition to restricting the maximum number prefixes that BGP is allowed to install, another important BGP session protection mechanism is the individual filtering of prefixes to prevent BGP from inadvertently installing unwanted or illegal prefixes in the routing table. Whether due to malicious intent or simple misconfiguration, prefix filtering should be configured to allow a network administrator to permit or deny specific prefixes that are sent to or received from each BGP peer. This configuration ensures that network traffic is sent over the intended paths. Prefix lists should be applied to each eBGP peer in both inbound and outbound directions. Prefix lists can be configured to specifically allow only those prefixes that are permitted by the routing policy of a network, which is an example of white list-based filtering. If this configuration is not feasible due to the large number of prefixes that are received, a prefix list can be configured to specifically block known undesirable prefixes (a technique known as black list filtering). These prefixes should include unallocated IP address space and networks that are reserved by RFC 3330 for special use, such as for internal or testing purposes. Outbound prefix lists should be configured to specifically permit only the prefixes that an organization intends to advertise. For the same reason best practices recommend that access control lists (ACLs) deny packets that use special-use addressing and packets that are sourced from addresses belonging to the enterprise IP address space, inbound and outbound prefix lists should, either explicitly or implicitly, prevent receipt and transmission of IP address space that is referenced by the following RFCs:

  • RFC 1918, which defines reserved address space that is not a valid source address on the Internet
  • RFC 2827, which provides anti-spoofing guidelines
  • RFC 3330, which defines special-use addresses that might require filtering

Configuration Example

White List Filtering Example

In the following example, the Ingress-White prefix list creates a white list so that only desired prefixes (10.10.10.0/24 and 10.20.20.0/24) are accepted inbound from the Service Provider BGP router (AS 65100).

Enterprise Edge BGP Router (AS 65000)

!
interface Loopback0
 description Loopback Interface used for non-BGP purposes
 ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/0
 description Interface to Service Provider BGP Router
 ip address 192.0.2.1 255.255.255.0
!
interface Ethernet0/1
 description Interface to Enterprise Internal Network
 ip address 192.168.200.1 255.255.255.0
!
!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 network 192.168.200.0
 neighbor 192.0.2.2 remote-as 65100
 neighbor 192.0.2.2 prefix-list Ingress-White in
 no auto-summary
!
ip prefix-list Ingress-White seq 5 permit 10.10.10.0/24
ip prefix-list Ingress-White seq 10 permit 10.20.20.0/24
ip prefix-list Ingress-White seq 15 deny 0.0.0.0/0 le 32
!

As compared with the baseline set of prefixes that are initially installed by the Enterprise router (AS 65000) at the beginning of this document, the following output of the show ip bgp command shows that only the desired prefixes are being accepted from the Service Provider router (AS 65100) via BGP:

R200#show ip bgp
BGP table version is 4, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.10.10.0/24    192.0.2.2                0             0 65100 i
*> 10.20.20.0/24    192.0.2.2                0             0 65100 i
*> 192.168.200.0    0.0.0.0                  0         32768 i
R200#

Note that the existing BGP session may require clearing for the prefix list to filter ingress prefixes.

Black List Filtering Example

In the following example, a black list approach is used. Only specific prefixes (10.10.10.0/24 and 10.20.20.0/24) are denied inbound, and everything else is permitted using the Ingress-Black prefix list.

!
router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 network 192.168.200.0
 neighbor 192.0.2.2 remote-as 65100
 neighbor 192.0.2.2 prefix-list Ingress-Black in
 no auto-summary
!    
ip prefix-list Ingress-Black seq 5 deny 10.10.10.0/24
ip prefix-list Ingress-Black seq 10 deny 10.20.20.0/24
ip prefix-list Ingress-Black seq 15 permit 0.0.0.0/0 le 32
!

The following show ip bgp output for the Enterprise router (AS 65000) shows that only the desired prefixes are being accepted from the Service Provider router (AS 65100) via BGP:

R200#show ip bgp   
BGP table version is 7, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          192.0.2.2                0             0 65100 i
*> 10.30.30.0/24    192.0.2.2                0             0 65100 i
*> 10.40.40.0/24    192.0.2.2                0             0 65100 i
*> 192.168.1.0      192.0.2.2                0             0 65100 i
*> 192.168.200.0    0.0.0.0                  0         32768 i
*> 192.168.210.0    192.0.2.2                0             0 65100 i
R200#

Refer to Connecting to a Service Provider Using External BGP for complete coverage of BGP prefix filtering.

Ingress Prefix Filter Templates

Cisco initially created and published Ingress Prefix Filters in 2002 and has maintained them since that time. The use of Ingress Prefix Filters is not mandated or required by Standards Bodies, but they are considered an industry best security practice and Cisco advocates their usage. To ensure that organizations are able to properly and successfully filter Bogon prefixes, Cisco continues to provide updates to the Ingress Prefix Filters as changes in Internet Assigned Numbers Authority (IANA) prefix allocations and other modifications dictate.

Cisco maintains two types of Ingress Prefix Filters, one that provides "strict" filtering and one that provides "loose" filtering. The strict filter policy restricts prefixes according to the minimum allocations that are specified by the Regional Internet Registries (RIRs), which are typically allocated to a /20 prefix length or longer. The loose filter policy is less restrictive and generally enforces a minimum prefix length of /24.

Strict and loose Ingress Prefix Filter policy templates are organized into the following logical filter groups, which are referred to as phases:

  • Phase 1– Deny Special Prefixes (1–99)
  • Phase 2– Deny Your Own Prefixes (100–199)
  • Phase 3– Deny IXP Prefixes (200–299)
  • Phase 4– Deny Bogon Prefixes (300–399)
  • Phase 5– Permit Critical Infrastructure Prefixes (400–699)
  • Phase 6– Permit RIR Prefixes On The Minimum Allocation That Is Advertised by the RIR for the 'Strict Filter' or Permit RIR Prefixes On The Minimum Allocation To A /24 for the 'Loose Filter' (4000–8999)
  • Phase 7– Permit The Rest Between /8 and /24 (10000–10999)

Prefix Filter Modifications

Each time the IANA IPv4 registry is updated to reflect the allocation or deallocation of IPv4 address space, Cisco updates the strict and loose Ingress Prefix Filter templates.

The current IANA IPv4 registry is available at the following link:
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt

The strict and loose Ingress Prefix Filter templates are available at the following link:
ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates

Note: The ftp-eng.cisco.com domain requires passive FTP from inside the Cisco network.

Update Notifications and Mailing List

An externally available mailing list has been created to allow interested parties to subscribe and receive notifications each time the strict and loose Ingress Prefix Filter templates have been updated to reflect a prefix allocation to an RIR, prefix deallocation from an RIR, or a prefix change in the IANA IPv4 registry.

To join to the strict and loose Ingress Prefix Filter templates announce mailing list, send an e-mail message to ipv4-ingress-prefix-filter-announce-join@cisco.com. Once the subscription request has been received, you will recieve a confirmation e-mail message to confirm you are interested in subscribing to the mailing list. Interested parties must respond to this confirmation message to receive announcement notifications. Once you have been successfully subscribed to the mailing list, you will receive a welcome message that contains your subscription information. Save this message for future reference should you need to unsubscribe from the mailing list.

Filtering BGP Prefixes with Autonomous System Path Access Lists

Overview

BGP autonomous system (AS) path access lists can also be used to filter prefixes to prevent unwanted or illegal prefixes from inadvertently being installed in the routing table by BGP. AS path access lists allow network administrators to filter received and advertised prefixes based on the AS path attribute of a prefix. This filtering method can be used in conjunction with prefix lists, which filter based on prefix, to establish a robust set of BGP route filters.

Configuration Example

This configuration example uses AS path access lists to restrict inbound prefixes to those that are originated by the remote AS (for example, AS 65100) and outbound prefixes to those that are originated by the local AS (for example, AS 65000). Prefixes that are sourced from all other autonomous systems are filtered and not installed in the routing table.
The following example shows the show ip bgp output of the router that is configured for AS 65000 prior to application of the AS path list:

R200#show ip bgp 
BGP table version is 1, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  0.0.0.0          192.0.2.2                0             0 65100 i
*  10.10.10.0/24    192.0.2.2                0             0 65100 1 i
*  10.20.20.0/24    192.0.2.2                0             0 65100 1 i
*  10.30.30.0/24    192.0.2.2                0             0 65100 i
*  10.40.40.0/24    192.0.2.2                0             0 65100 i
*  192.168.1.0      192.0.2.2                0             0 65100 i
*  192.168.200.0    0.0.0.0                  0         32768 i
*  192.168.210.0    192.0.2.2                0             0 65100 i
R200#

Note that the AS path of 65100 1 indicates that some of the routes appear to originate in AS 1. This scenario was accomplished by configuring a route map on the router at AS 65100, which prepends certain outbound BGP routing updates (10.10.10.0/24 and 10.20.20.0/24) with an AS of 1 (see configuration below). This configuration will cause two specific BGP routes from this router to appear as if they originate from AS 1, not AS 65100. The necessary configuration for the SP Provider BGP Peer Router is shown in the following example:

Service Provider BGP Peer Router (AS 65100)

!  
router bgp 65100
 no synchronization
 bgp log-neighbor-changes
 network 10.10.10.0 mask 255.255.255.0
 network 10.20.20.0 mask 255.255.255.0
 network 10.30.30.0 mask 255.255.255.0
 network 10.40.40.0 mask 255.255.255.0
 network 192.168.1.0
 network 192.168.210.0
 neighbor 192.0.2.1 remote-as 65000
 neighbor 192.0.2.1 default-originate
 neighbor 192.0.2.1 route-map as-path out
 no auto-summary
!
access-list 1 permit 10.10.10.0 0.0.0.255
access-list 1 permit 10.20.20.0 0.0.0.255
!
route-map as-path permit 10
 match ip address 1
 set as-path prepend 1
!
route-map as-path permit 20
!  

The router that is configured for AS 65000 now has an AS path list that was applied to all inbound routing updates using the filter-list command, which requires that the update originate from AS 65100.

router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 network 192.168.200.0
 neighbor 192.0.2.2 remote-as 65100 
 neighbor 192.0.2.2 filter-list 1 in
 neighbor 192.0.2.2 filter-list 2 out
 no auto-summary
!
! The following as-path access-list filter restricts all 
! incoming BGP routes to those that originated in AS 65100
ip as-path access-list 1 permit ^65100$
! The following as-path access-list filter restricts all 
! outgoing BGP routes to those that originated within the local (65000) AS
ip as-path access-list 2 permit ^$
!

With the above filter list applied to the router configured for AS 65000, no routes from the peer with AS 1 in its AS path are visible:

R200#show ip bgp 
BGP table version is 1, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  0.0.0.0          192.0.2.2                0             0 65100 i
*  10.30.30.0/24    192.0.2.2                0             0 65100 i
*  10.40.40.0/24    192.0.2.2                0             0 65100 i
*  192.168.1.0      192.0.2.2                0             0 65100 i
*  192.168.200.0    0.0.0.0                  0         32768 i
*  192.168.210.0    192.0.2.2                0             0 65100 i
R200#

AS Path Length Limiting

Overview

In addition to filtering routes based on specific AS paths (AS number), it is also possible to filter routes by limiting the number of AS path segments that each route can include. This limiting is performed primarily to prevent the router from expending too much memory when it stores routes with long AS paths. The bgp maxas-limit feature allows administrators to set a limit on the number of AS path segments that are associated with any route. Administrators should note that because this feature is a router configuration command that is not tied to any specific BGP neighbor, all neighbors will be treated uniformly according to the specified policy. Prior to the functionality change for the Cisco bug associated with CSCee30718, the value that can be entered for this argument is a number from 1 to 255. Following the functionality change associated with CSCee30718, it is possible to configure a higher threshold value (up to 2,000) for the AS path segment length. Advertising a route with an AS path length that exceeds 255 may result in an adverse impact when sending long AS path segments to downstream BGP routers. Because Cisco IOS Software limits the prepending value to 10 using route maps, the most that a Cisco device could add is 21 AS identifiers, or 10 on ingress, 10 on egress, and 1 for normal BGP AS processing.   An administrator can set the bgp maxas-limit to 234, which results in a maximum AS path length of 255 AS identifiers that can be sent to the downstream BGP peers.  Using a conservative value of 200 can simplify the configuration and also prevent this condition.  Administrators are advised to configure and fully test any limit in a lab environment prior to deployment on a production router.  The bgp maxas-limit command was introduced in Cisco IOS Software Release 12.2 and in 12.0(17)S in the 12.0S train. 

Please refer to the Team Cymru BGP/ASN Analysis Report for up-to-date information on the longest AS path length that is currently being advertised on the Internet.

Configuration Example

To configure BGP to discard routes with an AS path segment length that exceeds a specified value, use the bgp maxas-limit command in router configuration mode.

The following output of the show ip bgp command displays the BGP routes that are being accepted from the Service Provider router (AS 65100) prior to configuring the bgp maxas-limit command. Note that the 65100 1 1 1 1 1 1 AS path length consists of a total of seven AS path segments.

Router-Ent#show ip bgp
BGP table version is 1, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  0.0.0.0          192.0.2.2                0             0 65100 i
*  10.10.10.0/24    192.0.2.2                0             0 65100 1 1 1 1 1 1 i
*  10.20.20.0/24    192.0.2.2                0             0 65100 1 1 1 1 1 1 i
*  10.30.30.0/24    192.0.2.2                0             0 65100 1 1 1 1 1 1 i
*  10.40.40.0/24    192.0.2.2                0             0 65100 1 1 1 1 1 1 i
*  192.168.1.0      192.0.2.2                0             0 65100 1 1 1 1 1 1 i
*  192.168.210.0    192.0.2.2                0             0 65100 1 1 1 1 1 1 i
Router-Ent#

In the following configuration, the maximum length of the AS path that will be accepted is five segments. Once the number of AS path segments that are received exceeds five, the route will not be placed into the BGP routing table, and a log message will be generated. Routes that are already installed are not affected. Only routes that are received in updates subsequent to application of this configuration will be subjected to the policy.

Enterprise Edge BGP Router (AS 65000)

!
interface Loopback0
 description Loopback Interface used for non-BGP purposes
 ip address 10.1.1.1 255.255.255.0
!
interface Ethernet0/0
 description Interface to Service Provider BGP Router
 ip address 192.0.2.1 255.255.255.0
!
interface Ethernet0/1
 description Interface to Enterprise Internal Network
 ip address 192.168.200.1 255.255.255.0
!

router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 bgp maxas-limit 5
 network 192.168.200.0
 neighbor 192.0.2.2 remote-as 65100
 no auto-summary
!

No additional configurations are required on the Service Provider BGP peer because this BGP security mechanism does not require symmetric configuration. It only applies to the router on which it is configured.

Verification and Troubleshooting Examples

This following example is the syslog message that will be generated when the bgp maxas-limit command is used and the number of AS path segments that are received exceeds the configured threshold:

Feb 17 12:22:24: %BGP-6-ASPATH: Long AS path 65100 1 1 1 1 1 1 
 received from 192.0.2.2: More than configured MAXAS-LIMIT

The following show ip bgp output for the Enterprise router (AS 65000) shows that after clearing the BGP session, only the routes with an AP path length of less than five are now being accepted from the Service Provider router (AS 65100) via BGP:

Router-Ent#show ip bgp
BGP table version is 3, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          192.0.2.2                0             0 65100 i
*> 192.168.200.0    0.0.0.0                  0         32768 i
Router-Ent#

Refer to the bgp maxas-limit command for more information.

Infrastructure ACLs

Overview

To protect infrastructure devices and minimize the risk, impact, and effectiveness of direct infrastructure attacks, administrators are advised to deploy infrastructure ACLs (iACLs) to perform policy enforcement of traffic that is sent to infrastructure equipment. Administrators can construct an iACL by explicitly permitting only authorized BGP traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. Care should be taken to allow required traffic for other routing and administrative access prior to denying all unauthorized traffic.

Configuration Example

Although the following iACL includes the filtering of certain IP address ranges from which infrastructure devices are not normally expected to receive packets, it is neither an exhaustive ACL nor is it applicable all network environments. This iACL serves as an example and should be modified and tested by each network administrator prior to deployment in production environments. Because BGP mitigation is the focus of this document, the BGP-specific entries appear in bold text.

ip access-list extended Infrastructure-ACL-Policy
!--- Anti-spoofing entries are shown here.
!--- Deny special-use address sources.
!--- Refer to RFC 3330 for additional special use addresses.
 deny ip host 0.0.0.0 any
 deny ip 127.0.0.0 0.255.255.255 any
 deny ip 224.0.0.0 31.255.255.255 any
!--- Filter RFC 1918 space.
 deny ip 10.0.0.0 0.255.255.255 any
 deny ip 172.16.0.0 0.15.255.255 any
 deny ip 192.168.0.0 0.0.255.255 any
!--- Deny your space as source from entering your AS.
!--- Deploy only at the AS edge.
 deny ip 192.168.200.0 0.0.0.255 any
!--- Permit known-good BGP peers
 permit tcp host 192.0.2.2 host 192.0.2.1 eq bgp
 permit tcp host 192.0.2.2 eq bgp host 192.0.2.1
!--- Deny all other BGP packets
 deny tcp any any eq bgp
 deny tcp any eq bgp any
!--- Deny access to internal infrastructure addresses.
 deny ip any 192.168.200.0 0.0.0.255
!-- Permit/deny all other Layer 3 and Layer 4 traffic in accordance
!-- with existing security policies and configurations
!--- Permit transit traffic.
 permit ip any any
!-- Apply iACL to interfaces in the ingress direction
!
interface Ethernet0/0
 description Interface to Service Provider BGP Router
 ip address 192.0.2.1 255.255.255.0
 ip access-group Infrastructure-ACL-Policy in
!

Additional information about iACLs is in Protecting Your Core: Infrastructure Protection Access Control Lists.

Control Plane Policing

Overview

Control Plane Policing (CoPP) can be used to block untrusted BGP access to the device. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting, and if configured, rate limiting, only authorized traffic that is sent to infrastructure devices in accordance with existing security policies and configurations. It should be noted that dropping traffic from unknown or untrusted IP addresses may prevent hosts with dynamically assigned IP addresses from connecting to the Cisco IOS device.

Configuration Example

In the following simplistic example, only BGP traffic from the trusted BGP peer (192.0.2.2) is permitted to reach the route processor (RP). All other BGP traffic is dropped. Note that all other traffic destined to the RP is not classified or policed in this example. This CoPP configuration would require modification if administrators intend to include other control plane and management plane traffic that is of interest. It is further recommended that thorough testing be conducted prior to deploying CoPP in production environments. Because CoPP does not affect transit IP traffic, no policies need be defined for this traffic.

access-list 152 deny   tcp host 192.0.2.2 any eq bgp
access-list 152 deny   tcp host 192.0.2.2 eq bgp any
access-list 152 permit tcp any any eq bgp
access-list 152 permit tcp any eq bgp any
access-list 152 deny   ip any any
!
class-map match-all class-bgp
 match access-group 152
!
policy-map policy-bgp
 class class-bgp
   drop
!
control-plane
 service-policy input policy-bgp
!

In the preceding CoPP example, the ACL entries that match the BGP packets with the permit action result in the packets being matched or classified into the policy map and hence discarded by the drop function, while packets that match the deny action are not classified into the policy and hence not affected by the policy map. Note that in the 12.2S and 12.0S Cisco IOS Software Releases, a different policy map syntax is used to discard drop packets:

policy-map permit-bgp-policy
    class drop-bgp-class
    	police 32000 1500 1500 conform-action drop exceed-action drop

CoPP is available in Cisco IOS Software Releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T. Additional information on the configuration and use of the CoPP feature can be found at:

Control Plane Policing Implementation Best Practices
Control Plane Policing Feature Guide
Deploying Control Plane Policing

Memory Considerations

A primary concern of any administrator when configuring new features is the potential impact the enabling of the feature(s) will have on router performance. Pursuant to this concern is the amount of the memory required by the router, particularly when talking about the large routing table associated with BGP (427,365 prefixes recorded on 7-September-2012).

The question of how much memory is required by a BGP-enabled router in order to receive the full BGP routing table without impact can be answered as follows:

The amount of memory required to store BGP routes depends on many factors, such as the router, the number of alternate paths available, route dampening, the use of BGP Community Values (to control upstream routing policies), the number of maximum paths configured, the use of other BGP attributes, and VPN configurations. Without knowledge of these parameters it is difficult to calculate the amount of memory that is required to store a certain number of BGP routes. Cisco typically recommends a minimum of 512 MB of RAM in the router to store a complete global BGP routing table from one BGP peer. However, it is important to understand ways to reduce memory consumption and achieve optimal routing without the need to receive the complete Internet routing table. Refer to Achieve Optimal Routing and Reduce BGP Memory Consumption for more detailed information.

The above answer can be found here: BGP: Frequently Asked Questions.

A more difficult problem however is measuring the impact on router memory when enabling features such as those that have been described throughout this document. Due to the number of variables that are involved that impact router memory—hardware/platform, # of BGP peers, combination of features (both BGP and non-BGP) in use—it is a difficult, if not impossible, task to determine how much memory should be used in a particular router when enabling some or all of the BGP features described above.

Instead, it would be more helpful to identify those features that will undoubtedly have an impact, positive or negative, on the memory usage of the router. For that matter, the following sections will present the results of testing that was performed in order to evaluate the impact of these features on the consumption of router memory.

Baseline Measurements

A baseline is a snapshot in time of normal operating conditions. Baselines help plan for expansion and they help with troubleshooting abnormalities in performance. It is important that, once baselines are established, they should be periodically revisited, tested, and adjusted if necessary to insure that behavior that is anomalous to the baseline is sufficiently noticeable. Normal, or baseline, in the context of this document means that the router is running BGP, peering with another router, and accepting a full Internet table of BGP routes without introducing any of the BGP security features that are described throughout this document.

The following is version information for the Cisco 3945 Router running IOS version 15.0(1)M1 that was used as the Unit Under Test (UUT) in our testing environment:

BGP-Test#show  version 
   Cisco IOS Software, C3900  Software (C3900-UNIVERSALK9-M), 
    Version 15.0(1)M1, RELEASE SOFTWARE (fc1)
   Technical Support:  http://www.cisco.com/techsupport
   Copyright (c) 1986-2009 by Cisco  Systems, Inc.
   Compiled Wed 02-Dec-09 17:17 by  prod_rel_team
ROM: System Bootstrap, Version  15.0(1r)M1, RELEASE SOFTWARE (fc1)
BGP-Test uptime is 3 days, 5  hours, 51 minutes
   System returned to ROM by reload  at 12:29:00 UTC Fri Jul 20 2012
   System image file is  "flash0:c3900-universalk9-mz.SPA.150-1.M1.bin"
---  output removed for brevity ---

   Cisco CISCO3945-CHASSIS  (revision 1.0) with C3900-SPE150/K9
    with 2035712K/61440K bytes of memory.
   Processor board ID FTX1406AHZ1
   3 Gigabit Ethernet interfaces
   1 Virtual Private Network (VPN)  Module
   DRAM configuration is 72 bits  wide with parity enabled.
   255K bytes of non-volatile  configuration memory.
   4099032K bytes of ATA System  CompactFlash 0 (Read/Write)
   ---  output truncated for brevity ---

BGP Router Process

Prior to incorporating any of the above-mentioned features in our “Securing BGP” arsenal it was necessary to take some initial baseline measurements. We see from the below output that our router, displayed as “BGP-Test”, is currently receiving a total of 416,380 prefixes from our BGP peer (IP address: 10.220.231.254).

BGP-Test#show ip bgp sum
   BGP router identifier 10.48.208.36,  local AS number 65000
   BGP table version is 416440,  main routing table version 416440
   416380 network entries using  49965600 bytes of memory
   416380 path entries using  21651760 bytes of memory
   68394/68373 BGP path/bestpath  attribute entries using 8480856 bytes of memory
   61628 BGP AS-PATH entries using  2574364 bytes of memory
   0 BGP route-map cache entries  using 0 bytes of memory
   0 BGP filter-list cache entries  using 0 bytes of memory
   BGP using 82672580 total bytes  of memory
   BGP activity 14200209/13783823  prefixes, 
    16929534/16513154 paths, scan interval 60 secs
   Neighbor        V   AS  MsgRcvd  MsgSent    TblVer   InQ  OutQ  Up/Down  State/PfxRcd
   10.220.231.254  4  715    68849        6    416440     0     0  00:02:17       416380

Memory -- BGP Router Process

The following command shows the amount of memory the various BGP processes occupy in RAM:

BGP-Test#show processes memory | include BGP
   PID TTY   Allocated       Freed    Holding    Getbufs   Retbufs Process
    83   0    67354216    10499024       7144          0         0 BGP Task        
   129   0     2268908     3541064      10076          0         0 BGP Scheduler   
   159   0   106755196   162096748  242633116     102060         0 BGP Router      
   187   0  2618490260   353204172      10076          0         0 BGP I/O         
   200   0           0  2566567576      10076          0         0 BGP Scanner     
   232   0           0    19748340       7132          0         0 BGP Event       

For our baseline measurements, the BGP processes are occupying approximately 243 MB of memory and this is without any of the “Securing BGP” features configured.

BGP Neighbor Authentication with MD5

The next measurement will be made while incorporating the MD5 neighbor authentication feature on both our UUT router as well as our BGP peer. The following is a configuration snippet that displays the specific parameters that are needed for MD5 neighbor authentication:

router bgp 65000
   no synchronization
   bgp log-neighbor-changes
   neighbor 10.220.231.254 remote-as 715
   neighbor 10.220.231.254 password c1sc0 
   neighbor 10.220.231.254 ebgp-multihop 255
   no auto-summary
   !

Memory -- BGP Router Process

Below is the impact, if any, on the BGP memory processes with the above configuration changes.

BGP-Test#show processes memory | include BGP
    83    0    68160536    10712252        7144       0    0 BGP Task        
   129    0     2268908     3541064       10076       0    0 BGP Scheduler   
   159    0  3551376756   473204616   242781196  102060    0 BGP Router      
   187    0   259696516   546937196       10076       0    0 BGP I/O         
   200    0           0  2665126496       10076       0    0 BGP Scanner     
   232    0           0    19748340        7132       0    0 BGP Event       
   BGP-Test#

Based on the above measurements, incorporating the use of the BGP MD5 Authentication feature does not have any impact on the amount of memory that is being occupied by any of the BGP processes. As displayed above, and in accordance with our earlier baseline measurements, the BGP processes are occupying approximately 243 MB of memory.

BGP Time to Live Security Check

The next measurement will be made while incorporating the BGP TTL Security Check feature on our UUT router. The following is a configuration snippet that displays the specific parameters that are needed for the TTL Security Check:

router bgp 65000
  no synchronization
  bgp log-neighbor-changes
  neighbor 10.220.231.254 remote-as 715
  neighbor 10.220.231.254 ttl-security hops 14
  no auto-summary
! 

The following output also indicates that we have enabled the TTL Security Check feature as evidenced by the areas indicated in bold.

BGP-Test#show ip bgp neighbors 10.220.231.254
 BGP neighbor is 10.220.231.254,  remote AS 715, external link
   BGP version  4, remote router ID 204.61.214.144
   BGP state =  Established, up for 00:02:31
   Last read  00:00:08, last write 00:00:08, hold time is 180, keepalive 
 interval is 60  seconds
   Neighbor  sessions:
     1 active,  is not multisession capable
 --- output removed for brevity ---
   Address  tracking is enabled, the RIB does have a route to 
 10.220.231.254
   Connections  established 821; dropped 820
   Last reset  00:02:46, due to User reset of session 1
   External BGP neighbor may be up to 14 hops  away.
   Transport(tcp) path-mtu-discovery is enabled
     Graceful-Restart is disabled
   Connection state is ESTAB, I/O status: 1, unread  input bytes: 0            
   Connection is ECN  Disabled, Minimum incoming TTL 241, Outgoing TTL 255
   Local host: 10.48.208.36, Local port: 63296
   Foreign host: 10.220.231.254, Foreign port: 179 

Memory -- BGP Router Process

Below is the impact, if any, on the BGP memory processes with the above configuration changes.

BGP-Test#show processes  memory | include BGP
    83    0   68376692   10748200       44568       0       0 BGP Task        
   129    0    2268908    3541064       10076       0       0 BGP Scheduler   
   159    0  169467056 1450009504   242830484  102060       0 BGP Router      
   187    0  519565380  556721304       10076       0       0 BGP I/O         
   200    0          0 2687139640       10076       0       0 BGP Scanner     
   232    0          0   19748340        7132       0       0 BGP Event       
   BGP-Test#

Based on the above measurements, incorporating the use of the TTL Security Check feature does not have any impact on the amount of memory that is being occupied by any of the BGP processes. As displayed above, and in accordance with our earlier baseline measurements, the BGP processes are occupying approximately 243 MB of memory.

Configuring Maximum Prefixes

The next measurement will be made while incorporating the BGP Maximum Prefix feature on our UUT router. The following is a configuration snippet that displays the specific parameters that are needed for the Maximum Prefix limit:

router bgp 65000
   no synchronization
   bgp log-neighbor-changes
   neighbor 10.220.231.254 remote-as 715
   neighbor 10.220.231.254 ebgp-multihop 255
   neighbor 10.220.231.254 maximum-prefix 350000  80 warning-only
   no auto-summary

The following syslog message is an indication that the maximum-prefix limit of 350,000 prefixes has been exceeded:

*Jul 23  18:38:01.708: %BGP-3-MAXPFXEXCEED: 
Number of prefixes received from 10.220.231.254  (afi 0): 416140 exceeds limit 350000

Memory -- BGP Router Process

Below is the impact, if any, on the BGP memory processes with the above configuration changes.

BGP-Test#show processes memory | include BGP
    83   0    67452624    10531844       7144       0       0 BGP Task        
   129   0     2268908     3541064      10076       0       0 BGP Scheduler   
   159   0   653506988   961111944  242601256  102060       0 BGP Router      
   187   0  3038532352   425088620      10076       0       0 BGP I/O         
   200   0           0  2580477000      10076       0       0 BGP Scanner     
   232   0           0    19748340       7132       0       0 BGP Event       
   BGP-Test#

The BGP processes are unchanged from the baseline measurements as they are still occupying approximately 243 MB of memory.

Filtering BGP Prefixes with Prefix Lists

The next measurement will be made while incorporating the Prefix Lists feature on our UUT router to limit the number of BGP prefixes we receive. The following is a configuration snippet that displays the specific parameters that are needed for Prefix Filters:

router bgp 65000
   no synchronization
   bgp log-neighbor-changes
   neighbor 10.220.231.254 remote-as 715
   neighbor 10.220.231.254 ebgp-multihop 255
   neighbor 10.220.231.254 prefix-list  Ingress-White in
   no auto-summary
 ---  output removed for brevity ---
   !
   ip  prefix-list Ingress-White seq 5 hpermit 1.0.0.0/8
   ip  prefix-list Ingress-White seq 10 permit 2.0.0.0/8
   ip  prefix-list Ingress-White seq 15 permit 3.0.0.0/8
   ip  prefix-list Ingress-White seq 20 permit 4.0.0.0/8
   ip  prefix-list Ingress-White seq 25 permit 5.0.0.0/8
   ip  prefix-list Ingress-White seq 30 deny 0.0.0.0/0 le 32
BGP-Test#show ip bgp sum
   BGP router identifier 10.48.208.36,  local AS number 65000
   BGP table version is 3, main  routing table version 3
   2 network entries using 240  bytes of memory
   2 path entries using 104 bytes  of memory
   46/2 BGP path/bestpath attribute  entries using 5704 bytes of memory
   44 BGP AS-PATH entries using  1884 bytes of memory
   0 BGP route-map cache entries  using 0 bytes of memory
   0 BGP filter-list cache entries  using 0 bytes of memory
   BGP using 7932 total bytes of  memory
   BGP activity 13781053/13781051  prefixes,
    16510372/16510370 paths, scan interval 60 secs
   Neighbor       V   AS  MsgRcvd  MsgSent  TblVer  InQ  OutQ  Up/Down  State/PfxRcd
   10.220.231.254 4  715    69245       25       3    0     0  00:19:57            2
   BGP-Test#
BGP-Test#show ip bgp    
   BGP table version is 3, local  router ID is 10.48.208.36
   Status codes: s suppressed, d  damped, h history, * valid, > best, i - internal,
                 r RIB-failure, S Stale
   Origin codes: i - IGP, e - EGP,  ? - incomplete
      Network          Next Hop            Metric LocPrf Weight Path
   *> 3.0.0.0          10.220.231.254         0 715 7091 19151 6181  80 i
   *> 4.0.0.0          10.220.231.254         0 715 2914 3356 i
BGP-Test# 

Memory -- BGP Router Process

Below is the impact, if any, on the BGP memory processes with the above configuration changes.

BGP-Test#show processes memory | include BGP
    83   0    67662620    10564664    53144       0     0 BGP Task        
   129   0     2268908     3541064    10076       0     0 BGP Scheduler   
   159   0  1358382412  2085471892   445892  102060     0 BGP Router      
   187   0  3437230164   446973700    10076       0     0 BGP I/O         
   200   0           0  2615940348    10076       0     0 BGP Scanner     
   232   0           0    19748340     7132       0     0 BGP Event       
   BGP-Test#

Filtering the number of prefixes, in this case from roughly 416K entries down to a total of two (2) entries has drastically reduced the amount of memory being consumed by the BGP processes. The BGP processes are now using approximately 536 KB of memory, down from the baseline measurement of approximately 243 MB. That result was expected, since controlling the Prefixes practically controls the BGP routes installed in the routing table and thus the memory occupied by the table.

Filtering BGP Prefixes with Autonomous System Path Access Lists

The next measurement will be made while incorporating the use of BGP AS Path Access Lists on our UUT router. The following is a configuration snippet that displays the specific parameters that are needed to use AS Path ACLs:

router bgp 65000
   no synchronization
   bgp log-neighbor-changes
   neighbor 10.220.231.254 remote-as 715
   neighbor 10.220.231.254 ebgp-multihop 255
   neighbor 10.220.231.254 filter-list 1 in
   no auto-summary
   !
   --- output removed for brevity ---
   !
   ip  as-path access-list 1 permit ^715$
BGP-Test#show ip bgp sum
   BGP router identifier 10.48.208.36,  local AS number 65000
   BGP table version is 4, main  routing table version 4
   3 network entries using 360  bytes of memory
   3 path entries using 156 bytes  of memory
   38/1 BGP path/bestpath attribute  entries using 4712 bytes of memory
   38 BGP AS-PATH entries using  1588 bytes of memory
   0 BGP route-map cache entries  using 0 bytes of memory
   38 BGP filter-list cache entries  using 456 bytes of memory
   BGP using 7272 total bytes of  memory
   BGP activity 17460911/17460908  prefixes,
    20191920/20191917 paths, scan interval 60 secs
   Neighbor        V   AS MsgRcvd  MsgSent  TblVer  InQ  OutQ  Up/Down  State/PfxRcd
   10.220.231.254  4  715   69257        9       4    0     0  00:05:19            3
BGP-Test# 

Memory -- BGP Router Process

Below is the impact, if any, on the BGP memory processes with the above configuration changes.

BGP-Test#show processes memory | include BGP
83 0 67829416 10610664 39964 0 0 BGP Task 129 0 2268908 3541064 10076 0 0 BGP Scheduler 159 0 2178066128 3369775744 460808 102060 0 BGP Router 187 0 4087509344 525949036 10076 0 0 BGP I/O 200 0 0 2640047400 10076 0 0 BGP Scanner 232 0 0 19748340 7132 0 0 BGP Event BGP-Test#

Filtering the number of prefixes, in this case from roughly 416K entries down to a total of three (3) entries has again drastically reduced the amount of memory that is being consumed by the BGP processes. The BGP processes are now using approximately 538 KB of memory, down from the baseline measurement of approximately 243 MB.

AS Path Length Limiting

The next measurement will be made while incorporating the BGP AS Path Length Limiting feature on our UUT router. The following is a configuration snippet that displays the specific parameters that are needed to limit the AS Path Length that will be accepted:

router bgp 65000
  no synchronization
  bgp log-neighbor-changes
  bgp maxas-limit 5
  neighbor 10.220.231.254 remote-as 715
  neighbor 10.220.231.254 ebgp-multihop 255
  no auto-summary
BGP-Test#show ip bgp sum
   BGP router identifier 10.48.208.36,  local AS number 65000
   BGP table version is 353921,  main routing table version 353921
   353895 network entries using  42467400 bytes of memory
   353895 path entries using  18402540 bytes of memory
   53030/53024 BGP path/bestpath  attribute entries using 6575720 bytes of memory
   47075 BGP AS-PATH entries using  1870664 bytes of memory
   0 BGP route-map cache entries  using 0 bytes of memory
   0 BGP filter-list cache entries  using 0 bytes of memory
   BGP using 69316324 total bytes  of memory
   BGP activity 14554120/14200222  prefixes,
    17283446/16929551 paths, scan interval 60 secs
   Neighbor        V      AS MsgRcvd MsgSent   TblVer   InQ OutQ Up/Down  State/PfxRcd
   10.220.231.254  4     715   68838       6   353921     0    0 00:02:43       353895

Memory -- BGP Router Process

Below is the impact, if any, on the BGP memory processes with the above configuration changes.

BGP-Test#show processes memory | include BGP
    83   0    67895004    10643484       7144       0    0 BGP Task        
   129   0     2268908     3541064      10076       0    0 BGP Scheduler   
   159   0  2613766024  3774593796  205849752  102060    0 BGP Router      
   187   0  4275825500   539460164      10076       0    0 BGP I/O         
   200   0           0  2640462472      10076       0    0 BGP Scanner     
   232   0           0    19748340       7132       0    0 BGP Event       
BGP-Test#

Implementing the AS Path Limit filter in the above configuration results in a corresponding reduction in BGP prefixes. This reduction translates to approximately 206 MB of memory that is being consumed by the BGP processes, which is still down from the baseline measurement of approximately 243 MB.

NOTE: The impact of Infrastructure ACLs and Control Plane Policing (CoPP) was not tested because these configurations are both very specific to customer environments and they are not necessarily tied directly to the use of BGP.

Memory requirements will certainly change when there are additional peers and when there are more advanced configurations that include a multitude of other features, both those related to as well as those unrelated to BGP, that are being used. However, based on the testing results provided in this document, we see that there is no increase in the memory requirements when implementing any of the features that are used to protect your BGP deployment. In fact, memory consumption for BGP processes (specifically the BGP Router process) is tied directly to the number of BGP prefixes that are being accepted by the router. When the number of BGP prefixes accepted by the router is limited (for example, due to prefix lists, AS path access lists, etc.) the amount of memory consumed is decreased accordingly.

Conclusions

A multitude of threats exist that can adversely impact the robustness and effectiveness of the BGP routing protocol. Some threats are malicious in nature, while others may arise from misconfigurations. In either case, the integrity of the BGP process is critical.

Many features and techniques are available to network administrators to mitigate the effects of these threats. A number of these features and techniques have been discussed in this document, and configuration examples of each have been provided throughout. By applying these concepts to BGP configurations, administrators can increase the integrity and resilience of the BGP process and improve the reliability of their networks' data plane.

Acknowledgments

John Stuppi (jstuppi@cisco.com)
Incident Manager

Gregg Schudel (gschudel@cisco.com)
Network Consulting Engineer

Tim Sammut (tsammut@cisco.com)
Incident Manager

Tim Sammut, Gregg Schudel, and John Stuppi are members of the Security Intelligence Engineering organization at Cisco. Additional content produced by Security Intelligence Engineering is located in the Security Intelligence Best Practices section of Cisco Security Intelligence Operations.

References

BGP Vulnerability Testing: Separating Fact from FUD v1.1
http://www.nanog.org/mtg-0306/pdf/ciag-bgp-v1-1.pdf

RFC 1163
http://www.ietf.org/rfc/rfc1163.txt?number=1163"http://www.ietf.org/rfc/rfc1163.txt?number=1163

RFC 1267
http://www.ietf.org/rfc/rfc1267.txt?number=1267

RFC 2385
http://tools.ietf.org/html/rfc2385

RFC 1918
http://www.ietf.org/rfc/rfc1918.txt?number=1918

RFC 3330
http://www.ietf.org/rfc/rfc3330.txt?number=3330

RFC 2827
http://www.ietf.org/rfc/rfc2827.txt?number=2827

BGP Support for TTL Security Check
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_btsh.html

Neighbor Router Authentication
http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp3.html#wp1015208

CIDR Report
http://www.cidr-report.org/as2.0/

Configuring the BGP Maximum-Prefix Feature
http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a008010a28a.shtml

Connecting to a Service Provider Using External BGP
http://www.cisco.com/en/US/docs/ios/iproute/configuration/guide/irp_bgp_external_sp.html

Protecting Your Core: Infrastructure Protection Access Control Lists
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

Control Plane Policing Implementation Best Practices
http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

Control Plane Policing Feature Guide
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html

Deploying Control Plane Policing
http://www.cisco.com/en/US/products/ps6642/products_white_paper0900aecd804fa16a.shtml

Team Cymru BGP/ASN Analysis Report
http://www.cymru.com/BGP/summary.html

bgp maxas-limit
http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfbgp1.html#wp1254976

Parkhurst, William R., Ph.D. "Cisco BGP-4 Command and Configuration Handbook."  April 27, 2001


This document is part of Cisco Security Intelligence Operations.

This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.

Back to Top

Cisco Security Intelligence Operations