Network Working Group V. Gill
Request for Comments: 3682 J. Heasley
Category: Experimental D. Meyer
February 2004
Network Working Group V. Gill
Request for Comments: 3682 J. Heasley
Category: Experimental D. Meyer
February 2004
The Generalized TTL Security Mechanism (GTSM)
广义TTL安全机制（GTSM）
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), Bidirectional Forwarding Detection, and Label Distribution Protocol (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis.
在许多设置中，都建议使用数据包的生存时间（TTL）（IPv4）或跃点限制（IPv6）来保护协议栈免受基于CPU利用率的攻击（例如，请参见RFC 2461）。本文档概括了这些技术，以供其他协议使用，如BGP（RFC 1771）、多播源发现协议（MSDP）、双向转发检测和标签分发协议（LDP）（RFC 3036）。虽然广义TTL安全机制（GTSM）在保护直接连接的协议对等方方面最为有效，但它也可以为多跳会话提供较低级别的保护。GTSM不直接适用于采用泛洪机制（例如，多播）的协议，应根据具体情况考虑使用多跳GTSM。
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
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
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
The Generalized TTL Security Mechanism (GTSM) is designed to protect a router's TCP/IP based control plane from CPU-utilization based attacks. In particular, while cryptographic techniques can protect the router-based infrastructure (e.g., BGP [RFC1771], [RFC1772]) from a wide variety of attacks, many attacks based on CPU overload can be prevented by the simple mechanism described in this document. Note that the same technique protects against other scarce-resource attacks involving a router's CPU, such as attacks against processor-line card bandwidth.
广义TTL安全机制（GTSM）旨在保护路由器基于TCP/IP的控制平面免受基于CPU利用率的攻击。特别是，虽然密码技术可以保护基于路由器的基础设施（例如，BGP[RFC1771]、[RFC1772]）免受各种攻击，但许多基于CPU过载的攻击可以通过本文档中描述的简单机制来防止。请注意，相同的技术可以防止涉及路由器CPU的其他稀缺资源攻击，例如针对处理器线路卡带宽的攻击。
GTSM is based on the fact that the vast majority of protocol peerings are established between routers that are adjacent [PEERING]. Thus most protocol peerings are either directly between connected interfaces or at the worst case, are between loopback and loopback, with static routes to loopbacks. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value can provide a simple and reasonably robust defense from infrastructure attacks based on forged protocol packets.
GTSM基于这样一个事实，即绝大多数协议对等是在相邻的路由器之间建立的[对等]。因此，大多数协议对等要么直接在连接的接口之间，要么在最坏的情况下，在环回和环回之间，通过静态路由到环回。由于TTL欺骗被认为几乎是不可能的，因此基于预期TTL值的机制可以针对基于伪造协议包的基础设施攻击提供简单而合理的鲁棒防御。
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).
最后，GTSM机制同样适用于TTL（IPv4）和跃点限制（IPv6），并且从GTSM的角度来看，TTL和跃点限制具有相同的语义。因此，在本文件的其余部分中，术语“TTL”用于指TTL或跃点限制（视情况而定）。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
GTSM is predicated upon the following assumptions:
GTSM基于以下假设：
(i) The vast majority of protocol peerings are between adjacent routers [PEERING].
(i) 绝大多数协议对等是在相邻路由器之间进行的[对等]。
(ii) It is common practice for many service providers to ingress filter (deny) packets that have the provider's loopback addresses as the source IP address.
（ii）许多服务提供商通常会过滤（拒绝）以提供商的环回地址作为源IP地址的数据包。
(iii) Use of GTSM is OPTIONAL, and can be configured on a per-peer (group) basis.
（iii）GTSM的使用是可选的，可以在每个对等（组）的基础上进行配置。
(iv) The router supports a method of classifying traffic destined for the route processor into interesting/control and not-control queues.
（iv）路由器支持将目的地为路由处理器的流量分类为感兴趣/控制和非控制队列的方法。
(iv) The peer routers both implement GTSM.
（iv）对等路由器均实现GTSM。
This document assumes that GTSM will be manually configured between protocol peers. That is, no automatic GTSM capability negotiation, such as is envisioned by RFC 2842 [RFC2842] is assumed or defined.
本文档假设GTSM将在协议对等方之间手动配置。也就是说，未假设或定义RFC 2842[RFC2842]设想的自动GTSM能力协商。
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., 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).
我们还假设攻击者和受害者协议说话人之间的路径中的每个路由器都会适当地减少TTL（显然，如果路径或相邻对等方受到破坏，那么就有更糟糕的问题需要担心）。
Since the vast majority of our 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 which do NOT have an inbound TTL of 255.
由于我们的绝大多数对等是在相邻路由器之间进行的，因此我们可以将协议数据包上的TTL设置为255（IP的最大可能值），然后拒绝来自配置的对等方的任何协议数据包，这些对等方的入站TTL不为255。
GTSM can be disabled for applications such as route-servers and other large diameter multi-hop peerings. In the event that an the attack comes in from a compromised multi-hop peering, that peering can be shut down (a method to reduce exposure to multi-hop attacks is outlined below).
对于路由服务器和其他大直径多跳对等应用程序，可以禁用GTSM。如果攻击来自受损的多跳对等，则可以关闭该对等（下面概述了一种减少多跳攻击暴露的方法）。
GTSM SHOULD NOT be enabled by default. The following process describes the per-peer behavior:
默认情况下不应启用GTSM。以下过程描述了每个对等方的行为：
(i) If GTSM is enabled, an implementation performs the following procedure:
(i) 如果启用了GTSM，则执行以下步骤：
(a) For directly connected routers,
(a) 对于直接连接的路由器，
o Set the outbound TTL for the protocol connection to 255.
o 将协议连接的出站TTL设置为255。
o For each configured protocol peer:
o 对于每个配置的协议对等方：
Update the receive path Access Control List (ACL) or firewall to only allow protocol packets to pass onto 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 to achieve some robustness to changes in topology. Any directly connected check MUST be disabled for such peerings.
更新接收路径访问控制列表（ACL）或防火墙，以仅允许协议数据包传递到具有正确<source，destination，TTL>元组的路由处理器（RP）。TTL必须为255（对于直接连接的对等方），或255（可接受跳数的配置范围），对于多跳对等方。我们在这里指定一个范围，以实现对拓扑变化的一些鲁棒性。对于此类对等，必须禁用任何直接连接的检查。
It is assumed that a receive path ACL is an ACL that is designed to control which packets are allowed to go to the RP. This procedure will only allow protocol packets from adjacent router to pass onto the RP.
假设接收路径ACL是一个ACL，用于控制允许哪些数据包进入RP。此过程仅允许来自相邻路由器的协议数据包进入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. Rather, the packet is placed into a low priority queue, and subsequently logged and/or silently discarded. In this case, an ICMP message MUST NOT be generated.
(b) 如果入站TTL为255（对于直接连接的对等方）或255（可接受跳数的配置范围）（对于多跳对等方），则不处理数据包。相反，数据包被放入一个低优先级队列，随后被记录和/或静默丢弃。在这种情况下，不得生成ICMP消息。
(ii) If GTSM is not enabled, normal protocol behavior is followed.
（ii）如果未启用GTSM，则遵循正常协议行为。
When a multi-hop protocol session is required, we set the expected TTL value to be 255-(configured-range-of-acceptable-hops). This approach provides a qualitatively lower degree of security for the protocol implementing GTSM (i.e., a DoS attack could theoretically be launched by compromising some box in the path). However, GTSM will still catch the vast majority of observed DDoS attacks against a given protocol. Note that since the number of hops can change rapidly in real network situations, it is considered that GTSM may not be able to handle this scenario adequately and an implementation MAY provide OPTIONAL support.
当需要多跳协议会话时，我们将预期的TTL值设置为255-（可接受跳的配置范围）。这种方法为实现GTSM的协议提供了质量上较低的安全性（即，理论上可以通过破坏路径中的某些框来发起DoS攻击）。但是，GTSM仍将捕获针对给定协议的绝大多数观察到的DDoS攻击。请注意，由于跳数在实际网络情况下可能会快速变化，因此认为GTSM可能无法充分处理该场景，并且实现可能提供可选支持。
In general, GTSM is not 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 that has a source address of one of the loopback addresses used for the intra-domain peering. In addition, the current best practice is to further protect such peers or adjacencies with an MD5 signature [RFC2385].
一般来说，GTSM不用于域内协议对等点或邻接。iBGP对等的特殊情况可以通过在网络边缘过滤具有用于域内对等的环回地址之一的源地址的任何分组来保护。此外，当前的最佳实践是使用MD5签名[RFC2385]进一步保护此类对等点或邻接。
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, Vern Paxon, Pekka Savola, and Robert Raszuk also provided useful feedback on earlier versions of this document. David Ward provided insight on the generalization of the original BGP-specific idea.
使用TTL字段保护BGP起源于许多不同的人，包括保罗·特拉纳和乔恩·斯图尔特。Ryan McDowell也提出了类似的想法。Steve Bellovin、Jay Borkenhagen、Randy Bush、Vern Paxon、Pekka Savola和Robert Raszuk也提供了关于本文档早期版本的有用反馈。David Ward就BGP最初的具体想法的概括提供了见解。
GTSM is a simple procedure that protects single hop protocol sessions, except in those cases in which the peer has been compromised.
GTSM是一个保护单跳协议会话的简单过程，但对等方受到损害的情况除外。
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. 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).
这里描述的方法基于这样的观察，即TTL（或跃点限制）值255对于欺骗来说是非常重要的，因为当数据包通过路由器到达目的地时，TTL会减少1。因此，当路由器接收到数据包时，它可能无法确定该数据包的IP地址是否有效，但它可以确定该数据包的跳转次数（同样，假设路径中的所有路由器都不会以重置数据包的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 hasn't been tunneled to the decapsulator, and the intervening routers are operating in accordance with RFC 791 [RFC791]).
然而，请注意，虽然设计数据包的TTL以使其在来源于任意位置时具有特定值是困难的（但并非不可能），但从非直接连接位置设计255的TTL值是不可能的（同样，假设没有任何直接连接的邻居受到损害，则数据包没有通过隧道传输到解封装器，并且中间路由器按照RFC 791[RFC791]运行）。
An exception to the observation that a packet with TTL of 255 is difficult to spoof occurs when a protocol packet is tunneled to a decapsulator who then forwards the packet to a directly connected protocol peer. In this case the decapsulator (tunnel endpoint) can either be the penultimate hop, or the last hop itself. A related case arises when the protocol packet is tunneled directly to the protocol peer (the protocol peer is the decapsulator).
TTL为255的数据包很难欺骗的观察结果的一个例外情况是，协议数据包通过隧道传输到解封装器，然后由解封装器将数据包转发给直接连接的协议对等方。在这种情况下，解封装器（隧道端点）可以是倒数第二个跃点，也可以是最后一个跃点本身。当协议分组直接通过隧道传输到协议对等方（协议对等方是解封装器）时，会出现相关情况。
When the protocol packet is encapsulated in IP, it is possible to spoof the TTL. It may also be impossible to legitimately get the packet to the protocol peer with a TTL of 255, as in the IP in MPLS cases described below.
当协议包封装在IP中时，就有可能欺骗TTL。也可能无法合法地将数据包发送到TTL为255的协议对等方，如下文所述的MPLS情况下的IP。
Finally, note that 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.
最后，请注意，任何隧道技术的安全性在很大程度上取决于隧道端点处的身份验证，以及隧道数据包在飞行中的保护方式。然而，此类机制超出了本备忘录的范围。
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 (e.g., in IP-in-IP [RFC2003], GRE [RFC2784], or various forms of IPv6-in-IPv4 [RFC2893]). These cases are depicted below.
协议分组可通过IP直接隧道至协议对等方，或隧道至解封装器（隧道端点），该解封装器随后将分组转发至直接连接的协议对等方（例如，IP-in-IP[RFC2003]、GRE[RFC2784]或各种形式的IPv6-in-IPv4[RFC2893]）。这些案例描述如下。
Peer router ---------- Tunnel endpoint router and peer
TTL=255 [tunnel] [TTL=255 at ingress]
[TTL=255 at egress]
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]
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, in which the encapsulated packet is tunneled directly to the protocol peer, the encapsulated packet's TTL can be set arbitrary value. In the second case, in which the encapsulated packet is tunneled to a decapsulator (tunnel endpoint) which then forwards it to a directly connected protocol peer, RFC 2003 specifies the following behavior:
在第一种情况下，其中封装的分组直接通过隧道传输到协议对等方，封装的分组的TTL可以设置为任意值。在第二种情况下，封装的数据包通过隧道传输到解封装器（隧道端点），然后再将其转发到直接连接的协议对等方，RFC 2003指定以下行为：
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
当封装数据报时，如果作为转发数据报的一部分正在进行隧道传输，则内部IP报头中的TTL减小1；否则，内部标头TTL在封装期间不会更改。如果内部IP报头中的结果TTL为0，则丢弃数据报并返回ICMP时间
Exceeded message SHOULD be returned to the sender. An encapsulator MUST NOT encapsulate a datagram with TTL = 0.
超出的邮件应返回给发件人。封装器不能封装TTL=0的数据报。
Hence the inner IP packet header's TTL, as seen by the decapsulator, can be set to an arbitrary value (in particular, 255). As a result, it may not be possible to deliver the protocol packet to the peer with a TTL of 255.
因此，如去封装器所示，内部IP包头的TTL可以设置为任意值（特别是255）。因此，可能无法向TTL为255的对等方发送协议数据包。
Protocol packets may also be tunneled over MPLS to a protocol peer which either the penultimate hop (when the penultimate hop popping (PHP) is employed [RFC3032]), or one hop beyond the penultimate hop. These cases are depicted below.
协议分组也可以通过MPLS隧道传输到协议对等方，该对等方可以是倒数第二跳（当使用倒数第二跳弹出（PHP）时[RFC3032]），也可以是倒数第二跳之外的一跳。这些案例描述如下。
Peer router ---------- Penultimate Hop (PH) and peer
TTL=255 [tunnel] [TTL=255 at ingress]
[TTL<=254 at egress]
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]
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. RFC 3032 states that when the IP packet is first labeled:
RFC 3032中描述了这些情况的TTL处理。RFC 3032规定，当IP数据包首次标记时：
... 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.)
... 标签堆栈项的TTL字段必须设置为IP TTL字段的值。（如果作为IP处理的一部分，需要减少IP TTL字段，则假定已完成此操作。）
When the label is 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.
当弹出标签时，结果标签堆栈为空，则IP TTL字段的值应替换为传出TTL值，如上所述。在IPv4中，这还需要修改IP报头校验和。
where the definition of "outgoing TTL" is:
其中，“传出TTL”的定义为：
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.
标签数据包的“传入TTL”定义为接收数据包时顶部标签堆栈条目的TTL字段的值。
The "outgoing TTL" of a labeled packet is defined to be the larger of:
标记数据包的“传出TTL”定义为以下两者中的较大值：
a) one less than the incoming TTL, b) zero.
a) 比输入TTL小一个，b）零。
In either of these cases, the minimum value by which the TTL could be decremented would be one (the network operator prefers to hide its infrastructure by decrementing the TTL by the minimum number of LSP hops, one, rather than decrementing the TTL as it traverses its MPLS domain). As a result, the maximum TTL value at egress from the MPLS cloud is 254 (255-1), and as a result the check described in section 3 will fail.
在这两种情况中，TTL可以减少的最小值为1（网络运营商更愿意通过将TTL减少最小LSP跳数1来隐藏其基础设施，而不是在TTL穿过其MPLS域时减少TTL）。因此，MPLS云出口处的最大TTL值为254（255-1），因此第3节中描述的检查将失败。
While the GTSM method is less effective for multi-hop protocol sessions, it does close the window on several forms of attack. However, in the multi-hop scenario GTSM is an OPTIONAL extension. Protection of the protocol infrastructure beyond what is provided by the GTSM method will likely require cryptographic machinery such as is envisioned by Secure BGP (S-BGP) [SBGP1,SBGP2], and/or other extensions. Finally, note that in the multi-hop case described above, we specify a range of acceptable TTLs in order to achieve some robustness to topology changes. This robustness to topological change comes at the cost of the loss of some robustness to different forms of attack.
虽然GTSM方法对多跳协议会话的效果较差，但它确实关闭了几种形式的攻击窗口。但是，在多跳场景中，GTSM是可选的扩展。GTSM方法提供的协议基础设施保护可能需要加密机制，如安全BGP（S-BGP）[SBGP1、SBGP2]和/或其他扩展所设想的机制。最后，请注意，在上述多跳情况下，我们指定了一系列可接受的TTL，以实现对拓扑更改的一些鲁棒性。这种对拓扑变化的鲁棒性是以对不同形式的攻击失去一些鲁棒性为代价的。
This document creates no new requirements on IANA namespaces [RFC2434].
本文档对IANA名称空间[RFC2434]没有新的要求。
[RFC791] Postel, J., "Internet Protocol Specification", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议规范”，标准5，RFC7911981年9月。
[RFC1771] Rekhter, Y. and T. Li (Editors), "A Border Gateway Protocol (BGP-4)", RFC 1771, March 1995.
[RFC1771]Rekhter，Y.和T.Li（编辑），“边界网关协议（BGP-4）”，RFC 17711995年3月。
[RFC1772] Rekhter, Y. and P. Gross, "Application of the Border Gateway Protocol in the Internet", RFC 1772, March 1995.
[RFC1772]Rekhter，Y.和P.Gross，“互联网中边界网关协议的应用”，RFC 1772，1995年3月。
[RFC2003] Perkins, C., "IP Encapsulation with IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP封装与IP”，RFC 2003，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discover for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2784] Farinacci, D., "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，“通用路由封装（GRE）”，RFC2784，2000年3月。
[RFC2842] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000.
[RFC2842]Chandra，R.和J.Scudder，“BGP-4的能力广告”，RFC 2842，2000年5月。
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC2893]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 2893，2000年8月。
[RFC3032] Rosen, E. Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC3392]Chandra，R.和J.Scudder，“BGP-4的能力广告”，RFC 3392，2002年11月。
[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.
[SBGP1]Kent，S.，C.Lynn和K.Seo，“安全边界网关协议（安全BGP）”，IEEE通信选定领域杂志，第18卷，第4期，2000年4月。
[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.
[SBGP2]Kent，S.，C.Lynn，J.Mikkelson和K.Seo，“安全边界网关协议（S-BGP）——现实世界的性能和部署问题”，IEEE网络和分布式系统安全研讨会论文集，2000年2月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, June 2003.
[BFD]Katz，D.和D.Ward，“双向转发检测”，正在进行的工作，2003年6月。
[PEERING] Empirical data gathered from the Sprint and AOL backbones, October, 2002.
[PEERING]从Sprint和AOL主干网收集的经验数据，2002年10月。
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[RFC2028]Hovey，R.和S.Bradner，“参与IETF标准过程的组织”，BCP 11，RFC 2028，1996年10月。
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3618] Meyer, D. and W. Fenner, Eds., "The Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Meyer，D.和W.Fenner，编辑，“多播源发现协议（MSDP）”，RFC 3618，2003年10月。
Vijay Gill
维杰·吉尔
EMail: vijay@umbc.edu
EMail: vijay@umbc.edu
John Heasley
约翰·希斯利
EMail: heas@shrubbery.net
EMail: heas@shrubbery.net
David Meyer
大卫·梅耶尔
EMail: dmm@1-4-5.net
EMail: dmm@1-4-5.net
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is 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.
RFC编辑功能的资金目前由互联网协会提供。