Summary

  • GTSM checks packet proximity through IPv4 TTL or IPv6 Hop Limit; it does not authenticate the sender or replace cryptographic protection of a BGP TCP session.
  • A passing check depends on the configured hop radius, ingress filtering, direct-neighbor trust and tunnel behavior, so the same number can mean different things after a topology change.
  • Peer assurance needs a joined receipt: observed hop value, interface and tunnel path, approved neighbor, TCP-AO key state, session evidence and the owner of each control.

The cross-connect has just moved. Both BGP speakers still send control packets with TTL 255, and every received packet passes the configured GTSM check. The change record therefore declares that the remote peer has been authenticated.

That conclusion is stronger than the evidence. The check can show that a packet arrived within the allowed hop boundary. It cannot by itself show which authorized system created the packet, whether an on-link host could forge it, whether a tunnel changed the apparent distance, or whether the packet carried a valid cryptographic authenticator. The session may be operational and the GTSM control may be working exactly as designed while the word authenticated remains unsupported.

RFC 4271 places BGP above TCP. Two systems establish a TCP connection and then exchange BGP OPEN, UPDATE, KEEPALIVE and NOTIFICATION messages. That sequence creates several distinct questions: did an IP packet arrive from a plausible topological distance; did a TCP segment belong to the protected connection; did the configured BGP neighbor accept the session; and does the organization behind that neighbor still have authority to exchange routes? One green indicator cannot answer all four.

RFC 5082 defines the Generalized TTL Security Mechanism around a simple asymmetry. A directly connected protocol peer sends with the maximum TTL or Hop Limit of 255. A packet forwarded by a router loses at least one hop, so a receiver expecting 255 can reject traffic that plausibly originated farther away. Processing that classification close to line rate can also prevent forged control traffic from consuming scarce control-plane resources.

This is useful security, not weak security pretending to be something else. It narrows the attack surface and gives an operator a cheap topological test before expensive protocol processing. RFC 7454 accordingly recommends TTL security on directly connected BGP peerings.

The same RFC boundary is equally clear: GTSM is not a substitute for authentication. RFC 5082 says it does not protect against insider or on-the-wire spoofing and replay. A compromised directly connected device can be close enough. An attacker present on the trusted segment can be close enough. A packet emitted or decapsulated at an accepted tunnel endpoint can also look close enough. Passing the test establishes a configured proximity claim, not authorship.

Multi-hop operation makes the distinction more visible. GTSM can accept packets within a configured TTL radius rather than exactly one hop. That may be the correct design for loopbacks or a multihop session, but every extra accepted hop enlarges the set of places from which a plausible packet may arrive. A topology change can alter the meaning without altering the numeric threshold.

Tunnels add a second source of ambiguity. RFC 5082 works through several IP and MPLS cases because the inner TTL presented to the peer depends on encapsulation, propagation mode and whether the decapsulator is also the protocol endpoint. The tunnel’s integrity and termination therefore become part of the evidence. A GTSM alarm after migration may reveal a changed path; a passing result does not certify the tunnel.

Cryptographic segment authentication answers a different question. RFC 5925 defines TCP-AO for long-lived TCP connections such as BGP. It calculates a message authentication code over connection-bound material using managed key tuples and per-connection traffic keys. Sequence-number extensions protect long-lived connections against replay when the ordinary TCP sequence space wraps. A valid TCP-AO result can support the claim that the segment was produced by a holder of accepted key material for that connection.

Even TCP-AO does not eliminate governance. Operators must decide which key identifies which peering relationship, install it on both ends, define its validity interval, coordinate rollover and remove obsolete material. A valid MAC under a key that should have been retired is cryptographically coherent but operationally unauthorized. Conversely, a GTSM pass with a missing or failed TCP-AO check should never be upgraded into peer identity.

The controls are strongest together because they fail differently. GTSM filters implausibly distant traffic early. Ingress filtering reduces spoofed source addresses. TCP-AO authenticates protected TCP segments. BGP neighbor configuration binds the session to an intended routing relationship. Monitoring shows whether rejected packets, session resets, hop changes or key rollover have changed the operating state. None should borrow the name of another.

Sources