This document contains information to assist Cisco customers in identifying and mitigating the effects of Time to Live (TTL) packets that are sent to network devices with a value less than or equal to one. Cisco routers and switches running Cisco IOS have several mechanisms that can assist with the identification and mitigation of TTL packets that are sent with a value less than or equal to one.
When an IOS device receives a packet with a TTL value of less than or equal to one, an ICMPv4 Type 11, Code 0 message is sent by an IOS device, resulting in a corresponding impact on the CPU. This impact occurs because more CPU processing is required to respond (using TTL-exceeded packets) to packets with TTL values of less than one than to simply forward a packet with a TTL value greater than one.
The recent increase in attention surrounding TTL expiry packets is because many Internet Service Providers (ISPs) are choosing to rate-limit how many ICMP Type 11, Code 0 – “Time Exceeded” messages ISP routers send. Rate-limiting such messages adversely impacts the proper operation of tools and applications, such as traceroute, that use TTL expiry packets to function properly. This is a concern among network administrators seeking to understand how traffic is being routed inside an ISP.
The standard header that is used in IPv4 contains key information about an Internet Protocol (IP) packet. Information includes the source and destination IP addresses of the datagram, fragmentation control parameters, and packet length. Another key element of this header is the TTL field. The TTL field consists of a single byte and is capable of holding a value from 0–255. The entire 20 byte IPv4 header (which precedes the Options and Data fields) is shown in the following figure.
Figure 1. Standard IPv4 Header
Because IP is connectionless, the TTL field was included in the IP header by the original designers as a mechanism to limit the life span of packets within the network. A routing loop is the most common example used to illustrate why this functionality is required. Without such a control mechanism, a routing loop could cause a packet to circle a network infinitely, depleting bandwidth and eventually destabilizing the network. As insurance against this outcome, the TTL value of an IP datagram is decremented by a value of one each time the packet is forwarded by a network device. Thus, an IP packet can never be forwarded more than 254 times, preventing the infinite packet loop problem.
RFC 791 requires that a router destroy any datagram with a TTL value of zero. Packets that have been dropped due to the expiration of their TTL value are known as TTL expiry packets. When an IP packet is received with a TTL less than or equal to one and is expected to be forwarded by the router, the router is required to drop the packet and reply back to the source with an ICMPv4 Type 11, Code 0 Time Exceeded message. In theory, upon receipt of this message, the originating device should detect an issue—such as a routing problem when sending to that particular destination, or an initial TTL value that is too low—and react to overcome the problem.
Another ICMP Time Exceeded message exists—ICMP Type 11, Code 1—which is used when a fragmented IP datagram cannot be reassembled in the time allotted. The sending of this message prevents the destination from waiting indefinitely to receive and reassemble any remaining fragments. This message is only generated by the ultimate destination of a packet and not intermediate network devices. As such, the sending and subsequent receipt of this type of Time Exceeded message is not a valid network device attack vector and will not be discussed in this document.
Other than the infinite packet prevention mechanism described in the preceeding paragraphs, some network management tools make legitimate use of the TTL expiry behavior. The most common example of such a tool is traceroute, which uses the TTL expiry behavior in conjunction with ICMP Type 11, Code 0 messages to map the path that a packet would take through a network from source to destination.
The TTL expiry behavior creates a denial of service (DoS) attack vector against network equipment. Network devices are purpose-built to forward ordinary packets as quickly as possible. When exception packets are encountered, such as those with expiring TTL values, varying amounts of effort are expended by a router to respond appropriately. In the case of an IPv4 TTL expiry packet, the router must respond with an appropriate ICMP Time Exceeded message. The generation and subsequent transmission of this ICMP message is an exception process.
Under normal conditions, routers are capable of processing these exception packets. However, under attack conditions where the number of TTL expiry packets is large, high CPU utilization may result, leading to network instability. This security concern is causing Service Providers to review and adjust their core network behaviors, often rate-limiting or preventing the generation of ICMP Type 11, Code 0 Time Exceeded messages. Such action adversely impacts the proper operation of tools or applications, such as traceroute, which rely on these Time Exceeded messages to function. This is a concern among network administrators who desire metrics in support of Service Level Agreements and other management functions.
Most modern operating systems and network devices use a large default TTL value when originating packets; default values of 128 or 255 are commonplace. This fact, in conjunction with typical network diameters and path lengths across the Internet, makes the presence of low TTL values within legitimate packets unlikely.
It is recommended that enterprises filter incoming packets with low TTL values at untrusted-to-trusted network boundaries. While filtering such packets will prevent remote users from tracerouting into the network (outbound traceroute is unaffected), it will also eliminate a significant denial of service attack vector. As an additional benefit, filtering packets with low TTL values will eliminate certain firewall rule mapping techniques such as those used by Firewalk as well as IDS evasion techniques.
Security controls should filter packets with low TTL values to protect an enterprise network from TTL expiry attacks. In practice, filtering packets whereby TTL value is less than the value that is needed to traverse the longest path across the network will completely mitigate this attack vector. For example, if the width of a network is six routed hops, an enterprise should filter packets that enter the network with TTL values of six and below.
To demonstrate the implementation of these filters while providing a configuration that would be safe for the largest set of enterprises, the examples in this document filter packets with TTL values of 15 or less. This configuration should protect even the largest networks with minimal negative side effects. When implementing these features, it is imperative that an enterprise determine the proper configuration that is appropriate for individual enterprise needs.
In addition to filtering packets with low TTL values at network boundaries, administrators are advised to harden individual network devices against TTL expiry attacks. Doing so will affect the functionality of tools that leverage TTL expiry, such as traceroute, rendering such tools inoperable in the case of complete packet filtering, or impeding their effectiveness in the case of rate limiting. This hardening is accomplished by filtering packets with TTL values of zero or one on each network device.
IOS-based platforms include built-in functions as well as several user-configurable features that can be used to mitigate the effects of TTL expiry packets. A discussion of built-in functions is beyond the scope of this document. Such a discussion would include features such as raw-queues on line cards for the Cisco 12000 Series routers, Selective Packet Discard, and hard-coded rate-limiting on the Cisco 10000 Series routers.
The user-configurable options discussed throughout the remainder of this document include the following:
TTL-filtering in Router ACLs: ACL Support for Filtering on TTL Value allows users to apply extended Access Control Lists (ACLs) to routed interfaces with the ability to filter packets with specific TTL values. This feature can be used to protect the local network device and downstream network devices from TTL expiry attacks.
Control Plane Policing and Control Plane Protection: Control Plane Policing (CoPP) and Control Plane Protection (CPPr) can be used on IOS routers and switches to both identify and mitigate the presence of packets with low TTL values. CoPP and CPPr can be used to protect individual devices from TTL expiry attacks.
Flexible Packet Matching: Flexible Packet Matching (FPM) can be used to filter on specific fields within IP packet headers, including the TTL value. FPM can be leveraged to protect the local network device and downstream network devices from the effects of TTL expiry attacks.
CPU Hardware Rate Limiters: The Cisco Catalyst 6500 Series Supervisor Engine 32 and Supervisor Engine 720 support platform-specific, hardware-based rate limiters (HWRLs) for special networking scenarios. HWRLs can be used to protect the local device from TTL expiry attacks.
Note: Contrary to common perception, the no ip unreachables interface configuration command does not suppress the generation or transmission of ICMP Time Exceeded messages. The functionality of this command is specifically limited to ICMP Type 3 Destination Unreachable messages.
Access control lists (ACLs) applied to router interfaces are known as router ACLs or RACLs. Starting with IOS version 12.4(2)T, it is possible to add access control entries (ACEs) to RACLs that permit or deny traffic based on TTL value. This functionality can be used to protect the local network device as well as downstream network devices from TTL expiry attacks. Additionally, TTL filtering should be integrated into any deployment of Infrastructure or transit ACLs.
To protect the local network device as well as downstream network devices from TTL expiry attacks, administrators should configure an RACL that filters packets with low TTL values. The following configuration example builds and applies an RACL that will drop all IP packets with TTL values of 15 or less. As explained previously, filtering packets with these TTL values will protect the largest of enterprise networks while posing minimal risk to legitimate packets. ACLs such as this should be applied to interfaces at untrusted-to-trusted boundaries as well as internal interfaces to ensure a more effective defense against TTL expiry attacks.
! ip access-list extended ACL-BLOCK-LOW-TTL deny ip any any ttl lt 16 permit ip any any ! interface FastEthernet0 ip access-group ACL-BLOCK-LOW-TTL in !
As noted in the following CoPP section, some protocols make legitimate use of packets with very low TTL values. This use should be taken into account before the deployment of packet filtering that is based solely on TTL.
The following show access-lists output depicts the number of packets that were dropped by ACL-BLOCK-LOW-TTL.
Router#show access-lists ACL-BLOCK-LOW-TTL Extended IP access list ACL-BLOCK-LOW-TTL 10 deny ip any any ttl lt 16 (3003 matches) 20 permit ip any any (2670 matches) Router#
As displayed, there were 3003 packets dropped by the router access list ACL-BLOCK-LOW-TTL.
Administrators may be able to gain additional attack information through the use of ACL logging. ACL logging has been proven to elevate the CPU load of network devices and should not be enabled without careful planning. For more information see Access Control List Logging.
Control Plane Policing and Control Plane Protection can be used to protect an individual network device from TTL expiry attacks. CoPP and CPPr do not have visibility into transit packets with TTL values greater than one; therefore, CoPP and CPPr cannot be used to protect other network devices.
Beginning with Cisco IOS software version 12.4(2)T, an administrator may be able to leverage TTL filtering in access control lists with CoPP and CPPr to filter packets with TTL values of zero and one. The following configuration, although not a comprehensive example of the capabilities of CoPP, will mitigate the threat of TTL expiry on the local network device.
! !Add an ACL to match any IP packet with TTL values !of zero or one. ! ip access-list extended ACL-MATCH-TTL-0/1 permit ip any any ttl eq 0 permit ip any any ttl eq 1 ! !Define a class that contains packets matching !the ACL ACL-MATCH-TTL-0/1. ! class-map match-all COPP-CM-TTL-0/1 match access-group name ACL-MATCH-TTL-0/1 ! !Create the policy map that will be applied to !the control-plane. ! policy-map COPP-PM ! !Assign the action of ‘drop’ to the COPP-CM-TTL-0/1 !class. This will cause all packets in the class to be !dropped before they are processed by the CPU. ! class COPP-CM-TTL-0/1 drop ! !Assign the COPP-PM policy map the aggregate control- !plane interface in the inbound direction. ! control-plane service-policy input COPP-PM !
Some protocols make legitimate use of low TTL values; eBGP is one such protocol. Where required, the CoPP configuration will need to be altered to allow for the proper operation of these protocols. The following configuration builds on the previous example to allow eBGP packets with a TTL value of one.
! !Add an ACL to match EBGP packets (179/tcp) from !trusted sources with a TTL of one. ! ip access-list extended ACL-MATCH-TRUSTED-EBGP permit tcp host 192.168.1.101 any eq bgp ttl eq 1 permit tcp host 192.168.1.101 eq bgp any ttl eq 1 ! !Add an ACL to match any IP packet with TTL values !of zero or one. ! ip access-list extended ACL-MATCH-TTL-0/1 permit ip any any ttl eq 0 permit ip any any ttl eq 1 ! !Define a class that contains packets matching !the ACL ACL-MATCH-TRUSTED-EBGP. ! class-map match-all COPP-CM-EBGP match access-group name ACL-MATCH-TRUSTED-EBGP ! !Define a class that contains packets matching !the ACL ACL-MATCH-TTL-0/1. ! class-map match-all COPP-CM-TTL-0/1 match access-group name ACL-MATCH-TTL-0/1 ! !Create the policy map that will be applied to !the control-plane. ! policy-map COPP-PM ! !Assign the COPP-CM-EBGP class to this policy map. !There is no action, which will cause packets in this !class to be permitted by CoPP and processed by the CPU. ! class COPP-CM-EBGP ! !Assign the action of ‘drop’ to the COPP-CM-TTL-0/1 !class. This will cause all packets in the class to be !dropped before they are processed by the CPU. ! class COPP-CM-TTL-0/1 drop ! !Assign the COPP-PM policy map the aggregate control- !plane interface in the inbound direction. ! control-plane service-policy input COPP-PM !
Although CPPr offers a control plane subinterface specific to packets to be processed by the local network device, administrators are advised to apply the policy map to the aggregate control plane interface as shown in the preceding configuration. This configuration will ensure that both transit packets and packets to be processed locally with TTL values of zero and one will be dropped uniformly.
The show policy-map control-plane command will display the number of packets that have been matched by each class map within the applied policy map. The following sample output displays the number of packets that were dropped by the COPP-PM policy.
Router#show policy-map control-plane Control Plane Service-policy input: COPP-PM Class-map: COPP-CM-EBGP (match-all) 8 packets, 602 bytes 5 minute offered rate 0 bps Match: access-group name ACL-MATCH-TRUSTED-EBGP Class-map: COPP-CM-TTL-0/1 (match-all) 144 packets, 7776 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group name ACL-MATCH-TTL-0/1 drop Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Router#
The following show access-lists output displays the corresponding number of packets that matched the access list ACL-MATCH-TTL-0/1, which was used as part of the preceeding CoPP configuration.
Router#show access-lists Extended IP access list ACL-MATCH-TRUSTED-EBGP 10 permit tcp host 192.168.1.101 any eq bgp ttl eq 1 20 permit tcp host 192.168.1.101 eq bgp any ttl eq 1 (8 matches) Extended IP access list ACL-MATCH-TTL-0/1 10 permit ip any any ttl eq 0 20 permit ip any any ttl eq 1 (144 matches) Router#
As displayed, there were 144 packets matched and then dropped by the access list ACL-MATCH-TTL-0/1, which corresponds to the value shown in the previous show policy-map control-plane output.
Flexible Packet Matching (FPM) can be used to filter IP packets based on TTL value. FPM can be leveraged to protect both the local network device and downstream network devices from TTL expiry attacks through either rate limiting or complete filtering of packets with low TTL values.
Starting in 12.4(4)T, Flexible Packet Matching can be used to filter on specific fields within the IP packet. Included in those fields is the TTL value of the packet. The following configuration example illustrates the use of FPM to drop IP packets with TTL values of 15 or less.
! !Load the Protocol Header Description File (PHDF) for IP. ! load protocol flash:ip.phdf ! !Create access-control class map to match IP packets with a !TTL below 16. ! class-map type access-control match-all FPM-CM-MATCH-TTL-LT-16 match field IP ttl lt 16 ! !Create a policy map with a single class, !FPM-CM-MATCH-TTL-LT-16. Packets in that class will be dropped. ! policy-map type access-control FPM-PM-DROP-TTL-LT-16 class FPM-CM-MATCH-TTL-LT-16 drop ! !Apply the new policy map to the FastEthernet0 interface !in the inbound direction. ! interface FastEthernet0 service-policy type access-control input FPM-PM-DROP-TTL-LT-16 !
More information on using Flexible Packet Matching is available in the Flexible Packet Matching Deployment Guide.
The following show policy-map type access-control interface fa0 output shows the 75,029 packets that were dropped by the FPM policy and applied to the FastEthernet0 interface.
Router#show policy-map type access-control interface fa0 FastEthernet0 Service-policy access-control input: FPM-PM-DROP-TTL-LT-16 Class-map: FPM-CM-MATCH-TTL-LT-16 (match-all) 75029 packets, 10053886 bytes 5 minute offered rate 14000 bps, drop rate 14000 bps Match: field IP ttl lt 16 drop Class-map: class-default (match-any) 1288996 packets, 118831931 bytes 5 minute offered rate 8000 bps, drop rate 0 bps Match: any Router#
The Cisco Catalyst 6500 Series and Cisco 7600 Series Supervisor Engine 32 and Supervisor Engine 720 support platform-specific, hardware-based rate limiters (HWRLs) for special networking scenarios. These hardware-based rate limiters are called "special-case" rate limiters because they cover a specific predefined set of IPv4, IPv6, unicast, and multicast DoS scenarios. The TTL-Failure General Rate Limiter can be used to rate-limit unicast or multicast packets that fail the TTL check (i.e., packets with TTL values less than or equal to one).
Hardware Rate Limiters, specifically the TTL-Failure rate limiter, can only be used to protect the local device against TTL expiry attacks. HWRLs cannot protect downstream network devices from TTL expiry attacks.
The following command configures a Catalyst 6500 IOS Switch to rate-limit the TTL failure messages that it generates to 500 packets per second (pps) with a burst of ten packets:
Switch(config)#mls rate-limit all ttl-failure 500 10
Note: The TTL-failure rate limiter is a shared rate limiter, and its configured rate will be shared with the no-route, RPF failure, and ICMP Unreachable rate limiters.
To confirm the setting of the TTL-failure rate limiter, issue the show mls rate-limit command; the following output is example output from this command.
Switch#show mls rate-limit Sharing Codes: S - static, D - dynamic Codes dynamic sharing: H - owner (head) of the group, g - guest of the group Rate Limiter Type Status Packets/s Burst Sharing --------------------- ---------- --------- ----- ------- MCAST NON RPF Off - - - MCAST DFLT ADJ On 100000 100 Not sharing MCAST DIRECT CON Off - - - ACL BRIDGED IN On 500 10 Group:1 S ACL BRIDGED OUT On 500 10 Group:1 S IP FEATURES Off - - - ACL VACL LOG Off - - - CEF RECEIVE Off - - - CEF GLEAN On 10000 10 Not sharing MCAST PARTIAL SC On 100000 100 Not sharing IP RPF FAILURE Off - - - TTL FAILURE On 500 10 Not sharing ICMP UNREAC. NO-ROUTE Off - - - ICMP UNREAC. ACL-DROP Off - - - ICMP REDIRECT On 100 10 Not sharing MTU FAILURE Off - - - MCAST IP OPTION Off - - - UCAST IP OPTION Off - - - LAYER_2 PDU Off - - - LAYER_2 PT Off - - - IP ERRORS Off - - - CAPTURE PKT Off - - - MCAST IGMP Off - - - MCAST IPv6 DIRECT CON Off - - - MCAST IPv6 *G M BRIDG Off - - - MCAST IPv6 *G BRIDGE Off - - - MCAST IPv6 SG BRIDGE Off - - - MCAST IPv6 ROUTE CNTL Off - - - MCAST IPv6 DFLT DROP Off - - - MCAST IPv6 SECOND. DR Off - - - Switch#
For more information, see Hardware-Based Rate Limiters on the PFC3.
Currently, there is no counter associated with these Hardware Rate Limiters; as a result, there is no syslog message or SNMP trap when a given type of traffic crosses a rate limiter threshold. Hardware Rate Limiter information is available through the use of the show mls statistics command on systems with Policy Feature Cards (PFC) 3B or PFC-3BXLs.
Switch#show mls statistics Statistics for Earl in Module 7 L2 Forwarding Engine Total packets Switched : 1741460623 L3 Forwarding Engine Total packets L3 Switched : 1702442813 @ 0 pps Total Packets Bridged : 7720 Total Packets FIB Switched : 1571225488 Total Packets ACL Routed : 0 Total Packets Netflow Switched : 1 Total Mcast Packets Switched/Routed : 217239 Total ip packets with TOS changed : 217253 Total ip packets with COS changed : 2 Total non ip packets COS changed : 0 Total packets dropped by ACL : 123591 Total packets dropped by Policing : 0 Total packets exceeding CIR : 0 Total packets exceeding PIR : 0 Errors MAC/IP length inconsistencies : 0 Short IP packets received : 0 IP header checksum errors : 0 TTL failures : 828 MTU failures : 0 Total packets L3 Switched by all Modules: 1729461809 @ 10 pps
In the preceeding example, 828 packets with TTL values less than or equal to one have been processed by the CPU.
The purpose of this document is to provide several options that are currently available within IOS devices to mitigate the adverse impacts of TTL expiry attacks. All of these mitigation techniques should be performed in controlled lab environments prior to deploying these configurations in a production setting.
This document is part of the Cisco Security Center.
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.