The Generalized TTL Security Mechanism (GTSM)
RFC 3682

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

• Versions
• 04

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].