Summary

  • GTSM sends protected BGP traffic with IPv4 TTL or IPv6 Hop Limit 255 and admits only values consistent with an approved network distance. It can reject implausibly distant spoofed packets before they consume scarce control-plane resources.
  • The remaining value proves neither peer identity nor message integrity. On-link and on-path attackers, tunnels, fragments and multihop trust diameters require separate controls; TCP authentication, ingress filtering and BGP policy retain independent jobs.
  • Operational proof must join both directions: outgoing 255, observed arrival values, configured threshold, earliest drop counter, TCP and BGP state, and route outcome. A configuration line or an Established session is not enough.

The first instinct during the outage is to widen the allowance. Two hops became three, so set ttl-security hops 3 and restore the session. That can be the correct repair, but it is not clerical. The change enlarges the network diameter from which traffic can satisfy the proximity test. An operator is changing a security boundary because routing changed under it.

GTSM is valuable precisely because it makes that boundary small and testable. Its mistake-resistant use begins with an austere proposition: a packet that has lost too much TTL could not have come from the approved nearby path. It ends there. Everything else—who sent the packet, whether the TCP segment is authentic, whether the BGP message is valid, whether the advertised route is permitted—belongs to another layer.

The evidence is the number left over

IPv4 calls the field Time to Live; IPv6 calls it Hop Limit. In routing practice, each forwarding hop reduces the eight-bit value. GTSM takes advantage of the ceiling: 255. A protected speaker originates its control packets at that maximum. A directly connected peer should therefore receive 255. A routed path consumes one unit at each forwarding hop, leaving a value that bounds how far the packet travelled.

Many implementations expose the contract as a permitted hop count. Cisco's cited IOS guidance describes accepting a value greater than or equal to 255 minus the configured count. The cited FRRouting command is neighbor PEER ttl-security hops NUMBER. Those surfaces are useful, but their counting convention, coexistence with multihop configuration and dynamic behavior are vendor facts, not universal syntax. The safe invariant is simpler: derive the expected arrival range for the exact platform, then test it on the wire.

Suppose the approved minimum is 253. A segment arriving with 254 or 253 lies inside the admitted diameter. One arriving with 252 lies outside. The receiver does not learn the sender's identity from those values. It learns that the packet appears to have crossed no more routed hops than the threshold permits, assuming ordinary decrement behavior and no topology that resets or conceals the field.

That assumption is the mechanism's strength and its limit. An attacker many hops away cannot normally send a packet that arrives with 255, because there is no initial value above 255 from which to pay those decrements. An attacker as close as the legitimate peer does not face that constraint. Proximity is expensive to counterfeit at distance and cheap to counterfeit nearby.

Admission happens before interpretation

BGP runs over TCP. A router under attack may spend scarce resources long before a plausible UPDATE reaches route policy: forwarding traffic to the control plane, queueing it, matching a socket, processing TCP flags or verifying cryptographic options. RFC 5082 was designed in part to separate implausibly distant protocol traffic before it competes for those resources.

The standard classifies packets associated with registered protected sessions as Trusted when the received value is inside the expected range and Dangerous when it is not. Traffic that cannot be associated with such a session is Unknown. This vocabulary can mislead if read as a moral verdict. “Trusted” means the GTSM distance test passed. It does not mean the payload is truthful or the speaker is authorized.

By default, GTSM processing must not discard Trusted or Unknown traffic merely under that classification and may discard Dangerous traffic. It should keep Dangerous traffic from competing with Trusted or Unknown traffic. The placement matters. A drop after the packet has already saturated a control-plane queue does not deliver the denial-of-service benefit promised by a line-rate or forwarding-plane classifier.

Evidence must therefore name the earliest effective stage. A counter in the BGP daemon can prove that the daemon noticed a TTL failure. It cannot prove that forged traffic was excluded before consuming CPU. A hardware or forwarding-plane counter, control-plane policy counter, kernel visibility, TCP state and BGP log form a chain. The missing link identifies both the failure and the resource still exposed.

