Summary

  • GTSM starts protected protocol traffic at TTL 255 and lets a receiver compare the remaining value with the configured distance to its peer before expensive protocol processing.
  • The receiver may isolate or drop packets that fail that proximity test, but a valid TTL does not authenticate the sender, validate a route or defeat an attacker already on the trusted path.

A small field becomes an admission boundary

BGP runs over TCP, but a plausible source address is not proof that a packet came from the configured neighbor. An off-path attacker can send forged control traffic toward a router and make the control plane spend bandwidth and CPU deciding what it means. RFC 5082's Generalized TTL Security Mechanism, or GTSM, uses a fact that routers normally alter in transit: IPv4 TTL and IPv6 Hop Limit fall at each forwarding hop.

For directly connected peers, a GTSM sender sets the field to 255, the maximum value. A receiver expecting a one-hop neighbor requires the packet to arrive with 255. A packet launched farther away cannot normally recover the decremented value. Multi-hop deployments can accept a configured range below 255, but the wider that permitted diameter becomes, the more locations can produce a plausible value.

The standard separates packets into three categories. A packet associated with a protected session and inside the expected TTL range is Trusted. One associated with the session but outside the range is Dangerous. A packet that cannot be associated with a registered protected session is Unknown. These labels are operational classifications, not declarations about a person's or network's intent.

That distinction controls scarce resources. By default, Dangerous packets should not compete with Trusted or Unknown packets and may be dropped. GTSM processing must not drop Trusted or Unknown packets merely because of this classification. The receiver therefore gains a narrow power: it can reserve protocol attention for traffic whose network distance is plausible.

Authorization is configured, not inferred

RFC 5082 makes GTSM optional for existing protocols and defines no generic automatic negotiation. Operators configure it per peer, and RFC 7454 notes that BGP TTL security has to be configured at both ends. This is an explicit operating agreement: which session is protected, what distance is expected, how related ICMP errors are handled and what happens when the path changes.

The sender must originate protected protocol packets with TTL 255 and avoid an internal forwarding step decrementing them. The receiver must map the observed value to the correct session before applying its policy. Tunnels and multi-hop designs complicate the calculation because decapsulation and forwarding can change where a decrement occurs. A path migration can therefore break a previously correct threshold without changing either peer's identity.

The immediate beneficiaries are both peers. Off-path spoofed traffic is less able to compete with plausible control packets for the receiver's CPU or line-card bandwidth, which can make the session and its surrounding routing system more resilient. The cost is shared too: both parties carry configuration, monitoring and change-control work, while the receiver must preserve enough telemetry to explain why a packet was classified.

Proximity is not authentication

The name Trusted can invite a dangerous overclaim. RFC 5082 explicitly says GTSM is not a substitute for authentication. An attacker on the wire, inside the accepted hop diameter or otherwise able to meet the topology assumption may still spoof or replay traffic. A valid TTL does not prove ownership of a source address, authorize a BGP UPDATE or establish that an advertised route is legitimate.

Maximal protection also depends on strict ingress filtering. GTSM narrows the set of plausible origins; it does not repair every edge that admits spoofed source addresses. Nor does it inspect route policy. TCP protection, control-plane filtering, prefix and AS-path filtering, and monitoring remain separate controls with different evidence.

This boundary matters in incident response. A rising Dangerous count may show remote forged traffic, a stale distance configuration or a tunnel change. It does not by itself identify an attacker. A fall to zero may reflect effective filtering, no attack, a broken counter or traffic newly falling into Unknown. Leadership should demand observations that distinguish those explanations instead of turning a topology test into a verdict about identity.

Evidence and limits

RFC 5082 defines the TTL/Hop Limit procedure, the three classifications, default resource treatment, optional per-peer configuration, ICMP handling, topology assumptions and limits. RFC 7454 applies the mechanism to BGP operational security and recommends it for directly connected peerings. RFC 4271 describes BGP's TCP session, while RFC 4272 explains relevant security exposure. The framing of admission authority, beneficiaries and governance cost is analysis.

The sources do not prove deployment by any named operator, establish a universal multi-hop distance or show that a valid TTL authenticates a peer. They do not claim that GTSM alone prevents route leaks, false announcements, on-link attacks or every session reset. Those are explicit unknowns, not gaps to fill with confidence.

Sources