The Generalized TTL Security Mechanism (GTSM)
RFC 5082
| Document | Type |
RFC - Proposed Standard
(October 2007; No errata)
Obsoletes RFC 3682
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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",
Show full document text