BGP TTL Security, Pt. 2 (IOS-XE)
Last updated
Last updated
You may see BGP TTL Security referred to by its official name, GTSM (Generalized TTL Security Mechanism) from RFC 5082. GTMS, or TTL Security, uses the TTL value of a received packet to determine whether to drop the packet or accept it.
Let’s use our lab from the last article:
We’ll tear down the BGP session between R1 and R4, and then use TTL security so that the peering session can only be up to a maximum of 3 hops away.
The TTL Security command takes the maximum hop counts as a parameter. BGP subtracts the configured hop count from 256, and only accepts packets if they are at least that value.
An example will help. In this case, R1 and R4 are three hops away. We’ll configure the maximum hops as 3. 256 minus 3 = 253. So R1 and R4 will only accept the BGP packets if they have a TTL of 253 or higher.
You might wonder, why do we use 256 and not 255? A directly connected router would have a hop count of 1, and therefore the TTL would need to be exactly 255, right? So we would do 256-1=255. The router only decrements the TTL once it processes the packet and then forwards it to its next hop. We need the TTL value “on the wire” before decrementing takes place. Therefore we use 256 and not 255.
Where the TTL decrementation takes place can make this a little confusing. When the router receives a packet with 253 "on the wire", it decrements it by 1 and then technically preforms the TTL security check based on this value. However, I find it easier to understand by using 256 instead of 255. If it makes more sense to you, you can use (255 - hop count) instead of 256, but you will have to remember that the router decrements by 1 upon receiving the packet.
Let’s configure our peering session again, this time with ttl security.
Notice that we don’t configure ebgp-multihop this time. The ttl-security feature sets the TTL to 255 automatically.
Let’s look at a pcap taken on Gi1 of R1
The TTL values are the same as in the last article when we used ebgp-multihop with its default 255 hop count.
The difference now is if the TTL is lower than 253, R1 will reject the BGP session.
Let’s change the hop count on R1 to 2. This should instruct R1 to only accept the BGP session if the TTL is 254 or higher.
If I clear BGP on R1, the session to R4 will not come up
R1 tries to open the TCP session, but the TCP packets from R4 are rejected based on the TTL value.
Pop quiz: What will happen if we set both routers to a ttl-security hops of 5? Will they reject the packet because the TTL is not exaclty 251?
The neighborship comes up. This is because TTL security allows for a TTL value of at least (256 - hops). So as long as the TTL is 251 or above in this case, the peering session is established.
Let’s change this up even more. What will happen if we keep ttl-security hops 5 on R1, but we set R4 to use ebgp-multihop and remove ttl-security? Do you think the neighborship will still form? Pause to consider this before moving on!
The BGP session still comes up! The ttl-security feature is not a “negotiated” feature. It simply does a check on the packet’s TTL. By using the default ebgp-multihop hop count of 255, the packet from R4 is still originated with a TTL 255, so this passes R1’s configured ttl-security check.
So what is the difference right now when we use ebgp-multihop on R4, and ttl-security on R1? R4 is not inspecting the TTL value and dropping packets if they don’t have a certain TTL value.
Let’s push this a little bit further so you are solid on this feature. What is the minimum value we could use for ebgp-multihop on R4, with R1 still set to ttl-security hops 5? Pause to answer this before scrolling down.
The answer is 253.
R4 will send a packet with TTL=253. R3 decrements to 252 and sends to R2. R2 decrements to 251 and sends to R1. R1 accepts a TTL of at least 251.
In the next section we’ll breifly look at ttl-security on IOS-XR.
