RFC 3682

The Generalized TTL Security Mechanism (GTSM)

📅 published February 2004, from ietf

RFC 3682: The Generalized TTL Security Mechanism (GTSM) 💖

Okay bestie, come sit with me 🎀 This is RFC 3682, called The Generalized TTL Security Mechanism (GTSM). Its authors are V. Gill, J. Heasley, and D. Meyer, it's from the Network Working Group, and it's dated February 2004. It's in the Experimental category, and its title block doesn't list anything it obsoletes or updates. Main character energy, no notes 💅

Status of this Memo ✨

This memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind. The authors are asking for discussion and suggestions for improvement 🫶 Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 🦋

Okay so people have been proposing that you use a packet's Time to Live (TTL) on IPv4, or Hop Limit on IPv6, to protect a protocol stack from CPU-utilization based attacks, and it's been suggested in lots of different settings (see RFC 2461, for example) 🙈 This document generalizes those ideas so other protocols can use them too, like BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036). GTSM works best for protecting protocol peers that are directly connected, but it can also give a lower level of protection to multi-hop sessions. It's not directly applicable to protocols that use flooding mechanisms (like multicast), and multi-hop GTSM should be considered case by case 💜

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
          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 🧚

GTSM is designed to protect a router's TCP/IP based control plane from CPU-utilization based attacks. Cryptographic techniques can protect router infrastructure (like BGP [RFC1771], [RFC1772]) from a wide variety of attacks, but lots of CPU overload attacks can be stopped by the simple mechanism in this document. The same technique also protects against other scarce-resource attacks that involve a router's CPU, like attacks against processor-line card bandwidth ✨

Here's the vibe: the vast majority of protocol peerings are set up between routers that are adjacent [PEERING] 🫶 So most peerings are either directly between connected interfaces, or in the worst case loopback to loopback, with static routes to the loopbacks. TTL spoofing is considered nearly impossible, so a mechanism based on an expected TTL value can be a simple and reasonably robust defense against infrastructure attacks that use forged protocol packets 🔥

GTSM works the same for both TTL (IPv4) and Hop Limit (IPv6). From GTSM's point of view they have identical semantics, so for the rest of the document, "TTL" refers to both TTL and Hop Limit, whichever one applies 💅

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 built on these assumptions:

  • (i) The vast majority of protocol peerings are between adjacent routers [PEERING].
  • (ii) It's common practice for many service providers to ingress filter (deny) packets that have the provider's loopback addresses as the source IP address.
  • (iii) Use of GTSM is OPTIONAL, and it can be configured on a per-peer (group) basis.
  • (iv) The router supports a way of sorting traffic headed for the route processor into interesting/control and not-control queues.
  • (iv) The peer routers both implement GTSM.

2.1. GTSM Negotiation 🌈

This document assumes GTSM gets manually configured between protocol peers. So no automatic GTSM capability negotiation, like the kind envisioned by RFC 2842 [RFC2842], is assumed or defined here 💜

2.2. Assumptions on Attack Sophistication 😭

Throughout this document, we assume potential attackers have gotten sophisticated enough, and have enough access, to send control traffic to a protocol session, and that the traffic looks valid (it has the source and destination of configured peer routers) 👑

We also assume every router on the path between the attacker and the victim protocol speaker decrements TTL properly. (Obviously, if either the path or the adjacent peer is compromised, you've got bigger problems to worry about 💀)

Since the vast majority of our peerings are between adjacent routers, we can set the TTL on protocol packets to 255 (the maximum possible for IP), and then reject any protocol packets coming in from configured peers that do NOT have an inbound TTL of 255 🍓

GTSM can be turned off for stuff like route-servers and other large-diameter multi-hop peerings. If an attack comes in from a compromised multi-hop peering, that peering can be shut down (there's a way to reduce exposure to multi-hop attacks, outlined below) 🦋

3. GTSM Procedure 💖

GTSM SHOULD NOT be enabled by default. ✨

Here's how the per-peer behavior goes:

  • (i) If GTSM is enabled, an implementation does the following:
    • (a) For directly connected routers:
      • Set the outbound TTL for the protocol connection to 255.
      • For each configured protocol peer, update the receive path Access Control List (ACL) or firewall so it only lets protocol packets through to the Route Processor (RP) that have the correct <source, destination, TTL> tuple. The TTL must either be 255 (for a directly connected peer), or 255-(configured-range-of-acceptable-hops) for a multi-hop peer. We specify a range here so there's some robustness to changes in topology. Any directly connected check MUST be disabled for such peerings.
      • A receive path ACL is an ACL designed to control which packets are allowed to go to the RP. This procedure only lets protocol packets from adjacent routers through to the RP 🫶
    • (b) If the inbound TTL is 255 (for a directly connected peer), or 255-(configured-range-of-acceptable-hops) (for multi-hop peers), the packet is NOT processed. Instead, it gets placed into a low priority queue, and then logged and/or silently discarded. In this case, an ICMP message MUST NOT be generated 🙈
  • (ii) If GTSM is not enabled, normal protocol behavior is followed.

3.1. Multi-hop Scenarios 🌸

When a multi-hop protocol session is required, we set the expected TTL value to 255-(configured-range-of-acceptable-hops). This approach gives a qualitatively lower degree of security for the protocol using GTSM. (Like, a DoS attack could theoretically be launched by compromising some box in the path 😬) That said, GTSM will still catch the vast majority of observed DDoS attacks against a given protocol. Since the number of hops can change rapidly in real networks, GTSM may not be able to handle this scenario adequately, so an implementation MAY provide OPTIONAL support 🧚

3.1.1. Intra-domain Protocol Handling ⭐

In general, GTSM isn't used for intra-domain protocol peers or adjacencies. The special case of iBGP peers can be protected by filtering at the network edge for any packet whose source address is one of the loopback addresses used for the intra-domain peering. On top of that, the current best practice is to further protect these peers or adjacencies with an MD5 signature [RFC2385] 🔥

4. Acknowledgments 🫶

Using the TTL field to protect BGP started with lots of different people, including Paul Traina and Jon Stewart. Ryan McDowell also suggested a similar idea. Steve Bellovin, Jay Borkenhagen, Randy Bush, Vern Paxon, Pekka Savola, and Robert Raszuk also gave useful feedback on earlier versions of this document. And David Ward gave insight on generalizing the original BGP-specific idea 💜🌈

5.2. Tunneled Packets 🎀

okay so this is the exception to the whole "TTL of 255 is hard to fake" thing 👀 when a protocol packet gets tunneled to a decapsulator, and that decapsulator forwards it to a directly connected protocol peer, the tunnel endpoint can be either the penultimate hop 🧚 or the last hop itself. a related case is when the protocol packet gets tunneled straight to the protocol peer, so the peer is the decapsulator. 💅

when the protocol packet is encapsulated in IP, the TTL can be spoofed 😭 and sometimes it's just impossible to legitimately get the packet to the peer with a TTL of 255. that's the IP in MPLS situation we'll get to below. 🫶

and bestie, the security of ANY tunneling technique depends hard on authentication at the tunnel endpoints, plus how the tunneled packets are protected while they're in flight. 🔐 BUT that stuff is beyond the scope of this memo, so we're not going into it here. 🙈

5.2.1. IP in IP 🦋

protocol packets can be tunneled over IP directly to a protocol peer, OR to a decapsulator (tunnel endpoint) that then forwards the packet to a directly connected protocol peer. examples are IP-in-IP [RFC2003], GRE [RFC2784], or the various forms of IPv6-in-IPv4 [RFC2893]. here's how those two cases look:

 Peer router ---------- Tunnel endpoint router and peer
  TTL=255     [tunnel]   [TTL=255 at ingress]
                         [TTL=255 at egress]

 Peer router ---------- Tunnel endpoint router ----- On-link peer
  TTL=255     [tunnel]   [TTL=255 at ingress]  [TTL=254 at ingress]
                         [TTL=254 at egress]

in the first case, where the encapsulated packet goes straight to the protocol peer, the encapsulated packet's TTL can be set to an arbitrary value. 🤷‍♀️ in the second case, where it goes to a decapsulator that then forwards it to a directly connected peer, RFC 2003 spells out this behavior:

When encapsulating a datagram, the TTL in the inner IP header is decremented by one if the tunneling is being done as part of forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation. If the resulting TTL in the inner IP header is 0, the datagram is discarded and an ICMP Time Exceeded message SHOULD be returned to the sender. An encapsulator MUST NOT encapsulate a datagram with TTL = 0.

so the inner IP header's TTL, as the decapsulator sees it, can be set to any value at all (255 included) 🤯 which means it might not be possible to deliver the protocol packet to the peer with a TTL of 255. the vibes are very "the math doesn't work out" 💀

5.2.2. IP in MPLS 💜

protocol packets can also be tunneled over MPLS to a protocol peer. that peer is either the penultimate hop (when penultimate hop popping (PHP) is used [RFC3032]), or one hop beyond the penultimate hop. here are the cases:

 Peer router ---------- Penultimate Hop (PH) and peer
  TTL=255     [tunnel]   [TTL=255 at ingress]
                         [TTL<=254 at egress]


 Peer router ---------- Penultimate Hop  -------- On-link peer
  TTL=255     [tunnel]   [TTL=255 at ingress]  [TTL <=254 at ingress]
                         [TTL<=254 at egress]

TTL handling for these cases is described in RFC 3032 🌸 and when the IP packet is first labeled, RFC 3032 says:

... the TTL field of the label stack entry MUST BE set to the value of the IP TTL field. (If the IP TTL field needs to be decremented, as part of the IP processing, it is assumed that this has already been done.)

and when the label gets popped:

When a label is popped, and the resulting label stack is empty, then the value of the IP TTL field SHOULD BE replaced with the outgoing TTL value, as defined above. In IPv4 this also requires modification of the IP header checksum.

where "outgoing TTL" is defined like this:

The "incoming TTL" of a labeled packet is defined to be the value of the TTL field of the top label stack entry when the packet is received.
The "outgoing TTL" of a labeled packet is defined to be the larger of: a) one less than the incoming TTL, b) zero.

so the minimum the TTL could drop by is one. ✨ the network operator likes to hide its infrastructure by only decrementing the TTL by the minimum number of LSP hops (that's one), instead of dropping it at every hop as the packet crosses the MPLS domain. 🙈 net result: the maximum TTL at egress from the MPLS cloud is 254 (255-1), so the check described in section 3 will FAIL. 💀 okay it's giving "the TTL got eaten by the cloud" energy.

5.3. Multi-Hop Protocol Sessions 🌈

the GTSM method is less effective for multi-hop protocol sessions, BUT it still closes the window on several forms of attack 🔒 hmm, the catch is that in the multi-hop scenario GTSM is an OPTIONAL extension. 🫧 protecting the protocol infrastructure beyond what GTSM gives you will probably need cryptographic machinery, like what's envisioned by Secure BGP (S-BGP) [SBGP1,SBGP2], and/or other extensions. 🔑

and finally, in the multi-hop case we just described, we specify a range of acceptable TTLs so the setup can handle some topology changes gracefully 🦋 but this robustness to topology change comes at the cost of losing some robustness against different forms of attack. so it's a tradeoff, bestie. ⚖️

6. IANA Considerations 🧚

this document creates no new requirements on IANA namespaces [RFC2434]. 💖

7. References 📚

7.1. Normative References

[RFC791]   Postel, J., "Internet Protocol Specification", STD 5, RFC
           791, September 1981.

[RFC1771]  Rekhter, Y. and T. Li (Editors), "A Border Gateway
           Protocol (BGP-4)", RFC 1771, March 1995.

[RFC1772]  Rekhter, Y. and P. Gross, "Application of the Border
           Gateway Protocol in the Internet", RFC 1772, March 1995.

[RFC2003]  Perkins, C., "IP Encapsulation with IP", RFC 2003, October
           1996.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
           Signature Option", RFC 2385, August 1998.

[RFC2461]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor
           Discover for IP Version 6 (IPv6)", RFC 2461, December
           1998.

[RFC2784]  Farinacci, D., "Generic Routing Encapsulation (GRE)", RFC
           2784, March 2000.

[RFC2842]  Chandra, R. and J. Scudder, "Capabilities Advertisement
           with BGP-4", RFC 2842, May 2000.

[RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
           IPv6 Hosts and Routers", RFC 2893, August 2000.

[RFC3032]  Rosen, E. Tappan, D., Fedorkow, G., Rekhter, Y.,
           Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack
           Encoding", RFC 3032, January 2001.

[RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
           B. Thomas, "LDP Specification", RFC 3036, January 2001.

[RFC3392]  Chandra, R. and J. Scudder, "Capabilities Advertisement
           with BGP-4", RFC 3392, November 2002.

[SBGP1]    Kent, S., C. Lynn, and K. Seo, "Secure Border Gateway
           Protocol (Secure-BGP)", IEEE Journal on Selected Areas in
           Communications, volume 18, number 4, April, 2000.

[SBGP2]    Kent, S., C. Lynn, J. Mikkelson, and K. Seo, "Secure
           Border Gateway Protocol (S-BGP) -- Real World Performance
           and Deployment Issues", Proceedings of the IEEE Network
           and Distributed System Security Symposium, February, 2000.

7.2. Informative References

[BFD]      Katz, D. and D. Ward, "Bidirectional Forwarding
           Detection", Work in Progress, June 2003.

[PEERING]  Empirical data gathered from the Sprint and AOL backbones,
           October, 2002.

[RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
           the IETF Standards Process", BCP 11, RFC 2028, October
           1996.

[RFC2434]  Narten, T., and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 2434,
           October 1998.

[RFC3618]  Meyer, D. and W. Fenner, Eds., "The Multicast Source
           Discovery Protocol (MSDP)", RFC 3618, October 2003.

8. Authors' Addresses 💌

Vijay Gill

EMail: vijay@umbc.edu


John Heasley

EMail: heas@shrubbery.net


David Meyer

EMail: dmm@1-4-5.net

Copyright (C) The Internet Society (2004). All Rights Reserved. ©️

this document and translations of it may be copied and handed out to others 📄 and derivative works that comment on or explain it, or help with implementing it, may be made, copied, published and distributed, in whole or in part, without restriction of any kind. the one condition is that the above copyright notice and this paragraph stay on all those copies and derivative works. 🫶

however, this document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are when it's needed for developing Internet standards (then the copyright procedures in the Internet Standards process have to be followed) or when it's translated into languages other than English. 🌍

the limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assignees. 💜

this document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society. 🦋

📦 where this page comes from