Internet Engineering Task Force (IETF) C. Pignataro
Request for Comments: 6720 R. Asati
Updates: 5036 Cisco Systems
Category: Standards Track August 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Pignataro
Request for Comments: 6720 R. Asati
Updates: 5036 Cisco Systems
Category: Standards Track August 2012
ISSN: 2070-1721
The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)
标签分发协议（LDP）的广义TTL安全机制（GTSM）
Abstract
摘要
The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP).
广义TTL安全机制（GTSM）描述了对数据包生存时间（TTL）（IPv4）或跃点限制（IPv6）的广义使用，以验证数据包是否由连接链路上的节点来源，从而保护路由器的IP控制平面免受基于CPU利用率的攻击。这种技术提高了安全性，并被许多协议使用。本文件定义了用于标签分发协议（LDP）的GTSM。
This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036.
此规范使用RFC 5036中保留的位，因此更新RFC 5036。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6720.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6720.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
1.2. Scope ......................................................3
2. GTSM Procedures for LDP .........................................4
2.1. GTSM Flag in the Common Hello Parameter TLV ................4
2.2. GTSM Sending and Receiving Procedures for LDP Link Hello ...5
2.3. GTSM Sending and Receiving Procedures for LDP
Initialization .............................................5
3. LDP Peering Scenarios and GTSM Considerations ...................5
4. Security Considerations .........................................6
5. Acknowledgments .................................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................8
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................3
1.2. Scope ......................................................3
2. GTSM Procedures for LDP .........................................4
2.1. GTSM Flag in the Common Hello Parameter TLV ................4
2.2. GTSM Sending and Receiving Procedures for LDP Link Hello ...5
2.3. GTSM Sending and Receiving Procedures for LDP
Initialization .............................................5
3. LDP Peering Scenarios and GTSM Considerations ...................5
4. Security Considerations .........................................6
5. Acknowledgments .................................................7
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................8
LDP [RFC5036] specifies two peer discovery mechanisms, a Basic one and an Extended one, both using UDP transport. The Basic Discovery mechanism is used to discover LDP peers that are directly connected at the link level, whereas the Extended Discovery mechanism is used to locate Label Switching Router (LSR) neighbors that are not directly connected at the link level. Once discovered, the LSR neighbors can establish the LDP peering session, using the TCP transport connection.
LDP[RFC5036]指定了两种对等发现机制，一种是基本发现机制，另一种是扩展发现机制，两者都使用UDP传输。基本发现机制用于发现在链路级别直接连接的LDP对等点，而扩展发现机制用于定位在链路级别不直接连接的标签交换路由器（LSR）邻居。一旦发现，LSR邻居可以使用TCP传输连接建立LDP对等会话。
The Generalized TTL Security Mechanism (GTSM) [RFC5082] is a mechanism based on IPv4 Time To Live (TTL) or IPv6 Hop Limit value verification so as to provide a simple and reasonably robust defense from infrastructure attacks using forged protocol packets from outside the network. GTSM can be applied to any protocol peering
广义TTL安全机制（GTSM）[RFC5082]是一种基于IPv4生存时间（TTL）或IPv6跃点限制值验证的机制，以便使用来自网络外部的伪造协议数据包对基础设施攻击提供简单而合理的鲁棒防御。GTSM可以应用于任何协议对等
session that is established between routers that are adjacent. Therefore, GTSM can protect an LDP protocol peering session established using Basic Discovery.
在相邻路由器之间建立的会话。因此，GTSM可以保护使用基本发现建立的LDP协议对等会话。
This document specifies LDP enhancements to accommodate GTSM. In particular, this document specifies the enhancements in the following areas:
本文件规定了LDP增强功能，以适应GTSM。特别是，本文档规定了以下方面的增强功能：
1. The Common Hello Parameter TLV of LDP Link Hello message
1. LDP链路Hello报文的公共Hello参数TLV
2. Sending and Receiving procedures for LDP Link Hello message
2. LDP链路Hello报文的发送和接收程序
3. Sending and Receiving procedures for LDP Initialization message
3. LDP初始化报文的发送和接收程序
GTSM specifies that "it SHOULD NOT be enabled by default in order to remain backward compatible with the unmodified protocol" (see Section 3 of [RFC5082]). This document specifies a "built-in dynamic GTSM capability negotiation" for LDP to suggest the use of GTSM. GTSM will be used as specified in this document provided both peers on an LDP session can detect each others' support for GTSM procedures and agree to use it. That is, the desire to use GTSM (i.e., its negotiation mechanics) is enabled by default without any configuration.
GTSM规定“为了保持与未修改协议的向后兼容，默认情况下不应启用它”（参见[RFC5082]第3节）。本文件规定了LDP的“内置动态GTSM能力协商”，以建议使用GTSM。如果LDP会话中的两个对等方能够检测到对方对GTSM程序的支持并同意使用，则将按照本文件的规定使用GTSM。也就是说，使用GTSM（即其协商机制）的愿望在默认情况下是启用的，无需任何配置。
This specification uses a bit reserved in Section 3.5.2 of [RFC5036] and therefore updates [RFC5036].
本规范使用了[RFC5036]第3.5.2节中保留的位，因此更新了[RFC5036]。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document defines procedures for LDP using IPv4 routing but not for LDP using IPv6 routing, since the latter has GTSM built into the protocol definition [LDP-IPV6].
本文档定义了使用IPv4路由的LDP的过程，但没有定义使用IPv6路由的LDP的过程，因为后者在协议定义[LDP-IPv6]中内置了GTSM。
Additionally, the GTSM for LDP specified in this document applies only to single-hop LDP peering sessions and not to multi-hop LDP peering sessions, in line with Section 5.5 of [RFC5082]. Consequently, any LDP method or feature (such as LDP IGP Synchronization [RFC5443] or LDP Session Protection [LDP-SPROT]) that relies on multi-hop LDP peering sessions would not work with GTSM and will require (statically or dynamically) disabling the GTSM capability. See Section 3.
此外，根据[RFC5082]第5.5节，本文件中规定的LDP GTSM仅适用于单跳LDP对等会话，而不适用于多跳LDP对等会话。因此，任何依赖于多跳LDP对等会话的LDP方法或功能（如LDP IGP同步[RFC5443]或LDP会话保护[LDP-SPROT]）都不会与GTSM一起工作，并且需要（静态或动态）禁用GTSM功能。见第3节。
A new flag in the Common Hello Parameter TLV, named G flag (for GTSM), is defined by this document in a previously reserved bit. An LSR indicates that it is capable of applying GTSM procedures, as defined in this document, to the subsequent LDP peering session, by setting the GTSM flag to 1. The Common Hello Parameters TLV, defined in Section 3.5.2 of [RFC5036], is updated as shown in Figure 1.
通用Hello参数TLV中的新标志名为G flag（用于GTSM），由本文档在先前保留的位中定义。LSR通过将GTSM标志设置为1，表明其能够将本文件中定义的GTSM程序应用于后续LDP对等会话。[RFC5036]第3.5.2节中定义的通用Hello参数TLV如图1所示进行更新。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Hello Parms(0x0400)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |T|R|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Hello Parms(0x0400)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |T|R|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T, Targeted Hello As specified in [RFC5036].
T、 [RFC5036]中指定的目标Hello。
R, Request Send Targeted Hellos As specified in [RFC5036].
R、 请求发送[RFC5036]中指定的目标Hello。
G, GTSM A value of 1 specifies that this LSR supports GTSM procedures, where a value of 0 specifies that this LSR does not support GTSM.
G、 GTSM值1指定此LSR支持GTSM程序，其中值0指定此LSR不支持GTSM。
Reserved This field is reserved. It MUST be set to zero on transmission and ignored on receipt.
保留此字段为保留字段。必须在传输时将其设置为零，在接收时将其忽略。
Figure 1: GTSM Flag in the Common Hello Parameter TLV
图1：通用Hello参数TLV中的GTSM标志
The G flag is meaningful only if the T flag is set to 0 (which must be the case for Basic Discovery); otherwise, the value of the G flag is ignored on receipt.
只有当T标志设置为0时，G标志才有意义（基本发现必须是这样）；否则，在接收时忽略G标志的值。
Any LSR not supporting GTSM for LDP as defined in this document (i.e., an LSR that does not recognize the G flag) would continue to ignore the G flag, independent of the values of the T and R flags, as per Section 3.5.2 of [RFC5036]. Similarly, an LSR that does recognize the G flag but that does not support GTSM (either because it is not implemented or because it is so configured) would not set the G flag (i.e., G=0) when sending LDP Link Hellos and would effectively ignore the G flag when receiving LDP Link Hello messages.
根据[RFC5036]第3.5.2节的规定，任何不支持LDP GTSM的LSR（即不识别G标志的LSR）将继续忽略G标志，与T和R标志的值无关。类似地，当发送LDP链路Hello时，确实识别G标志但不支持GTSM的LSR（因为它没有实现或因为它是这样配置的）将不会设置G标志（即，G=0），并且在接收LDP链路Hello消息时将有效地忽略G标志。
First, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello messages to link-level multicast address (224.0.0.2 or "all routers"). Such messages are never forwarded beyond one hop and are RECOMMENDED to have their IP TTL or Hop Count = 1.
首先，使用LDP基本发现[RFC5036]的LSR将LDP Hello消息发送到链路级多播地址（224.0.0.2或“所有路由器”）。此类消息的转发不会超过一个跃点，建议其IP TTL或跃点计数为1。
Unless configured otherwise, an LSR that supports GTSM procedures MUST set the G flag (for GTSM) to 1 in the Common Hello Parameter TLV in the LDP Link Hello message [RFC5036].
除非另有配置，否则支持GTSM过程的LSR必须在LDP链路Hello消息[RFC5036]中的公共Hello参数TLV中将G标志（用于GTSM）设置为1。
If an LSR that supports GTSM and is configured to use it recognizes the presence of the G flag (in the Common Hello Parameter TLV) with the value = 1 in the received LDP Link Hello message, then it MUST enforce GTSM for LDP in the subsequent TCP/LDP peering session with the neighbor that sent the Hello message, as specified in Section 2.3 of this document.
如果支持GTSM并配置为使用它的LSR在接收到的LDP链路Hello消息中识别出值为1的G标志（在公共Hello参数TLV中）的存在，则它必须在与发送Hello消息的邻居的后续TCP/LDP对等会话中对LDP强制GTSM，如本文件第2.3节所述。
If an LSR does not recognize the presence of the G flag (in the Common Hello Parameter TLV of Link Hello message), or recognizes the presence of G flag with the value = 0, then the LSR MUST NOT enforce GTSM for LDP in the subsequent TCP/LDP peering session with the neighbor that sent the Hello message. This ensures backward compatibility as well as automatic GTSM deactivation.
如果LSR不识别G标志的存在（在链路Hello消息的公共Hello参数TLV中），或识别值为0的G标志的存在，则LSR不得在与发送Hello消息的邻居的后续TCP/LDP对等会话中对LDP强制GTSM。这确保了向后兼容性以及自动GTSM停用。
If an LSR that has sent and received LDP Link Hello with G flag = 1 from the directly connected neighbor, then the LSR MUST enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the forthcoming TCP Transport Connection with that neighbor. This means that the LSR MUST check for the incoming unicast packets' TTL or Hop Count to be 255 for the particular LDP/TCP peering session and decide the further processing as per [RFC5082].
如果一个LSR从直接连接的邻居发送和接收了LDP链路Hello（G标志=1），则LSR必须在与该邻居的即将到来的TCP传输连接中执行[RFC5082]第3节中定义的GTSM程序。这意味着LSR必须检查特定LDP/TCP对等会话的传入单播数据包的TTL或跃点计数是否为255，并根据[RFC5082]决定进一步处理。
If an LSR that has sent LDP Link Hello with G flag = 1, but received LDP Link Hello with G flag = 0 from the directly connected neighbor, then the LSR MUST NOT enforce GTSM procedures, as defined in Section 3 of [RFC5082], in the forthcoming TCP Transport Connection with that neighbor.
如果已发送G标志为1的LDP链路Hello，但从直接连接的邻居接收到G标志为0的LDP链路Hello的LSR，则LSR不得在与该邻居的即将到来的TCP传输连接中执行[RFC5082]第3节中定义的GTSM程序。
This section discusses GTSM considerations arising from the LDP peering scenarios used, including single-hop versus multi-hop LDP neighbors, as well as the use of LDP Basic Discovery versus Extended Discovery.
本节讨论所使用的LDP对等场景引起的GTSM注意事项，包括单跳与多跳LDP邻居，以及LDP基本发现与扩展发现的使用。
The reason that the GTSM capability negotiation is enabled for Basic Discovery by default (i.e., G=1) but not for Extended Discovery is that the usage of Basic Discovery typically relates to a single-hop LDP peering session, whereas the usage of Extended Discovery typically relates to a multi-hop LDP peering session. GTSM protection for multi-hop LDP sessions is outside the scope of this specification (see Section 1.2). However, it is worth clarifying the following exceptions that may occur with Basic or Extended Discovery usage:
GTSM能力协商默认为基本发现（即，G=1）而不是扩展发现启用的原因是，基本发现的使用通常与单跳LDP对等会话相关，而扩展发现的使用通常与多跳LDP对等会话相关。多跳LDP会话的GTSM保护不在本规范范围内（见第1.2节）。但是，有必要澄清以下基本或扩展发现用法可能出现的例外情况：
a. Two adjacent LSRs (i.e., back-to-back PE routers) forming a single-hop LDP peering session after doing an Extended Discovery (e.g., for Pseudowire signaling)
a. 两个相邻的LSR（即背对背PE路由器）在执行扩展发现（例如，用于伪线信令）后形成单跳LDP对等会话
b. Two adjacent LSRs forming a multi-hop LDP peering session after doing a Basic Discovery, due to the way IP routing is set up between them (either temporarily or permanently)
b. 两个相邻的LSR在进行基本发现后形成多跳LDP对等会话，这是由于它们之间的IP路由设置方式（临时或永久）
c. Two adjacent LSRs (i.e., back-to-back PE routers) forming a single-hop LDP peering session after doing both Basic and Extended Discovery
c. 两个相邻的LSR（即背对背的PE路由器）在执行基本和扩展发现后形成单跳LDP对等会话
In the first case (a), GTSM is not enabled for the LDP peering session by default. In the second case (b), GTSM is actually enabled by default and enforced for the LDP peering session; hence, it would prohibit the LDP peering session from getting established (note that this may impact features such as LDP IGP Synchronization [RFC5443] or LDP Session Protection [LDP-SPROT]). In the third case (c), GTSM is enabled by default for Basic Discovery and enforced on the subsequent LDP peering, and is not for Extended Discovery. However, if each LSR uses the same IPv4 transport address object value in both Basic and Extended Discoveries, then it would result in a single LDP peering session that would be enabled with GTSM. Otherwise, GTSM would not be enforced on the second LDP peering session corresponding to the Extended Discovery.
在第一种情况（a）中，默认情况下不为LDP对等会话启用GTSM。在第二种情况（b）中，GTSM实际上默认启用并针对LDP对等会话强制实施；因此，它将禁止建立LDP对等会话（注意，这可能会影响LDP IGP同步[RFC5443]或LDP会话保护[LDP-SPROT]等功能）。在第三种情况（c）中，GTSM默认为基本发现启用，并在后续LDP对等上强制实施，而不是用于扩展发现。但是，如果每个LSR在基本发现和扩展发现中使用相同的IPv4传输地址对象值，那么它将导致使用GTSM启用的单个LDP对等会话。否则，GTSM将不会在与扩展发现相对应的第二个LDP对等会话上实施。
This document allows for the implementation to provide an option to statically (e.g., via configuration) and/or dynamically override the default behavior and enable/disable GTSM on a per-peer basis. This would address all the exceptions listed above.
本文档允许实现提供静态（例如，通过配置）和/或动态覆盖默认行为的选项，并在每个对等基础上启用/禁用GTSM。这将解决上述所有例外情况。
This document increases the security for LDP, making it more resilient to off-link attacks. Security considerations for GTSM are detailed in Section 5 of [RFC5082].
该文件提高了LDP的安全性，使其更能抵御脱离链路的攻击。GTSM的安全注意事项详见[RFC5082]第5节。
As discussed in Section 3, it is possible that
如第3节所述，有可能
o GTSM for LDP may not always be enforced on a single-hop LDP peering session, and LDP may still be susceptible to forged/ spoofed protocol packets, if a single-hop LDP peering session is set up using Extended Discovery.
o LDP的GTSM可能并不总是在单跳LDP对等会话上实施，并且如果使用扩展发现建立单跳LDP对等会话，LDP可能仍然容易受到伪造/欺骗的协议分组的影响。
o GTSM for LDP may cause the LDP peering session to not get established (or may be torn down), if IP routing ever declares that the directly connected peer is more than one IP hop away. Suffice to say, use of cryptographic integrity (e.g., [RFC5925]) is recommended as an alternate solution for detecting forged protocol packets (especially for the multi-hop case).
o LDP的GTSM可能导致LDP对等会话无法建立（或可能被中断），如果IP路由曾经声明直接连接的对等方距离多个IP跃点。可以说，建议使用加密完整性（例如，[RFC5925]）作为检测伪造协议包的替代解决方案（特别是对于多跳情况）。
The GTSM specification [RFC5082] says that protocol messages used for dynamic negotiation of GTSM support MUST be authenticated. However, LDP discovery [RFC5036] uses UDP transport and does not have an authentication mechanism. The GTSM specification further elaborates by saying that GTSM is not a substitute for authentication and does not secure against insider on-the-wire attacks. LDP Basic Discovery uses link-level multicast address (224.0.0.2 or "all routers") that are never forwarded beyond the link, and this acts as a basic protection against off-the-wire attacks.
GTSM规范[RFC5082]规定，用于GTSM支持动态协商的协议消息必须经过身份验证。但是，LDP发现[RFC5036]使用UDP传输，并且没有身份验证机制。GTSM规范进一步阐述说，GTSM不是身份验证的替代品，不能防止内部在线攻击。LDP基本发现使用从不在链路之外转发的链路级多播地址（224.0.0.2或“所有路由器”），这是对离线攻击的基本保护。
The authors of this document do not make any claims on the originality of the ideas described. The concept of GTSM for LDP has been proposed a number of times and is documented in both the Experimental and Standards Track specifications of GTSM. Among other people, we would like to acknowledge Enke Chen and Albert Tian for their document "TTL-Based Security Option for the LDP Hello Message".
本文件的作者不对所述想法的独创性提出任何主张。LDP的GTSM概念已被多次提出，并记录在GTSM的实验和标准轨道规范中。在其他人中，我们要感谢陈恩科和田伟业的文档“基于TTL的LDP Hello消息安全选项”。
The authors would like to thank Loa Andersson, Bin Mo, Mach Chen, Vero Zheng, Adrian Farrel, Eric Rosen, Eric Gray, and Brian Weis for their thorough reviews and useful comments and suggestions.
作者要感谢Loa Andersson、Bin Mo、Mach Chen、Vero Zheng、Adrian Farrel、Eric Rosen、Eric Gray和Brian Weis的全面评论和有用的意见和建议。
[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月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，2007年10月。
[LDP-IPV6] Asati, R., Manral, V., Papneja, R., and C. Pignataro, "Updates to LDP for IPv6", Work in Progress, June 2012.
[LDP-IPV6]Asati，R.，Manral，V.，Papneja，R.，和C.Pignataro，“针对IPV6的LDP更新”，正在进行的工作，2012年6月。
[LDP-SPROT] Cisco Systems, Inc., "MPLS LDP Session Protection", <http://www.cisco.com/en/US/docs/ios-xml/ios/mp_ldp/ configuration/12-4m/mp-ldp-sessn-prot.html>.
[LDP-SPROT]思科系统公司，“MPLS LDP会话保护”<http://www.cisco.com/en/US/docs/ios-xml/ios/mp_ldp/ 配置/12-4m/mp ldp sessn prot.html>。
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, March 2009.
[RFC5443]Jork，M.，Atlas，A.，和L.Fang，“LDP IGP同步”，RFC 54432009年3月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
Authors' Addresses
作者地址
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USA
Carlos Pignataro思科系统7200-12美国北卡罗来纳州Kit Creek路研究三角公园，邮编27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park, NC 27709 USA
Rajiv Asati Cisco Systems 7025-6 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
EMail: rajiva@cisco.com
EMail: rajiva@cisco.com