для Cisco Cisco IOS Software Release 12.2(27)SBC
BGP Support for TTL Security Check
Information About BGP Support for TTL Security Check
3
Cisco IOS Release: Multiple releases (see the Feature History table)
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.
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.
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.
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.
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.
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.
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.
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.
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.