GTSM is one of the internet's most elegant hacks: a single-field trick that turns an ancient IP header quirk into a robust defense for BGP and other single-hop protocols. It replaces (and formalizes) an earlier experimental spec, RFC 3682, and it works by exploiting the one thing about the IP Time-To-Live field that cannot be forged from far away: routers decrement it, and they cannot un-decrement it.

The problem. BGP sessions run over TCP between directly-connected routers. A remote attacker who can spoof the peer's source IP can flood a router with SYNs, RSTs, or bogus BGP messages, chewing CPU on TCP state and, worse, potentially tearing down peerings. MD5 authentication (RFC 2385) helps against session hijacking, but validating an MD5 signature is itself expensive — an attacker who fires millions of bogus packets can still exhaust the control plane just by making the router check them. Route processors on carrier-grade routers are often surprisingly weak CPUs; a modest DDoS aimed at TCP/179 was, and still is, a real operational threat.

The trick. For a protocol that is only ever spoken between adjacent boxes, set the outgoing IP TTL (or IPv6 Hop Limit) to 255, and configure the receiver to drop the packet unless the arriving TTL is 255 (or, more generally, >= 255 - hops). Since every router on the path must decrement TTL by at least one, any packet originating more than N hops away arrives with a TTL lower than the threshold. The check is a single integer comparison in the fast path — often done in silicon before the packet ever reaches the CPU.

Why this is stronger than it looks. The TTL field is not spoofable across the internet. You can lie about your source address, your TCP flags, your MD5 key attempt — but you cannot make a packet you launched from 12 hops away arrive with TTL 255. To defeat GTSM, an attacker must be on the same L2 segment as the victim (or must have compromised a directly-adjacent router). That collapses the threat surface from "the entire internet" to "the local wire," which is precisely the surface operators can control with physical and link-layer security.

Design decisions worth noting.

• Send 255, check on receive. The RFC deliberately does not require negotiation. Either end can start sending TTL 255 unilaterally; only the receiver's check matters. This made deployment trivial in an era where you couldn't count on your peer upgrading.
• Generalized to N hops. Though most famous for eBGP-multihop-of-1, the "generalized" part of the name matters: GTSM permits configuring an expected hop count, so it also protects LDP, MSDP, and multi-hop eBGP sessions between loopbacks a few hops apart.
• Explicitly not a cryptographic control. The RFC is careful to say GTSM is a filter, not authentication. It complements MD5/TCP-AO; it doesn't replace them. The threat model it addresses is resource exhaustion and off-path injection, not on-path tampering.
• IPv6 parity. The mechanism applies identically to the IPv6 Hop Limit, which was one motivation for restating RFC 3682 as a Standards Track document.

Why it still matters. Every major router vendor implements GTSM (Cisco calls it ttl-security, Juniper multihop ttl), and it is essentially universal on internet exchange peerings today. It is also a lovely teaching example of defense in depth done cheaply: a two-line config change that pushes an entire class of attack down to hardware-speed drops. When you next design a protocol between adjacent nodes, ask whether a TTL check would save you a lot of authentication cost.