RFC 5082
The Generalized TTL Security Mechanism (GTSM)
RFC 5082: The Generalized TTL Security Mechanism (GTSM) 🎀
okay bestie, this one is Standards Track, so it's an official Internet standards doc 💅 It was published in October 2007 by V. Gill, J. Heasley, D. Meyer, P. Savola (Ed.), and C. Pignataro. It obsoletes RFC 3682, which was an Experimental doc, and it doesn't claim to update anything else. The title is literally The Generalized TTL Security Mechanism (GTSM), and yes, it's giving main character 🦋
Status of This Memo 💖
this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈
Abstract ✨
okay so the thing is, lots of recent protocols already check a packet's Time to Live (TTL) on IPv4 or its Hop Limit on IPv6 to figure out whether the packet came from an adjacent node on a connected link 👀 This doc takes that trick and generalizes it 🧚 This document obsoletes Experimental RFC 3682.
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 . . . . . . . . . . . . . . . 151. Introduction 🧚
okay so GTSM (the Generalized TTL Security Mechanism) exists to protect a router's IP-based control plane from CPU-utilization-based attacks 🛡️ Cryptographic techniques can protect router infrastructure like BGP [RFC4271], [RFC4272] from a wide variety of attacks, which is iconic, but a lot of attacks based on CPU overload can be stopped by the simple mechanism described in this document 💅 ngl the same trick also protects against other scarce-resource attacks that involve a router's CPU, like attacks against processor-line card bandwidth ✨
GTSM is built on the fact that the vast majority of protocol peerings happen between routers that are adjacent 🫶 So most protocol peerings are either directly between connected interfaces or, in the worst case, loopback to loopback, with static routes to loopbacks 🌸 TTL spoofing is considered nearly impossible, so a mechanism based on an expected TTL value can give you a simple and reasonably robust defense against infrastructure attacks that use forged protocol packets from outside the network 🔥 But heads up, GTSM is not a substitute for authentication mechanisms 😭 It does not protect against insider on-the-wire attacks, like packet spoofing or replay.
Finally, the GTSM mechanism works equally well for TTL (IPv4) and Hop Limit (IPv6), and from GTSM's point of view, TTL and Hop Limit have identical semantics 🦋 So for the rest of this document, the term "TTL" is used to refer 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 RFC 2119 [RFC2119] 📚🎀
2. Assumptions Underlying GTSM 🌈
GTSM is predicated upon the following assumptions, so let's go through them:
- The vast majority of protocol peerings are between adjacent routers.
- Service providers may or may not configure strict ingress filtering [RFC3704] on non-trusted links. If maximal protection is desired, such filtering is necessary as described in Section 2.2.
- Use of GTSM is OPTIONAL, and can be configured on a per-peer (group) basis.
- The peer routers both implement GTSM.
- 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, like 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, since those are hardware and implementation-specific.
However, the possibility of denial-of-service (DoS) attack prevention is based on the assumption that packets are classified and their paths are separated before they 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 👑
2.1. GTSM Negotiation 🍓
This document assumes that, when used with existing protocols, GTSM will be manually configured between protocol peers. That means no automatic GTSM capability negotiation, like the one provided by RFC 3392 [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 ✨
2.2. Assumptions on Attack Sophistication 🕵️♀️
Throughout this document, we assume that potential attackers have evolved in both sophistication and access to the point that they can send control traffic to a protocol session, and that this traffic appears to be valid control traffic (i.e., it has the source/destination of configured peer routers) 😤
We also assume that each router in the path between the attacker and the victim protocol speaker decrements TTL properly. (Obviously, if either the path or the adjacent peer is compromised, then there are worse problems to worry about 💀)
For maximal protection, ingress filtering should be applied before the packet goes through the scarce resource. Otherwise an attacker directly connected to one interface could disturb a GTSM-protected session on the same or another interface. Interfaces that aren't configured with this filtering (e.g., backbone links) are assumed to not have such attackers (i.e., they are trusted) 🦋
As a specific instance of such interfaces, we assume that tunnels are not a back door for allowing TTL-spoofing on protocol packets to a GTSM-protected peering session with a directly connected neighbor. We assume that:
- there are no tunneled packets terminating on the router,
- tunnels terminating on the router are assumed to be secure and endpoints are trusted,
- tunnel decapsulation includes source address spoofing prevention [RFC3704], or
- 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 🙏
3. GTSM Procedure 🌸
If GTSM is not built into the protocol and is used as an additional feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by default, so it stays backward-compatible with the unmodified protocol. However, if the protocol defines a built-in dynamic capability negotiation for GTSM, a protocol peer MAY suggest the use of GTSM, provided that GTSM would only be enabled if both peers agree to use it 🤝
If GTSM is enabled for a protocol session, the following steps get added to the IP packet sending and reception procedures 💅
Sending protocol packets:
The TTL field in all IP packets used for transmission of messages associated with GTSM-enabled protocol sessions MUST be set to 255. This also applies to the related ICMP error handling messages 🫶
On some architectures, the TTL of control plane originated traffic is decremented in the forwarding plane under some configurations. The TTL of GTSM-enabled sessions MUST NOT be decremented 🛑
Receiving protocol packets:
The GTSM packet identification step associates each received packet addressed to the router's control plane with one of the following three trustworthiness categories:
- Unknown: these are packets that cannot be associated with any registered GTSM-enabled session, and hence GTSM cannot make any judgment on the level of risk associated with them.
- Trusted: these are packets that have been identified as belonging to one of the GTSM-enabled sessions, and their TTL values are within the expected range.
- 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. 🗑️
4. Acknowledgments ✨
okay so the TTL trick for protecting BGP came from a LOT of people 🫶 Paul Traina and Jon Stewart were among the first, and Ryan McDowell pitched a similar idea too. Steve Bellovin, Jay Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk, and Alex Zinin gave super helpful feedback on earlier drafts 💜 David Ward helped turn the BGP-specific idea into the general one 🧠 Alex Zinin, Alia Atlas, and John Scudder gave a ton of feedback on the newer versions 🙌 And during and after IETF Last Call, Francis Dupont, Sam Hartman, Lars Eggert, and Ross Callon dropped useful comments. the whole group project energy is iconic 👑
5. Security Considerations 🔐
this section is serious, so read it carefully bestie 😭
okay so GTSM is a simple procedure that protects single-hop protocol sessions, except in cases where the peer has been compromised. it does NOT protect against the wide range of on-the-wire attacks. if you need protection from those, you need more rigorous security mechanisms 💀
5.1. TTL (Hop Limit) Spoofing 🦋
the whole approach is based on one observation: a TTL (or Hop Limit) value of 255 is non-trivial to spoof. why? because every router a packet passes through on its way to the destination decrements the TTL by one 🧚 so when a router gets a packet, it might not be able to tell whether the packet's IP address is valid, but it CAN figure out how many router hops away the packet came from (again, assuming none of the routers in the path are compromised in a way that would reset the packet's TTL).
ngl this part is so clever. engineering a packet's TTL to have a particular value when it's sent from an arbitrary location is difficult (but not impossible) 🥴 BUT engineering a TTL of 255 from locations that aren't directly connected is not possible. this holds again as long as none of the directly connected neighbors are compromised, the packet hasn't been tunneled to the decapsulator, and the intervening routers are operating in accordance with RFC 791 [RFC0791].
5.2. Tunneled Packets 🎀
the security of any tunneling technique depends heavily on authentication at the tunnel endpoints, plus how the tunneled packets are protected while they're in flight. those mechanisms are, however, beyond the scope of this memo, so you'll have to look elsewhere for them 🙈
there's an exception to the "TTL of 255 is hard to spoof" idea: it can happen when a protocol packet is tunneled and the tunnel is NOT integrity-protected (aka the lower layer is compromised) 😬
when the protocol packet is tunneled directly to the protocol peer (so the peer is the decapsulator), GTSM gives some limited extra protection, because the security depends entirely on the integrity of the tunnel 🌸
for protocol adjacencies over a tunnel, if the tunnel itself is deemed secure (the underlying infrastructure is secure, and the tunnel offers spoofing protection like keys or cryptographic security), GTSM can act as a check that the protocol packet didn't originate beyond the head-end of the tunnel ✨ and if the protocol peer can receive packets for the GTSM-protected session from outside the tunnel, GTSM can help stop attacks coming from beyond the adjacent router 💅
when the tunnel tail-end decapsulates the protocol packet and then IP-forwards it to a directly connected protocol peer, the TTL gets decremented as described below. that means the tunnel decapsulator is the penultimate node from the GTSM-protected peer's point of view. so the GTSM check protects against attackers encapsulating packets to your peers 🫶 BUT there are specific cases where the connection from the decapsulator to the protocol peer is NOT an IP forwarding hop, so the TTL never gets decremented (e.g., layer-2 tunneling, bridging, etc). in the IPsec architecture [RFC4301], another example is Bump-in-the-Wire (BITW) [BITW] 👀
5.2.1. IP Tunneled over 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 of IP-over-IP tunneling are IP-in-IP [RFC2003], GRE [RFC2784], and various forms of IPv6-in-IPv4 (e.g., [RFC4213]). here's how those cases look:
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 (the 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 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.
in the first case, the encapsulated packet goes straight to the protocol peer (who is also a tunnel endpoint), so the peer can receive the encapsulated packet's TTL with an arbitrary value, including 255 🧁
in the second case, the encapsulated packet goes 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 this 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.
so 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's possible to deliver the protocol packet with a TTL of 255 (first case). but if the decapsulator has to forward the protocol packet to a directly connected protocol peer, the TTL gets decremented (second case). that's the whole plot twist 🎬
5.2.2. IP Tunneled over MPLS 💜
protocol packets can also be tunneled over MPLS Label Switched Paths (LSPs) to a protocol peer. here's the topology:
Peer router -------- LSP Termination router and peer
TTL=255 MPLS LSP [TTL=x at ingress]MPLS LSPs can run in Uniform or Pipe tunneling models. the TTL handling for these models is described in RFC 3443 [RFC3443], which updates RFC 3032 [RFC3032] on TTL processing in MPLS networks. RFC 3443 specifies TTL processing in both Uniform and Pipe Models, which can be used with or without penultimate hop popping (PHP) 🫠 TTL processing in these cases gives different behaviors, so they get analyzed separately. please refer to Section 3.1 through Section 3.3 of RFC 3443 📚
the main difference from a TTL perspective, between Uniform and Pipe Models at the LSP termination node, is how the incoming TTL (iTTL) gets determined. the tunneling model decides the iTTL: for Uniform Model LSPs, the iTTL is the TTL value from the popped MPLS header (the encapsulating header), while for Pipe Model LSPs, the iTTL is the TTL value from the exposed header (the 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 that point on, the inner TTL (i.e., the TTL of the tunneled IP datagram) is non-meaningful information 🙃 at the egress node or during PHP, the ingress TTL (iTTL) equals the TTL of the popped MPLS header (see Section 3.1 of RFC 3443). as a result, for Uniform Model LSPs of more than one hop, the TTL at ingress (iTTL) will be less than 255 (x <= 254), and 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 rather than the encapsulation packet. the ingress TTL (iTTL) is the TTL of the exposed header, which is the tunneled IP datagram's TTL. so the protocol packet's TTL as seen by the LSP termination can be set to an arbitrary value (including 255). if the LSP termination router is ALSO the protocol peer, it's 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. so the same conclusions for Short Pipe Model LSPs without PHP and Pipe Model LSPs (without PHP only) apply here too. 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 🥲 also, for all tunneling modes, if the LSP termination router needs to forward the protocol packet to a directly connected protocol peer, it's not possible to deliver the protocol packet to that peer with a TTL of 255. if the packet is forwarded further, the outgoing TTL (oTTL) is calculated by decrementing iTTL by one 🧮
5.3. Onlink Attackers 😈
as described in Section 2, an attacker directly connected to one interface can disrupt 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. so interfaces without that protection need to be trusted not to originate attacks on the router 🚨
5.4. Fragmentation Considerations ✨
okay so remember how fragmentation can make packets harder to classify? 🧩 Non-initial IP fragments don't carry any Layer 4 information, so they're highly likely to be impossible to associate with a registered GTSM-enabled session 😭. Following the receiving procedures in Section 3, non-initial fragments would likely get classified as Unknown trustworthiness. And since the whole packet has to be reassembled before it can be processed, the initial fragment of a GTSM-enabled session basically gets treated like an Unknown-trustworthiness packet, and the fully reassembled packet ends up with the combined treatment of all those Unknowns 💀.
In principle, an implementation could remember the TTL of every fragment it receives. Then, when it reassembles the packet, it could verify that every fragment's TTL matches the required value for an associated GTSM-enabled session 🧐. But in the likely common case where the implementation doesn't check every fragment, a legit first fragment (which passes the GTSM check) could get combined with spoofed non-initial fragments. That means the integrity of the received packet is unknown and unprotected 🙈. If the check runs on all fragments at reassembly and any one of them fails the GTSM check for a GTSM-enabled session, the reassembled packet is categorized as Dangerous-trustworthiness and gets the corresponding treatment 🚨.
Also, reassembly means waiting for all the fragments, which likely invalidates or weakens the fifth assumption from Section 2 🥲. It may not be possible to classify non-initial fragments before they pass through a scarce resource in the system, since fragments have to be buffered for reassembly and later processed by a CPU. In other words, when classification can't be done with the required granularity, non-initial fragments of GTSM-enabled session packets wouldn't use different resource pools.
So, to get practical protection from fragment attacks, operators may need to rate-limit or discard all received fragments 🛡️. It is highly RECOMMENDED for GTSM-protected protocols to avoid fragmentation and reassembly by manual MTU tuning, by using adaptive measures such as Path MTU Discovery (PMTUD), or by any other available method [RFC1191], [RFC1981], or [RFC4821] 💖.
5.5. Multi-Hop Protocol Sessions 🌸
GTSM could possibly offer some small, though hard to quantify, degree of protection when used with multi-hop protocol sessions (see Appendix A). To avoid having to quantify that protection and figure out what it means for multi-hop applicability, we only describe the single-hop case, because its security properties are clearer 🧠.
6. Applicability Statement 🎀
GTSM is only applicable to environments with inherently limited topologies, and it's most effective when protocol peers are directly connected 🔗. Its application should be limited to those cases in which protocol peers are directly connected.
GTSM will not protect against attackers who are as close to the protected station as its legitimate peer 😬. For example, if the legitimate peer is one hop away, GTSM won't protect against attacks from directly connected devices on the same interface (see Section 2.2 for more).
Experimentation on GTSM's applicability and security properties is still needed in multi-hop scenarios 🔬. The multi-hop scenarios where GTSM might be applicable are expected to have these characteristics: the topology between peers is fairly static and well-known, and the intervening network (between the peers) is trusted 🦋.
6.1. Backwards Compatibility 🔙
RFC 3682 [RFC3682] did not specify how to handle "related messages" (ICMP errors) 🙃. This specification mandates setting and verifying TTL=255 for those as well as for 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 an impact on 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 that 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 don't depend on related messages. For example, a protocol will typically do an exchange to close the session instead of doing a TCP-RST, and the delivery of related messages isn't reliable anyway 🤷♀️. As such, related messages typically provide an optimization to shorten a protocol keepalive timeout. Regardless of all that, given that related messages provide a significant attack vector (e.g., to reset protocol sessions), making this further restriction seems sensible 🔐.
7. References 📚
7.1. Normative References
[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.7.2. Informative References
[BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and
BITW' on int-area list, Message-ID:
<Pine.LNX.4.64.0606020830220.12705@netcore.fi>",
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.Appendix A. Multi-Hop GTSM 🧚
NOTE: This is a non-normative part of the specification.
The main applicability of GTSM is for directly connected peers 🔗. GTSM could be used for sessions that aren't directly connected as well, where the recipient would check that the TTL is within a configured number of hops from 255 (e.g., check that packets have 254 or 255). Since that kind of deployment is expected to have more limited applicability and different security implications, it is not specified in this document.
Appendix B. Changes Since RFC 3682 🍓
- Bring the work on the Standards Track (RFC 3682 was Experimental).
- New text on GTSM applicability and use in new and existing protocols.
- Restrict the scope to not specify multi-hop scenarios.
- 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.
- Clarifications relating to fragmentation, security with tunneling, and implications of ingress filtering.
- A significant number of editorial improvements and clarifications.
Authors' Addresses 💌
Vijay Gill
EMail: vijay@umbc.edu
John Heasley
EMail: heas@shrubbery.net
David Meyer
EMail: dmm@1-4-5.net
Pekka Savola (editor)
Espoo
Finland
EMail: psavola@funet.fi
Carlos Pignataro
EMail: cpignata@cisco.comFull Copyright Statement 📜
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions in BCP 78. Except as set forth there, the authors keep all their rights 💜.
This document and the information in it are provided on an "AS IS" basis, and the disclaimer below applies in full:
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 on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope 🧾. It also doesn't say whether any license for those rights is available, and it hasn't made any independent effort to find such rights. For the rules about rights in RFC documents, check out BCP 78 and BCP 79 📖.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users to use these proprietary rights can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍.
The IETF invites anyone who's interested to bring any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard to its attention. Send that information to the IETF at ietf-ipr@ietf.org 💅.
📦 where this page comes from
- ietf: rfc5082 2007-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms