Table Of Contents
BGP Support for TTL Security Check
Prerequisites for BGP Support for TTL Security Check
Restrictions for BGP Support for TTL Security Check
Information About BGP Support for TTL Security Check
BGP Support for TTL Security Check Feature Overview
Configuring the TTL Security Check for BGP Peering Sessions
Configuring the TTL Security Check for Multihop BGP Peering Sessions
Benefits of the BGP Support for TTL Security Check Feature
How to Secure BGP Sessions with the BGP Support for TTL Security Check Feature
Configuring the TTL-Security Check
Verifying the TTL-Security Check Configuration
Configuration Examples for the BGP Support for TTL Security Check Feature
Configuring the TTL-Security Check: Example
Verifying the TTL-Security Check Configuration: Example
BGP Support for TTL Security Check
The BGP Support for TTL Security Check feature introduces a lightweight security mechanism to protect external Border Gateway Protocol (eBGP) peering sessions from CPU utilization-based attacks using forged IP packets. Enabling this feature prevents attempts to hijack the eBGP peering session by a host on a network segment that is not part of either BGP network or by a host on a network segment that is not between the eBGP peers.
You enable this feature by configuring a minimum Time To Live (TTL) value for incoming IP packets received from a specific eBGP peer. When this feature is enabled, BGP will establish and maintain the session only if the TTL value in the IP packet header is equal to or greater than the TTL value configured for the peering session. If the value is less than the configured value, the packet is silently discarded and no Internet Control Message Protocol (ICMP) message is generated. This feature is both effective and easy to deploy.
Feature History for the BGP Support for TTL Security Check Feature
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•Prerequisites for BGP Support for TTL Security Check
•Restrictions for BGP Support for TTL Security Check
•Information About BGP Support for TTL Security Check
•How to Secure BGP Sessions with the BGP Support for TTL Security Check Feature
•Configuration Examples for the BGP Support for TTL Security Check Feature
Prerequisites for BGP Support for TTL Security Check
•BGP must be configured in your network and eBGP peering sessions must be established.
•This feature needs to be configured on each participating router. It protects the eBGP peering session in the incoming direction only and has no effect on outgoing IP packets or the remote router.
Restrictions for BGP Support for TTL Security Check
•This feature is designed to protect only eBGP peering sessions and is not supported for internal BGP (iBGP) peers and iBGP peer groups.
•When configuring the BGP Support for TTL Security Check feature to support an existing multihop peering session, you must first disable the neighbor ebgp-multihop router configuration command by entering the no neighbor ebgp-multihop command before configuring this feature with the neighbor ttl-security router configuration command. These commands are mutually exclusive, and only one command is required to establish a multihop peering session. If you attempt to configure both commands for the same peering session, an error message will be displayed in the console.
•The effectiveness of this feature is reduced in large-diameter multihop peerings. In the event of a CPU utilization-based attack against a BGP router that is configured for large-diameter peering, you may still need to shut down the affected peering sessions to handle the attack.
•This feature is not effective against attacks from a peer that has been compromised inside your network. This restriction also includes BGP peers that are not part of the local or external BGP network but are connected to the network segment between the BGP peers (for example, a switch or hub that is used to connect the local and external BGP networks).
•This feature does not protect the integrity of data sent between eBGP peers and does not validate eBGP peers through any authentication method. This feature validates only the locally configured TTL count against the TTL field in the IP packet header.
Information About BGP Support for TTL Security Check
To configure the BGP Support for TTL Security Check feature, you must understand the following concepts:
•BGP Support for TTL Security Check Feature Overview
•Configuring the TTL Security Check for BGP Peering Sessions
•Configuring the TTL Security Check for Multihop BGP Peering Sessions
•Benefits of the BGP Support for TTL Security Check Feature
BGP Support for TTL Security Check Feature Overview
The BGP Support for TTL Security Check feature introduces a lightweight security mechanism to protect eBGP peering sessions from CPU utilization-based attacks. These types of attacks are typically brute force Denial of Service (DoS) attacks that attempt to disable the network by flooding the network with IP packets that contain forged source and destination IP addresses.
This feature protects the eBGP peering session by comparing the value in the TTL field of received IP packets against a hop count that is configured locally for each eBGP peering session. If the value in the TTL field of the incoming IP packet is greater than or equal to the locally configured value, the IP packet is accepted and processed normally. If the TTL value in the IP packet is less than the locally configured value, the packet is silently discarded and no ICMP message is generated. This is designed behavior; a response to a forged packet is unnecessary.
Although it is possible to forge the TTL field in an IP packet header, accurately forging the TTL count to match the TTL count from a trusted peer is impossible unless the network to which the trusted peer belongs has been compromised.
This feature supports both directly connected peering sessions and multihop eBGP peering sessions. The BGP peering session is not affected by incoming packets that contain invalid TTL values. The BGP peering session will remain open, and the router will silently discard the invalid packet. The BGP session, however, can still expire if keepalive packets are not received before the session timer expires.
Configuring the TTL Security Check for BGP Peering Sessions
The BGP Support for TTL Security Check feature is configured with the neighbor ttl-security command in router configuration mode or address family configuration mode. When this feature is enabled, BGP will establish or maintain a session only if the TTL value in the IP packet header is equal to or greater than the TTL value configured for the peering session. Enabling this feature secures the eBGP session in the incoming direction only and has no effect on outgoing IP packets or the remote router. The hop-count argument is used to configure the maximum number of hops that separate the two peers. The TTL value is determined by the router from the configured hop count. The value for this argument is a number from 1 to 254.
Configuring the TTL Security Check for Multihop BGP Peering Sessions
The BGP Support for TTL Security Check feature supports both directly connected peering sessions and multihop peering sessions. When this feature is configured for a multihop peering session, the neighbor ebgp-multihop router configuration command cannot be configured and is not needed to establish the peering session. These commands are mutually exclusive, and only one command is required to establish a multihop peering session. If you attempt to configure both commands for the same peering session, an error message will be displayed in the console.
To configure this feature for an existing multihop session, you must first disable the existing peering session with the no neighbor ebgp-multihop command. The multihop peering session will be restored when you enable this feature with the neighbor ttl-security command.
This feature should be configured on each participating router. To maximize the effectiveness of this feature, the hop-count argument should be strictly configured to match the number of hops between the local and external network. However, you should also consider path variation when configuring this feature for a multihop peering session.
Benefits of the BGP Support for TTL Security Check Feature
The BGP Support for TTL Security Check feature provides an effective and easy-to-deploy solution to protect eBGP peering sessions from CPU utilization-based attacks. When this feature is enabled, a host cannot attack a BGP session if the host is not a member of the local or remote BGP network or if the host is not directly connected to a network segment between the local and remote BGP networks. This solution greatly reduces the effectiveness of DoS attacks against a BGP autonomous system.
How to Secure BGP Sessions with the BGP Support for TTL Security Check Feature
This section contains the following procedures:
•Configuring the TTL-Security Check (required)
•Verifying the TTL-Security Check Configuration (optional)
Configuring the TTL-Security Check
To configure the BGP Support for TTL Security Check Feature, perform the steps in this section.
Prerequisites
•To maximize the effectiveness of this feature, we recommend that you configure it on each participating router. Enabling this feature secures the eBGP session in the incoming direction only and has no effect on outgoing IP packets or the remote router.
Restrictions
•The neighbor ebgp-multihop command is not needed when this feature is configured for a multihop peering session and should be disabled before configuring this feature.
•The effectiveness of this feature is reduced in large-diameter multihop peerings. In the event of a CPU utilization-based attack against a BGP router that is configured for large-diameter peering, you may still need to shut down the affected peering sessions to handle the attack.
•This feature is not effective against attacks from a peer that has been compromised inside of the local and remote network. This restriction also includes peers that are on the network segment between the local and remote network.
SUMMARY STEPS
1. enable
2. trace [protocol] destination
3. configure terminal
4. router bgp as-number
5. neighbor ip-address ttl-security hops hop-count
6. end
DETAILED STEPS
Examples
The following example sets the expected incoming TTL value for a directly connected eBGP peer. The hop-count argument is set to 2 configuring BGP to only accept IP packets with a TTL count in the header that is equal to or greater than 253. If the 10.1.1.1 neighbor is more than 2 hops away, the peering session will not be accepted.
neighbor 10.1.1.1 ttl-security hops 2What to Do Next
The next task is to verify the TTL-security check configuration. Use the steps in the Verifying TTL-Security Check Configuration section.
Verifying the TTL-Security Check Configuration
You can verify the local configuration of this feature with the show running-config and show ip bgp neighbors commands.
SUMMARY STEPS
1. enable
2. show running-config [interface type number] [linenum] [map-class]
3. show ip bgp neighbors neighbor-address [advertised-routes | dampened-routes | paths regular-expression | policy | received-routes | routes | received prefix-filter]
DETAILED STEPS
Configuration Examples for the BGP Support for TTL Security Check Feature
The following examples show how to configure and verify this feature:
•Configuring the TTL-Security Check: Example
•Verifying the TTL-Security Check Configuration: Example
Configuring the TTL-Security Check: Example
The example configurations in this section show how to configure the BGP Support for TTL Security Check feature.
The following example uses the trace command to determine the hop count to an eBGP peer. The hop count number is displayed in the output for each networking device that IP packets traverse to reach the specified neighbor. In the example below, the hop count for the 10.1.1.1 neighbor is 1.
Router# trace ip 10.1.1.1
Type escape sequence to abort.Tracing the route to 10.1.1.11 10.1.1.1 0 msec * 0 msecThe following example sets the hop count to 2 for the 10.1.1.1 neighbor. Because the hop-count argument is set to 2, BGP will only accept IP packets with a TTL count in the header that is equal to or greater than 253.
Router(config-router)# neighbor 10.1.1.1 ttl-security hops 2
Verifying the TTL-Security Check Configuration: Example
The configuration of the BGP Support for TTL Security Check feature can be verified with the show running-config and show ip bgp neighbors commands. This feature is configured locally on each peer, so there is no remote configuration to verify.
The following is sample output from the show running-config command. The output shows that neighbor 10.1.1.1 is configured to establish or maintain the peering session only if the expected TTL count in the incoming IP packet is 253 or 254.
Router# show running-config | begin bgprouter bgp 65000no synchronizationbgp log-neighbor-changesneighbor 10.1.1.1 remote-as 55000neighbor 10.1.1.1 ttl-security hops 2no auto-summary...The following is sample output from the show ip bgp neighbors command. The output shows that the local router will accept packets from the 10.1.1.1 neighbor if it is no more than 2 hops away. The configuration of this feature is displayed in the address family section of the output. The relevant line is bolded in the output.
Router# show ip bgp neighbors 10.1.1.1
BGP neighbor is 10.1.1.1, remote AS 55000, external linkBGP version 4, remote router ID 10.2.2.22BGP state = Established, up for 00:59:21Last read 00:00:21, hold time is 180, keepalive interval is 60 secondsNeighbor capabilities:Route refresh: advertised and received(new)Address family IPv4 Unicast: advertised and receivedMessage statistics:InQ depth is 0OutQ depth is 0Sent RcvdOpens: 2 2Notifications: 0 0Updates: 0 0Keepalives: 226 227Route Refresh: 0 0Total: 228 229Default minimum time between advertisement runs is 5 secondsFor address family: IPv4 UnicastBGP table version 1, neighbor version 1/0Output queue sizes : 0 self, 0 replicatedIndex 1, Offset 0, Mask 0x2Member of update-group 1Sent RcvdPrefix activity: ---- ----Prefixes Current: 0 0Prefixes Total: 0 0Implicit Withdraw: 0 0Explicit Withdraw: 0 0Used as bestpath: n/a 0Used as multipath: n/a 0Outbound InboundLocal Policy Denied Prefixes: -------- -------Total: 0 0Number of NLRIs in the update sent: max 0, min 0Connections established 2; dropped 1Last reset 00:59:50, due to User resetExternal BGP neighbor may be up to 2 hops away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0Local host: 10.2.2.22, Local port: 179Foreign host: 10.1.1.1, Foreign port: 11001Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)Event Timers (current time is 0xCC28EC):Timer Starts Wakeups NextRetrans 63 0 0x0TimeWait 0 0 0x0AckHold 62 50 0x0SendWnd 0 0 0x0KeepAlive 0 0 0x0GiveUp 0 0 0x0PmtuAger 0 0 0x0DeadWait 0 0 0x0iss: 712702676 snduna: 712703881 sndnxt: 712703881 sndwnd: 15180irs: 2255946817 rcvnxt: 2255948041 rcvwnd: 15161 delrcvwnd: 1223SRTT: 300 ms, RTTO: 607 ms, RTV: 3 ms, KRTT: 0 msminRTT: 0 ms, maxRTT: 300 ms, ACK hold: 200 msFlags: passive open, nagle, gen tcbsDatagrams (max data segment is 1460 bytes):Rcvd: 76 (out of order: 0), with data: 63, total data bytes: 1223Sent: 113 (retransmit: 0, fastretransmit: 0), with data: 62, total data bytes: 4Additional References
The following sections provide references related to the BGP Support For TTL Security Check feature.
Related Documents
Related Topic Document TitleBGP commands
Cisco IOS Release 12.0 Network Protocols Command Reference, Part 1
Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols, Release 12.2
Cisco IOS IP Command Reference, Volume 2 of 4: Routing Protocols, Release 12.3T
BGP configuration tasks
Cisco IOS Release 12.0 Network Protocols Configuration Guide, Part 1
Cisco IOS IP Configuration Guide, Release 12.2
Cisco IOS IP Configuration Guide, Release 12.3
Standards
Standards TitleNo new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
Technical Assistance
Description LinkTechnical Assistance Center (TAC) home page, containing 30,000 pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
TAC Home Page:
http://www.cisco.com/public/support/tac/home.shtml
BGP Support Page:
http://www.cisco.com/cgi-bin/Support/browse/psp_view.pl?p=Internetworking:BGP
Command Reference
This section documents new and modified commands.
New Command
Modified Command
neighbor ttl-security
To secure a Border Gateway Protocol (BGP) peering session and to configure the maximum number of hops that separate two external BGP (eBGP) peers, use the neighbor ttl-security command in address-family or router configuration mode. To disable this feature, use the no form of this command.
neighbor neighbor-address ttl-security hops hop-count
no neighbor neighbor-address ttl-security hops hop-count
Syntax Description
Defaults
No default behavior or values
Command Modes
Address-family configuration
Router configurationCommand History
Usage Guidelines
The neighbor ttl-security command provides a lightweight security mechanism to protect BGP peering sessions from CPU utilization-based attacks. These types of attacks are typically brute force Denial of Service (DoS) attacks that attempt to disable the network by flooding the network with IP packets that contain forged source and destination IP addresses in the packet headers.
This feature leverages designed behavior of IP packets by accepting only IP packets with a TTL count that is equal to or greater than the locally configured value. Accurately forging the TTL count in an IP packet is generally considered to be impossible. Accurately forging a packet to match the TTL count from a trusted peer is not possible without internal access to the source or destination network.
This feature should be configured on each participating router. It secures the BGP session in the incoming direction only and has no effect on outgoing IP packets or the remote router. When this feature is enabled, BGP will establish or maintain a session only if the TTL value in the IP packet header is equal to or greater than the TTL value configured for the peering session. This feature has no effect on the BGP peering session, and the peering session can still expire if keepalive packets are not received. If the TTL value in a received packet is less than the locally configured value, the packet is silently discarded and no Internet Control Message Protocol (ICMP) message is generated. This is designed behavior; a response to a forged packet is not necessary.
To maximize the effectiveness of this feature, the hop-count value should be strictly configured to match the number of hops between the local and external network. However, you should also take path variation into account when configuring this feature for a multihop peering session.
The following restrictions apply to the configuration of this command:
•This feature is not supported for internal BGP (iBGP) peers or iBGP peer groups.
•The neighbor ttl-security command cannot be configured for a peer that is already configured with the neighbor ebgp-multihop command. The configuration of these commands is mutually exclusive, and only one of these commands is needed to enable a multihop eBGP peering session. An error message will be displayed in the console if you attempt to configure both commands for the same peering session.
•The effectiveness of this feature is reduced in large-diameter multihop peerings. In the event of a CPU utilization-based attack against a BGP router that is configured for large-diameter peering, you may still need to shut down the affected peering sessions to handle the attack.
•This feature is not effective against attacks from a peer that has been compromised inside of your network. This restriction also includes peers that are on the network segment between the source and destination network.
Examples
The following example sets the hop count to 2 for a directly connected neighbor. Because the hop-count argument is set to 2, BGP will accept only IP packets with a TTL count in the header that is equal to or greater than 253. If a packet is received with any other TTL value in the IP packet header, the packet will be silently discarded.
neighbor 10.0.0.1 ttl-security hops 2Related Commands
show ip bgp neighbors
To display information about Border Gateway Protocol (BGP) and TCP connections to neighbors, use the show ip bgp neighbors command in privileged EXEC mode.
show ip bgp neighbors [all] [ip-address [advertised-routes | dampened-routes | paths [regexp] | received prefix-filter | received-routes | routes]]
Syntax Description
Command Default
The output of this command displays information for only IPv4 address family sessions if the all keyword is not entered.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
The show ip bgp neighbors command is used to display BGP and TCP connection information for neighbor sessions. For BGP, this includes detailed neighbor attribute, capability, path, and prefix information. For TCP, this includes statistics related to BGP neighbor session establishment and maintenance. This command displays information only about IPv4 address-family sessions unless the all keyword is entered.
Prefix activity is displayed based on the number of prefixes that are advertised and withdrawn. Policy denials display the number of routes that were advertised but then ignored based the function or attribute that is displayed in the output.
Examples
show ip bgp neighbors example
The following example shows the 10.108.50.2 neighbor. This neighbor is an internal BGP (iBGP) peer. This neighbor supports the route refresh and graceful restart capabilities.
Router# show ip bgp neighbors 10.108.50.2
BGP neighbor is 10.108.50.2, remote AS 1, internal linkBGP version 4, remote router ID 192.168.252.252BGP state = Established, up for 00:24:25Last read 00:00:24, last write 00:00:24, hold time is 180, keepalive interval is 60 secondsNeighbor capabilities:Route refresh: advertised and received(old & new)Graceful Restart Capabilty:advertised and receivedAddress family IPv4 Unicast: advertised and receivedMessage statistics:InQ depth is 0OutQ depth is 0Sent RcvdOpens: 3 3Notifications: 0 0Updates: 0 0Keepalives: 113 112Route Refresh: 0 0Total: 116 115Default minimum time between advertisement runs is 5 secondsFor address family: IPv4 UnicastBGP table version 1, neighbor version 1/0Output queue size : 0Index 1, Offset 0, Mask 0x21 update-group memberSent RcvdPrefix activity: ---- ----Prefixes Current: 0 0Prefixes Total: 0 0Implicit Withdraw: 0 0Explicit Withdraw: 0 0Used as bestpath: n/a 0Used as multipath: n/a 0Outbound InboundLocal Policy Denied Prefixes: -------- -------Total: 0 0Number of NLRIs in the update sent: max 0, min 0Connections established 3; dropped 2Last reset 00:24:26, due to Peer closed the sessionConnection state is ESTAB, I/O status: 1, unread input bytes: 0Connection is ECN DisabledLocal host: 10.108.50.1, Local port: 179Foreign host: 10.108.50.2, Foreign port: 42698Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)Event Timers (current time is 0x68B944):Timer Starts Wakeups NextRetrans 27 0 0x0TimeWait 0 0 0x0AckHold 27 18 0x0SendWnd 0 0 0x0KeepAlive 0 0 0x0GiveUp 0 0 0x0PmtuAger 0 0 0x0DeadWait 0 0 0x0iss: 3915509457 snduna: 3915510016 sndnxt: 3915510016 sndwnd: 15826irs: 233567076 rcvnxt: 233567616 rcvwnd: 15845 delrcvwnd: 539SRTT: 292 ms, RTTO: 359 ms, RTV: 67 ms, KRTT: 0 msminRTT: 12 ms, maxRTT: 300 ms, ACK hold: 200 msFlags: passive open, nagle, gen tcbsIP Precedence value : 6Datagrams (max data segment is 1460 bytes):Rcvd: 38 (out of order: 0), with data: 27, total data bytes: 539Sent: 45 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 08Table 1 describes the significant fields shown in the display. Fields that are preceded by the asterisk character are displayed only when the counter has a non-zero value.
show ip bgp neighbors advertised-routes example
The following example displays routes advertised for only the 172.16.232.178 neighbor:
Router# show ip bgp neighbors 172.16.232.178 advertised-routes
BGP table version is 27, local router ID is 172.16.232.181Status codes: s suppressed, d damped, h history, * valid, > best, i - internalOrigin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path*>i110.0.0.0 172.16.232.179 0 100 0 ?*> 200.2.2.0 0.0.0.0 0 32768 iTable 2 describes the significant fields shown in the display.
show ip bgp neighbors paths
The following is example output from the show ip bgp neighbors command entered with the paths keyword:
Router# show ip bgp neighbors 172.29.232.178 paths ^10
Address Refcount Metric Path0x60E577B0 2 40 10 ?Table 3 describes the significant fields shown in the display.
show ip bgp neighbors received prefix-filter
The following example shows that a prefix-list the filters all routes in the 10.0.0.0 network has be received from the 192.168.20.72 neighbor:
Router# show ip bgp neighbor 192.168.20.72 received prefix-filter
Address family:IPv4 Unicastip prefix-list 192.168.20.72:1 entriesseq 5 deny 10.0.0.0/8 le 32Table 4 describes the significant fields shown in the display.
Copyright © 2005 Cisco Systems, Inc. All rights reserved.