The Generalized TTL Security Mechanism (GTSM)
RFC 3682
Document | Type |
RFC - Experimental
(February 2004; No errata)
Obsoleted by RFC 5082
Was draft-gill-gtsh (rtg)
|
|
---|---|---|---|
Authors | Vijay Gill , John Heasley , David Meyer | ||
Last updated | 2015-10-14 | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | ISE state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3682 (Experimental) | |
Action Holders |
(None)
|
||
Telechat date | |||
Responsible AD | Alex Zinin | ||
Send notices to | (None) |
Network Working Group V. Gill Request for Comments: 3682 J. Heasley Category: Experimental D. Meyer February 2004 The Generalized TTL Security Mechanism (GTSM) Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Assumptions Underlying GTSM. . . . . . . . . . . . . . . . . . 2 2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . 3 2.2. Assumptions on Attack Sophistication . . . . . . . . . . 3 3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Multi-hop Scenarios. . . . . . . . . . . . . . . . . . . 4 3.1.1. Intra-domain Protocol Handling . . . . . . . . . 5 4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5 5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . 5 5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . 6 5.2.1. IP in IP . . . . . . . . . . . . . . . . . . . . 6 Gill, et al. Experimental [Page 1] RFC 3682 Generalized TTL Security Mechanism February 2004 5.2.2. IP in MPLS . . . . . . . . . . . . . . . . . . . 7 5.3. Multi-Hop Protocol Sessions. . . . . . . . . . . . . . . 8 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 1. Introduction The Generalized TTL Security Mechanism (GTSM) is designed to protect a router's TCP/IP based control plane from CPU-utilization based attacks. In particular, while cryptographic techniques can protect the router-based infrastructure (e.g., BGP [RFC1771], [RFC1772]) from a wide variety of attacks, many attacks based on CPU overload can be prevented by the simple mechanism described in this document. Note that the same technique protects against other scarce-resource attacks involving a router's CPU, such as attacks against processor-line card bandwidth. GTSM is based on the fact that the vast majority of protocol peerings are established between routers that are adjacent [PEERING]. Thus most protocol peerings are either directly between connected interfaces or at the worst case, are between loopback and loopback, with static routes to loopbacks. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value can provide a simple and reasonably robust defense from infrastructure attacks based on forged protocol packets. Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop Limit have identical semantics. As a result, in the remainder of this document the term "TTL" is used to refer to both TTL or Hop Limit (as appropriate). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Assumptions Underlying GTSM GTSM is predicated upon the following assumptions: (i) The vast majority of protocol peerings are between adjacent routers [PEERING].Show full document text