The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)
Extracted elements (19)
A previously reserved bit in RFC 5036's Common Hello Parameter TLV is repurposed as the G flag, so that existing LSRs unaware of GTSM will continue to ignore it per RFC 5036 Section 3.5.2, preserving interoperability without requiring a new TLV type.
GTSM capability negotiation is enabled by default (G=1) for Basic Discovery but not for Extended Discovery because Basic Discovery typically corresponds to single-hop LDP peering sessions, while Extended Discovery typically corresponds to multi-hop sessions where GTSM's TTL=255 check would be inappropriate.
Rather than requiring explicit configuration to enable GTSM, this document specifies a 'built-in dynamic GTSM capability negotiation' where both peers automatically detect each other's support and agree to use GTSM, lowering deployment friction while preserving backward compatibility with non-GTSM peers.
Features relying on multi-hop LDP peering sessions — such as LDP IGP Synchronization (RFC 5443) and LDP Session Protection — are incompatible with GTSM and require GTSM to be statically or dynamically disabled on the relevant peers.
GTSM for LDP as defined here applies only to single-hop LDP peering sessions and IPv4; LDP over IPv6 has GTSM built into its protocol definition. Multi-hop LDP peering is explicitly out of scope.
In case (b) — two adjacent LSRs forming a multi-hop LDP peering session via Basic Discovery due to IP routing configuration — GTSM is enabled by default and enforced, which will prohibit the LDP peering session from being established. The implementation SHOULD provide a per-peer configuration option to override.
Two adjacent LSRs using Extended Discovery alone (case a, e.g., for Pseudowire signaling) will not have GTSM enabled by default for their LDP session, even though they are single-hop neighbors, leaving them unprotected by GTSM.
If a GTSM-capable LSR recognizes G=1 in a received LDP Link Hello, it MUST enforce GTSM for LDP in the subsequent TCP/LDP peering session with that neighbor.
If an LSR does not recognize the G flag or receives G=0 in a Link Hello, it MUST NOT enforce GTSM in the subsequent TCP/LDP peering session, ensuring backward compatibility and automatic GTSM deactivation.
If an LSR sent G=1 but received G=0 from the directly connected neighbor, it MUST NOT enforce GTSM procedures in the forthcoming TCP transport connection with that neighbor.
LDP Hello messages sent via Basic Discovery (to link-level multicast 224.0.0.2) are RECOMMENDED to have IP TTL or Hop Count = 1, since such messages are never forwarded beyond one hop.
The Reserved field in the Common Hello Parameter TLV MUST be set to zero on transmission and ignored on receipt.
Unless configured otherwise, an LSR that supports GTSM procedures MUST set the G flag to 1 in the Common Hello Parameter TLV in the LDP Link Hello message.
When both peers have exchanged G=1 in LDP Link Hello, the LSR MUST check incoming unicast packets' TTL or Hop Count to be 255 for the particular LDP/TCP peering session, and process further as per RFC 5082.
The G flag is the GTSM capability indicator in the Common Hello Parameter TLV. It is meaningful only when T=0 (Basic Discovery). When T=1 (Targeted/Extended Discovery), the G flag value is ignored on receipt.
GTSM for LDP increases security by making LDP more resilient to off-link attacks. By verifying that incoming LDP/TCP packets have TTL=255, packets forged from outside the directly connected subnet are discarded before they consume router CPU resources.
GTSM for LDP may not always be enforced on single-hop sessions established via Extended Discovery, leaving LDP susceptible to forged/spoofed protocol packets in those scenarios. Use of cryptographic integrity (e.g., TCP-AO per RFC 5925) is recommended as an alternate or complementary solution.
RFC 5082 requires that protocol messages used for dynamic GTSM negotiation MUST be authenticated, but LDP Basic Discovery uses UDP and lacks an authentication mechanism. The use of link-level multicast (224.0.0.2) provides basic protection against off-the-wire attacks but not insider on-the-wire attacks.
The Common Hello Parameter TLV (type 0x0400) is extended with a G (GTSM) flag in a previously reserved bit position. The 32-bit TLV value field carries Hold Time (16 bits), followed by T, R, G flags, and reserved bits. G=1 signals GTSM capability; G=0 or absent signals no GTSM support.