The Generalized TTL Security Mechanism (GTSM)
RFC 5082
Document | Type |
RFC - Proposed Standard
(October 2007; No errata)
Obsoletes RFC 3682
|
|
---|---|---|---|
Authors | Carlos Pignataro , Pekka Savola , David Meyer , Vijay Gill , John Heasley | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5082 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ross Callon | ||
Send notices to | (None) |
Network Working Group V. Gill Request for Comments: 5082 J. Heasley Obsoletes: 3682 D. Meyer Category: Standards Track P. Savola, Ed. C. Pignataro October 2007 The Generalized TTL Security Mechanism (GTSM) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. Gill, et al. Standards Track [Page 1] RFC 5082 GTSM October 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3 2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4 2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4 3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7 5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7 5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8 5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9 5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11 5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11 5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12 6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12 6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Multi-Hop GTSM . . . . . . . . . . . . . . . . . . . 15 Appendix B. Changes Since RFC 3682 . . . . . . . . . . . . . . . 15 1. Introduction The Generalized TTL Security Mechanism (GTSM) is designed to protect a router's IP-based control plane from CPU-utilization based attacks. In particular, while cryptographic techniques can protect the router- based infrastructure (e.g., BGP [RFC4271], [RFC4272]) 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. Thus, most protocol peerings are either directly between connected interfaces or, in 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 from outside the network. Note, however, that GTSM is not a substitute for authentication mechanisms. In particular, it does not secure against insider on-the-wire attacks, such as packet spoofing or replay. Gill, et al. Standards Track [Page 2] RFC 5082 GTSM October 2007 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 RFC 2119 [RFC2119]. 2. Assumptions Underlying GTSM GTSM is predicated upon the following assumptions:Show full document text