diff options
Diffstat (limited to 'doc/rfc/rfc5082.txt')
| -rw-r--r-- | doc/rfc/rfc5082.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc5082.txt b/doc/rfc/rfc5082.txt new file mode 100644 index 0000000..c0bd986 --- /dev/null +++ b/doc/rfc/rfc5082.txt @@ -0,0 +1,899 @@ + + + + + + +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: + + 1. The vast majority of protocol peerings are between adjacent + routers. + + 2. 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. + + 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. + + + + + + + +Gill, et al. Standards Track [Page 3] + +RFC 5082 GTSM October 2007 + + +2.1. GTSM Negotiation + + This document assumes that, when used with existing protocols, GTSM + will be manually configured between protocol peers. That is, no + automatic GTSM capability negotiation, such as is 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 (clearly, 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., 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: 1) there are no tunneled packets terminating on the + router, 2) tunnels terminating on the router are assumed to be secure + and endpoints are trusted, 3) tunnel decapsulation includes source + address spoofing prevention [RFC3704], or 4) the GTSM-enabled session + does not allow protocol packets coming from a tunnel. + + + + +Gill, et al. Standards Track [Page 4] + +RFC 5082 GTSM October 2007 + + + 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 in order to remain 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 are + 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 under some configurations decremented in the + forwarding plane. 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. + + + + +Gill, et al. Standards Track [Page 5] + +RFC 5082 GTSM October 2007 + + + + 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 + + The use of the TTL field to protect BGP originated with many + different people, including Paul Traina and Jon Stewart. Ryan + McDowell also suggested a similar idea. Steve Bellovin, Jay + Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk, + and Alex Zinin also provided useful feedback on earlier versions of + this document. David Ward provided insight on the generalization of + the original BGP-specific idea. Alex Zinin, Alia Atlas, and John + Scudder provided a significant amount of feedback for the newer + versions of the document. During and after the IETF Last Call, + useful comments were provided by Francis Dupont, Sam Hartman, Lars + Eggert, and Ross Callon. + +5. Security Considerations + + GTSM is a simple procedure that protects single-hop protocol + sessions, except in those cases in which the peer has been + compromised. In particular, it does not protect against the wide + range of on-the-wire attacks; protection from these attacks requires + more rigorous security mechanisms. + + + + + +Gill, et al. Standards Track [Page 6] + +RFC 5082 GTSM October 2007 + + +5.1. TTL (Hop Limit) Spoofing + + The approach described here is based on the observation that a TTL + (or Hop Limit) value of 255 is non-trivial to spoof, since as the + packet passes through routers towards the destination, the TTL is + decremented by one per router. As a result, when a router receives a + packet, it may not be able to determine if the packet's IP address is + valid, but it can determine how many router hops away it is (again, + assuming none of the routers in the path are compromised in such a + way that they would reset the packet's TTL). + + Note, however, that while engineering a packet's TTL such that it has + a particular value when sourced from an arbitrary location is + difficult (but not impossible), engineering a TTL value of 255 from + non-directly connected locations is not possible (again, assuming + none of the directly connected neighbors are compromised, the packet + has not 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, as well as how the tunneled + packets are protected in flight. Such mechanisms are, however, + beyond the scope of this memo. + + An exception to the observation that a packet with TTL of 255 is + difficult to spoof may occur when a protocol packet is tunneled and + the tunnel is not integrity-protected (i.e., the lower layer is + compromised). + + When the protocol packet is tunneled directly to the protocol peer + (i.e., the protocol peer is the decapsulator), the GTSM provides some + limited added protection as the security depends entirely on the + integrity of the tunnel. + + For protocol adjacencies over a tunnel, if the tunnel itself is + deemed secure (i.e., the underlying infrastructure is deemed secure, + and the tunnel offers degrees of protection against spoofing such as + keys or cryptographic security), the GTSM can serve as a check that + the protocol packet did not originate beyond the head-end of the + tunnel. In addition, if the protocol peer can receive packets for + the GTSM-protected protocol session from outside the tunnel, the GTSM + can help thwart attacks from beyond the adjacent router. + + When the tunnel tail-end decapsulates the protocol packet and then + IP-forwards the packet to a directly connected protocol peer, the TTL + is decremented as described below. This means that the tunnel + + + +Gill, et al. Standards Track [Page 7] + +RFC 5082 GTSM October 2007 + + + 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]. + +5.2.1. IP Tunneled over IP + + Protocol packets may 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 tunneling IP over + IP include IP-in-IP [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 + + + +Gill, et al. Standards Track [Page 8] + +RFC 5082 GTSM October 2007 + + + 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). + +5.2.2. IP Tunneled over MPLS + + Protocol packets may also be tunneled over MPLS Label Switched Paths + (LSPs) to a protocol peer. The following diagram depicts the + topology. + + Peer router -------- LSP Termination router and peer + TTL=255 MPLS LSP [TTL=x at ingress] + + MPLS LSPs can operate in Uniform or Pipe tunneling models. The TTL + handling for these models is described in RFC 3443 [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). + + + + + + + +Gill, et al. Standards Track [Page 9] + +RFC 5082 GTSM October 2007 + + + 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. + + + + + + + +Gill, et al. Standards Track [Page 10] + +RFC 5082 GTSM October 2007 + + +5.3. Onlink Attackers + + As described in 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. + +5.4. Fragmentation Considerations + + As mentioned, fragmentation may restrict the amount of information + available for classification. Since non-initial IP fragments do not + contain Layer 4 information, it is highly likely that they cannot be + associated with a registered GTSM-enabled session. Following the + receiving protocol procedures described in 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 + + + +Gill, et al. Standards Track [Page 11] + +RFC 5082 GTSM October 2007 + + + 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]. + +5.5. Multi-Hop Protocol Sessions + + GTSM could possibly offer some small, though difficult to quantify, + degree of protection when used with multi-hop protocol sessions (see + 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. + +6. Applicability Statement + + GTSM is only applicable to environments with inherently limited + topologies (and is most effective in those cases where protocol peers + are directly connected). In particular, 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 will not protect from attacks + from directly connected devices on the same interface (see + 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. + +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 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 + + + +Gill, et al. Standards Track [Page 12] + +RFC 5082 GTSM October 2007 + + + 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. + +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. + + + + + +Gill, et al. Standards Track [Page 13] + +RFC 5082 GTSM October 2007 + + +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. + + + + + + + + + + + + + + + + + + + + + + +Gill, et al. Standards Track [Page 14] + +RFC 5082 GTSM October 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 non-directly connected sessions 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). As such + deployment is expected to have a more limited applicability and + different security implications, it is not specified in this + document. + +Appendix B. Changes Since RFC 3682 + + o Bring the work on the Standards Track (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. + +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.com + + + +Gill, et al. Standards Track [Page 15] + +RFC 5082 GTSM October 2007 + + +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 + ietf-ipr@ietf.org. + + + + + + + + + + + + +Gill, et al. Standards Track [Page 16] + |