Once upon a time reading some CCIE paper at work I asked myself a question : “Why would someone bother to invent ttl-security and even write RFC 5082 The Generalized TTL Security Mechanism (GTSM) about it when multi-hop EBGP feature provides the same end result ?” . First some background. For some reasons BGP peering was envisioned as TCP connection between directly connected routers, by default. To proceed with this design (worth checking BGP RFCs if it was actually an obligation) vendors (Cisco,Juniper and even Fortinet) implemented all BGP protocol communication using TTL=1 in TCP packets being exchanged. As the logical consequence of this if a router was placed more than 1 hop away from its peer BGP session could not be established. To provide for such set ups when peers are many hops away the ebgp-multihop term was coined – on configuration level you can specify that BGP peer is that hops far away and override this limit of "directly connected".

What happens in fact is that when you specify such multi-hop BGP peer the router starts sending BGP packets with TTL being equal to the number of hops you set . That means if I set peer to be 3 hops away and some attacker tries to spoof legit peer’s IP but is 4 hops away – such attack won’t succeed cause my router will receive spoofed BGP packets ok but will send replies with TTL of 3 which will expire just 1 hop away from the attacker.

Questionable , but security . So why ttl security?
This feature indeed enforces that BGP peer is no more than given hops away . And here comes the difference – it enforces it inbound . It works this way – after you enable ttl security on the BGP peer session and specify how many hops away this peer is allowed to be, your router checks incoming TCP packets from this peer and does this simple calculation ; configured value <= 255 – hops-away-to-peer , if it holds true your router goes on with establishing BGP session , if not – session is shut down. Regarding outgoing TTL values – may be it is Cisco-only thing, may be not , but the moment you enable ttl security for some BGP peer on Cisco the router itself starts sending BGP-related packets to this peer with initial ttl being equal to 255. I guess it is logical that if you enforce on your side ttl security the peering side will want to do the same.

When ttl rule is broken we see in the debug session:
Dec 27 19:08:04.103: %BGP-4-INCORRECT_TTL: Discarded message with TTL 1 from 124.2.11.15

And neighbor status is:

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
124.2.11.15   4 13462      33      63        0    0    0 00:04:31 Idle

sh ip bgp neighbors 124.2.11.15

BGP neighbor is 124.2.11.15, remote AS 13462, external link BGP version 4, remote router ID 0.0.0.0 BGP state = Closing

Additional resources:
- Fortigate BGP cookbook of example configuration and debug commands.
- Fortigate BGP - configure and debug.

Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ not to miss what I publish on Linkedin, Github, blog, and more.