The ipTTL and ipTotalLength information elements and how they are used for network traffic analysis

IPFIX provides a sufficient level of information on several network traffic parameters so that we can understand traffic structure.

IPFIX ElementID ipTTL and ipTotalLength are primarily related to network performance and network attacks. Let’s look at how to monitor and collect them on Cisco IOS devices.

1. ipTTL – IPFIX ElementID

The IPFIX Information Element 192 value corresponds to the Time to Live (TTL) field in the IPv4 packet header. The TTL field is 8 bits long, giving us a maximum value of 255. For IPv6, the value of the information element matches the value of the Hop Limit field in the IPv6 packet header.

Time-to-Live (TTL)

TTL is a mechanism that prevents packets from looping endlessly in the case of routing loops. Without this mechanism, packets would be sent endlessly between the same routers. Figure 1 shows the location of the 2B Total Length and 1B TTL fields in the IPv4 header.

Figure 1 – The Total Length and TTL in IPv4 Header

The TTL field in the packet header is set by the sending host. Its value depends on the operating system being used. For example, the Linux operating system sets the TTL to 64, while the Windows operating system generates a TTL of 128. Cisco, in its turn, generates IP packets with a TTL of 225.

The TTL value is decremented by 1 on each router (hop) before the packet is forwarded to the other interfaces. When a hop receives a packet with TTL set to 1 and the packet is not destined for the hop itself, the packet is dropped. In this case, the router sends IPv4: type 11: “Time Exceeded”, code 0: “time to live exceeded in transit” to the source IP of the packet.

The TTL value used by your OS can be easily checked by sending a ping to the return IP address. In the following example, the TTL value on the Linux system was temporarily changed from the default value of 64 to 1 using the following command:

$ sudo sysctl -w net.ipv4.ip_default_ttl=1

Figure 2 – ICMP Echo Replies with TTL value 1 while Pinging Loopback IP

Sending host (freepc) receives the “ICMP Time to live exceeded” message from the default gateway (router-lan) while the TTL is set to 1 when pinging noction.com

Figure 3 – Default GW Generates Time Exceed When TTL is set to 1

So why do we need to monitor IPFIX flows with a certain TTL value or hop count?

Firstly, the TTL should remain constant between two hosts in the backbone; if it does not, it could mean that the routing has changed. This could trigger an alert that is set for a particular TTL value.

Secondly, unauthorized NAT configured on end devices can pose a significant security problem as it can hide a number of hosts [1]. This, however, can be detected based on an unexpectedly lower TTL in flows. Every hop reduces the TTL by 1; therefore, the NAT presence can be effectively detected [1].

Finally, the TTL Expiry attacks can be detected based on a large number of flows with the ipTTL value set to 1. If an attacker sends a flood of packets with the TTL value set such that the packets expire on the switch, the switch is forced to generate many ICMP TTL Exceeded messages. [2]. This way, the CPU usage increases, and all the network services are affected.

To collect the first seen TTL/hop limit value fields in the IPFIX or NetFlow v9 flows, the following must be configured on Cisco IOS devices:

Router(config)# flow record FLOW-RECORD-1
Router(config-flow-record)# collect ipv4 ttl
Router(config-flow-record)# collect ipv6 hop-limit

To collect the lowest IPv4 TTL and IPv6 hop limit values seen in the lifetime of the flow:

Router(config)# flow record FLOW-RECORD-1
Router(config-flow-record)# collect ipv4 ttl minimum
Router(config-flow-record)# collect ipv6 hop-limit minimum

Similarly, the following example configures the highest value for IPv4 TTL and IPv6 hop limit seen in the flows as a nonkey field:

Router(config)# flow record FLOW-RECORD-1
Router(config-flow-record)# collect ipv4 ttl maximum
Router(config-flow-record)# collect ipv6 hop-limit maximum

2. IpTotalLength – Element ID 224

IPFIX IpTotalLength ElementID 224 reports the total length of IP packet. Monitoring packet length helps network admins identify performance issues caused by fragmented IP packets or small size packets.

For instance, packets need to be fragmented if the packet size exceeds the maximum transmission unit (MTU). In such cases, fragmentation can cause excessive retransmissions when fragments encounter packet loss, and reliable protocols such as TCP retransmit all of the fragments to recover from the loss of a single fragment [3].

On the other hand, too many small size packets add a great overhead for the network so the bandwidth is wasted.

Total Length

The Total Length is the length of the IP packet, measured in octets, including the internet header and data. This field allows the length of a datagram to be up to 65,535 octets.

To collect IPv4 total length of the first seen packet for Cisco IOS devices, the following must be configured:

Router(config)# flow record FLOW-RECORD-1
Router(config-flow-record)# collect ipv4 length total

To collect both the largest and smallest value for IPv4 length seen in the flow:

Router(config)# flow record FLOW-RECORD-1
Router(config-flow-record)# collect ipv4 length total maximum
Router(config-flow-record)# collect ipv4 length total minimum

The IPFIX flow shown in Figure 4 is captured by Wireshark. The TTL value set by the host 192.168.88.102 is 255, so the host is likely a Cisco router. The default TTL value has not been decremented, which means there are no additional hops between hosts 192.168.88.101 and 192.168.88.102.

Figure 4 – IPFIX Flow with IP TTL and IP total Length Information Elements

The destination TCP port is 22, meaning SSH is used to remotely manage a device with IP 192.168.88.101. The reported IP packet length is only 44B, and the flow consists of two packets. The presence of the SYN and ACK TCP flags confirms that the flow is part of a three-way TCP handshake.