IP TTL Security : Why and How?

IP TTL Security

TTL (Time-To-Live) is a field in the IPv4 header. TTL field is of 8 bits and so it can take a maximum value of 255. When a sender sends out a packet, it sets the TTL value (usually as 64) in the IP header. Each router that receives this packet, decreases the TTL value by 1 before forwarding the packet towards the destination. A router decrements the TTL only if it is forwarding the packet to another router/host. A router do not forward and may discard a packet received with TTL 1. In such a case, a router may send an ICMP unreachable back to the sender. So in effect, TTL is used to limit the number-of-hops a packet can traverse in a network. For example, if a sender sets the TTL to 2, the packet can be forwarded by only one router. In other words, TTL is used to stop a packet from forwarding, forever in a routing loop.


With this information, let us look at how a packet’s TTL looks when a receiver receives an IP packet. If a packet is sent out to a directly connected router or host, the packet is received without any change in the TTL value. See figure 1.




If a packet is sent out to a router which is behind the directly connected router, the receiver will receive the packet with TTL value 1 less than what the sender sets in the packet. In figure 2, R1 sends a packet with TTL 64 and it reaches router R3 with TTL 63. See figure 2.




Now the above figures provide a very interesting observation. If the receiver can figure out the number of hops between the sender and himself, he can predict the TTL in the received packet if he knows the starting TTL. I will go on a little further and add that if receiver has such a knowledge, he can discard packets with any TTL other than the expected one, without even looking at the packet’s contents. So for example in figure 2, if R3 knows that R1 is sending out packets with TTL 64 and R1 is behind router R2, then R3 can discard packets from R1 if the TTL in received packets are not 63. Now let us look at how this interesting property of TTL can be used for our advantage.


Routers establish peering with the adjacent routers for most of the networking protocols. Though routers uses authentication for control packets but an attacker, sitting somewhere in the network, can still send out spoof packets and make router spend critical resources in processing these packet.


Routers sending protocol packets use a TTL of 1 as they are sending this to adjacent routers. Can this be spoofed? First impression is Naah!, it is not possible. This is because that packet will get discarded if someone sitting multiple hops away sends a spoofed packet with TTL 1. But in reality, this is possible.


Let us assume that this someone is really smart and somehow (May be using ICMP) figures out the number of hops between him and the target router. He then sends a packet out with TTL set to the number-of-hops + 1. Now the spoofed packet will reach the target router with a TTL of 1. See figure 3. Target router R2 receives a packet with TTL 1 from both R1 and R5.




Now what? Whatever we have been calling special is not special. Is it? No. I did not say that. Can you guess what TTL value should sender use to make sure that it is impossible for the attacker to spoof a packet? I am sure you got it right. The TTL value must be set to the maximum i.e. 255. Now with this new TTL value, let us again look at the above scenario. A router would expect a packet to come with a TTL of 255. It is possible for all adjacent routers to achieve this if they send out their packet with a TTL of 255. Can the attacker’s packet reach the router with a TTL of 255? No. They cannot. TTL security won’t help much if attacker is on the same LAN but in such a case, we will have far bigger problems anyway. See figure 4. Target router R2 receives packet from R1 with TTL 255 but a packet sent by R5 will reach with a TTL of 253. In this case, target router R2 can discard packets received with any TTL other than 255.




Ability to drop invalid packets based on the expected TTL value is termed as “IP TTL security”. Is not this a simple and effective technique?


This technique can also be used when routers are multiple hop away if network administrator can configure the receiver with a correct expected TTL value.


In IPv6, TTL field is replaced with hop-limit field. The overall functionality of hop-limit is same as TTL. So technique mentioned here can be applied with hop-limit to provide similar security in IPv6 networks.


Most of the vendors support the IP TTL security technique for various protocols. Most of these vendors also provide configuration to enable TTL security on per protocol on per interface basis. I have seen vendors supporting this for OSPF, PIM, BFD etc.




Bharat Joshi is a co-founder of VuNet Systems (www.vunetsystems.com). In the past, he worked as a Product Technical Architect in Infosys Ltd. Bharat has more than 15 years of industry experience in design and development of router software including various networking protocols. Bharat has contributed in several international forums including IETF, IEEE and SANOG. He is the author of multiple IETF standards related to DHCP and PIM-SM. He maintains a personal blog Bite-The-Bytes (http://bite-the-bytes.blogspot.com/).

What do you think about this article?


  1. Informative article, but using this technique will also stop any legitimate traffic coming in if it has been routed an other path than the expected as this alomost certainly will have a different TTL value. This means that even if the network is “self healing” and reroutes the traffic, this solution will reject the traffic stopping the communication.

    • I agree that there might be such an issue if IP TTL security is used in a multi-hop environment. However, currently IP TTL security is usually deployed in a single-hop LAN environment where adjacent routers are talking to each other. In such a case, there is no intermediate routers and so this issue cannot happen.

    • Could you use a modified spanning tree protocol software to have it dynamically updated? Not sure how hard that would be, or realistic depending on time frame.

      • I am not sure if I understood what you mean by ‘modified spanning tree protocol’.

        As the problem arises for the multi-hop case, It will be difficult to find the new TTL dynamically as the destination would not know about the new path. Though it can be done using ICMP or other protocols.

        Moreover, as its related to security, I think it is better configured statically.

  2. Very cool and informative article on the life of a packet.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

About us

RouterFreak is a blog dedicated to professional network engineers. We
focus on network fundamentals, product/service reviews, and career advancements.


As an Amazon Associate, I earn from qualifying purchases.

RouterFreak is supported by its audience. We may receive a small commission from the affiliate links in this post, at no extra cost to our readers.