Ttl-security
Maitane Roderiques
By default, IOS sends BGP messages to EBGP neighbors with an IP time-to-live (TTL) of 1. (This can be adjusted with ebgp-multihop attached to the desired neighbor or peer group under BGP configuration.) Sending BGP messages with a TTL of one requires that the peer be directly connected, or the packets will expire in transit. Likewise, a BGP router will only accept incoming BGP messages with a TTL of 1 (or whatever value is specified by ebgp-multihop), which can help mitigate spoofing attacks.
A very simple solution to this, as discussed in RFC 5082, is to invert the direction in which the TTL is counted. The maximum value of the 8-bit TTL field in an IP packet is 255; instead of accepting only packets with a TTL set to 1, we can accept only packets with a TTL of 255 to ensure the originator really is exactly one hop away. This is accomplished on IOS with the TTL security feature, by appending ttl-security hops to the BGP peer statement.
Only BGP messages with an IP TTL greater than or equal to 255 minus the specified hop count will be accepted. TTL security and EBGP multihop are mutually exclusive; ebgp-multihop is no longer needed when TTL security is in use.
As of 2007, there is new RFC 5082 describing the TTL-Security feature. The RFC You mentioned is obsolete although the idea stays the same. Just thought it would be a good idea to correct this because at the time you wrote the article, new RFC was already out ;)
255 is the highest possible value for the TTL field, which is eight bits in length. It is illegal for a router to forward an IP packet to a new hop without decrementing the TTL value by one. Therefore, it can be deduced that any packet with a TTL of 255 was originated on the local segment.
There are so many people that are confused on this subject. This helped me diagnose but was a little hard to put together (or just the way it read to me). In using his example...I would put the command "neighbor x.x.x.x ttl-security hops 254" presuming that I wanted the router to drop anything less than 254. This is NOT the case and can be proven with "show ip bgp nei inc TTL" after the adjacency comes up. It actually states the expected hop count.
We need to configure it on both peers, right? I have one case like this:configure ebgp-multihop on one peer and configure ttl_security hops on another peer, can these two peers be established? If not ,why?
You guys can lab it up.But in real life we will never want to use ebgp on one peer and ttl-secuity on other peer, i used it to illustrate the check router performs when configured with TTL-security feature, which is TTL in Packet received should be equal or greater than 255-HOPCOUNT+1.
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.
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.
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.
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
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.
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.
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.
My router is peered to another via BGP. Pings are allowed but traceroute is not. I am trying to implement ttl security hops, but the configuration causes my peers to drop. It doesn't matter if I set the hop count from 1 to 250, same results. Is traceroute traffic required to use this feature?
The issue with running the ttl-security only on one side, is that the eBGP neighbor not configured with this feature will send a TTL of 1 by default instead of TTL of 255 when the ttl-security feature is configured. This will cause the neighbor configured with the ttl-security feature to silently drop the packets and the BGP session not to come up.
By default OSPF sends packets with a TTL set to 1 (as can be seen in the capture below). Everytime a packet is routed its TTL is decremented. In the above diagram the attacker is sending a TTL with a value of 2, and using the same source address as R2. When R1 recieves the packet, it decrements the TTL by 1 and sends it to R1. Consquently R1 will recieve the packet and think it is from R2.
The OSPF process may respond to these packets causing potential instability. Even if the packet is meaningless it is still processed by the control plane, and consequently the attacker could cause a denial of service attack by sending large amounts of packets to R1.
The OSPF TTL Security Check sends the packet with a TTL set to 255 and by default will not accept a packet with a TTL less than 255. However an optional parameter can be set to determine by how many counts the TTL can be decremented (set to 1 by default). If this were set to 55 for example, the OSPF process would accept packets with a TTL of 200-255.
The largest possible TTL is 255, so now the attacker is unable to send a larger TTL. For example the attacker would have to send a TTL of 256 in order for R1 to recieve it as 255 (after being decremented by 1 by R2).
Bear in mind that in order for an adjecency to form, all OSPF neighbours require matching TTL values. Implementing the TTL Security Check may therefore cause a neighbour adjacency to drop should the dead timer expire.
The OSPF TTL Security feature can be enabled on the general OSPF router process (for all interfaces) and then selectively disabled. Alternatively it can be just enabled on on selective interfaces directly:
Enabling TTL on all interfaces does not include virtual-links, or OSPF sham links. To enable it on a virtual link, use the area virtual-link ttl-security command. To enable it on a sham link use the area sham-link ttl-security command.
OSPF is a reliable and scalable dynamic routing protocol. However, the protocol has some weaknesses that may get exploited by attackers. For example, hackers can run remote CPU-utilization-based attacks, which can disrupt OSPF adjacencies. Here comes OSPF TTL Security Check that can help protect against those kinds of attacks by allowing the processing of OSPF packets with particular TTL values.
OSPF TTL Security Check is a technique used to protect against CPU utilization-based attacks targeting OSPF-enabled routers. When this feature is enabled, OSPF packets get sent with a TTL value of 255, and OSPF processes routing packets that have a valid TTL value only.
Cisco IOS allows enabling OSPF TTL Security Check either globally on an OSPF process or on a per-interface basis. When you activate this feature without specifying the maximum hop count allowed, the router sets the TTL value of generated OSPF packets to 255 and rejects received OSPF packets with TTL values greater than 1.
Moreover, you can activate OSPF TTL Security Check on virtual links and sham links using the area virtual-link ttl-security and area sham-link ttl-security commands, respectively.
Cisco IOS supports configuring TTL Security Check on a per-interface basis. The ip ospf ttl-security command to activate this feature on a specific interface. To specify the maximum hop count allowed, use the ip ospf ttl-security hops hop_count, where hop_count is a number between 1 and 254.
c80f0f1006