TTL Expiry Attack Identification and Mitigation

Summary

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

 

operation of the SPD state check diagram

 

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.

TTL Expiry Attacks

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.

Identification and Mitigation Technique Overview

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.

TTL Filtering in Router ACLs

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.

Mitigation

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.

Identification

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

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.

Mitigation

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.

Identification

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 

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.

Mitigation 

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.

Identification

 

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# 

CPU Hardware Rate Limiters  

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.

Mitigation

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.

Identification

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.  

Conclusion

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.

Back to Top

Cisco Security Center