OSPF TTL Security Check

The OSPF TTL security check is a mechanism that protects OSPF against remote attacks. When you enable this feature, OSPF will send packets with a TTL of 255 and rejects any packets with a TTL that are smaller than a configured threshold. By default, once you enable this it will only accept packets with a TTL of 255. Since routing decrements the TTL by one, this means that only OSPF packets from directly connected devices will be accepted.

Let’s look at an example. I will use the following topology:

ospf r1 r2 area 0 h1

Above we have two routers running OSPF, behind R2 is an attacker that wants to attack R1. It will do so by sending spoofed unicast OSPF packets destined to 192.168.12.1:

ospf r1 receives spoofed packet

H1 sends a spoofed OSPF, impersonating R2 and destined to R1. When R2 forwards this packet, the TTL will be decreased by 1 and R1 will receive the IP packet. Even if OSPF rejects the packet because the content is garbage, it still has to be processed by the control plane. If H1 sends enough packets, it might succeed in overloading the router’s control plane.

To stop a remote attack like this, we can implement the OSPF TTL security check.

By default, all OSPF packets have a TTL of 1 as you can see in the packet capture below:

ospf packets ttl 1

When TTL security check is enabled, OSPF will only accept packets with a certain TTL value, 255 by default. When it receives packets with a lower TTL, they will be discarded.

Configuration

Let’s give this a try. We can enable this globally for all interfaces like this:

R1(config)#router ospf 1
R1(config-router)#ttl all-interfaces
You can also enable TTL security check on the interface level with the ip ospf ttl-security command.

As soon as you enable this on one router, the neighbor adjacency with R2 will drop once the dead timer expires. Why? We can see the reason when we enable a debug:

R1#debug ip ospf adj
OSPF adjacency debugging is on

On the console of R1, you will see this message:

R1#
OSPF-1 ADJ   Gi0/1: Drop packet from 192.168.12.2 with TTL: 1

R1 will now only accept packets with a TTL of 255 and since R2 is sending OSPF packets with a TTL of 1, they are discarded. Let’s enable TTL security on R2 as well:

R2(config)#router ospf 1
R2(config-router)#ttl all-interfaces

The OSPF neighbor adjacency will recover and both R1 and R2 are now sending OSPF packets with a TTL of 255 to each other:

ospf ttl 255

Here’s a packet capture where you can see the new TTL value:

ospf packets ttl 255

Wireshark Capture OSPF TTL Security Check

Above you can see that the TTL is now 255. Since this is the highest value possible for the TTL field, it is impossible for H1 to send a spoofed unicast OSPF packet to R1, preventing a remote attack like this.

The TTL security check is not applied to virtual links or sham links by default. If you want to use this, then you can use the area virtual-link ttl-security or area sham-link ttl-security commands.

By default, the lowest TTL that OSPF TTL security check will accept is 255. You can add the hops parameter to use another value. For example, if you use ttl-security all-interfaces hops 100 then OSPF will accept all OSPF packets with a TTL of 155-255.

That’s all there is to it. You can read more about TTL security in the following RFC: The Generalized TTL Security Mechanism (GTSM)

Configurations

Want to take a look for yourself? Here you will find the configuration of each device.

R1

hostname R1
!
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.12.1 255.255.255.0
!
router ospf 1
 ttl-security all-interfaces
 network 192.168.12.0 0.0.0.255 area 0
!
end

R2

hostname R2
!
ip cef
!
interface GigabitEthernet0/1
 ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
 ip address 192.168.2.254 255.255.255.0
!
router ospf 1
 ttl-security all-interfaces
 network 192.168.12.0 0.0.0.255 area 0
!
end

Forum Replies

  1. I guess if the person spoofing is capable of spoofing a TTL of 2, they are also capable of spooing a TTL of 256 which (with the default config) would effectively override this safety mechanism in this scenario :slight_smile:

    Unless the TTL is an 8 bit field, so 255 is the highest value!

  2. Hello Chris

    Yes, you are correct that the TTL field is an 8 bit field, so the highest value can be 255.

    I hope this has been helpful!

    Laz

  3. Hello again Chris.

    You must remember that the value configured in the ttl-security all-interfaces hops command is the number of allowed hops and not the actual value of the TTL field. The value is essentially a threshold.

    The default value is actually 0. This means that it will accept any values of TTL equal to or greater than 255-0. Since routing decrements the TTL by one, this means that only OSPF packets from directly connected devices will be accepted.

    If this threshold is configured at 100 hops, then only packets with a TTL higher than 255-100 = 155 wil

    ... Continue reading in our forum

  4. Hi Rene,
    Hopefully you are doing good…

    I have one question When i am going through you CCIE R&S Written Table of Contents here why 3.6e:Path Preference & 3.6f:Operations not showing anything when i am trying to click there no page is opening so are you want to add any content there or its mistake by you? then 3.6g:Convergence and Scalability having content because when i clicking the + button the content is coming.

    For your reference i attached the screenshot as well.

    //cdn-forum.networklessons.com/uploads/default/original/1X/9d369eba8402951a81e414f54c915ad9bd1

    ... Continue reading in our forum

  5. Hi Rene,
    Thanks for replying … if you add any thing there defenately I will go through the point…

    Thanks & Regards,
    Arindom

3 more replies! Ask a question or join the discussion by visiting our Community Forum