Internet Engineering Task Force (IETF) L. Zheng
Request for Comments: 7349 M. Chen
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 M. Bhatia
Ionos Networks
August 2014
Internet Engineering Task Force (IETF) L. Zheng
Request for Comments: 7349 M. Chen
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 M. Bhatia
Ionos Networks
August 2014
LDP Hello Cryptographic Authentication
LDP Hello密码认证
Abstract
摘要
This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well-known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code (HMAC) with the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms.
本文档介绍了一种新的可选加密身份验证TLV，LDP可以使用它来保护其Hello消息。它保护Hello消息免受欺骗攻击和一些针对IP报头的已知攻击。本文档描述了一种使用哈希消息认证码（HMAC）和国家标准与技术研究所（NIST）安全哈希标准算法系列保护LDP Hello消息的机制。
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/rfc7349.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7349.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4
2.1. Optional Parameter for Hello Message . . . . . . . . . . 4
2.2. LDP Security Association . . . . . . . . . . . . . . . . 4
2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6
2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 7
3. Cryptographic Authentication Procedure . . . . . . . . . . . 8
4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . . 8
5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8
5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9
5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 9
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Processing Hello Message Using Cryptographic Authentication . 10
6.1. Transmission Using Cryptographic Authentication . . . . . 10
6.2. Receipt Using Cryptographic Authentication . . . . . . . 10
7. Operational Considerations . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4
2.1. Optional Parameter for Hello Message . . . . . . . . . . 4
2.2. LDP Security Association . . . . . . . . . . . . . . . . 4
2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6
2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 7
3. Cryptographic Authentication Procedure . . . . . . . . . . . 8
4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . . 8
5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8
5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9
5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 9
5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Processing Hello Message Using Cryptographic Authentication . 10
6.1. Transmission Using Cryptographic Authentication . . . . . 10
6.2. Receipt Using Cryptographic Authentication . . . . . . . 10
7. Operational Considerations . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 14
The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions that run between LDP peers. The peers could either be directly connected at the link level or be multiple hops away. An LDP Label Switching Router (LSR) could either be configured with the identity of its peers or could discover them using LDP Hello messages. These messages are sent encapsulated in UDP addressed to "all routers on this subnet" or to a specific IP address. Periodic Hello messages are also used to maintain the relationship between LDP peers necessary to keep the LDP session active.
标签分发协议（LDP）[RFC5036]设置在LDP对等点之间运行的LDP会话。对等点可以在链路级别直接连接，也可以是多跳距离。LDP标签交换路由器（LSR）既可以配置其对等方的身份，也可以使用LDP Hello消息发现它们。这些消息被封装在UDP中发送到“此子网上的所有路由器”或特定IP地址。周期性Hello消息还用于维护LDP对等方之间的关系，以保持LDP会话处于活动状态。
Since the Hello messages are sent using UDP and not TCP, these messages cannot use the security mechanisms defined for TCP [RFC5926]. While some configuration guidance is given in [RFC5036] to help protect against false discovery messages, it does not provide an explicit security mechanism to protect the Hello messages.
由于Hello消息是使用UDP而不是TCP发送的，因此这些消息不能使用为TCP定义的安全机制[RFC5926]。虽然[RFC5036]中给出了一些配置指南，以帮助防止错误发现消息，但它没有提供明确的安全机制来保护Hello消息。
Spoofing a Hello message for an existing adjacency can cause the valid adjacency to time out and in turn can result in termination of the associated session. This can occur when the spoofed Hello specifies a smaller Hold Time, causing the receiver to expect Hellos
欺骗现有邻接的Hello消息可能会导致有效邻接超时，进而导致相关会话终止。当伪造的Hello指定较小的保持时间时，可能会发生这种情况，从而导致接收者期望Hello
within this smaller interval, while the true neighbor continues sending Hellos at the previously agreed lower frequency. Spoofing a Hello message can also cause the LDP session to be terminated directly, which can occur when the spoofed Hello specifies a different Transport Address, other than the previously agreed one between neighbors. Spoofed Hello messages have been observed and reported as a real problem in production networks [RFC6952].
在这个较小的间隔内，真正的邻居继续以先前约定的较低频率发送hello。欺骗Hello消息还可能导致LDP会话直接终止，当欺骗的Hello指定不同的传输地址（而不是邻居之间先前约定的传输地址）时，可能会发生这种情况。在生产网络[RFC6952]中，已经观察到并报告了伪造的Hello消息，这是一个实际问题。
For Link Hello, [RFC5036] states that the threat of spoofed Hellos can be reduced by accepting Hellos only on interfaces to which LSRs that can be trusted are directly connected and ignoring Hellos not addressed to the "all routers on this subnet" multicast group. The Generalized TTL Security Mechanism (GTSM) provides a simple and reasonably robust defense mechanism for Link Hello [RFC6720], but it does not secure against packet spoofing attacks or replay attacks [RFC5082].
对于链路Hello，[RFC5036]指出，通过仅在可信任的LSR直接连接的接口上接受Hello，并忽略未发送到“此子网上的所有路由器”多播组的Hello，可以降低欺骗Hello的威胁。广义TTL安全机制（GTSM）为链路Hello[RFC6720]提供了一种简单且相当健壮的防御机制，但它不能防止数据包欺骗攻击或重放攻击[RFC5082]。
Spoofing attacks via Targeted Hellos are a potentially more serious threat. [RFC5036] states that an LSR can reduce the threat of spoofed Targeted Hellos by filtering them and accepting only those originating at sources permitted by an access list. However, filtering using access lists requires LSR resources and does not prevent IP-address spoofing.
通过目标Hello进行的欺骗攻击可能是一种更严重的威胁。[RFC5036]指出，LSR可以通过过滤目标Hello并仅接受来自访问列表允许的源的Hello，从而降低欺骗目标Hello的威胁。但是，使用访问列表进行过滤需要LSR资源，并且不能防止IP地址欺骗。
This document introduces a new Cryptographic Authentication TLV that is used in LDP Hello messages as an optional parameter. It enhances the authentication mechanism for LDP by securing the Hello message against spoofing attacks. It also introduces a cryptographic sequence number carried in the Hello messages that can be used to protect against replay attacks.
本文档介绍了一种新的加密身份验证TLV，该TLV在LDP Hello消息中用作可选参数。它通过保护Hello消息免受欺骗攻击，增强了LDP的身份验证机制。它还引入了Hello消息中携带的加密序列号，可用于防止重播攻击。
Using this Cryptographic Authentication TLV, one or more secret keys (with corresponding Security Association (SA) IDs) are configured in each system. For each LDP Hello message, the key is used to generate and verify an HMAC Hash that is stored in the LDP Hello message. For the cryptographic hash function, this document proposes to use SHA-1, SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard (SHS) [FIPS-180-4]. The HMAC authentication mode defined in [RFC2104] is used. Of the above, implementations MUST include support for at least HMAC-SHA-256, SHOULD include support for HMAC-SHA-1, and MAY include support for HMAC-SHA-384 and HMAC-SHA-512.
使用此加密身份验证TLV，在每个系统中配置一个或多个密钥（具有相应的安全关联（SA）ID）。对于每个LDP Hello消息，密钥用于生成和验证存储在LDP Hello消息中的HMAC哈希。对于加密散列函数，本文件建议使用美国NIST安全散列标准（SHS）[FIPS-180-4]中定义的SHA-1、SHA-256、SHA-384和SHA-512。使用[RFC2104]中定义的HMAC认证模式。其中，实施必须包括对至少HMAC-SHA-256的支持，应包括对HMAC-SHA-1的支持，并可能包括对HMAC-SHA-384和HMAC-SHA-512的支持。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
[RFC5036] defines the encoding for the Hello message. Each Hello message contains zero or more Optional Parameters, each encoded as a TLV. Three Optional Parameters are defined by [RFC5036]. This document defines a new Optional Parameter: the Cryptographic Authentication parameter.
[RFC5036]定义Hello消息的编码。每个Hello消息都包含零个或多个可选参数，每个参数都编码为TLV。[RFC5036]定义了三个可选参数。本文档定义了一个新的可选参数：加密身份验证参数。
Optional Parameter Type
-------------------------------- --------
IPv4 Transport Address 0x0401 (RFC 5036)
Configuration Sequence Number 0x0402 (RFC 5036)
IPv6 Transport Address 0x0403 (RFC 5036)
Cryptographic Authentication TLV 0x0405 (this document)
Optional Parameter Type
-------------------------------- --------
IPv4 Transport Address 0x0401 (RFC 5036)
Configuration Sequence Number 0x0402 (RFC 5036)
IPv6 Transport Address 0x0403 (RFC 5036)
Cryptographic Authentication TLV 0x0405 (this document)
The encoding for the Cryptographic Authentication TLV is described in Section 2.3.
第2.3节描述了加密认证TLV的编码。
An LDP Security Association (SA) contains a set of parameters shared between any two legitimate LDP speakers.
LDP安全关联（SA）包含任意两个合法LDP说话者之间共享的一组参数。
Parameters associated with an LDP SA are as follows:
与LDP SA相关联的参数如下：
o Security Association Identifier (SA ID)
o 安全关联标识符（SA ID）
This is a 32-bit unsigned integer used to uniquely identify an LDP SA between two LDP peers, as manually configured by the network operator (or, possibly by some key management protocol specified by the IETF in the future).
这是一个32位无符号整数，用于唯一标识两个LDP对等方之间的LDP SA，由网络运营商手动配置（或可能由IETF将来指定的某个密钥管理协议配置）。
The receiver determines the active SA by looking at the SA ID field in the incoming Hello message.
接收器通过查看传入Hello消息中的SA ID字段来确定活动SA。
The sender, based on the active configuration, selects an SA to use and puts the correct SA ID value associated with the SA in the LDP Hello message. If multiple valid and active LDP SAs exist for a given interface, the sender may use any of those SAs to protect the packet.
发送方根据活动配置选择要使用的SA，并将与SA关联的正确SA ID值放入LDP Hello消息中。如果给定接口存在多个有效且活动的LDP SA，则发送方可以使用这些SA中的任何一个来保护数据包。
Using SA IDs makes changing keys while maintaining protocol operation convenient. Each SA ID specifies two independent parts, the authentication algorithm and the authentication key, as explained below.
使用SA ID可以在维护协议操作的同时方便地更改密钥。每个SA ID指定两个独立的部分，即身份验证算法和身份验证密钥，如下所述。
Normally, an implementation would allow the network operator to configure a set of keys in a key chain, with each key in the chain having a fixed lifetime. The actual operation of these mechanisms is outside the scope of this document.
通常，实现将允许网络运营商在密钥链中配置一组密钥，其中链中的每个密钥具有固定的生存期。这些机制的实际运作超出了本文件的范围。
Note that each SA ID can indicate a key with a different authentication algorithm. This allows the introduction of new authentication mechanisms without disrupting existing LDP sessions.
请注意，每个SA ID可以使用不同的身份验证算法指示密钥。这允许在不中断现有LDP会话的情况下引入新的身份验证机制。
o Authentication Algorithm
o 认证算法
This signifies the authentication algorithm to be used with the LDP SA. This information is never sent in clear text over the wire. Because this information is not sent on the wire, the implementer chooses an implementation-specific representation for this information.
这表示要与LDP SA一起使用的认证算法。此信息从不以明文形式通过电线发送。因为该信息不是通过线路发送的，所以实现者为该信息选择了特定于实现的表示。
Currently, the following algorithms are supported:
目前，支持以下算法：
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512。
o Authentication Key
o 认证密钥
This value denotes the cryptographic authentication key associated with the LDP SA. The length of this key is variable and depends upon the authentication algorithm specified by the LDP SA.
该值表示与LDP SA相关联的加密认证密钥。该密钥的长度是可变的，取决于LDP SA指定的身份验证算法。
o KeyStartAccept
o 按键开始接受
The time that this LDP router will accept packets that have been created with this LDP Security Association.
此LDP路由器将接受使用此LDP安全关联创建的数据包的时间。
o KeyStartGenerate
o 键值开始生成
The time that this LDP router will begin using this LDP Security Association for LDP Hello message generation.
此LDP路由器将开始使用此LDP安全关联生成LDP Hello消息的时间。
o KeyStopGenerate
o 密钥生成
The time that this LDP router will stop using this LDP Security Association for LDP Hello message generation.
此LDP路由器将停止使用此LDP安全关联生成LDP Hello消息的时间。
o KeyStopAccept
o Keyspaccept
The time that this LDP router will stop accepting packets generated with this LDP Security Association.
此LDP路由器将停止接受使用此LDP安全关联生成的数据包的时间。
In order to achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left unspecified, the time will default to 0, and the key will be used immediately. If KeyStopGenerate or KeyStopAccept are left unspecified, the time will default to infinity, and the key's lifetime will be infinite. When a new key replaces an old, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key. Any unspecified values are encoded as zero.
为了实现平滑的密钥转换，KeyStartAccept应该小于KeyStartGenerate，KeyspGenerate应该小于Keyspaccept。如果未指定KeyStartGenerate或KeyStartAccept，则时间将默认为0，并且将立即使用该键。如果KeyStopGenerate或KeyStopAccept未指定，则时间将默认为无穷大，并且密钥的生存期将是无限的。当新密钥替换旧密钥时，新密钥的KeyStartGenerate时间必须小于或等于旧密钥的KeyspGenerate时间。任何未指定的值都被编码为零。
Key storage SHOULD persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition and not advisable to disrupt routing. Therefore, the router SHOULD send a "last Authentication Key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured.
密钥存储应在系统重新启动期间保持不变，无论是热重启还是冷重启，以避免操作问题。如果与接口关联的最后一个密钥过期，则无法恢复到未经验证的状态，并且不建议中断路由。因此，路由器应向网络管理器发送“上次验证密钥到期”通知，并将密钥视为具有无限生存期，直到延长生存期、通过网络管理删除密钥或配置新密钥为止。
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| Auth (0x0405) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Auth (0x0405) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data (Variable) |
~ ~
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 0x0405, Cryptographic Authentication
o 类型：0x0405，加密身份验证
o Length: The length in octets of the value field, including the Security Association ID and Cryptographic Sequence Number fields.
o 长度：值字段的长度（以八位字节为单位），包括安全关联ID和加密序列号字段。
o Security Association ID: The 32-bit field that maps to the authentication algorithm and the secret key used to create the message digest carried in LDP payload.
o 安全关联ID：映射到身份验证算法的32位字段和用于创建LDP有效负载中携带的消息摘要的密钥。
Though the SA ID implies the algorithm, the HMAC output size should not be used by implementers as an implicit hint because additional algorithms may be defined in the future that have the same output size.
尽管SA ID暗示了算法，但HMAC输出大小不应被实现者用作隐式提示，因为将来可能会定义具有相同输出大小的其他算法。
o Cryptographic Sequence Number: The 64-bit, strictly increasing sequence number that is used to guard against replay attacks. The 64-bit sequence number MUST be incremented for every LDP Hello message sent by the LDP router. Upon reception, the sequence number MUST be greater than the sequence number in the last LDP Hello message accepted from the sending LDP neighbor. Otherwise, the LDP message is considered a replayed packet and is dropped. The Cryptographic Sequence Number is a single space per LDP router.
o 加密序列号：用于防止重播攻击的64位严格递增序列号。对于LDP路由器发送的每个LDP Hello消息，必须增加64位序列号。接收时，序列号必须大于从发送LDP邻居接收的最后一条LDP Hello消息中的序列号。否则，LDP消息被视为重播分组并被丢弃。加密序列号是每个LDP路由器的单个空间。
LDP routers implementing this specification MUST use existing mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the LDP router (including cold restarts). One mechanism for accomplishing this could be to use the high-order 32 bits of the sequence number as a boot count that is incremented anytime the LDP router loses its sequence number state. Techniques such as sequence number space partitioning described above or non-volatile storage preservation can be used but are beyond the scope of this specification. Sequence number wrap is described in Section 2.4.
实现本规范的LDP路由器必须使用现有机制，在LDP路由器的部署寿命内（包括冷重启），保持序列号严格递增的特性。实现这一点的一种机制可以是使用序列号的高阶32位作为引导计数，当LDP路由器丢失其序列号状态时，引导计数将增加。可以使用上述序列号空间分区或非易失性存储保存等技术，但这些技术超出了本规范的范围。第2.4节描述了序列号包装。
o Authentication Data: This field carries the digest computed by the Cryptographic Authentication algorithm in use. The length of the Authentication Data varies based on the cryptographic algorithm in use, which is shown below:
o 身份验证数据：此字段携带由使用中的加密身份验证算法计算的摘要。身份验证数据的长度因使用的加密算法而异，如下所示：
Auth type Length
--------------- ----------
HMAC-SHA1 20 bytes
HMAC-SHA-256 32 bytes
HMAC-SHA-384 48 bytes
HMAC-SHA-512 64 bytes
Auth type Length
--------------- ----------
HMAC-SHA1 20 bytes
HMAC-SHA-256 32 bytes
HMAC-SHA-384 48 bytes
HMAC-SHA-512 64 bytes
When incrementing the sequence number for each transmitted LDP message, the sequence number should be treated as an unsigned 64-bit value. If the lower-order 32-bit value wraps, the higher-order 32-bit value should be incremented and saved in non-volatile storage. If the LDP router is deployed long enough that the 64-bit sequence number wraps, all keys, independent of the key distribution
增加每个传输的LDP消息的序列号时，序列号应视为无符号64位值。如果低阶32位值换行，则高阶32位值应递增并保存在非易失性存储器中。如果LDP路由器部署的时间足够长，以至于64位序列号可以包裹所有密钥，而不受密钥分发的影响
mechanism, MUST be reset. This is done to avoid the possibility of replay attacks. Once the keys have been changed, the higher-order sequence number can be reset to 0 and saved to non-volatile storage.
机械装置，必须复位。这样做是为了避免重播攻击的可能性。更换钥匙后，可以将高阶序列号重置为0并保存到非易失性存储器中。
As noted earlier, the Security Association ID maps to the authentication algorithm and the secret key used to generate and verify the message digest. This specification discusses the computation of LDP Cryptographic Authentication data when any of the NIST SHS family of algorithms is used in the Hashed Message Authentication Code (HMAC) mode.
如前所述，安全关联ID映射到用于生成和验证消息摘要的认证算法和密钥。本规范讨论了在哈希消息认证码（HMAC）模式下使用NIST SHS系列算法时LDP加密认证数据的计算。
The currently valid algorithms (including mode) for LDP Cryptographic Authentication include:
目前LDP密码认证的有效算法（包括模式）包括：
HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
HMAC-SHA-1、HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512
Of the above, implementations of this specification MUST include support for at least HMAC-SHA-256, SHOULD include support for HMAC-SHA-1, and MAY also include support for HMAC-SHA-384 and HMAC-SHA-512.
其中，本规范的实现必须包括对至少HMAC-SHA-256的支持，应包括对HMAC-SHA-1的支持，还可能包括对HMAC-SHA-384和HMAC-SHA-512的支持。
Implementations of this standard MUST use HMAC-SHA-256 as the default authentication algorithm.
本标准的实施必须使用HMAC-SHA-256作为默认身份验证算法。
In order to prevent cross-protocol replay attacks for protocols sharing common keys, the 2-octet LDP Cryptographic Protocol ID is appended to the authentication key prior to use (refer to Section 8). Other protocols using the common key similarly append their own Cryptographic Protocol IDs to their keys prior to use, thus ensuring that a different key value is used for each protocol.
为了防止共享公共密钥的协议的跨协议重放攻击，在使用前将2-octet LDP加密协议ID附加到认证密钥中（参考第8节）。使用公共密钥的其他协议在使用前也会将自己的加密协议ID附加到密钥中，从而确保每个协议使用不同的密钥值。
In the algorithm description below, the following nomenclature is used:
在下面的算法描述中，使用了以下术语：
o H is the specific hashing algorithm (e.g., SHA-256).
o H是特定的散列算法（例如，SHA-256）。
o K is the Authentication Key from the LDP Security Association.
o K是来自LDP安全关联的身份验证密钥。
o Ks is a Protocol-Specific Authentication Key obtained by appending Authentication Key (K) with the 2-octet LDP Cryptographic Protocol ID.
o Ks是通过将身份验证密钥（K）与2-octet LDP加密协议ID相加而获得的特定于协议的身份验证密钥。
o Ko is the cryptographic key used with the hash algorithm.
o Ko是与哈希算法一起使用的加密密钥。
o L is the length of the hash, measured in octets rather than bits.
o L是散列的长度，以八位字节而不是位来度量。
o AuthTag is a value that is the same length as the hash output. In the case of IPv4, the first 4 octets contain the IPv4 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times. In the case of IPv6, the first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets.
o AuthTag是一个与哈希输出长度相同的值。对于IPv4，前4个八位字节包含IPv4源地址，后跟十六进制值0x878FE1F3，重复（L-4）/4次。对于IPv6，前16个八位字节包含IPv6源地址，后跟十六进制值0x878FE1F3，重复（L-16）/4次。这意味着哈希输出的长度始终至少为16个八位字节。
The LDP Cryptographic Protocol ID is appended to the Authentication Key (K) yielding a Protocol-Specific Authentication Key (Ks). In this application, Ko is always L octets long. Keys that are longer than the bit length of the hash function are hashed to force them to this length, as we describe below. Ks is computed as follows.
LDP加密协议ID被附加到认证密钥（K）上，产生协议特定的认证密钥（Ks）。在此应用程序中，Ko的长度始终为L个八位字节。对长于哈希函数位长度的键进行哈希处理，使其达到该长度，如下所述。Ks的计算如下。
If the Protocol-Specific Authentication Key (Ks) is L octets long, then Ko is equal to Ks. If the Protocol-Specific Authentication Key (Ks) is more than L octets long, then Ko is set to H(Ks). If the Protocol-Specific Authentication Key (Ks) is less than L octets long, then Ko is set to the Protocol-Specific Authentication Key (Ks) with zeros appended to the end of the Protocol-Specific Authentication Key (Ks) such that Ko is L octets long.
如果协议特定身份验证密钥（Ks）的长度为L个八位字节，则Ko等于Ks。如果协议特定身份验证密钥（Ks）的长度超过L个八位字节，则Ko设置为H（Ks）。如果协议特定身份验证密钥（Ks）的长度小于L个八位字节，则将Ko设置为协议特定身份验证密钥（Ks），并在协议特定身份验证密钥（Ks）的末尾附加零，从而使Ko的长度为L个八位字节。
For higher entropy, it is RECOMMENDED that Key Ks should be at least L octets long.
对于更高的熵，建议密钥Ks的长度至少为L个八位字节。
First, the Authentication Data field in the Cryptographic Authentication TLV is filled with the value AuthTag. Then, to compute HMAC over the Hello message it performs:
首先，加密身份验证TLV中的身份验证数据字段用值AuthTag填充。然后，要在Hello消息上计算HMAC，它将执行以下操作：
AuthData = HMAC(Ko, Hello Message)
AuthData=HMAC（Ko，Hello消息）
Hello Message refers to the LDP Hello message excluding the IP and the UDP headers.
Hello消息是指LDP Hello消息，不包括IP和UDP头。
The resultant Hash becomes the Authentication Data that is sent in the Authentication Data field of the Cryptographic Authentication TLV. The length of the Authentication Data field is always identical to the message digest size of the specific hash function H that is being used.
结果散列成为在加密身份验证TLV的身份验证数据字段中发送的身份验证数据。身份验证数据字段的长度始终与正在使用的特定哈希函数H的消息摘要大小相同。
This also means that the use of hash functions with larger output sizes will also increase the size of the LDP message as transmitted on the wire.
这也意味着使用具有更大输出大小的散列函数也将增加在线路上传输的LDP消息的大小。
Prior to transmitting the LDP Hello message, the Length in the Cryptographic Authentication TLV header is set as per the authentication algorithm that is being used. It is set to 24 for HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384, and 68 for HMAC-SHA-512.
在发送LDP Hello消息之前，根据正在使用的认证算法设置加密认证TLV报头中的长度。HMAC-SHA-1设置为24，HMAC-SHA-256设置为36，HMAC-SHA-384设置为52，HMAC-SHA-512设置为68。
The Security Association ID field is set to the ID of the current authentication key. The HMAC Hash is computed as explained in Section 5. The resulting Hash is stored in the Authentication Data field prior to transmission. The authentication key MUST NOT be carried in the packet.
安全关联ID字段设置为当前身份验证密钥的ID。HMAC散列的计算如第5节所述。结果散列在传输之前存储在身份验证数据字段中。数据包中不得携带身份验证密钥。
The receiving LSR applies acceptability criteria for received Hellos using cryptographic authentication. If the Cryptographic Authentication TLV is unknown to the receiving LSR, the received packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036].
接收LSR使用加密身份验证为接收的Hello应用可接受性标准。如果接收LSR不知道加密认证TLV，则必须根据[RFC5036]第3.5.1.2.2节丢弃接收的数据包。
The receiving router MUST determine whether or not to accept a Hello message from a particular source IP address as follows. First, if the router has, for that source IP address, a stored LDP Hello cryptographic sequence number or is configured to require LDP Hello authentication, then the router MUST discard any unauthenticated Hello packets. As specified later in this section, a cryptographic sequence number is only stored for a source IP address as a result of receiving a valid authenticated Hello.
接收路由器必须确定是否接受来自特定源IP地址的Hello消息，如下所示。首先，如果路由器对于该源IP地址具有存储的LDP Hello加密序列号或配置为需要LDP Hello认证，则路由器必须丢弃任何未经认证的Hello数据包。如本节后面所述，由于接收到有效的经过身份验证的Hello，因此仅为源IP地址存储加密序列号。
The receiving LSR locates the LDP SA using the Security Association ID field carried in the message. If the SA is not found or if the SA is not valid for reception (i.e., current time < KeyStartAccept or current time >= KeyStopAccept), the LDP Hello message MUST be discarded, and an error event SHOULD be logged.
接收LSR使用消息中携带的安全关联ID字段定位LDP SA。如果找不到SA或SA接收无效（即当前时间<KeyStartAccept或当前时间>=Keyspaccept），则必须丢弃LDP Hello消息，并记录错误事件。
If the cryptographic sequence number in the LDP Hello message is less than or equal to the last sequence number received from the same neighbor, the LDP Hello message MUST be discarded, and an error event SHOULD be logged.
如果LDP Hello消息中的加密序列号小于或等于从同一邻居接收的最后一个序列号，则必须丢弃LDP Hello消息，并记录错误事件。
Before the receiving LSR performs any processing, it needs to save the values of the Authentication Data field. The receiving LSR then replaces the contents of the Authentication Data field with AuthTag and computes the Hash using the authentication key specified by the received Security Association ID field, as explained in Section 3. If the locally computed Hash is equal to the received value of the Authentication Data field, the received packet is accepted for other normal checks and processing as described in [RFC5036]. Otherwise, if the locally computed Hash is not equal to the received value of the Authentication Data field, the received LDP Hello message MUST be discarded, and an error event SHOULD be logged. The aforesaid logging needs to be carefully rate limited, because while a LDP router is under attack by a storm of spoofed Hellos, the resources required for logging could be overwhelming.
在接收LSR执行任何处理之前，它需要保存身份验证数据字段的值。然后，接收LSR用AuthTag替换身份验证数据字段的内容，并使用接收到的安全关联ID字段指定的身份验证密钥计算哈希，如第3节所述。如果本地计算的散列值等于认证数据字段的接收值，则接收到的数据包被接受用于[RFC5036]中所述的其他正常检查和处理。否则，如果本地计算的哈希值不等于认证数据字段的接收值，则必须丢弃接收到的LDP Hello消息，并记录错误事件。前面提到的日志记录需要小心地限制速率，因为当LDP路由器受到大量欺骗Hello的攻击时，日志记录所需的资源可能是巨大的。
After the LDP Hello message has been successfully authenticated, implementations MUST store the 64-bit cryptographic sequence number for the LDP Hello message received from the source IP address. The saved cryptographic sequence numbers will be used for replay checking for subsequent packets received from the source IP address.
LDP Hello消息成功通过身份验证后，实现必须存储从源IP地址接收的LDP Hello消息的64位加密序列号。保存的加密序列号将用于重播检查从源IP地址接收的后续数据包。
Careful consideration must be given to when and how to enable and disable authentication on LDP Hellos. On the one hand, it is critical that an attack cannot cause the authentication to be disabled. On the other hand, it is equally important that an operator can change the hardware and/or software associated with a neighbor's IP address and successfully bring up an LDP adjacency with the desired level of authentication, which may be with different or no authentication due to software restrictions.
必须仔细考虑何时以及如何在LDP Hello上启用和禁用身份验证。一方面，攻击不能导致身份验证被禁用是至关重要的。另一方面，同样重要的是，运营商可以改变与邻居的IP地址相关联的硬件和/或软件，并成功地提出具有所需认证级别的LDP邻接，由于软件限制，该认证可能具有不同或无认证。
LDP Hello authentication information (e.g., whether authentication is enabled and what the last cryptographic sequence number is) associated with an IP address is learned via a set of interfaces. If an interface is administratively disabled, the LDP Hello authentication information learned via that interface MAY be
通过一组接口学习与IP地址相关联的LDP Hello身份验证信息（例如，是否启用身份验证以及最后的加密序列号是什么）。如果接口被管理性禁用，则通过该接口学习的LDP Hello认证信息可能被禁用
forgotten. This enables an operator that is not specifically manipulating LDP Hello authentication configurations to easily bring up an LDP adjacency. An implementation of this standard SHOULD provide a configuration mechanism by which the LDP Hello authentication information associated with an IP address can be shown and can be forgotten; configuration mechanisms are assumed to be accessed via an authenticated channel.
被遗忘的。这使得没有专门操纵LDP Hello身份验证配置的运营商能够轻松地提出LDP邻接。本标准的实现应提供一种配置机制，通过该配置机制，与IP地址相关联的LDP Hello认证信息可被显示且可被遗忘；配置机制假定通过经过身份验证的通道访问。
Section 1 of this document describes the security issues arising from the use of unauthenticated LDP Hello messages. In order to address those issues, it is RECOMMENDED that all deployments use the Cryptographic Authentication TLV to authenticate the Hello messages.
本文件第1节描述了使用未经验证的LDP Hello消息所产生的安全问题。为了解决这些问题，建议所有部署使用加密身份验证TLV对Hello消息进行身份验证。
The quality of the security provided by the Cryptographic Authentication TLV depends completely on the strength of the cryptographic algorithm in use, the strength of the key being used, and the correct implementation of the security mechanism in communicating LDP implementations. Also, the level of security provided by the Cryptographic Authentication TLV varies based on the authentication type used.
密码认证TLV提供的安全性的质量完全取决于所使用的密码算法的强度、所使用密钥的强度以及在通信LDP实现中安全机制的正确实现。此外，加密身份验证TLV提供的安全级别根据所使用的身份验证类型而有所不同。
It should be noted that the authentication method described in this document is not being used to authenticate the specific originator of a packet but is rather being used to confirm that the packet has indeed been issued by a router that has access to the authentication key.
应当注意，本文档中描述的认证方法不是用于认证数据包的特定发起人，而是用于确认数据包确实是由能够访问认证密钥的路由器发出的。
Deployments SHOULD use sufficiently long and random values for the authentication key so that guessing and other cryptographic attacks on the key are not feasible in their environments. In support of these recommendations, management systems SHOULD support hexadecimal input of authentication keys.
部署应为身份验证密钥使用足够长的随机值，以便在其环境中不可能对密钥进行猜测和其他加密攻击。为了支持这些建议，管理系统应支持认证密钥的十六进制输入。
The mechanism described herein is not perfect. However, this mechanism introduces a significant increase in the effort required for an adversary to successfully attack the LDP Hello protocol while not causing undue implementation, deployment, or operational complexity.
本文描述的机制并不完善。然而，这种机制大大增加了对手成功攻击LDP Hello协议所需的努力，同时又不会造成不当的实现、部署或操作复杂性。
The IANA has assigned a new TLV from the "Label Distribution Protocol (LDP) Parameters" registry, "TLV Type Name Space".
IANA已从“标签分发协议（LDP）参数”注册表“TLV类型名称空间”中分配了一个新的TLV。
Value Description Reference
------ -------------------------------- ---------------------------
0x0405 Cryptographic Authentication TLV this document (Section 2.3)
Value Description Reference
------ -------------------------------- ---------------------------
0x0405 Cryptographic Authentication TLV this document (Section 2.3)
The IANA has also assigned a value from the "Authentication Cryptographic Protocol ID" registry under the "Keying and Authentication for Routing Protocols (KARP) Parameters" category.
IANA还从“路由协议的键控和认证（KARP）参数”类别下的“认证加密协议ID”注册表中分配了一个值。
Value Description Reference
----- -------------------------------- -------------------------
2 LDP Cryptographic Protocol ID this document (Section 4)
Value Description Reference
----- -------------------------------- -------------------------
2 LDP Cryptographic Protocol ID this document (Section 4)
We are indebted to Yaron Sheffer who helped us enormously in rewriting the document to get rid of the redundant crypto mathematics that we had added here.
我们要感谢亚龙·谢弗，他在重写文档时为我们提供了巨大帮助，从而消除了我们在此添加的冗余加密数学。
We would also like to thank Liu Xuehu for his work on background and motivation for LDP Hello authentication. Last but not least, we would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen Farrell, Eric Gray, Kamran Raza, and Acee Lindem for their valuable comments.
我们还要感谢刘学虎在自民党Hello认证背景和动机方面所做的工作。最后但并非最不重要的是，我们还要感谢阿德里安·法雷尔、埃里克·罗森、萨姆·哈特曼、斯蒂芬·法雷尔、埃里克·格雷、卡姆兰·拉扎和亚齐·林登的宝贵评论。
[FIPS-180-4] National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", FIPS 180-4, March 2012.
[FIPS-180-4]国家标准与技术研究所（NIST），“安全哈希标准（SHS）”，FIPS 180-42012年3月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[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月。
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, June 2010.
[RFC5926]Lebovitz，G.和E.Rescorla，“TCP认证选项（TCP-AO）的加密算法”，RFC 5926，2010年6月。
[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)", RFC 6720, August 2012.
[RFC6720]Pignataro，C.和R.Asati，“标签分发协议（LDP）的通用TTL安全机制（GTSM）”，RFC 6720，2012年8月。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013.
[RFC6952]Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，2013年5月。
Authors' Addresses
作者地址
Lianshu Zheng Huawei Technologies China
华为技术中国有限公司
EMail: vero.zheng@huawei.com
EMail: vero.zheng@huawei.com
Mach(Guoyi) Chen Huawei Technologies China
马赫（郭毅）陈华为技术中国有限公司
EMail: mach.chen@huawei.com
EMail: mach.chen@huawei.com
Manav Bhatia Ionos Networks India
Manav Bhatia Ionios网络印度
EMail: manav@ionosnetworks.com
EMail: manav@ionosnetworks.com