The Generalized TTL Security Mechanism (GTSM)
RFC 5082

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 10

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: