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.
AbstractThe 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.
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 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.
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]. RFC3704] on non-trusted links. If maximal protection is desired, such filtering is necessary as described in Section 2.2. 3. Use of GTSM is OPTIONAL, and can be configured on a per-peer (group) basis. 4. The peer routers both implement GTSM. 5. The router supports a method to use separate resource pools (e.g., queues, processing quotas) for differently classified traffic. Note that this document does not prescribe further restrictions that a router may apply to packets not matching the GTSM filtering rules, such as dropping packets that do not match any configured protocol session and rate-limiting the rest. This document also does not suggest the actual means of resource separation, as those are hardware and implementation-specific. However, the possibility of denial-of-service (DoS) attack prevention is based on the assumption that classification of packets and separation of their paths are done before the packets go through a scarce resource in the system. In practice, the closer GTSM processing is done to the line-rate hardware, the more resistant the system is to DoS attacks.
RFC3392], is assumed or defined. If a new protocol is designed with built-in GTSM support, then it is recommended that procedures are always used for sending and validating received protocol packets (GTSM is always on, see for example [RFC2461]). If, however, dynamic negotiation of GTSM support is necessary, protocol messages used for such negotiation MUST be authenticated using other security mechanisms to prevent DoS attacks. Also note that this specification does not offer a generic GTSM capability negotiation mechanism, so messages of the protocol augmented with the GTSM behavior will need to be used if dynamic negotiation is deemed necessary. RFC3704], or 4) the GTSM-enabled session does not allow protocol packets coming from a tunnel.
Since the vast majority of peerings are between adjacent routers, we can set the TTL on the protocol packets to 255 (the maximum possible for IP) and then reject any protocol packets that come in from configured peers that do NOT have an inbound TTL of 255. GTSM can be disabled for applications such as route-servers and other multi-hop peerings. In the event that an attack comes in from a compromised multi-hop peering, that peering can be shut down.
+ Dangerous: these are packets that have been identified as belonging to one of the GTSM-enabled sessions, but their TTL values are NOT within the expected range, and hence GTSM believes there is a risk that these packets have been spoofed. The exact policies applied to packets of different classifications are not postulated in this document and are expected to be configurable. Configurability is likely necessary in particular with the treatment of related messages (ICMP errors). It should be noted that fragmentation may restrict the amount of information available for classification. However, by default, the implementations: + SHOULD ensure that packets classified as Dangerous do not compete for resources with packets classified as Trusted or Unknown. + MUST NOT drop (as part of GTSM processing) packets classified as Trusted or Unknown. + MAY drop packets classified as Dangerous.
decapsulator is the penultimate node from the GTSM-protected protocol peer's perspective. As a result, the GTSM check protects from attackers encapsulating packets to your peers. However, specific cases arise when the connection from the tunnel decapsulator node to the protocol peer is not an IP forwarding hop, where TTL-decrementing does not happen (e.g., layer-2 tunneling, bridging, etc). In the IPsec architecture [RFC4301], another example is the use of Bump-in- the-Wire (BITW) [BITW]. RFC2003], GRE [RFC2784], and various forms of IPv6-in-IPv4 (e.g., [RFC4213]). These cases are depicted below. Peer router ---------- Tunnel endpoint router and peer TTL=255 [tunnel] [TTL=255 at ingress] [TTL=255 at processing] Peer router -------- Tunnel endpoint router ----- On-link peer TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress] [TTL=254 at egress] In both cases, the encapsulator (origination tunnel endpoint) is the (supposed) sending protocol peer. The TTL in the inner IP datagram can be set to 255, since RFC 2003 specifies the following 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. In the first case, the encapsulated packet is tunneled directly to the protocol peer (also a tunnel endpoint), and therefore the encapsulated packet's TTL can be received by the protocol peer with an arbitrary value, including 255. In the second case, the encapsulated packet is tunneled to a decapsulator (tunnel endpoint), which then forwards it to a directly connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies the following decapsulator behavior: The TTL in the inner IP header is not changed when decapsulating. If, after decapsulation, the inner datagram has TTL = 0, the decapsulator MUST discard the datagram. If, after decapsulation, the decapsulator forwards the datagram to one of its network
interfaces, it will decrement the TTL as a result of doing normal IP forwarding. See also Section 4.4. And similarly, for GRE tunnels, RFC 2784 specifies the following decapsulator behavior: When a tunnel endpoint decapsulates a GRE packet which has an IPv4 packet as the payload, the destination address in the IPv4 payload packet header MUST be used to forward the packet and the TTL of the payload packet MUST be decremented. Hence the inner IP packet header's TTL, as seen by the decapsulator, can be set to an arbitrary value (in particular, 255). If the decapsulator is also the protocol peer, it is possible to deliver the protocol packet to it with a TTL of 255 (first case). On the other hand, if the decapsulator needs to forward the protocol packet to a directly connected protocol peer, the TTL will be decremented (second case). RFC3443] that updates RFC 3032 [RFC3032] in regards to TTL processing in MPLS networks. RFC 3443 specifies the TTL processing in both Uniform and Pipe Models, which in turn can used with or without penultimate hop popping (PHP). The TTL processing in these cases results in different behaviors, and therefore are analyzed separately. Please refer to Section 3.1 through Section 3.3 of RFC 3443. The main difference from a TTL processing perspective between Uniform and Pipe Models at the LSP termination node resides in how the incoming TTL (iTTL) is determined. The tunneling model determines the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL field from the popped MPLS header (encapsulating header), whereas for Pipe Model LSPs, the iTTL is the value of the TTL field from the exposed header (encapsulated header).
For Uniform Model LSPs, RFC 3443 states that at ingress: For each pushed Uniform Model label, the TTL is copied from the label/IP-packet immediately underneath it. From this point, the inner TTL (i.e., the TTL of the tunneled IP datagram) represents non-meaningful information, and at the egress node or during PHP, the ingress TTL (iTTL) is equal to the TTL of the popped MPLS header (see Section 3.1 of RFC 3443). In consequence, for Uniform Model LSPs of more than one hop, the TTL at ingress (iTTL) will be less than 255 (x <= 254), and as a result the check described in Section 3 of this document will fail. The TTL treatment is identical between Short Pipe Model LSPs without PHP and Pipe Model LSPs (without PHP only). For these cases, RFC 3443 states that: For each pushed Pipe Model or Short Pipe Model label, the TTL field is set to a value configured by the network operator. In most implementations, this value is set to 255 by default. In these models, the forwarding treatment at egress is based on the tunneled packet as opposed to the encapsulation packet. The ingress TTL (iTTL) is the value of the TTL field of the header that is exposed, that is the tunneled IP datagram's TTL. The protocol packet's TTL as seen by the LSP termination can therefore be set to an arbitrary value (including 255). If the LSP termination router is also the protocol peer, it is possible to deliver the protocol packet with a TTL of 255 (x = 255). Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled packet is unchanged after the PHP operation. Therefore, the same conclusions drawn regarding the Short Pipe Model LSPs without PHP and Pipe Model LSPs (without PHP only) apply to this case. For Short Pipe Model LSPs, the TTL at egress has the same value with or without PHP. In conclusion, GTSM checks are possible for IP tunneled over Pipe model LSPs, but not for IP tunneled over Uniform model LSPs. Additionally, for all tunneling modes, if the LSP termination router needs to forward the protocol packet to a directly connected protocol peer, it is not possible to deliver the protocol packet to the protocol peer with a TTL of 255. If the packet is further forwarded, the outgoing TTL (oTTL) is calculated by decrementing iTTL by one.
Section 2, an attacker directly connected to one interface can disturb a GTSM-protected session on the same or another interface (by spoofing a GTSM peer's address) unless ingress filtering has been applied on the connecting interface. As a result, interfaces that do not include such protection need to be trusted not to originate attacks on the router. Section 3, non-initial IP fragments would likely be classified with Unknown trustworthiness. And since the IP packet would need to be reassembled in order to be processed, the end result is that the initial-fragment of a GTSM- enabled session effectively receives the treatment of an Unknown- trustworthiness packet, and the complete reassembled packet receives the aggregate of the Unknowns. In principle, an implementation could remember the TTL of all received fragments. Then when reassembling the packet, verify that the TTL of all fragments match the required value for an associated GTSM-enabled session. In the likely common case that the implementation does not do this check on all fragments, then it is possible for a legitimate first fragment (which passes the GTSM check) to be combined with spoofed non-initial fragments, implying that the integrity of the received packet is unknown and unprotected. If this check is performed on all fragments at reassembly, and some fragment does not pass the GTSM check for a GTSM-enabled session, the reassembled packet is categorized as a Dangerous-trustworthiness packet and receives the corresponding treatment. Further, reassembly requires to wait for all the fragments and therefore likely invalidates or weakens the fifth assumption presented in Section 2: it may not be possible to classify non- initial fragments before going through a scarce resource in the system, when fragments need to be buffered for reassembly and later processed by a CPU. That is, when classification cannot be done with the required granularity, non-initial fragments of GTSM-enabled session packets would not use different resource pools. Consequently, to get practical protection from fragment attacks, operators may need to rate-limit or discard all received fragments. As such, it is highly RECOMMENDED for GTSM-protected protocols to
avoid fragmentation and reassembly by manual MTU tuning, using adaptive measures such as Path MTU Discovery (PMTUD), or any other available method [RFC1191], [RFC1981], or [RFC4821]. Appendix A). In order to avoid having to quantify the degree of protection and the resulting applicability of multi-hop, we only describe the single-hop case because its security properties are clearer. Section 2.2 for more). Experimentation on GTSM's applicability and security properties is needed in multi-hop scenarios. The multi-hop scenarios where GTSM might be applicable is expected to have the following characteristics: the topology between peers is fairly static and well-known, and in which the intervening network (between the peers) is trusted. RFC3682] did not specify how to handle "related messages" (ICMP errors). This specification mandates setting and verifying TTL=255 of those as well as the main protocol packets. Setting TTL=255 in related messages does not cause issues for RFC 3682 implementations. Requiring TTL=255 in related messages may have impact with RFC 3682 implementations, depending on which default TTL the implementation uses for originated packets; some implementations are known to use 255, while 64 or other values are also used. Related messages from the latter category of RFC 3682 implementations would be classified
as Dangerous and treated as described in Section 3. This is not believed to be a significant problem because protocols do not depend on related messages (e.g., typically having a protocol exchange for closing the session instead of doing a TCP-RST), and indeed the delivery of related messages is not reliable. As such, related messages typically provide an optimization to shorten a protocol keepalive timeout. Regardless of these issues, given that related messages provide a significant attack vector to e.g., reset protocol sessions, making this further restriction seems sensible. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002. [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and BITW' on int-area list, Message-ID: <Pine.LNX.firstname.lastname@example.org>", June 2006, <http://www1.ietf.org/mail-archive/web/ int-area/current/msg00267.html>. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
RFC 3682 was Experimental). o New text on GTSM applicability and use in new and existing protocols. o Restrict the scope to not specify multi-hop scenarios. o Explicitly require that related messages (ICMP errors) must also be sent and checked to have TTL=255. See Section 6.1 for discussion on backwards compatibility. o Clarifications relating to fragmentation, security with tunneling, and implications of ingress filtering. o A significant number of editorial improvements and clarifications.
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.