Manual agreement is not negotiated truth

RFC 5082 defines no generic GTSM capability negotiation for existing protocols. Operators configure the relationship. Each side must emit protected traffic at 255 and admit the values expected from the other side. A correct line on one router cannot repair an incompatible line, unsupported feature or different path at the other.

This produces four separate facts: intended topology, configured allowance, observed path and enforced threshold. They often coincide on commissioning day. They diverge during maintenance, failover, route optimization, a loopback migration, a vendor replacement or an IPv4-to-IPv6 change.

An Established session is weak historical evidence. It shows that some packets passed enough layers to form BGP at that time. It does not show the current outgoing TTL, prove that the receiving check was active or reveal the rejected negative space. A feature accidentally disabled on both sides can still produce a healthy session.

The negative test matters. Capture a legitimate packet at the expected value, then in an isolated canary send a packet from beyond the admitted diameter. Confirm that the first is visible to TCP and the second disappears at the predicted early counter. Test the exact threshold and one unit below it. That pair turns a configuration claim into a running boundary.

Multihop converts a line into a trust diameter

The clearest GTSM case is direct adjacency. A legitimate packet arrives at 255; any ordinary routed path reduces it. RFC 5082 deliberately gives its normative applicability to inherently limited topologies and says its security properties are clearest for the single-hop case.

Operations still use TTL security for multihop BGP. It can be useful: admitting three hops excludes attackers who are four or more routed hops away. Yet the meaning changes. Everyone able to inject traffic from inside the admitted diameter may satisfy the same distance condition. RFC 7454 warns that multihop use is less effective for this reason.

The configured number is therefore a trust budget, not just a reachability knob. Increasing it by one does two things at once. It protects availability across a longer legitimate path, and it admits another ring of possible sources. Decreasing it tightens exposure and may turn a harmless reroute into a session outage.

Leadership should require a reason for the margin. If the steady path is two hops, why is the allowance five? Perhaps failure routing needs it. Perhaps a route server sits in the path. Perhaps the number was copied from an old configuration profile. Those are materially different answers. The approved value should cover observed steady, maintenance and credible failure paths—with the smallest explicit margin—not the maximum that makes alarms disappear.

Direction is an independent contract

Network paths can be asymmetric. A to B may cross two routed hops while B to A crosses three. GTSM operates on received packets, so the two thresholds are independent even though operators speak of “the session” as one object.

This asymmetry produces deceptive states. One endpoint's SYN can reach the peer, while the SYN-ACK fails the reverse threshold. A TCP connection can reset when a later ECMP choice changes the received value in only one direction. IPv4 can pass over a direct path while IPv6 follows a routed link-local or loopback design with different behavior.

Never infer the reverse value from traceroute in one direction. Capture outbound 255 and inbound arrival on both endpoints, per address family. Retain a distribution, not only a single sample, when ECMP or failure routing is possible. A threshold that passes the median but drops one valid path is an intermittent outage waiting for traffic hashing to select it.

Session evidence should be keyed by epoch. Store endpoint addresses, family, intended topology, both configured allowances, observed values, path identity and the first successful TCP/BGP transition together. When a session re-establishes over a changed path, the old screenshot is not current authority.

Tunnels can counterfeit the arithmetic without an attacker

A tunnel changes what “hop” means. The outer packet may cross many routers while the inner TTL remains untouched. A decapsulator may then deliver an inner packet with a value that appears adjacent. Other models copy or propagate values. MPLS uniform, pipe and short-pipe behavior can produce different evidence.

RFC 5082 treats tunnel integrity and endpoint trust as explicit assumptions, not incidental details. If untrusted traffic can enter a tunnel that terminates near the protected peer, distance across the visible inner header no longer describes the attacker's true origin. The tunnel can become a proximity elevator.

Do not record “tunnel = one hop”. Record encapsulation type, who may inject at the head end, whether the tunnel is integrity protected, decapsulation point, inner and outer values and source validation at termination. Then capture the actual BGP traffic through the production data path.

