The Generalized TTL Security Mechanism (GTSM)
obsoletes
- rfc-3682 — The Generalized TTL Security Mechanism (GTSM)
Extracted elements (23)
GTSM does not prescribe policies for packets not matching GTSM filtering rules (e.g., rate-limiting non-matching packets), nor does it mandate specific means of resource separation, as those are hardware and implementation-specific.
GTSM is based on the fact that the vast majority of protocol peerings are established between adjacent routers, making a TTL value of 255 difficult to spoof from non-directly connected locations since each intervening router decrements TTL by one.
GTSM is explicitly not a substitute for authentication mechanisms and does not secure against insider on-the-wire attacks such as packet spoofing or replay; it only protects against infrastructure attacks based on forged protocol packets from outside the network.
GTSM is only applicable to environments with inherently limited topologies where protocol peers are directly connected. It will not protect against attackers as close to the protected station as the legitimate peer (e.g., same interface).
The closer GTSM processing is done to line-rate hardware, the more resistant the system is to DoS attacks, because the possibility of DoS prevention depends on classification and path separation occurring before packets reach a scarce resource.
For Uniform Model MPLS LSPs of more than one hop, the TTL at ingress (iTTL) will be less than 255, causing GTSM checks to fail. GTSM is only applicable over Pipe Model LSPs when tunneled over MPLS.
RFC 5082 adds a new requirement vs. RFC 3682: related messages (ICMP errors) must also be sent and checked to have TTL=255. RFC 3682 implementations that use a default TTL other than 255 for originated packets will have their ICMP messages classified as Dangerous under RFC 5082.
When a tunnel decapsulator forwards a protocol packet to a directly connected protocol peer (rather than being the peer itself), the TTL is decremented by normal IP forwarding, making it impossible to deliver the packet to the protocol peer with TTL=255.
By default, implementations SHOULD ensure that packets classified as Dangerous do not compete for resources with packets classified as Trusted or Unknown.
If dynamic negotiation of GTSM support is necessary, protocol messages used for such negotiation MUST be authenticated using other security mechanisms to prevent DoS attacks.
If GTSM is not built into the protocol, it SHOULD NOT be enabled by default in order to remain backward-compatible with the unmodified protocol.
Implementations MAY drop packets classified as Dangerous (those belonging to a GTSM-enabled session but whose TTL is not within the expected range).
Implementations MUST NOT drop (as part of GTSM processing) packets classified as Trusted or Unknown.
It is highly RECOMMENDED for GTSM-protected protocols to avoid fragmentation and reassembly by manual MTU tuning, PMTUD, or other methods to get practical protection from fragment attacks.
The TTL field in all IP packets used for transmission of messages associated with GTSM-enabled protocol sessions MUST be set to 255. This also applies to the related ICMP error handling messages.
The TTL of GTSM-enabled sessions MUST NOT be decremented, even on architectures where control plane originated traffic TTL is decremented in the forwarding plane.
GTSM defines three packet trustworthiness classifications applied to received control-plane packets: Unknown, Trusted, and Dangerous, with policies for resource allocation and drop behavior applied per classification. Exact policies are configurable by the operator.
GTSM is OPTIONAL and configured on a per-peer (group) basis. No automatic GTSM capability negotiation is defined; manual configuration between protocol peers is assumed when used with existing protocols.
An attacker directly connected to one interface can disturb a GTSM-protected session on the same or another interface by spoofing a GTSM peer's address unless ingress filtering (RFC 3704) has been applied on the connecting interface.
Fragmentation restricts GTSM's effectiveness: non-initial IP fragments cannot be associated with a registered GTSM-enabled session and receive Unknown treatment; a legitimate initial fragment could be combined with spoofed non-initial fragments, leaving packet integrity unknown. Operators may need to rate-limit or discard all received fragments.
GTSM protects single-hop protocol sessions but does not protect against on-the-wire attacks; it only makes it difficult (not impossible) to engineer a TTL of 255 from non-directly connected locations, assuming no compromised routers in the path.
Tunneled packets present a significant GTSM vulnerability: when a protocol packet is tunneled and the tunnel is not integrity-protected, the observation that TTL=255 is difficult to spoof may not hold. GTSM checks are possible for IP tunneled over Pipe model LSPs but not for Uniform model LSPs.
Each received packet addressed to the router's control plane is classified into one of three trustworthiness states: Unknown (cannot be associated with any GTSM-enabled session), Trusted (belongs to a GTSM-enabled session with TTL within expected range), or Dangerous (belongs to a GTSM-enabled session but TTL is NOT within expected range).