The same discipline applies during migrations. Moving a peer behind a firewall, DDoS scrubbing service, service chain or virtual router may preserve IP reachability while changing where TTL is decremented or checked. If the security design depends on proximity, the intermediate system is part of the trust boundary even when it is absent from the BGP configuration.

Fragments expose the classifier's blind side

Non-initial IP fragments do not carry the transport header needed to associate them with a particular BGP TCP session. A classifier may therefore treat them as Unknown until reassembly. Waiting for reassembly can consume exactly the memory and CPU the early check is meant to protect.

RFC 5082 recommends avoiding fragmentation for protected protocols and considers separate rate limits or discard policy. The useful governance point is broader: an admission mechanism is only as strong as the traffic it can classify before scarcity is consumed.

Test the exceptional paths. Verify that normal BGP packets fit the effective MTU. Inventory ICMP handling, because the standard also covers related error messages. Inspect fragment counters and the platform's order of operations. A green unfragmented canary does not prove that fragment floods reach the same early decision.

Proximity, identity and route authority are separate columns

GTSM answers: did this packet arrive with a network distance consistent with the relationship? TCP-AO answers a different question: does the TCP segment authenticate under the expected key context and remain protected against specified spoofing or tampering? Ingress source validation asks whether this source address is plausible on this interface. Control-plane policy asks whether this traffic class should reach scarce resources. BGP parsing and policy ask whether the message and route are acceptable.

None is redundant. A directly connected attacker can satisfy GTSM and spoof the peer address; ingress filtering may stop it. An on-path attacker can satisfy the same distance; cryptographic authentication is needed for identity and integrity. A compromised, fully authenticated peer can advertise an unauthorized prefix; local import policy must still reject it. A flood of Unknown traffic may never be judged by GTSM; control-plane policing must contain it.

This separation prevents two opposite errors. The first is security inflation: calling TTL 255 authentication. The second is security dismissal: treating GTSM as useless because it does not authenticate. A door's distance sensor is not a lock, but it can still reject traffic that could not plausibly have reached the door from the approved corridor.

The control matrix should retain separate owners and failure evidence for each layer. Topology engineering owns path and allowance. Platform engineering owns the earliest classifier and counters. Security owns source validation and key lifecycle. Routing owns TCP/BGP state and route policy. One dashboard may join the evidence; one green checkbox must not collapse the authorities.

The maintenance canary must predict a drop

Before a path change, capture both directions under normal load. Confirm every protected control packet leaves at 255. Record minimum, maximum and common received values by family and ECMP path. Identify the configured threshold and the exact hardware or software stage that enforces it.

Model the maintenance and failure paths. If the new legitimate minimum will be 252, decide whether topology should remain inside the old boundary or the allowance should change. Approve the additional trust diameter explicitly. Change both endpoints in an order that does not create an asymmetric outage, with independent reachability, authentication and route-policy controls intact.

In a canary relationship, send three probes: one arriving above the threshold, one exactly at it and one below it. Prove the first two reach the expected later stage and the last increments the predicted early-drop counter without appearing at TCP or BGP. Then establish the real session and verify its packets use the same path and values as the probes.

After cutover, correlate threshold counters, TCP retransmissions, BGP transitions, control-plane queue pressure and received routes. If routes disappear, locate the first missing evidence. Do not jump from “no route” to “GTSM drop”; an ACL, failed TCP authentication, BGP notification or import policy can produce the same reader-visible result.

Rollback is bilateral and scoped. Restore the former path or former explicit thresholds while preserving the other layers. Disabling GTSM on one side and widening it to the maximum on the other creates a working session with an unrecorded security regression. The rollback record must state which boundary returned, not merely that BGP recovered.

The packet at 252 is not guilty. It is inconsistent with a contract written for 253. GTSM works when operators keep that distinction exact: the field can prove bounded proximity under known topology, and nothing more. Its authority is powerful because it is deliberately incomplete.