Independent Submission D. Ovsienko
Request for Comments: 7298 Yandex
Updates: 6126 July 2014
Category: Experimental
ISSN: 2070-1721
Independent Submission D. Ovsienko
Request for Comments: 7298 Yandex
Updates: 6126 July 2014
Category: Experimental
ISSN: 2070-1721
Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication
Babel哈希消息身份验证码（HMAC）加密身份验证
Abstract
摘要
This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.
本文档描述了Babel路由协议的加密身份验证机制。本文档更新了RFC 6126。该机制为身份验证数据分配两种新的TLV类型，使用哈希消息身份验证码（HMAC），并且是可选的和向后兼容的。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc7298.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7298.
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. Cryptographic Aspects ...........................................5
2.1. Mandatory-to-Implement and Optional Hash Algorithms ........5
2.2. Definition of Padding ......................................6
2.3. Cryptographic Sequence Number Specifics ....................8
2.4. Definition of HMAC .........................................9
3. Updates to Protocol Data Structures ............................11
3.1. RxAuthRequired ............................................11
3.2. LocalTS ...................................................11
3.3. LocalPC ...................................................11
3.4. MaxDigestsIn ..............................................11
3.5. MaxDigestsOut .............................................12
3.6. ANM Table .................................................12
3.7. ANM Timeout ...............................................13
3.8. Configured Security Associations ..........................14
3.9. Effective Security Associations ...........................16
4. Updates to Protocol Encoding ...................................17
4.1. Justification .............................................17
4.2. TS/PC TLV .................................................19
4.3. HMAC TLV ..................................................20
5. Updates to Protocol Operation ..................................21
5.1. Per-Interface TS/PC Number Updates ........................21
5.2. Deriving ESAs from CSAs ...................................23
5.3. Updates to Packet Sending .................................25
5.4. Updates to Packet Receiving ...............................28
5.5. Authentication-Specific Statistics Maintenance ............30
6. Implementation Notes ...........................................31
6.1. Source Address Selection for Sending ......................31
6.2. Output Buffer Management ..................................31
6.3. Optimizations of Deriving Procedure for ESAs ..............32
6.4. Duplication of Security Associations ......................33
7. Network Management Aspects .....................................34
7.1. Backward Compatibility ....................................34
7.2. Multi-Domain Authentication ...............................35
7.3. Migration to and from Authenticated Exchange ..............36
7.4. Handling of Authentication Key Exhaustion .................37
8. Security Considerations ........................................38
9. IANA Considerations ............................................43
10. Acknowledgements ..............................................43
11. References ....................................................44
11.1. Normative References .....................................44
11.2. Informative References ...................................44
Appendix A. Figures and Tables ....................................47
Appendix B. Test Vectors ..........................................52
1. Introduction ....................................................3
1.1. Requirements Language ......................................5
2. Cryptographic Aspects ...........................................5
2.1. Mandatory-to-Implement and Optional Hash Algorithms ........5
2.2. Definition of Padding ......................................6
2.3. Cryptographic Sequence Number Specifics ....................8
2.4. Definition of HMAC .........................................9
3. Updates to Protocol Data Structures ............................11
3.1. RxAuthRequired ............................................11
3.2. LocalTS ...................................................11
3.3. LocalPC ...................................................11
3.4. MaxDigestsIn ..............................................11
3.5. MaxDigestsOut .............................................12
3.6. ANM Table .................................................12
3.7. ANM Timeout ...............................................13
3.8. Configured Security Associations ..........................14
3.9. Effective Security Associations ...........................16
4. Updates to Protocol Encoding ...................................17
4.1. Justification .............................................17
4.2. TS/PC TLV .................................................19
4.3. HMAC TLV ..................................................20
5. Updates to Protocol Operation ..................................21
5.1. Per-Interface TS/PC Number Updates ........................21
5.2. Deriving ESAs from CSAs ...................................23
5.3. Updates to Packet Sending .................................25
5.4. Updates to Packet Receiving ...............................28
5.5. Authentication-Specific Statistics Maintenance ............30
6. Implementation Notes ...........................................31
6.1. Source Address Selection for Sending ......................31
6.2. Output Buffer Management ..................................31
6.3. Optimizations of Deriving Procedure for ESAs ..............32
6.4. Duplication of Security Associations ......................33
7. Network Management Aspects .....................................34
7.1. Backward Compatibility ....................................34
7.2. Multi-Domain Authentication ...............................35
7.3. Migration to and from Authenticated Exchange ..............36
7.4. Handling of Authentication Key Exhaustion .................37
8. Security Considerations ........................................38
9. IANA Considerations ............................................43
10. Acknowledgements ..............................................43
11. References ....................................................44
11.1. Normative References .....................................44
11.2. Informative References ...................................44
Appendix A. Figures and Tables ....................................47
Appendix B. Test Vectors ..........................................52
Authentication of routing protocol exchanges is a common means of securing computer networks. The use of protocol authentication mechanisms helps in ascertaining that only the intended routers participate in routing information exchange and that the exchanged routing information is not modified by a third party.
路由协议交换的身份验证是保护计算机网络安全的常用手段。协议认证机制的使用有助于确定只有预期的路由器参与路由信息交换，并且交换的路由信息没有被第三方修改。
[BABEL] ("the original specification") defines data structures, encoding, and the operation of a basic Babel routing protocol instance ("instance of the original protocol"). This document ("this specification") defines data structures, encoding, and the operation of an extension to the Babel protocol -- an authentication mechanism ("this mechanism"). Both the instance of the original protocol and this mechanism are mostly self-contained and interact only at coupling points defined in this specification.
[BABEL]（“原始规范”）定义了基本BABEL路由协议实例（“原始协议实例”）的数据结构、编码和操作。本文档（“本规范”）定义了数据结构、编码和Babel协议扩展的操作——一种身份验证机制（“本机制”）。原始协议的实例和该机制都是自包含的，并且仅在本规范中定义的耦合点上进行交互。
A major design goal of this mechanism is transparency to operators that is not affected by implementation and configuration specifics. A complying implementation makes all meaningful details of authentication-specific processing clear to the operator, even when some of the operational parameters cannot be changed.
该机制的一个主要设计目标是对操作员透明，不受实现和配置细节的影响。即使某些操作参数无法更改，符合要求的实现也能使操作员清楚地了解特定于身份验证的处理的所有有意义的细节。
The currently established (see [RIP2-AUTH], [OSPF2-AUTH], [ISIS-AUTH-A], [RFC6039], and [OSPF3-AUTH-BIS]) approach to an authentication mechanism design for datagram-based routing protocols such as Babel relies on two principal data items embedded into protocol packets, typically as two integral parts of a single data structure:
目前为基于数据报的路由协议（如Babel）建立的身份验证机制设计方法（参见[RIP2-AUTH]、[OSPF2-AUTH]、[ISIS-AUTH-A]、[RFC6039]和[OSPF3-AUTH-BIS]）依赖于嵌入到协议包中的两个主要数据项，通常作为单个数据结构的两个组成部分：
o A fixed-length unsigned integer, typically called a cryptographic sequence number, used in replay attack protection.
o 用于重放攻击保护的固定长度无符号整数，通常称为加密序列号。
o A variable-length sequence of octets, a result of the Hashed Message Authentication Code (HMAC) construction (see [RFC2104]) computed on meaningful data items of the packet (including the cryptographic sequence number) on one hand and a secret key on the other, used in proving that both the sender and the receiver share the same secret key and that the meaningful data was not changed in transmission.
o 八位字节的可变长度序列，一方面是对数据包的有意义数据项（包括加密序列号）计算的哈希消息认证码（HMAC）构造的结果（参见[RFC2104]），另一方面是密钥，用于证明发送方和接收方共享相同的密钥，并且有意义的数据在传输过程中没有改变。
Depending on the design specifics, either all protocol packets or only those packets protecting the integrity of protocol exchange are authenticated. This mechanism authenticates all protocol packets.
根据设计细节，对所有协议数据包或仅保护协议交换完整性的数据包进行身份验证。此机制验证所有协议数据包。
Although the HMAC construction is just one of many possible approaches to cryptographic authentication of packets, this mechanism makes use of relevant prior experience by using HMAC as well, and its
尽管HMAC构造只是对数据包进行加密身份验证的许多可能方法之一，但该机制也利用了使用HMAC的相关先前经验，并且其
solution space correlates with the solution spaces of the mechanisms above. At the same time, it allows for a future extension that treats HMAC as a particular case of a more generic mechanism. Practical experience with the mechanism defined herein should be useful in designing such a future extension.
解空间与上述机制的解空间相关。同时，它允许将来的扩展将HMAC视为更通用机制的特定情况。本文定义的机制的实际经验对于设计这样一个未来的扩展应该是有用的。
This specification defines the use of the cryptographic sequence number in detail sufficient to make replay attack protection strength predictable. That is, an operator can tell the strength from the declared characteristics of an implementation and, if the implementation allows the changing of relevant parameters, the effect of a reconfiguration as well.
本规范详细定义了加密序列号的使用，足以使重播攻击保护强度可预测。也就是说，操作员可以从声明的实现特征中判断强度，如果实现允许更改相关参数，还可以判断重新配置的效果。
This mechanism explicitly allows for multiple HMAC results per authenticated packet. Since meaningful data items of a given packet remain the same, each such HMAC result stands for a different secret key and/or a different hash algorithm. This enables a simultaneous, independent authentication within multiple domains. This specification is not novel in this regard; for example, the Layer 2 Tunneling Protocol (L2TPv3) allows for one or two results per authenticated packet ([RFC3931] Section 5.4.1), and Mobile Ad Hoc Network (MANET) protocols allow for several ([RFC7183] Section 6.1).
此机制明确允许每个经过身份验证的数据包有多个HMAC结果。由于给定分组的有意义数据项保持不变，因此每个这样的HMAC结果代表不同的密钥和/或不同的散列算法。这使得能够在多个域中同时进行独立的身份验证。本规范在这方面并不新颖；例如，第2层隧道协议（L2TPv3）允许每个经过身份验证的数据包产生一个或两个结果（[RFC3931]第5.4.1节），移动自组织网络（MANET）协议允许几个结果（[RFC7183]第6.1节）。
An important concern addressed by this mechanism is limiting the amount of HMAC computations done per authenticated packet, independently for sending and receiving. Without these limits, the number of computations per packet could be as high as the number of configured authentication keys (in the sending case) or as high as the number of keys multiplied by the number of supplied HMAC results (in the receiving case).
该机制解决的一个重要问题是限制每个经过身份验证的数据包独立于发送和接收进行的HMAC计算量。如果没有这些限制，每个数据包的计算数量可能与配置的认证密钥数量（在发送情况下）或与密钥数量乘以提供的HMAC结果数量（在接收情况下）一样高。
These limits establish a basic competition between the configured keys and (in the receiving case) an additional competition between the supplied HMAC results. This specification defines related data structures and procedures in a way to make such competition transparent and predictable for an operator.
这些限制建立了配置密钥之间的基本竞争和（在接收情况下）提供的HMAC结果之间的额外竞争。本规范定义了相关的数据结构和程序，以使此类竞争对运营商来说是透明和可预测的。
Wherever this specification mentions the operator reading or changing a particular data structure, variable, parameter, or event counter "at runtime", it is up to the implementor how this is to be done. For example, the implementation can employ an interactive command line interface (CLI), a management protocol such as the Simple Network Management Protocol (SNMP), a means of inter-process communication such as a local socket, or a combination of these.
当本规范提到操作员“在运行时”读取或更改特定数据结构、变量、参数或事件计数器时，这取决于实现者如何完成。例如，该实现可以采用交互式命令行界面（CLI）、诸如简单网络管理协议（SNMP）的管理协议、诸如本地套接字的进程间通信手段，或者这些的组合。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。
[RFC2104] defines HMAC as a construction that can use any cryptographic hash algorithm with a known digest length and internal block size. This specification preserves this property of HMAC by defining data processing that itself does not depend on any particular hash algorithm either. However, since this mechanism is a protocol extension case, there are relevant design considerations to take into account.
[RFC2104]将HMAC定义为可以使用任何具有已知摘要长度和内部块大小的加密哈希算法的构造。本规范通过定义本身也不依赖于任何特定哈希算法的数据处理来保留HMAC的这一属性。然而，由于该机制是一种协议扩展情况，因此需要考虑相关的设计考虑。
Section 4.5 of [RFC6709] suggests selecting one hash algorithm as mandatory to implement for the purpose of global interoperability (Section 3.2 of [RFC6709]) and selecting another of distinct lineage as recommended for implementation for the purpose of cryptographic agility. This specification makes the latter property guaranteed, rather than probable, through an elevation of the requirement level. There are two mandatory-to-implement hash algorithms; each is unambiguously defined and generally available in multiple implementations.
[RFC6709]第4.5节建议选择一种哈希算法作为强制实现，以实现全局互操作性（第[RFC6709]第3.2节），并选择另一种不同的谱系，以实现加密灵活性。本规范通过提高需求水平，保证而不是可能实现后一种特性。有两种强制实现哈希算法；每一个都有明确的定义，通常可以在多个实现中使用。
An implementation of this mechanism MUST include support for two hash algorithms:
该机制的实现必须包括对两种哈希算法的支持：
o RIPEMD-160 (160-bit digest)
o RIPEMD-160（160位摘要）
o SHA-1 (160-bit digest)
o SHA-1（160位摘要）
Besides that, an implementation of this mechanism MAY include support for additional hash algorithms, provided each such algorithm is publicly and openly specified and its digest length is 128 bits or more (to meet the constraint implied in Section 2.2). Implementors SHOULD consider strong, well-known hash algorithms as additional implementation options and MUST NOT consider a hash algorithm if meaningful attacks exist for it or it is commonly viewed as deprecated.
除此之外，该机制的实现可能包括对附加散列算法的支持，前提是公开指定每个此类算法，并且其摘要长度为128位或更多（以满足第2.2节中暗示的约束）。实现者应该考虑强的、众所周知的散列算法作为附加的实现选项，并且如果有意义的攻击存在，或者它通常被视为不赞成的话，就不必考虑哈希算法。
In the latter case, it is important to take into account considerations both common (such as those made in [RFC4270]) and specific to the HMAC application of the hash algorithm. For example, [RFC6151] considers MD5 collisions and concludes that new protocol designs should not use HMAC-MD5, while [RFC6194] includes a comparable analysis of SHA-1 that finds HMAC-SHA-1 secure for the same purpose.
在后一种情况下，重要的是要考虑到常见的（如[RFC4270]中所述）和特定于哈希算法的HMAC应用的考虑因素。例如，[RFC6151]考虑了MD5冲突，并得出结论，新协议设计不应使用HMAC-MD5，而[RFC6194]包括对SHA-1的可比分析，该分析发现HMAC-SHA-1出于相同目的是安全的。
For example, the following hash algorithms meet these requirements at the time of this writing (in alphabetical order):
例如，在撰写本文时，以下哈希算法满足这些要求（按字母顺序）：
o GOST R 34.11-94 (256-bit digest)
o GOST R 34.11-94（256位摘要）
o SHA-224 (224-bit digest, SHA-2 family)
o SHA-224（224位摘要，SHA-2系列）
o SHA-256 (256-bit digest, SHA-2 family)
o SHA-256（256位摘要，SHA-2系列）
o SHA-384 (384-bit digest, SHA-2 family)
o SHA-384（384位摘要，SHA-2系列）
o SHA-512 (512-bit digest, SHA-2 family)
o SHA-512（512位摘要，SHA-2系列）
o Tiger (192-bit digest)
o 老虎（192位摘要）
o Whirlpool (512-bit digest, 2nd rev., 2003)
o 惠而浦（512位摘要，第二版，2003年）
The set of hash algorithms available in an implementation MUST be clearly stated. When known weak authentication keys exist for a hash algorithm used in the HMAC construction, an implementation MUST deny the use of such keys.
必须明确说明实现中可用的哈希算法集。当HMAC构造中使用的哈希算法存在已知弱身份验证密钥时，实现必须拒绝使用此类密钥。
Many practical applications of HMAC for authentication of datagram-based network protocols (including routing protocols) involve the padding procedure, a design-specific conditioning of the message that both the sender and the receiver perform before the HMAC computation. The specific padding procedure of this mechanism addresses the following needs:
HMAC在基于数据报的网络协议（包括路由协议）认证中的许多实际应用涉及填充过程，这是发送方和接收方在HMAC计算之前对消息进行的特定于设计的调节。此机制的特定填充过程满足以下需求：
o Data Initialization
o 数据初始化
A design that places the HMAC result(s) computed for a message inside that same message after the computation has to have previously (i.e., before the computation) allocated in that message some data unit(s) purposed specifically for those HMAC
在计算之后（即计算之前），必须在该消息中预先分配一些专门用于这些HMAC的数据单元，将为消息计算的HMAC结果放在该消息中的一种设计
result(s) (in this mechanism, it is the HMAC TLV(s); see Section 4.3). The padding procedure sets the respective octets of the data unit(s), in the simplest case to a fixed value known as the padding constant.
结果（在该机制中，为HMAC TLV；见第4.3节）。填充过程将数据单元的各个八位字节（在最简单的情况下）设置为称为填充常量的固定值。
The particular value of the constant is specific to each design. For instance, in [RIP2-AUTH] as well as works derived from it ([ISIS-AUTH-B], [OSPF2-AUTH], and [OSPF3-AUTH-BIS]), the value is 0x878FE1F3. In many other designs (for instance, [RFC3315], [RFC3931], [RFC4030], [RFC4302], [RFC5176], and [ISIS-AUTH-A]), the value is 0x00.
该常数的特定值特定于每种设计。例如，在[RIP2-AUTH]及其衍生作品（[ISIS-AUTH-B]、[OSPF2-AUTH]和[OSPF3-AUTH-BIS]）中，值为0x878FE1F3。在许多其他设计中（例如，[RFC3315]、[RFC3931]、[RFC4030]、[RFC4302]、[RFC5176]和[ISIS-AUTH-A]），该值为0x00。
However, the HMAC construction is defined on the basis of a cryptographic hash algorithm, that is, an algorithm meeting a particular set of requirements made for any input message. Thus, any padding constant values, whether single- or multiple-octet, as well as any other message-conditioning methods, don't affect cryptographic characteristics of the hash algorithm and the HMAC construction, respectively.
然而，HMAC构造是在加密哈希算法的基础上定义的，即满足对任何输入消息的特定要求集的算法。因此，任何填充常量值，无论是单个八位字节还是多个八位字节，以及任何其他消息调节方法，都不会分别影响哈希算法和HMAC构造的加密特性。
o Source Address Protection
o 源地址保护
In the specific case of datagram-based routing protocols, the protocol packet (that is, the message being authenticated) often does not include network-layer addresses, although the source and (to a lesser extent) the destination address of the datagram may be meaningful in the scope of the protocol instance.
在基于数据报的路由协议的特定情况下，协议分组（即被认证的消息）通常不包括网络层地址，尽管数据报的源地址和（在较小程度上）目的地地址在协议实例的范围内可能是有意义的。
In Babel, the source address may be used as a prefix next hop (see Section 3.5.3 of [BABEL]). A well-known (see Section 2.3 of [OSPF3-AUTH-BIS]) solution to the source address protection problem is to set the first respective octets of the data unit(s) above to the source address (yet setting the rest of the octets to the padding constant). This procedure adapts this solution to the specifics of Babel, which allows for the exchange of protocol packets using both IPv4 and IPv6 datagrams (see Section 4 of [BABEL]). Even though in the case of IPv6 exchange a Babel speaker currently uses only link-local source addresses (Section 3.1 of [BABEL]), this procedure protects all octets of an arbitrary given source address for the reasons of future extensibility. The procedure implies that future Babel extensions will never use an IPv4-mapped IPv6 address as a packet source address.
在Babel中，源地址可以用作下一跳的前缀（见[Babel]第3.5.3节）。源地址保护问题的一个众所周知的解决方案（见[OSPF3-AUTH-BIS]第2.3节）是将上述数据单元的第一个相应八位字节设置为源地址（但将其余八位字节设置为填充常数）。此过程使此解决方案适应Babel的具体情况，该解决方案允许使用IPv4和IPv6数据报交换协议数据包（参见[Babel]第4节）。即使在IPv6交换的情况下，Babel扬声器目前仅使用链路本地源地址（见[Babel]第3.1节），出于未来可扩展性的原因，此过程保护任意给定源地址的所有八位字节。该过程意味着未来的Babel扩展将永远不会使用IPv4映射的IPv6地址作为数据包源地址。
This procedure does not protect the destination address, which is currently considered meaningless (Section 3.1 of [BABEL]) in the same scope. A future extension that looks to add such protection would likely use a new TLV or sub-TLV to include the destination address in the protocol packet (see Section 4.1).
本程序不保护目标地址，该地址目前在同一范围内被视为无意义（见[BABEL]第3.1节）。希望添加此类保护的未来扩展可能会使用新的TLV或子TLV将目标地址包括在协议包中（参见第4.1节）。
Description of the padding procedure:
填充过程的说明：
1. Set the first 16 octets of the Digest field of the given HMAC TLV to:
1. 将给定HMAC TLV摘要字段的前16个八位字节设置为：
* the given source address, if it is an IPv6 address, or
* 给定的源地址（如果是IPv6地址），或
* the IPv4-mapped IPv6 address (per Section 2.5.5.2 of [RFC4291]) holding the given source address, if it is an IPv4 address.
* 保存给定源地址的IPv4映射IPv6地址（根据[RFC4291]第2.5.5.2节），如果是IPv4地址。
2. Set the remaining (TLV Length - 18) octets of the Digest field of the given HMAC TLV to 0x00 each.
2. 将给定HMAC TLV的摘要字段的剩余（TLV长度-18）八位字节分别设置为0x00。
For an example of a Babel packet with padded HMAC TLVs, see Table 3 in Appendix A.
关于带有填充HMAC TLV的Babel数据包示例，请参见附录a中的表3。
The operation of this mechanism may involve multiple local and multiple remote cryptographic sequence numbers, each essentially being a 48-bit unsigned integer. This specification uses the term "TS/PC number" to avoid confusion with the route's (Section 2.5 of [BABEL]) or node's (Section 3.2.1 of [BABEL]) sequence numbers of the original Babel specification and to stress the fact that there are two distinguished parts of this 48-bit number, each handled in its specific way (see Section 5.1):
该机制的操作可能涉及多个本地和多个远程加密序列号，每个基本上是48位无符号整数。本规范使用术语“TS/PC编号”以避免与原始巴贝尔规范的路由（巴贝尔规范第2.5节）或节点（巴贝尔规范第3.2.1节）序号混淆，并强调该48位编号有两个不同部分，每个部分以其特定方式处理（见第5.1节）：
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 // 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS // | PC |
+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//
0 1 2 3 4
0 1 2 3 4 5 6 7 8 9 0 // 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS // | PC |
+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//
The high-order 32 bits are called "timestamp" (TS), and the low-order 16 bits are called "packet counter" (PC).
高阶32位称为“时间戳”（TS），低阶16位称为“数据包计数器”（PC）。
This mechanism stores, updates, compares, and encodes each TS/PC number as two independent unsigned integers -- TS and PC, respectively. Such a comparison of TS/PC numbers, as performed in item 3 of Section 5.4, is algebraically equivalent to a comparison of the respective 48-bit unsigned integers. Any byte order conversion, when required, is performed on TS and PC parts independently.
该机制将每个TS/PC号存储、更新、比较并编码为两个独立的无符号整数——TS和PC。如第5.4节第3项所述，TS/PC号的比较在代数上等同于相应48位无符号整数的比较。需要时，可在TS和PC部件上独立执行任何字节顺序转换。
The algorithm description below uses the following nomenclature, which is consistent with [FIPS-198]:
下面的算法描述使用以下术语，与[FIPS-198]一致：
Text The data on which the HMAC is calculated (note item (b) of Section 8). In this specification, it is the contents of a Babel packet ranging from the beginning of the Magic field of the Babel packet header to the end of the last octet of the Packet Body field, as defined in Section 4.2 of [BABEL] (see Figure 2 in Appendix A).
计算HMAC所依据的数据（注：第8节第（b）项）。在本规范中，如[Babel]第4.2节所定义，它是Babel数据包的内容，范围从Babel数据包报头的魔术字段开始到数据包正文字段的最后八位字节结束（参见附录a中的图2）。
H The specific hash algorithm (see Section 2.1).
H特定哈希算法（见第2.1节）。
K A sequence of octets of an arbitrary, known length.
K任意已知长度的八位元序列。
Ko The cryptographic key used with the hash algorithm.
Ko与哈希算法一起使用的加密密钥。
B The block size of H, measured in octets rather than bits. Note that B is the internal block size, not the digest length.
B H的块大小，用八位字节而不是位来测量。请注意，B是内部块大小，而不是摘要长度。
L The digest length of H, measured in octets rather than bits.
L H的摘要长度，以八位字节而不是位来测量。
XOR The bitwise exclusive-or operation.
XOR按位异或操作。
Opad The hexadecimal value 0x5C repeated B times.
Opad十六进制值0x5C重复B次。
Ipad The hexadecimal value 0x36 repeated B times.
将十六进制值0x36重复B次。
The algorithm below is the original, unmodified HMAC construction as defined in both [RFC2104] and [FIPS-198]; hence, it is different from the algorithms defined in [RIP2-AUTH], [ISIS-AUTH-B], [OSPF2-AUTH], and [OSPF3-AUTH-BIS] in exactly two regards:
以下算法是[RFC2104]和[FIPS-198]中定义的原始、未修改的HMAC结构；因此，它与[RIP2-AUTH]、[ISIS-AUTH-B]、[OSPF2-AUTH]和[OSPF3-AUTH-BIS]中定义的算法在两个方面完全不同：
o The algorithm below sets the size of Ko to B, not to L (L is not greater than B). This resolves both ambiguity in XOR expressions and incompatibility in the handling of keys that have length greater than L but not greater than B.
o 下面的算法将Ko的大小设置为B，而不是L（L不大于B）。这解决了XOR表达式中的歧义和处理长度大于L但不大于B的键时的不兼容性。
o The algorithm below does not change the value of Text before or after the computation. Padding a Babel packet before the computation and placing the result inside the packet are both performed elsewhere.
o 下面的算法不会在计算之前或之后更改文本的值。在计算之前填充Babel数据包和将结果放入数据包中都在其他地方执行。
The intent of this is to enable the most straightforward use of cryptographic libraries by implementations of this specification. At the time of this writing, implementations of the original HMAC construction coupled with hash algorithms of choice are generally available.
其目的是通过本规范的实现实现最直接地使用加密库。在撰写本文时，通常可以使用原始HMAC构造的实现以及所选的哈希算法。
Description of the algorithm:
算法说明：
1. Preparation of the Key
1. 钥匙的准备
In this application, Ko is always B octets long. If K is B octets long, then Ko is set to K. If K is more than B octets long, then Ko is set to H(K) with the necessary amount of zeroes appended to the end of H(K), such that Ko is B octets long. If K is less than B octets long, then Ko is set to K with zeroes appended to the end of K, such that Ko is B octets long.
在此应用程序中，Ko的长度始终为B个八位字节。如果K是B个八位字节长，则将Ko设置为K。如果K的长度大于B个八位字节长，则将Ko设置为H（K），并在H（K）的末尾附加必要数量的零，从而使Ko是B个八位字节长。如果K的长度小于B个八位字节，则将Ko设置为K，并在K的末尾附加零，从而使Ko的长度为B个八位字节。
2. First-Hash
2. 第一散列
A First-Hash, also known as the inner hash, is computed as follows:
第一个散列（也称为内部散列）的计算如下：
First-Hash = H(Ko XOR Ipad || Text)
第一个Hash=H（Ko-XOR-Ipad | | Text）
3. Second-Hash
3. 第二散列
A Second-Hash, also known as the outer hash, is computed as follows:
第二个散列（也称为外部散列）的计算如下：
Second-Hash = H(Ko XOR Opad || First-Hash)
第二个散列=H（Ko-XOR-Opad | |第一个散列）
4. Result
4. 后果
The resulting Second-Hash becomes the authentication data that is returned as the result of HMAC calculation.
产生的第二个散列成为作为HMAC计算结果返回的身份验证数据。
Note that in the case of Babel the Text parameter will never exceed a few thousand octets in length. In this specific case, the optimization discussed in Section 6 of [FIPS-198] applies, namely, for a given K that is more than B octets long, the following associated intermediate results may be precomputed only once: Ko, (Ko XOR Ipad), and (Ko XOR Opad).
注意，在Babel的情况下，文本参数的长度永远不会超过几千个八位字节。在此特定情况下，[FIPS-198]第6节中讨论的优化适用，即，对于长度超过B个八位字节的给定K，以下相关中间结果只能预计算一次：Ko，（Ko-XOR-Ipad）和（Ko-XOR-Opad）。
RxAuthRequired is a boolean parameter. Its default value MUST be TRUE. An implementation SHOULD make RxAuthRequired a per-interface parameter but MAY make it specific to the whole protocol instance. The conceptual purpose of RxAuthRequired is to enable a smooth migration from an unauthenticated Babel packet exchange to an authenticated Babel packet exchange and back (see Section 7.3). The current value of RxAuthRequired directly affects the receiving procedure defined in Section 5.4. An implementation SHOULD allow the operator to change the RxAuthRequired value at runtime or by means of a Babel speaker restart. An implementation MUST allow the operator to discover the effective value of RxAuthRequired at runtime or from the system documentation.
RxAuthRequired是一个布尔参数。其默认值必须为TRUE。实现应使RxAuthRequired成为每个接口参数，但可能使其特定于整个协议实例。RxAuthRequired的概念目的是实现从未经验证的Babel数据包交换到经过验证的Babel数据包交换的平滑迁移（见第7.3节）。RxAuthRequired的当前值直接影响第5.4节中定义的接收程序。实现应允许操作员在运行时或通过Babel扬声器重启来更改RxAuthRequired值。实现必须允许操作员在运行时或从系统文档中发现RxAuthRequired的有效值。
LocalTS is a 32-bit unsigned integer variable. It is the TS part of a per-interface TS/PC number. LocalTS is a strictly per-interface variable not intended to be changed by the operator. Its initialization is explained in Section 5.1.
LocalTS是一个32位无符号整数变量。它是每个接口TS/PC号的TS部分。LocalTS是一个严格按照接口的变量，不打算由操作员更改。第5.1节对其初始化进行了说明。
LocalPC is a 16-bit unsigned integer variable. It is the PC part of a per-interface TS/PC number. LocalPC is a strictly per-interface variable not intended to be changed by the operator. Its initialization is explained in Section 5.1.
LocalPC是一个16位无符号整数变量。它是每个接口TS/PC号的PC部分。LocalPC是一个严格按照接口的变量，不打算由操作员更改。第5.1节对其初始化进行了说明。
MaxDigestsIn is an unsigned integer parameter conceptually purposed for limiting the amount of CPU time spent processing a received authenticated packet. The receiving procedure performs the most CPU-intensive operation -- the HMAC computation -- only at most MaxDigestsIn (Section 5.4 item 7) times for a given packet.
MaxDigestsIn是一个无符号整数参数，概念上用于限制处理已接收的经过身份验证的数据包所花费的CPU时间。对于给定的数据包，接收过程最多只能执行MaxDigestsIn（第5.4节第7项）次CPU密集型操作（HMAC计算）。
The MaxDigestsIn value MUST be at least 2. An implementation SHOULD make MaxDigestsIn a per-interface parameter but MAY make it specific to the whole protocol instance. An implementation SHOULD allow the operator to change the value of MaxDigestsIn at runtime or by means of a Babel speaker restart. An implementation MUST allow the operator to discover the effective value of MaxDigestsIn at runtime or from the system documentation.
MaxDigestsIn值必须至少为2。实现应该使MaxDigestsIn成为每个接口参数，但可能使其特定于整个协议实例。实现应允许操作员在运行时或通过巴别塔扬声器重启来更改MaxDigestsIn的值。实现必须允许操作员在运行时或从系统文档中发现MaxDigestsIn的有效值。
MaxDigestsOut is an unsigned integer parameter conceptually purposed for limiting the amount of a sent authenticated packet's space spent on authentication data. The sending procedure adds at most MaxDigestsOut (Section 5.3 item 5) HMAC results to a given packet.
MaxDigestsOut是一个无符号整数参数，概念上用于限制已发送的经过身份验证的数据包在身份验证数据上的空间量。发送过程最多向给定数据包添加MaxDigestsOut（第5.3节第5项）HMAC结果。
The MaxDigestsOut value MUST be at least 2. An implementation SHOULD make MaxDigestsOut a per-interface parameter but MAY make it specific to the whole protocol instance. An implementation SHOULD allow the operator to change the value of MaxDigestsOut at runtime or by means of a Babel speaker restart, in a safe range. The maximum safe value of MaxDigestsOut is implementation specific (see Section 6.2). An implementation MUST allow the operator to discover the effective value of MaxDigestsOut at runtime or from the system documentation.
MaxDigestsOut值必须至少为2。实现应该使MaxDigestsOut成为每个接口的参数，但可以使其特定于整个协议实例。实现应允许操作员在运行时或通过巴别塔扬声器重启在安全范围内更改MaxDigestsOut的值。MaxDigestsOut的最大安全值是特定于实现的（参见第6.2节）。实现必须允许操作员在运行时或从系统文档中发现MaxDigestsOut的有效值。
The ANM (Authentic Neighbours Memory) table resembles the neighbour table defined in Section 3.2.3 of [BABEL]. Note that the term "neighbour table" means the neighbour table of the original Babel specification, and the term "ANM table" means the table defined herein. Indexing of the ANM table is done in exactly the same way as indexing of the neighbour table, but its purpose, field set, and associated procedures are different.
ANM（真实邻居内存）表类似于[BABEL]第3.2.3节中定义的邻居表。注意，术语“相邻表”是指原始巴贝尔规范的相邻表，术语“ANM表”是指本文定义的表。ANM表的索引方式与相邻表的索引方式完全相同，但其目的、字段集和相关过程不同。
The conceptual purpose of the ANM table is to provide longer-term replay attack protection than would be possible using the neighbour table. Expiry of an inactive entry in the neighbour table depends on the last received Hello Interval of the neighbour and typically stands for tens to hundreds of seconds (see Appendixes A and B of [BABEL]). Expiry of an inactive entry in the ANM table depends only on the local speaker's configuration. The ANM table retains (for at least the amount of seconds set by the ANM timeout parameter as defined in Section 3.7) a copy of the TS/PC number advertised in authentic packets by each remote Babel speaker.
ANM表的概念目的是提供比使用相邻表更长期的重放攻击保护。邻居表中非活动项的到期时间取决于最近收到的邻居的Hello间隔，通常为数十秒到数百秒（见[BABEL]的附录A和附录B）。ANM表中非活动项的到期时间仅取决于本地扬声器的配置。ANM表保留（至少在第3.7节中定义的ANM超时参数设置的秒数内）每个远程巴别塔扬声器在真实数据包中公布的TS/PC号副本。
The ANM table is indexed by pairs of the form (Interface, Source). Every table entry consists of the following fields:
ANM表由成对的表单（接口、源）索引。每个表条目由以下字段组成：
o Interface
o 界面
An implementation-specific reference to the local node's interface through which the authentic packet was received.
对本地节点接口的特定于实现的引用，通过该接口接收真实数据包。
o Source
o 来源
The source address of the Babel speaker from which the authentic packet was received.
接收真实数据包的巴别塔扬声器的源地址。
o LastTS
o 拉斯特
A 32-bit unsigned integer -- the TS part of a remote TS/PC number.
32位无符号整数——远程TS/PC号的TS部分。
o LastPC
o LastPC
A 16-bit unsigned integer -- the PC part of a remote TS/PC number.
16位无符号整数——远程TS/PC号的PC部分。
Each ANM table entry has an associated aging timer, which is reset by the receiving procedure (Section 5.4 item 9). If the timer expires, the entry is deleted from the ANM table.
每个ANM表格条目都有一个相关的老化计时器，该计时器由接收程序重置（第5.4节第9项）。如果计时器过期，将从ANM表中删除该条目。
An implementation SHOULD use persistent memory (NVRAM) to retain the contents of the ANM table across restarts of the Babel speaker, but only as long as both the Interface field reference and expiry of the aging timer remain correct. An implementation MUST be clear regarding if and how persistent memory is used for the ANM table. An implementation SHOULD allow the operator to retrieve the current contents of the ANM table at runtime. An implementation SHOULD allow the operator to remove some or all ANM table entries at runtime or by means of a Babel speaker restart.
实现应使用持久内存（NVRAM）在巴别塔扬声器重启期间保留ANM表的内容，但前提是接口字段引用和老化计时器的到期时间保持正确。实现必须明确ANM表是否以及如何使用持久内存。实现应该允许操作员在运行时检索ANM表的当前内容。实现应允许操作员在运行时或通过巴别塔扬声器重启删除部分或全部ANM表项。
ANM timeout is an unsigned integer parameter. An implementation SHOULD make ANM timeout a per-interface parameter but MAY make it specific to the whole protocol instance. ANM timeout is conceptually purposed for limiting the maximum age (in seconds) of entries in the ANM table that stand for inactive Babel speakers. The maximum age is immediately related to replay attack protection strength. The strongest protection is achieved with the maximum possible value of ANM timeout set, but it may not provide the best overall result for specific network segments and implementations of this mechanism.
ANM timeout是一个无符号整数参数。一个实现应该使ANM超时成为每个接口参数，但可以使其特定于整个协议实例。ANM timeout在概念上用于限制ANM表中代表非活动巴别塔扬声器的条目的最大年龄（以秒为单位）。最大年龄与重放攻击防护强度直接相关。使用ANM timeout set的最大可能值可以实现最强的保护，但它可能无法为特定网段和此机制的实现提供最佳的总体结果。
Specifically, implementations unable to maintain the local TS/PC number strictly increasing across Babel speaker restarts will reuse the advertised TS/PC numbers after each restart (see Section 5.1). The neighbouring speakers will treat the new packets as replayed and discard them until the aging timer of the respective ANM table entry expires or the new TS/PC number exceeds the one stored in the entry.
具体而言，无法在巴别塔扬声器重启期间严格保持本地TS/PC号增加的实施将在每次重启后重新使用公布的TS/PC号（见第5.1节）。相邻扬声器将把新分组视为重播，并丢弃它们，直到相应ANM表条目的老化计时器过期或新TS/PC号超过条目中存储的TS/PC号。
Another possible, but less probable, case could be an environment that uses IPv6 for the exchange of Babel datagrams and that involves physical moves of network-interface hardware between Babel speakers. Even when performed without restarting the speakers, these physical moves would cause random drops of the TS/PC number advertised for a given (Interface, Source) index, as viewed by neighbouring speakers, since IPv6 link-local addresses are typically derived from interface hardware addresses.
另一种可能但可能性较小的情况可能是使用IPv6交换巴别塔数据报的环境，该环境涉及巴别塔扬声器之间网络接口硬件的物理移动。即使在不重新启动扬声器的情况下执行，这些物理移动也会导致为给定（接口、源）索引播发的TS/PC号随机下降，如相邻扬声器所看到的，因为IPv6链路本地地址通常来自接口硬件地址。
Assuming that in such cases the operators would prefer to use a lower ANM timeout value to let the entries expire on their own rather than having to manually remove them from the ANM table each time, an implementation SHOULD set the default value of ANM timeout to a value between 30 and 300 seconds.
假设在这种情况下，操作员希望使用较低的ANM超时值让条目自行过期，而不是每次都必须手动将其从ANM表中删除，则实现应将ANM超时的默认值设置为30到300秒之间的值。
At the same time, network segments may exist with every Babel speaker having its advertised TS/PC number strictly increasing over the deployed lifetime. Assuming that in such cases the operators would prefer using a much higher ANM timeout value, an implementation SHOULD allow the operator to change the value of ANM timeout at runtime or by means of a Babel speaker restart. An implementation MUST allow the operator to discover the effective value of ANM timeout at runtime or from the system documentation.
同时，网络段可能存在，每个巴别塔扬声器的广告TS/PC数量在部署的生命周期内严格增加。假设在这种情况下，操作员更喜欢使用更高的ANM超时值，则实现应允许操作员在运行时或通过巴别塔扬声器重启来更改ANM超时值。实现必须允许操作员在运行时或从系统文档中发现ANM超时的有效值。
A Configured Security Association (CSA) is a data structure conceptually purposed for associating authentication keys and hash algorithms with Babel interfaces. All CSAs are managed in finite sequences, one sequence per interface (hereafter referred to as "interface's sequence of CSAs"). Each interface's sequence of CSAs, as an integral part of the Babel speaker configuration, MAY be intended for persistent storage as long as this conforms with the implementation's key-management policy. The default state of an interface's sequence of CSAs is empty, which has a special meaning of no authentication configured for the interface. The sending (Section 5.3 item 1) and the receiving (Section 5.4 item 1) procedures address this convention accordingly.
配置安全关联（CSA）是一种数据结构，概念上用于将身份验证密钥和哈希算法与Babel接口相关联。所有CSA都以有限的顺序进行管理，每个接口一个顺序（以下称为“CSA的接口顺序”）。每个接口的CSA序列作为Babel扬声器配置的一个组成部分，可以用于持久存储，只要符合实现的密钥管理策略。接口的CSA序列的默认状态为空，这意味着没有为接口配置身份验证。发送（第5.3节第1项）和接收（第5.4节第1项）程序相应地涉及本公约。
A single CSA structure consists of the following fields:
单个CSA结构由以下字段组成：
o HashAlgo
o 哈萨尔戈
An implementation-specific reference to one of the hash algorithms supported by this implementation (see Section 2.1).
此实现支持的哈希算法之一的特定于实现的参考（参见第2.1节）。
o KeyChain
o 钥匙链
A finite sequence of elements (hereafter referred to as "KeyChain sequence") representing authentication keys, each element being a structure consisting of the following fields:
表示认证密钥的有限元素序列（以下称为“密钥链序列”），每个元素是由以下字段组成的结构：
* LocalKeyID
* LocalKeyID
An unsigned integer of an implementation-specific bit length.
实现特定位长度的无符号整数。
* AuthKeyOctets
* AuthKeyOctets
A sequence of octets of an arbitrary, known length to be used as the authentication key.
任意长度的八位字节序列，用作身份验证密钥。
* KeyStartAccept
* 按键开始接受
The time that this Babel speaker will begin considering this authentication key for accepting packets with authentication data.
此巴别塔扬声器开始考虑此身份验证密钥以接受包含身份验证数据的数据包的时间。
* KeyStartGenerate
* 键值开始生成
The time that this Babel speaker will begin considering this authentication key for generating packet authentication data.
该巴别塔扬声器开始考虑该身份验证密钥以生成数据包身份验证数据的时间。
* KeyStopGenerate
* 密钥生成
The time that this Babel speaker will stop considering this authentication key for generating packet authentication data.
此巴别塔扬声器将停止考虑此身份验证密钥以生成数据包身份验证数据的时间。
* KeyStopAccept
* Keyspaccept
The time that this Babel speaker will stop considering this authentication key for accepting packets with authentication data.
此巴别塔扬声器将停止考虑此身份验证密钥以接受包含身份验证数据的数据包的时间。
Since there is no limit imposed on the number of CSAs per interface, but the number of HMAC computations per sent/received packet is limited (through MaxDigestsOut and MaxDigestsIn, respectively), it may appear that only a fraction of the associated keys and hash
由于每个接口的CSA数量没有限制，但每个发送/接收数据包的HMAC计算数量是有限的（分别通过MaxDigestsOut和MaxDigestsIn），因此似乎只有一小部分相关键和散列
algorithms are used in the process. The ordering of elements within a sequence of CSAs and within a KeyChain sequence is important to make the association selection process deterministic and transparent. Once this ordering is deterministic at the Babel interface level, the intermediate data derived by the procedure defined in Section 5.2 will be deterministically ordered as well.
在这个过程中使用了算法。CSA序列和钥匙链序列中元素的排序对于使关联选择过程具有确定性和透明性非常重要。一旦该顺序在巴别塔接口级别上是确定的，则第5.2节中定义的程序衍生的中间数据也将是确定的顺序。
An implementation SHOULD allow an operator to set any arbitrary order of elements within a given interface's sequence of CSAs and within the KeyChain sequence of a given CSA. Regardless of whether this requirement is or isn't met, the implementation MUST provide a means to discover the actual element order used. Whichever order is used by an implementation, it MUST be preserved across Babel speaker restarts.
实现应该允许操作员在给定接口的CSA序列和给定CSA的键链序列内设置任意元素顺序。无论是否满足此要求，实现都必须提供一种方法来发现实际使用的元素顺序。无论实现使用哪种顺序，都必须在Babel speaker重新启动期间保留该顺序。
Note that none of the CSA structure fields is constrained to contain unique values. Section 6.4 explains this in more detail. It is possible for the KeyChain sequence to be empty, although this is not the intended manner of using CSAs.
请注意，没有任何CSA结构字段被约束为包含唯一值。第6.4节对此进行了更详细的解释。钥匙链序列可能为空，尽管这不是使用CSA的预期方式。
The KeyChain sequence has a direct prototype, which is the "key chain" syntax item of some existing router configuration languages. If an implementation already implements this syntax item, it is suggested that the implementation reuse it, that is, implement a CSA syntax item that refers to a key chain item rather than reimplement the latter in full.
密钥链序列有一个直接原型，它是一些现有路由器配置语言的“密钥链”语法项。如果一个实现已经实现了这个语法项，建议实现重用它，也就是说，实现一个引用密钥链项的CSA语法项，而不是完全重新实现后者。
An Effective Security Association (ESA) is a data structure immediately used in sending (Section 5.3) and receiving (Section 5.4) procedures. Its conceptual purpose is to determine a runtime interface between those procedures and the deriving procedure defined in Section 5.2. All ESAs are temporary data units managed as elements of finite sequences that are not intended for persistent storage. Element ordering within each such finite sequence (hereafter referred to as "sequence of ESAs") MUST be preserved as long as the sequence exists.
有效安全关联（ESA）是在发送（第5.3节）和接收（第5.4节）过程中立即使用的数据结构。其概念目的是确定这些程序与第5.2节中定义的派生程序之间的运行时接口。所有ESA都是临时数据单元，作为有限序列的元素进行管理，不用于持久存储。只要序列存在，每个有限序列（以下称为“ESA序列”）内的元素顺序必须保持不变。
A single ESA structure consists of the following fields:
单个ESA结构由以下字段组成：
o HashAlgo
o 哈萨尔戈
An implementation-specific reference to one of the hash algorithms supported by this implementation (see Section 2.1).
此实现支持的哈希算法之一的特定于实现的参考（参见第2.1节）。
o KeyID
o 钥匙
A 16-bit unsigned integer.
16位无符号整数。
o AuthKeyOctets
o AuthKeyOctets
A sequence of octets of an arbitrary, known length to be used as the authentication key.
任意长度的八位字节序列，用作身份验证密钥。
Note that among the protocol data structures introduced by this mechanism, the ESA structure is the only one not directly interfaced with the system operator (see Figure 1 in Appendix A); it is not immediately present in the protocol encoding, either. However, the ESA structure is not just a possible implementation technique but an integral part of this specification: the deriving (Section 5.2), the sending (Section 5.3), and the receiving (Section 5.4) procedures are defined in terms of the ESA structure and its semantics provided herein. The ESA structure is as meaningful for a correct implementation as the other protocol data structures.
注意，在该机制引入的协议数据结构中，ESA结构是唯一未与系统操作员直接接口的结构（参见附录A中的图1）；它也不会立即出现在协议编码中。然而，ESA结构不仅是一种可能的实现技术，而且是本规范的一个组成部分：推导（第5.2节）、发送（第5.3节）和接收（第5.4节）过程根据本文提供的ESA结构及其语义进行定义。ESA结构与其他协议数据结构一样，对正确实施具有重要意义。
The choice of encoding is very important in the long term. The protocol encoding limits various authentication mechanism designs and encodings, which in turn limit future developments of the protocol.
从长远来看，编码的选择非常重要。协议编码限制了各种身份验证机制的设计和编码，这反过来又限制了协议的未来发展。
Considering existing implementations of the Babel protocol instance itself and related modules of packet analysers, the current encoding of Babel allows for compact and robust decoders. At the same time, this encoding allows for future extensions of Babel by three (not excluding each other) principal means as defined in Sections 4.2 and 4.3 of [BABEL] and further discussed in [BABEL-EXTENSION]:
考虑到Babel协议实例本身的现有实现和包分析器的相关模块，Babel的当前编码允许紧凑和健壮的解码器。同时，该编码允许巴别塔未来扩展三种（不相互排斥）主要方法，如[Babel]第4.2节和第4.3节所定义，并在[Babel-扩展]中进一步讨论：
a. A Babel packet consists of a four-octet header followed by a packet body, that is, a sequence of TLVs (see Figure 2 in Appendix A). Besides the header and the body, an actual Babel
a. Babel数据包由一个四个八位组的报头和一个数据包体组成，即一个TLV序列（参见附录A中的图2）。除了头球和身体，一个真正的巴别塔
datagram may have an arbitrary amount of trailing data between the end of the packet body and the end of the datagram. An instance of the original protocol silently ignores such trailing data.
数据报在包体末端和数据报末端之间可以具有任意数量的尾随数据。原始协议的实例会自动忽略这些后续数据。
b. The packet body uses a binary format allowing for 256 TLV types and imposing no requirements on TLV ordering or number of TLVs of a given type in a packet. [BABEL] allocates TLV types 0 through 10 (see Table 1 in Appendix A), defines the TLV body structure for each, and establishes the requirement for a Babel protocol instance to ignore any unknown TLV types silently. This makes it possible to examine a packet body (to validate the framing and/or to pick particular TLVs for further processing), taking into account only the type (to distinguish between a Pad1 TLV and any other TLV) and the length of each TLV, regardless of whether any additional TLV types are eventually deployed (and if so, how many).
b. 包体使用二进制格式，允许256种TLV类型，并且不对包中给定类型的TLV顺序或数量施加任何要求。[BABEL]分配TLV类型0到10（见附录A中的表1），为每个类型定义TLV主体结构，并建立BABEL协议实例忽略任何未知TLV类型的要求。这使得检查数据包主体（验证帧和/或选择特定TLV进行进一步处理）成为可能，只考虑类型（区分Pad1 TLV和任何其他TLV）和每个TLV的长度，而不管是否最终部署了任何其他TLV类型（如果是，有多少）。
c. Within each TLV of the packet body, there may be some extra data after the expected length of the TLV body. An instance of the original protocol silently ignores any such extra data. Note that any TLV types without the expected length defined (such as the PadN TLV) cannot be extended with the extra data.
c. 在包体的每个TLV内，在TLV体的预期长度之后可能有一些额外的数据。原始协议的实例会自动忽略任何此类额外数据。请注意，任何未定义预期长度的TLV类型（如PadN TLV）都不能使用额外数据进行扩展。
Considering each of these three principal extension means for the specific purpose of adding authentication data items to each protocol packet, the following arguments can be made:
考虑到将认证数据项添加到每个协议分组的特定目的，这三个主要扩展手段中的每一个，可以提出以下参数：
o The use of the TLV extra data of some existing TLV type would not be a solution, since no particular TLV type is guaranteed to be present in a Babel packet.
o 使用某些现有TLV类型的TLV额外数据不是一个解决方案，因为不能保证Babel数据包中存在特定的TLV类型。
o The use of the TLV extra data could also conflict with future developments of the protocol encoding.
o TLV额外数据的使用也可能与协议编码的未来发展相冲突。
o Since the packet trailing data is currently unstructured, using it would involve defining an encoding structure and associated procedures; this would add to the complexity of both specification and implementation and would increase exposure to protocol attacks such as fuzzing.
o 由于数据包尾部数据当前是非结构化的，因此使用它将涉及定义编码结构和相关过程；这将增加规范和实现的复杂性，并增加对模糊等协议攻击的暴露。
o A naive use of the packet trailing data would make it unavailable to any future extension of Babel. Since this mechanism is possibly not the last extension and since some other extensions may allow no other embedding means except the packet trailing data, the defined encoding structure would have to enable the multiplexing of data items belonging to different extensions. Such a definition is out of the scope of this work.
o 天真地使用数据包尾部数据将使其无法用于Babel的任何未来扩展。由于该机制可能不是最后一个扩展，并且由于一些其他扩展可能不允许除了分组尾随数据之外的任何其他嵌入手段，因此定义的编码结构必须能够复用属于不同扩展的数据项。这样的定义超出了本工作的范围。
o Deprecating an extension (or only its protocol encoding) that uses purely purpose-allocated TLVs is as simple as deprecating the TLVs.
o 否决使用纯目的分配的TLV的扩展（或仅其协议编码）与否决TLV一样简单。
o The use of purpose-allocated TLVs is transparent for both the original protocol and any its future extensions, regardless of the embedding technique(s) used by the latter.
o 无论原始协议使用何种嵌入技术，目的分配TLV的使用对于原始协议及其任何未来扩展都是透明的。
Considering all of the above, this mechanism uses neither the packet trailing data nor the TLV extra data but uses two new TLV types: type 11 for a TS/PC number and type 12 for an HMAC result (see Table 1 in Appendix A).
考虑到上述所有因素，该机制既不使用包尾随数据也不使用TLV额外数据，而是使用两种新的TLV类型：类型11表示TS/PC号，类型12表示HMAC结果（见附录a中的表1）。
The purpose of a TS/PC TLV is to store a single TS/PC number. There is exactly one TS/PC TLV in an authenticated Babel packet.
TS/PC TLV的目的是存储单个TS/PC编号。在经过身份验证的Babel数据包中正好有一个TS/PC TLV。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length | PacketCounter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length | PacketCounter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Type Set to 11 to indicate a TS/PC TLV.
输入设置为11以指示TS/PC TLV。
Length The length, in octets, of the body, exclusive of the Type and Length fields.
长度正文的长度，以八位字节为单位，不包括类型和长度字段。
PacketCounter A 16-bit unsigned integer in network byte order -- the PC part of a TS/PC number stored in this TLV.
PacketCounter网络字节顺序的16位无符号整数——存储在此TLV中的TS/PC号的PC部分。
Timestamp A 32-bit unsigned integer in network byte order -- the TS part of a TS/PC number stored in this TLV.
时间戳网络字节顺序的32位无符号整数——存储在此TLV中的TS/PC号的TS部分。
Note that the ordering of PacketCounter and Timestamp in the TLV structure is the opposite of the ordering of TS and PC in the TS/PC number and the 48-bit equivalent (see Section 2.3).
请注意，TLV结构中PacketCounter和时间戳的顺序与TS/PC号和48位等效物中TS和PC的顺序相反（见第2.3节）。
Considering the expected length and the extra data as mentioned in Section 4.3 of [BABEL], the expected length of a TS/PC TLV body is unambiguously defined as 6 octets. The receiving procedure would correctly process any TS/PC TLV with body length not less than the expected length, ignoring any extra data (Section 5.4 items 3 and 9).
考虑到[BABEL]第4.3节中提到的预期长度和额外数据，TS/PC TLV体的预期长度明确定义为6个八位组。接收程序将正确处理主体长度不小于预期长度的任何TS/PC TLV，忽略任何额外数据（第5.4节第3项和第9项）。
The sending procedure produces a TS/PC TLV with body length equal to the expected length and the Length field, respectively, set as described in Section 5.3 item 3.
发送程序产生一个TS/PC TLV，主体长度分别等于预期长度和长度字段，如第5.3节第3项所述。
Future Babel extensions (such as sub-TLVs) MAY modify the sending procedure to include the extra data after the fixed-size TS/PC TLV body defined herein, making adjustments to the Length TLV field, the "Body length" packet header field, and output buffer management (as explained in Section 6.2) necessary.
未来的Babel扩展（例如子TLV）可以修改发送过程，以包括本文定义的固定大小TS/PC TLV正文之后的额外数据，对长度TLV字段、“正文长度”分组报头字段和输出缓冲区管理（如第6.2节所述）进行必要的调整。
The purpose of an HMAC TLV is to store a single HMAC result. To assist a receiver in reproducing the HMAC computation, LocalKeyID modulo 2^16 of the authentication key is also provided in the TLV. There is at least one HMAC TLV in an authenticated Babel packet.
HMAC TLV的目的是存储单个HMAC结果。为了帮助接收器再现HMAC计算，TLV中还提供认证密钥的LocalKeyID模2^16。经过身份验证的Babel数据包中至少有一个HMAC TLV。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length | KeyID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest...
+-+-+-+-+-+-+-+-+-+-+-+-
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length | KeyID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest...
+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
领域：
Type Set to 12 to indicate an HMAC TLV.
输入设置为12以指示HMAC TLV。
Length The length, in octets, of the body, exclusive of the Type and Length fields.
长度正文的长度，以八位字节为单位，不包括类型和长度字段。
KeyID A 16-bit unsigned integer in network byte order.
KeyID网络字节顺序的16位无符号整数。
Digest A variable-length sequence of octets that is at least 16 octets long (see Section 2.2).
摘要至少16个八位字节长的可变长度八位字节序列（见第2.2节）。
Considering the expected length and the extra data as mentioned in Section 4.3 of [BABEL], the expected length of an HMAC TLV body is not defined. The receiving and padding procedures process every octet of the Digest field, deriving the field boundary from the Length field value (Section 5.4 item 7 and Section 2.2, respectively). The sending procedure produces HMAC TLVs with the Length field precisely sizing the Digest field to match the digest length of the hash algorithm used (Section 5.3 items 5 and 8).
考虑到[BABEL]第4.3节中提到的预期长度和额外数据，未定义HMAC TLV车体的预期长度。接收和填充程序处理摘要字段的每个八位字节，从长度字段值导出字段边界（分别为第5.4节第7项和第2.2节）。发送过程生成HMAC TLV，长度字段精确调整摘要字段的大小，以匹配所用哈希算法的摘要长度（第5.3节第5项和第8项）。
The HMAC TLV structure defined herein is final. Future Babel extensions MUST NOT extend it with any extra data.
此处定义的HMAC TLV结构为最终结构。未来的Babel扩展不得使用任何额外数据对其进行扩展。
The LocalTS and LocalPC interface-specific variables constitute the TS/PC number of a Babel interface. This number is advertised in the TS/PC TLV of authenticated Babel packets sent from that interface. There is only one property that is mandatory for the advertised TS/PC number: its 48-bit equivalent (see Section 2.3) MUST be strictly increasing within the scope of a given interface of a Babel speaker as long as the protocol instance is continuously operating. This property, combined with ANM tables of neighbouring Babel speakers, provides them with the most basic replay attack protection.
LocalTS和LocalPC接口特定变量构成了Babel接口的TS/PC编号。该号码在从该接口发送的经过身份验证的Babel数据包的TS/PC TLV中公布。对于公布的TS/PC号，只有一个属性是强制性的：只要协议实例持续运行，其48位等效值（见第2.3节）必须在巴别塔扬声器的给定接口范围内严格增加。该属性与邻近巴别塔扬声器的ANM表相结合，为他们提供了最基本的重播攻击保护。
Initialization and increment are two principal updates performed on an interface TS/PC number. The initialization is performed when a new interface becomes a part of a Babel protocol instance. The increment is performed by the sending procedure (Section 5.3 item 2) before advertising the TS/PC number in a TS/PC TLV.
初始化和增量是对TS/PC号接口执行的两个主要更新。当新接口成为Babel协议实例的一部分时，将执行初始化。在TS/PC TLV中公布TS/PC号之前，通过发送程序（第5.3节第2项）执行增量。
Depending on the particular implementation method of these two updates, the advertised TS/PC number may possess additional properties that improve the replay attack protection strength. This includes, but is not limited to, the methods below.
根据这两个更新的特定实现方法，公布的TS/PC号码可能具有提高重播攻击保护强度的附加属性。这包括但不限于以下方法。
a. The most straightforward implementation would use LocalTS as a plain wrap counter, defining the updates as follows:
a. 最简单的实现是使用LocalTS作为普通换行计数器，定义更新如下：
initialization Set LocalPC to 0, and set LocalTS to 0.
初始化将LocalPC设置为0，并将LocalTS设置为0。
increment Increment LocalPC by 1. If LocalPC wraps (0xFFFF + 1 = 0x0000), increment LocalTS by 1.
将LocalPC增加1。如果LocalPC换行（0xFFFF+1=0x0000），则将LocalTS增加1。
In this case, the advertised TS/PC numbers would be reused after each Babel protocol instance restart, making neighbouring speakers reject authenticated packets until the respective ANM table entries expire or the new TS/PC number exceeds the old (see Sections 3.6 and 3.7).
在这种情况下，在每个Babel协议实例重新启动后，将重新使用公布的TS/PC号，使相邻的扬声器拒绝经过身份验证的数据包，直到相应的ANM表条目过期或新的TS/PC号超过旧的TS/PC号（见第3.6和3.7节）。
b. A more advanced implementation could make use of any 32-bit unsigned integer timestamp (number of time units since an arbitrary epoch), such as the UNIX timestamp, if the timestamp itself spans a reasonable time range and is guaranteed against a decrease (such as one resulting from network time use). The updates would be defined as follows:
b. 更高级的实现可以使用任何32位无符号整数时间戳（自任意历元以来的时间单位数），例如UNIX时间戳，前提是时间戳本身跨越合理的时间范围，并且保证不会减少（例如由于网络时间使用而导致的减少）。更新的定义如下：
initialization Set LocalPC to 0, and set LocalTS to 0.
初始化将LocalPC设置为0，并将LocalTS设置为0。
increment If the current timestamp is greater than LocalTS, set LocalTS to the current timestamp and LocalPC to 0, then consider the update complete. Otherwise, increment LocalPC by 1, and if LocalPC wraps, increment LocalTS by 1.
如果当前时间戳大于Loalts，则将Loalts设置为当前时间戳和LoalPC到0，然后考虑更新完成。否则，将LocalPC增加1，如果LocalPC换行，则将LocalTS增加1。
In this case, the advertised TS/PC number would remain unique across the speaker's deployed lifetime without the need for any persistent storage. However, a suitable timestamp source is not available in every implementation case.
在这种情况下，播发的TS/PC号码将在扬声器的部署生命周期内保持唯一，而不需要任何持久存储。然而，并非在每种实现情况下都有合适的时间戳源可用。
c. Another advanced implementation could use LocalTS in a way similar to the "wrap/boot count" suggested in Section 4.1 of [OSPF3-AUTH-BIS], defining the updates as follows:
c. 另一个高级实现可以以类似于[OSPF3-AUTH-BIS]第4.1节中建议的“包装/引导计数”的方式使用LocalTS，将更新定义如下：
initialization Set LocalPC to 0. If there is a TS value stored in NVRAM for the current interface, set LocalTS to the stored TS value, then increment the stored TS value by 1. Otherwise, set LocalTS to 0, and set the stored TS value to 1.
初始化将LocalPC设置为0。如果当前接口的NVRAM中存储有TS值，请将LocalTS设置为存储的TS值，然后将存储的TS值增加1。否则，将LocalTS设置为0，并将存储的TS值设置为1。
increment Increment LocalPC by 1. If LocalPC wraps, set LocalTS to the TS value stored in NVRAM for the current interface, then increment the stored TS value by 1.
将LocalPC增加1。如果LocalPC包装，则将LocalTS设置为当前接口存储在NVRAM中的TS值，然后将存储的TS值增加1。
In this case, the advertised TS/PC number would also remain unique across the speaker's deployed lifetime, relying on NVRAM for storing multiple TS numbers, one per interface.
在这种情况下，播发的TS/PC号码在扬声器的部署生命周期内也将保持唯一，依靠NVRAM存储多个TS号码，每个接口一个。
As long as the TS/PC number retains its mandatory property stated above, it is up to the implementor to determine which methods of TS/ PC number updates are available and whether the operator can configure the method per interface and/or at runtime. However, an implementation MUST disclose the essence of each update method it includes, in a comprehensible form such as natural language description, pseudocode, or source code. An implementation MUST allow the operator to discover which update method is effective for any given interface, either at runtime or from the system
只要TS/PC号保留上述强制属性，则由实施者确定可用的TS/PC号更新方法，以及操作员是否可以在每个接口和/或运行时配置该方法。但是，实现必须以可理解的形式（如自然语言描述、伪代码或源代码）披露其包含的每个更新方法的本质。实现必须允许操作员在运行时或从系统中发现哪个更新方法对任何给定接口有效
documentation. These requirements are necessary to enable the optimal (see Section 3.7) management of ANM timeout in a network segment.
文档这些要求对于实现网段中ANM超时的最佳管理（见第3.7节）是必要的。
Note that wrapping (0xFFFFFFFF + 1 = 0x00000000) of LastTS is unlikely, but possible, causing the advertised TS/PC number to be reused. Resolving this situation requires replacing all authentication keys of the involved interface. In addition to that, if the wrap was caused by a timestamp reaching its end of epoch, using this mechanism will be impossible for the involved interface until some different timestamp or update implementation method is used.
请注意，不太可能包装LastTS（0xFFFFFFFF+1=0x00000000），但可能会导致重新使用公布的TS/PC号。解决此问题需要替换相关接口的所有身份验证密钥。除此之外，如果wrap是由到达其历元末尾的时间戳引起的，则在使用某些不同的时间戳或更新实现方法之前，相关接口将无法使用此机制。
Neither receiving nor sending procedures work with the contents of an interface's sequence of CSAs directly; both (Section 5.4 item 4 and Section 5.3 item 4, respectively) derive a sequence of ESAs from the sequence of CSAs and use the derived sequence (see Figure 1 in Appendix A). There are two main goals achieved through this indirection:
接收和发送过程都不能直接处理接口的CSA序列的内容；两者（分别为第5.4节第4项和第5.3节第4项）均从CSA序列推导出ESA序列，并使用推导出的序列（参见附录a中的图1）。通过这种间接方式可以实现两个主要目标：
o Elimination of expired authentication keys and deduplication of security associations. This is done as early as possible to keep subsequent procedures focused on their respective tasks.
o 消除过期的身份验证密钥和安全关联的重复数据消除。这是尽可能早地完成的，以使后续程序专注于各自的任务。
o Maintenance of particular ordering within the derived sequence of ESAs. The ordering deterministically depends on the ordering within the interface's sequence of CSAs and the ordering within the KeyChain sequence of each CSA. The particular correlation maintained by this procedure implements a concept of fair (independent of the number of keys contained by each) competition between CSAs.
o 在ESA的衍生序列中维持特定顺序。顺序确定地取决于接口CSA序列内的顺序以及每个CSA的钥匙链序列内的顺序。本程序维护的特定相关性实现了CSA之间公平竞争（独立于每个CSA包含的密钥数量）的概念。
The deriving procedure uses the following input arguments:
派生过程使用以下输入参数：
o input sequence of CSAs
o CSAs的输入序列
o direction (sending or receiving)
o 方向（发送或接收）
o current time (CT)
o 当前时间（CT）
The processing of input arguments begins with an empty output sequence of ESAs and consists of the following steps:
输入参数的处理从ESA的空输出序列开始，包括以下步骤：
1. Make a temporary copy of the input sequence of CSAs.
1. 制作CSA输入序列的临时副本。
2. Remove all expired authentication keys from each KeyChain sequence of the copy, that is, any keys such that:
2. 从副本的每个密钥链序列中删除所有过期的身份验证密钥，即任何密钥，以便：
* for receiving: KeyStartAccept is greater than CT or KeyStopAccept is less than CT
* 用于接收：KeyStartAccept大于CT或Keyspaccept小于CT
* for sending: KeyStartGenerate is greater than CT or KeyStopGenerate is less than CT
* 用于发送：KeyStartGenerate大于CT或KeyspGenerate小于CT
Note well that there are no special exceptions. Remove all expired keys, even if there are no keys left after that (see Section 7.4).
请注意，没有特殊的例外情况。移除所有过期的钥匙，即使之后没有剩余钥匙（参见第7.4节）。
3. Use the copy to populate the output sequence of ESAs as follows:
3. 使用副本填充ESA的输出序列，如下所示：
3.1. When the KeyChain sequence of the first CSA contains at least one key, use its first key to produce an ESA with fields set as follows:
3.1. 当第一个CSA的钥匙链序列包含至少一个钥匙时，使用其第一个钥匙生成ESA，字段设置如下：
HashAlgo Set to HashAlgo of the current CSA.
HashAlgo设置为当前CSA的HashAlgo。
KeyID Set to LocalKeyID modulo 2^16 of the current key of the current CSA.
KeyID设置为LocalKeyID，模为当前CSA的当前密钥的2^16。
AuthKeyOctets Set to AuthKeyOctets of the current key of the current CSA.
AuthKeyOctets设置为当前CSA的当前密钥的AuthKeyOctets。
Append this ESA to the end of the output sequence.
将此ESA附加到输出序列的末尾。
3.2. When the KeyChain sequence of the second CSA contains at least one key, use its first key the same way, and so forth until all first keys of the copy are processed.
3.2. 当第二个CSA的密钥链序列包含至少一个密钥时，以相同的方式使用其第一个密钥，依此类推，直到处理副本的所有第一个密钥。
3.3. When the KeyChain sequence of the first CSA contains at least two keys, use its second key the same way.
3.3. 当第一个CSA的密钥链序列包含至少两个密钥时，以相同的方式使用其第二个密钥。
3.4. When the KeyChain sequence of the second CSA contains at least two keys, use its second key the same way, and so forth until all second keys of the copy are processed.
3.4. 当第二个CSA的密钥链序列包含至少两个密钥时，以相同的方式使用其第二个密钥，依此类推，直到处理副本的所有第二个密钥。
3.5. ...and so forth, until all keys of all CSAs of the copy are processed, exactly once each.
3.5. …以此类推，直到副本的所有CSA的所有密钥都被处理，每个密钥只处理一次。
In the description above, the ordinals ("first", "second", and so on) with regard to keys stand for an element position after the removal of expired keys, not before. For example, if a KeyChain sequence was { Ka, Kb, Kc, Kd } before the removal and became { Ka, Kd } after, then Ka would be the "first" element and Kd would be the "second".
在上面的描述中，关于键的序号（“第一”、“第二”等）表示移除过期键之后而不是之前的元素位置。例如，如果一个键链序列在移除之前是{Ka，Kb，Kc，Kd}，在移除之后变成{Ka，Kd}，那么Ka将是“第一”元素，Kd将是“第二”。
4. Deduplicate the ESAs in the output sequence; that is, wherever two or more ESAs exist that share the same (HashAlgo, KeyID, AuthKeyOctets) triplet value, remove all of these ESAs except the one closest to the beginning of the sequence.
4. 对输出序列中的ESA进行重复数据消除；也就是说，如果存在两个或多个共享相同（HashAlgo、KeyID、AuthKeyOctets）三元组值的ESA，则删除所有这些ESA，但最靠近序列开头的ESA除外。
The resulting sequence will contain zero or more unique ESAs, ordered in a way deterministically correlated with the ordering of CSAs within the original input sequence of CSAs and the ordering of keys within each KeyChain sequence. This ordering maximizes the probability of having an equal amount of keys per original CSA in any N first elements of the resulting sequence. Possible optimizations of this deriving procedure are outlined in Section 6.3.
结果序列将包含零个或多个唯一ESA，其排序方式与CSA原始输入序列中的CSA顺序以及每个钥匙链序列中的钥匙顺序确定相关。这种排序最大化了在结果序列的任意N个前元素中每个原始CSA具有相等数量密钥的概率。第6.3节概述了该推导过程的可能优化。
Perform the following authentication-specific processing after the instance of the original protocol considers an outgoing Babel packet ready for sending, but before the packet is actually sent (see Figure 1 in Appendix A). After that, send the packet, regardless of whether the authentication-specific processing modified the outgoing packet or left it intact.
在原始协议的实例认为一个即将发送的Babel数据包已准备好发送之后，但在该数据包实际发送之前，执行以下特定于身份验证的处理（参见附录A中的图1）。之后，发送数据包，而不管特定于身份验证的处理是修改了传出数据包还是使其保持原样。
1. If the current outgoing interface's sequence of CSAs is empty, finish authentication-specific processing and consider the packet ready for sending.
1. 如果当前输出接口的CSA序列为空，则完成验证特定的处理，并考虑数据包准备发送。
2. Increment the TS/PC number of the current outgoing interface, as explained in Section 5.1.
2. 增加当前输出接口的TS/PC号，如第5.1节所述。
3. Add to the packet body (see the note at the end of this section) a TS/PC TLV with fields set as follows:
3. 将TS/PC TLV添加到数据包正文（参见本节末尾的注释），字段设置如下：
Type Set to 11.
输入设置为11。
Length Set to 6.
长度设置为6。
PacketCounter Set to the current value of the LocalPC variable of the current outgoing interface.
PacketCounter设置为当前传出接口的LocalPC变量的当前值。
Timestamp Set to the current value of the LocalTS variable of the current outgoing interface.
时间戳设置为当前传出接口的LocalTS变量的当前值。
Note that the current step may involve byte order conversion.
请注意，当前步骤可能涉及字节顺序转换。
4. Derive a sequence of ESAs, using the procedure defined in Section 5.2, with the current interface's sequence of CSAs as the input sequence of CSAs, the current time as CT, and "sending" as the direction. Proceed to the next step even if the derived sequence is empty.
4. 使用第5.2节中定义的程序推导ESA序列，当前接口的CSA序列作为CSA的输入序列，当前时间为CT，“发送”为方向。即使派生序列为空，也继续执行下一步。
5. Iterate over the derived sequence, using its ordering. For each ESA, add to the packet body (see the note at the end of this section) an HMAC TLV with fields set as follows:
5. 使用其顺序在派生序列上迭代。对于每个ESA，向数据包正文（参见本节末尾的注释）添加一个HMAC TLV，字段设置如下：
Type Set to 12.
输入设置为12。
Length Set to 2 plus the digest length of HashAlgo of the current ESA.
长度设置为2加上当前ESA哈希算法的摘要长度。
KeyID Set to KeyID of the current ESA.
KeyID设置为当前ESA的KeyID。
Digest Size exactly equal to the digest length of HashAlgo of the current ESA. Pad (see Section 2.2), using the source address of the current packet (see Section 6.1).
摘要大小完全等于当前ESA的HashAlgo摘要长度。Pad（见第2.2节），使用当前数据包的源地址（见第6.1节）。
As soon as there are MaxDigestsOut HMAC TLVs added to the current packet body, immediately proceed to the next step.
一旦有MaxDigestsOut HMAC TLV添加到当前数据包正文中，立即进入下一步。
Note that the current step may involve byte order conversion.
请注意，当前步骤可能涉及字节顺序转换。
6. Increment the "Body length" field value of the current packet header by the total length of TS/PC and HMAC TLVs appended to the current packet body so far.
6. 将当前数据包头的“Body length”字段值增加到当前数据包主体附加的TS/PC和HMAC TLV的总长度。
Note that the current step may involve byte order conversion.
请注意，当前步骤可能涉及字节顺序转换。
7. Make a temporary copy of the current packet.
7. 制作当前数据包的临时副本。
8. Iterate over the derived sequence again, using the same order and number of elements. For each ESA (and, respectively, for each HMAC TLV recently appended to the current packet body), compute an HMAC result (see Section 2.4), using the temporary copy (not the original packet) as Text, HashAlgo of the current ESA as H, and AuthKeyOctets of the current ESA as K. Write the HMAC result to the Digest field of the current HMAC TLV (see Table 4 in Appendix A) of the current packet (not the copy).
8. 使用相同的元素顺序和数量，再次迭代派生序列。对于每个ESA（以及最近附加到当前数据包正文的每个HMAC TLV），使用临时副本（而不是原始数据包）作为文本，当前ESA的HashAlgo作为H，当前ESA的AuthKeyOctets作为K，计算HMAC结果（见第2.4节）。将HMAC结果写入当前HMAC TLV的摘要字段（见附录A中的表4）的当前数据包（不是副本）。
9. After this point, allow no more changes to the current packet header and body, and consider it ready for sending.
9. 在这一点之后，不允许对当前包头和主体进行更多的更改，并认为它已准备好发送。
Note that even when the derived sequence of ESAs is empty, the packet is sent anyway, with only a TS/PC TLV appended to its body. Although such a packet would not be authenticated, the presence of the sole TS/PC TLV would indicate authentication key exhaustion to operators of neighbouring Babel speakers. See also Section 7.4.
请注意，即使ESA的派生序列为空，也会发送数据包，并且只有TS/PC TLV附加到其主体。尽管这样的分组不会被认证，但是唯一的TS/PC TLV的存在将向相邻巴别塔扬声器的操作员指示认证密钥耗尽。另见第7.4节。
Also note that it is possible to place the authentication-specific TLVs in the packet's sequence of TLVs in a number of different valid ways so long as there is exactly one TS/PC TLV in the sequence and the ordering of HMAC TLVs relative to each other, as produced in step 5 above, is preserved.
还请注意，只要序列中正好有一个TS/PC TLV，并且如上面步骤5中产生的HMAC TLV的相对顺序被保留，就可以以多种不同的有效方式将认证特定TLV放置在TLV的分组序列中。
For example, see Figure 2 in Appendix A. The diagrams represent a Babel packet without (D1) and with (D2, D3, D4) authentication-specific TLVs. The optional trailing data block that is present in D1 is preserved in D2, D3, and D4. Indexing (1, 2, ..., n) of the HMAC TLVs means the order in which the sending procedure produced them (and, respectively, the HMAC results). In D2, the added TLVs are appended: the previously existing TLVs are followed by the TS/PC TLV, which is followed by the HMAC TLVs. In D3, the added TLVs are prepended: the TS/PC TLV is the first and is followed by the HMAC TLVs, which are followed by the previously existing TLVs. In D4, the added TLVs are intermixed with the previously existing TLVs and the TS/PC TLV is placed after the HMAC TLVs. All three packets meet the requirements above.
例如，参见附录A中的图2。这些图表示没有（D1）和（D2、D3、D4）认证特定TLV的Babel数据包。D1中存在的可选尾随数据块保留在D2、D3和D4中。HMAC TLV的索引（1，2，…，n）是指发送过程产生它们的顺序（分别是HMAC结果）。在D2中，添加的TLV被追加：先前存在的TLV之后是TS/PC TLV，之后是HMAC TLV。在D3中，添加的TLV是前置的：TS/PC TLV是第一个，然后是HMAC TLV，之后是先前存在的TLV。在D4中，添加的TLV与先前存在的TLV混合，TS/PC TLV放置在HMAC TLV之后。所有三个数据包都满足上述要求。
Implementors SHOULD use appending (D2) for adding the authentication-specific TLVs to the sequence; this is expected to result in more straightforward implementation and troubleshooting in most use cases.
实现者应该使用追加（D2）将特定于身份验证的TLV添加到序列中；在大多数用例中，这将导致更直接的实现和故障排除。
Perform the following authentication-specific processing after an incoming Babel packet is received from the local network stack but before it is acted upon by the Babel protocol instance (see Figure 1 in Appendix A). The final action conceptually depends not only upon the result of the authentication-specific processing but also on the current value of the RxAuthRequired parameter. Immediately after any processing step below accepts or refuses the packet, either deliver the packet to the instance of the original protocol (when the packet is accepted or RxAuthRequired is FALSE) or discard it (when the packet is refused and RxAuthRequired is TRUE).
在从本地网络堆栈接收到传入的Babel数据包之后，但在Babel协议实例对其进行操作之前，执行以下特定于身份验证的处理（参见附录A中的图1）。从概念上讲，最终操作不仅取决于特定于身份验证的处理结果，还取决于RxAuthRequired参数的当前值。在下面的任何处理步骤接受或拒绝数据包后，立即将数据包传递到原始协议的实例（当数据包被接受或RxAuthRequired为FALSE时），或丢弃它（当数据包被拒绝且RxAuthRequired为TRUE时）。
1. If the current incoming interface's sequence of CSAs is empty, accept the packet.
1. 如果当前传入接口的CSA序列为空，则接受该数据包。
2. If the current packet does not contain exactly one TS/PC TLV, refuse it.
2. 如果当前数据包不包含一个TS/PC TLV，请拒绝它。
3. Perform a lookup in the ANM table for an entry having Interface equal to the current incoming interface and Source equal to the source address of the current packet. If such an entry does not exist, immediately proceed to the next step. Otherwise, compare the entry's LastTS and LastPC field values with the Timestamp and PacketCounter values, respectively, of the TS/PC TLV of the packet. That is, refuse the packet if at least one of the following two conditions is true:
3. 在ANM表中查找接口等于当前传入接口且源等于当前数据包源地址的条目。如果不存在此类条目，请立即进入下一步。否则，将条目的lasts和LastPC字段值分别与数据包的TS/PC TLV的Timestamp和PacketCounter值进行比较。即，如果以下两个条件中的至少一个为真，则拒绝数据包：
* Timestamp is less than LastTS
* 时间戳小于LastTS
* Timestamp is equal to LastTS and PacketCounter is not greater than LastPC
* 时间戳等于LastTS，且PacketCounter不大于LastPC
Note that the current step may involve byte order conversion.
请注意，当前步骤可能涉及字节顺序转换。
4. Derive a sequence of ESAs, using the procedure defined in Section 5.2, with the current interface's sequence of CSAs as the input sequence of CSAs, current time as CT, and "receiving" as the direction. If the derived sequence is empty, refuse the packet.
4. 使用第5.2节中定义的程序，以当前接口的CSA序列作为CSA的输入序列，以当前时间为CT，以“接收”为方向，推导ESA序列。如果派生序列为空，则拒绝该数据包。
5. Make a temporary copy of the current packet.
5. 制作当前数据包的临时副本。
6. Pad (see Section 2.2) every HMAC TLV present in the temporary copy (not the original packet), using the source address of the original packet.
6. 使用原始数据包的源地址，对临时副本（非原始数据包）中的每个HMAC TLV进行Pad（见第2.2节）。
7. Iterate over all the HMAC TLVs of the original input packet (not the copy), using their order of appearance in the packet. For each HMAC TLV, look up all ESAs in the derived sequence such that 2 plus the digest length of HashAlgo of the ESA is equal to Length of the TLV and KeyID of the ESA is equal to the value of KeyID of the TLV. Iterate over these ESAs in the relative order of their appearance on the full sequence of ESAs. Note that nesting the iterations the opposite way (over ESAs, then over HMAC TLVs) would be wrong.
7. 使用原始输入数据包（而不是副本）的HMAC TLV在数据包中的出现顺序，对其进行迭代。对于每个HMAC TLV，在导出序列中查找所有ESA，以便2加上ESA的HashAlgo摘要长度等于TLV的长度，ESA的KeyID等于TLV的KeyID值。按照ESA完整序列中出现的相对顺序对这些ESA进行迭代。请注意，以相反的方式嵌套迭代（在ESA上，然后在HMAC TLV上）是错误的。
For each of these ESAs, compute an HMAC result (see Section 2.4), using the temporary copy (not the original packet) as Text, HashAlgo of the current ESA as H, and AuthKeyOctets of the current ESA as K. If the current HMAC result exactly matches the contents of the Digest field of the current HMAC TLV, immediately proceed to the next step. Otherwise, if the number of HMAC computations done for the current packet so far is equal to MaxDigestsIn, immediately proceed to the next step. Otherwise, follow the normal order of iterations.
对于每个ESA，使用临时副本（而非原始数据包）作为文本，当前ESA的HashAlgo作为H，当前ESA的AuthKeyOctets作为K，计算HMAC结果（见第2.4节）。如果当前HMAC结果与当前HMAC TLV摘要字段的内容完全匹配，则立即进入下一步。否则，如果到目前为止对当前数据包进行的HMAC计算数量等于MaxDigestsIn，则立即进入下一步。否则，遵循正常的迭代顺序。
Note that the current step may involve byte order conversion.
请注意，当前步骤可能涉及字节顺序转换。
8. Refuse the input packet unless there was a matching HMAC result in the previous step.
8. 拒绝输入数据包，除非在上一步中有匹配的HMAC结果。
9. Modify the ANM table, using the same index as for the entry lookup above, to contain an entry with LastTS set to the value of Timestamp and LastPC set to the value of PacketCounter fields of the TS/PC TLV of the current packet. That is, either add a new ANM table entry or update the existing one, depending on the result of the entry lookup above. Reset the entry's aging timer to the current value of ANM timeout.
9. 使用与上述条目查找相同的索引修改ANM表，以包含一个条目，其中LastTS设置为Timestamp值，LastPC设置为当前数据包的TS/PC TLV的PacketCounter字段值。也就是说，根据上述条目查找的结果，添加新的ANM表条目或更新现有条目。将条目的老化计时器重置为ANM timeout的当前值。
Note that the current step may involve byte order conversion.
请注意，当前步骤可能涉及字节顺序转换。
10. Accept the input packet.
10. 接受输入数据包。
Before performing the authentication-specific processing above, an implementation SHOULD perform those basic procedures of the original protocol that don't take any protocol actions on the contents of the packet but that will discard the packet if it is not sufficiently well formed for further processing. Although the exact composition of such procedures belongs to the scope of the original protocol, it seems reasonable to state that a packet SHOULD be discarded early, regardless of whether any authentication-specific processing is due, unless its source address conforms to Section 3.1 of [BABEL] and is not the receiving speaker's own address (see item (e) of Section 8).
在执行上述特定于身份验证的处理之前，实现应执行原始协议的那些基本过程，这些过程不对数据包的内容采取任何协议操作，但如果数据包的格式不足以进行进一步处理，则将丢弃该数据包。尽管此类程序的确切组成属于原始协议的范围，但似乎可以合理地指出，无论是否需要任何特定于身份验证的处理，数据包应尽早丢弃，除非其源地址符合[BABEL]第3.1节的规定，并且不是接收说话人自己的地址（见第8节第（e）项）。
Note that RxAuthRequired affects only the final action but not the defined flow of authentication-specific processing. The purpose of this is to preserve authentication-specific processing feedback (such as log messages and event-counter updates), even with RxAuthRequired set to FALSE. This allows an operator to predict the effect of changing RxAuthRequired from FALSE to TRUE during a migration scenario (Section 7.3) implementation.
请注意，RxAuthRequired仅影响最终操作，而不影响特定于身份验证的处理的定义流。这样做的目的是保留特定于身份验证的处理反馈（例如日志消息和事件计数器更新），即使RxAuthRequired设置为FALSE。这允许操作员在迁移场景（第7.3节）实施期间预测将RxAuthRequired从FALSE更改为TRUE的效果。
A Babel speaker implementing this mechanism SHOULD maintain a set of counters for the following events, per protocol instance and per interface:
实现此机制的巴别塔扬声器应为每个协议实例和每个接口的以下事件维护一组计数器：
a. Sending an unauthenticated Babel packet through an interface having an empty sequence of CSAs (Section 5.3 item 1).
a. 通过具有空CSA序列的接口发送未经验证的Babel数据包（第5.3节第1项）。
b. Sending an unauthenticated Babel packet with a TS/PC TLV but without any HMAC TLVs, due to an empty derived sequence of ESAs (Section 5.3 item 4).
b. 由于ESA的派生序列为空，发送带有TS/PC TLV但没有任何HMAC TLV的未经验证的Babel数据包（第5.3节第4项）。
c. Sending an authenticated Babel packet containing both TS/PC and HMAC TLVs (Section 5.3 item 9).
c. 发送包含TS/PC和HMAC TLV的经过认证的巴别塔数据包（第5.3节第9项）。
d. Accepting a Babel packet received through an interface having an empty sequence of CSAs (Section 5.4 item 1).
d. 接受通过具有空CSA序列的接口接收的Babel数据包（第5.4节第1项）。
e. Refusing a received Babel packet due to an empty derived sequence of ESAs (Section 5.4 item 4).
e. 由于ESA派生序列为空，拒绝接收到的Babel数据包（第5.4节第4项）。
f. Refusing a received Babel packet that does not contain exactly one TS/PC TLV (Section 5.4 item 2).
f. 拒绝接收不完全包含一个TS/PC TLV的Babel数据包（第5.4节第2项）。
g. Refusing a received Babel packet due to the TS/PC TLV failing the ANM table check (Section 5.4 item 3). With possible future extensions in mind, in implementations of this mechanism, this event SHOULD leave out some small amount, per current (Interface, Source, LastTS, LastPC) tuple, of the packets refused due to the Timestamp value being equal to LastTS and the PacketCounter value being equal to LastPC.
g. 由于TS/PC TLV未能通过ANM表检查（第5.4节第3项），因此拒绝接收Babel数据包。考虑到未来可能的扩展，在该机制的实现中，该事件应该在每个当前（接口、源、LastTS、LastPC）元组中遗漏一些少量的数据包，因为时间戳值等于LastTS，PacketCounter值等于LastPC。
h. Refusing a received Babel packet missing any HMAC TLVs (Section 5.4 item 8).
h. 拒绝接收缺少任何HMAC TLV的Babel数据包（第5.4节第8项）。
i. Refusing a received Babel packet due to none of the processed HMAC TLVs passing the ESA check (Section 5.4 item 8).
i. 由于处理的HMAC TLV均未通过ESA检查（第5.4节第8项），因此拒绝接收Babel数据包。
j. Accepting a received Babel packet having both TS/PC and HMAC TLVs (Section 5.4 item 10).
j. 接收同时具有TS/PC和HMAC TLV的巴别塔数据包（第5.4节第10项）。
k. Delivery of a refused packet to the instance of the original protocol due to the RxAuthRequired parameter being set to FALSE.
k. 由于RxAuthRequired参数设置为FALSE，将拒绝的数据包传递到原始协议的实例。
Note that the terms "accepting" and "refusing" are used in the sense of the receiving procedure; that is, "accepting" does not mean a packet delivered to the instance of the original protocol purely because the RxAuthRequired parameter is set to FALSE. Event-counter readings SHOULD be available to the operator at runtime.
请注意，“接受”和“拒绝”这两个术语是在接收程序的意义上使用的；也就是说，“接受”并不意味着仅仅因为RxAuthRequired参数被设置为FALSE而将数据包传递到原始协议的实例。事件计数器读数应在运行时提供给操作员。
Section 3.1 of [BABEL] allows for the exchange of protocol datagrams, using IPv4, IPv6, or both. The source address of the datagram is a unicast (link-local in the case of IPv6) address. Within an address family used by a Babel speaker, there may be more than one address eligible for the exchange and assigned to the same network interface. The original specification considers this case out of scope and leaves it up to the speaker's network stack to select one particular address as the datagram source address, but the sending procedure requires (Section 5.3 item 5) exact knowledge of the packet source address for proper padding of HMAC TLVs.
[BABEL]第3.1节允许使用IPv4、IPv6或两者交换协议数据报。数据报的源地址是单播（在IPv6情况下为本地链路）地址。在巴别塔扬声器使用的地址族中，可能有多个地址符合交换条件并分配给同一网络接口。原始规范认为这种情况超出了范围，并将选择一个特定地址作为数据报源地址留给演讲者的网络堆栈，但发送程序要求（第5.3节第5项）准确了解数据包源地址，以便正确填充HMAC TLV。
As long as a network interface has more than one address eligible for the exchange within the same address family, the Babel speaker SHOULD internally choose one of those addresses for Babel packet sending purposes and then indicate this choice to both the sending procedure and the network stack (see Figure 1 in Appendix A). Wherever this requirement cannot be met, this limitation MUST be clearly stated in the system documentation to allow an operator to plan network address management accordingly.
只要网络接口在同一地址系列中有多个符合交换条件的地址，巴别塔扬声器应在内部选择其中一个地址用于巴别塔数据包发送，然后向发送程序和网络堆栈指示该选择（参见附录a中的图1）。如果无法满足此要求，则必须在系统文档中明确说明此限制，以允许运营商相应地规划网络地址管理。
An instance of the original protocol will buffer produced TLVs until the buffer becomes full or a delay timer has expired. This is performed independently for each Babel interface, with each buffer sized according to the interface MTU (see Sections 3.1 and 4 of [BABEL]).
原始协议的实例将缓冲产生的TLV，直到缓冲区变满或延迟计时器过期。这是针对每个Babel接口独立执行的，每个缓冲区的大小根据接口MTU确定（见[Babel]第3.1节和第4节）。
Since TS/PC TLVs, HMAC TLVs, and any other TLVs -- and most likely the TLVs of the original protocol -- share the same packet space (see Figure 2 in Appendix A) and, respectively, the same buffer space, a particular portion of each interface buffer needs to be reserved for one TS/PC TLV and up to MaxDigestsOut HMAC TLVs. The amount (R) of this reserved buffer space is calculated as follows:
由于TS/PC TLV、HMAC TLV和任何其他TLV——最有可能是原始协议的TLV——共享相同的数据包空间（参见附录A中的图2）和相同的缓冲区空间，每个接口缓冲区的特定部分需要为一个TS/PC TLV和最多MaxDigestsOut HMAC TLV保留。此保留缓冲区空间的量（R）计算如下：
R = St + MaxDigestsOut * Sh
R = 8 + MaxDigestsOut * (4 + Lmax)
R = St + MaxDigestsOut * Sh
R = 8 + MaxDigestsOut * (4 + Lmax)
St The size of a TS/PC TLV.
St为TS/PC TLV的尺寸。
Sh The size of an HMAC TLV.
Sh为HMAC TLV的尺寸。
Lmax The maximum possible digest length in octets for a particular interface. It SHOULD be calculated based on the particular interface's sequence of CSAs but MAY be taken as the maximum digest length supported by a particular implementation.
Lmax特定接口的最大可能摘要长度（以八位字节为单位）。它应该基于特定接口的CSA序列进行计算，但可以作为特定实现支持的最大摘要长度。
An implementation allowing for a per-interface value of MaxDigestsOut or Lmax has to account for a different value of R across different interfaces, even interfaces having the same MTU. An implementation allowing for a runtime change to the value of R (due to MaxDigestsOut or Lmax) has to take care of the TLVs already buffered by the time of the change -- specifically, when the value of R increases.
允许每个接口的MaxDigestsOut或Lmax值的实现必须考虑不同接口的不同R值，即使接口具有相同的MTU。允许对R值进行运行时更改的实现（由于MaxDigestsOut或Lmax）必须处理更改时已经缓冲的TLV——特别是在R值增加时。
The maximum safe value of the MaxDigestsOut parameter depends on the interface MTU and maximum digest length used. In general, at least 200-300 octets of a Babel packet should always be available to data other than TS/PC and HMAC TLVs. An implementation following the requirements of Section 4 of [BABEL] would send packets of 512 octets or larger. If, for example, the maximum digest length is 64 octets and the MaxDigestsOut value is 4, the value of R would be 280, leaving less than half of a 512-octet packet for any other TLVs. As long as the interface MTU is larger or the digest length is smaller, higher values of MaxDigestsOut can be used safely.
MaxDigestsOut参数的最大安全值取决于所使用的接口MTU和最大摘要长度。通常，除了TS/PC和HMAC TLV之外，Babel数据包的至少200-300个八位字节应始终可用于其他数据。遵循[BABEL]第4节要求的实现将发送512个八位字节或更大的数据包。例如，如果最大摘要长度为64个八位字节，而MaxDigestsOut值为4，则R的值将为280，为任何其他TLV留下不到512个八位字节数据包的一半。只要接口MTU较大或摘要长度较小，就可以安全地使用较高的MaxDigestsOut值。
The following optimizations of the deriving procedure for ESAs can reduce the amount of CPU time consumed by authentication-specific processing, preserving an implementation's effective behaviour.
以下ESA派生过程的优化可以减少特定于身份验证的处理所消耗的CPU时间，从而保持实现的有效行为。
a. The most straightforward implementation would treat the deriving procedure as a per-packet action, but since the procedure is deterministic (its output depends on its input only), it is possible to significantly reduce the number of times the procedure is performed.
a. 最直接的实现是将派生过程视为每包操作，但由于该过程是确定性的（其输出仅取决于其输入），因此可以显著减少执行该过程的次数。
The procedure would obviously return the same result for the same input arguments (sequence of CSAs, direction, CT) values. However, it is possible to predict when the result will remain the same, even for a different input. That is, when the input sequence of CSAs and the direction both remain the same but CT changes, the result will remain the same as long as CT's order on the time axis (relative to all critical points of the sequence of CSAs) remains unchanged. Here, the critical points are KeyStartAccept and KeyStopAccept (for the receiving direction), and KeyStartGenerate and KeyStopGenerate (for the sending direction), of all keys of all CSAs of the input sequence. In other words, in this case the result will remain the same as long as (1) none of the active keys expire and (2) none of the inactive keys enter into operation.
对于相同的输入参数（CSA序列、方向、CT）值，该过程显然会返回相同的结果。但是，即使输入不同，也可以预测结果何时保持不变。也就是说，当CSA的输入序列和方向都保持不变，但CT发生变化时，只要CT在时间轴上的顺序（相对于CSA序列的所有临界点）保持不变，结果将保持不变。这里，关键点是输入序列的所有CSA的所有键的KeyStartAccept和Keyspaccept（用于接收方向）以及KeyStartGenerate和KeyspGenerate（用于发送方向）。换言之，在这种情况下，只要（1）所有活动密钥均未过期，且（2）所有非活动密钥均未投入运行，结果将保持不变。
An implementation optimized in this way would perform the full deriving procedure for a given (interface, direction) pair only after an operator's change to the interface's sequence of CSAs or after reaching one of the critical points mentioned above.
以这种方式优化的实现仅在操作员更改接口的CSA序列或达到上述临界点之一后，才会对给定（接口、方向）对执行完整的推导过程。
b. Considering that the sending procedure iterates over at most MaxDigestsOut elements of the derived sequence of ESAs (Section 5.3 item 5), there would be little sense, in the case of the sending direction, in returning more than MaxDigestsOut ESAs in the derived sequence. Note that a similar optimization would be relatively difficult in the case of the receiving direction, since the number of ESAs actually used in examining a particular received packet (not to be confused with the number of HMAC computations) depends on additional factors besides just MaxDigestsIn.
b. 考虑到发送过程最多迭代ESA派生序列的MaxDigestsOut元素（第5.3节第5项），在发送方向的情况下，在派生序列中返回多于MaxDigestsOut ESA是没有意义的。注意，在接收方向的情况下，类似的优化将相对困难，因为在检查特定接收数据包时实际使用的ESA数量（不要与HMAC计算的数量混淆）取决于除MaxDigestsIn之外的其他因素。
This specification defines three data structures as finite sequences: a KeyChain sequence, an interface's sequence of CSAs, and a sequence of ESAs. There are associated semantics to take into account during implementation, in that the same element can appear multiple times at different positions of the sequence. In particular, none of the CSA structure fields (including HashAlgo, LocalKeyID, and AuthKeyOctets), alone or in a combination, have to be unique within a given CSA, or within a given sequence of CSAs, or within all sequences of CSAs of a Babel speaker.
本规范将三种数据结构定义为有限序列：钥匙链序列、CSA接口序列和ESA序列。在实现过程中需要考虑相关的语义，因为同一元素可以在序列的不同位置多次出现。特别是，CSA结构字段（包括HashAlgo、LocalKeyID和AuthKeyOctets）单独或组合在给定CSA、给定CSA序列或巴别塔扬声器的所有CSA序列中都不必是唯一的。
In the CSA space defined in this way, for any two authentication keys, their one field (in)equality would not imply another field (in)equality. In other words, it is acceptable to have more than one authentication key with the same LocalKeyID or the same AuthKeyOctets, or both at a time. It is a conscious design decision
在以这种方式定义的CSA空间中，对于任何两个身份验证密钥，它们的一个字段（In）相等并不意味着另一个字段（In）相等。换句话说，一次可以有多个具有相同LocalKeyID或相同AuthKeyOctets或两者的身份验证密钥。这是一个有意识的设计决策
that CSA semantics allow for duplication of security associations. Consequently, ESA semantics allow for duplication of intermediate ESAs in the sequence until the explicit deduplication (Section 5.2 item 4).
CSA语义允许复制安全关联。因此，ESA语义允许在序列中复制中间ESA，直到显式重复数据消除（第5.2节第4项）。
One of the intentions of this is to define the security association management in a way that allows the addressing of some specifics of Babel as a mesh routing protocol. For example, a system operator configuring a Babel speaker to participate in more than one administrative domain could find each domain using its own authentication key (AuthKeyOctets) under the same LocalKeyID value, e.g., a "well-known" or "default" value like 0 or 1. Since reconfiguring the domains to use distinct LocalKeyID values isn't always feasible, the multi-domain Babel speaker, using several distinct authentication keys under the same LocalKeyID, would make a valid use case for such duplication.
其目的之一是定义安全关联管理，允许将Babel的某些细节作为网状路由协议进行寻址。例如，系统操作员将巴别塔扬声器配置为参与多个管理域，可以在相同的LocalKeyID值（例如“已知”或“默认”值，如0或1）下使用其自己的身份验证密钥（AuthKeyOctets）查找每个域。由于将域重新配置为使用不同的LocalKeyID值并不总是可行的，因此在同一LocalKeyID下使用多个不同身份验证密钥的多域Babel speaker将成为此类复制的有效用例。
Furthermore, if the operator decided in this situation to migrate one of the domains to a different LocalKeyID value in a seamless way, the respective Babel speakers would use the same authentication key (AuthKeyOctets) under two different LocalKeyID values for the time of the transition (see also item (f) of Section 8). This would make a similar use case.
此外，如果操作员在这种情况下决定以无缝方式将其中一个域迁移到不同的LocalKeyID值，则在转换期间，各个巴别塔扬声器将在两个不同的LocalKeyID值下使用相同的身份验证密钥（AuthKeyOctets）（另请参见第8节的（f）项）。这将产生一个类似的用例。
Another intention of this design decision is to decouple security association management from authentication key management as much as possible, so that the latter, be it manual keying or a key-management protocol, could be designed and implemented independently (as the respective reasoning made in Section 3.1 of [RIP2-AUTH] still applies). This way, the additional key-management constraints, if any, would remain out of the scope of this authentication mechanism. A similar thinking justifies the LocalKeyID field having a bit length in an ESA structure definition, but not in that of the CSA.
该设计决策的另一个目的是尽可能地将安全关联管理与认证密钥管理分离，以便后者（无论是手动密钥还是密钥管理协议）可以独立设计和实施（如[RIP2-AUTH]第3.1节中的相应推理仍然适用）。这样，附加的密钥管理约束（如果有的话）将不在此身份验证机制的范围内。类似的想法证明LocalKeyID字段在ESA结构定义中具有位长度，但在CSA结构定义中不具有位长度。
Support of this mechanism is optional. It does not change the default behaviour of a Babel speaker and causes no compatibility issues with speakers properly implementing the original Babel specification. Given two Babel speakers -- one implementing this mechanism and configured for authenticated exchange (A) and another not implementing it (B) -- these speakers would not distribute routing information unidirectionally, form a routing loop, or experience other protocol logic issues specific purely to the use of this mechanism.
此机制的支持是可选的。它不会改变巴别塔扬声器的默认行为，也不会导致与正确实现原始巴别塔规范的扬声器的兼容性问题。给定两个巴别塔扬声器——一个实现此机制并配置为经过身份验证的交换（A），另一个未实现此机制（B）——这些扬声器不会单向分发路由信息，形成路由循环，或遇到纯粹使用此机制所特有的其他协议逻辑问题。
The Babel design requires a bidirectional neighbour reachability condition between two given speakers for a successful exchange of routing information. Apparently, neighbour reachability would be unidirectional in the case above. The presence of TS/PC and HMAC TLVs in Babel packets sent by A would be transparent to B, but a lack of authentication data in Babel packets sent by B would make them effectively invisible to the instance of the original protocol of A. Unidirectional links are not specific to the use of this mechanism; they naturally exist on their own and are properly detected and coped with by the original protocol (see Section 3.4.2 of [BABEL]).
巴贝尔设计要求在两个给定的说话人之间具有双向邻居可达性条件，以便成功地交换路由信息。显然，在上述情况下，邻居可达性是单向的。A发送的Babel数据包中存在TS/PC和HMAC TLV对B是透明的，但B发送的Babel数据包中缺少身份验证数据将使其对A的原始协议实例实际上是不可见的。单向链路不特定于此机制的使用；它们自然独立存在，并由原始协议正确检测和处理（见[BABEL]第3.4.2节）。
The receiving procedure treats a packet as authentic as soon as one of its HMAC TLVs passes the check against the derived sequence of ESAs. This allows for packet exchange authenticated with multiple (hash algorithm, authentication key) pairs simultaneously, in combinations as arbitrary as permitted by MaxDigestsIn and MaxDigestsOut.
一旦数据包的一个HMAC TLV通过对ESA派生序列的检查，接收过程就会将其视为真实数据包。这允许同时以MaxDigestsIn和MaxDigestsOut允许的任意组合使用多个（哈希算法、身份验证密钥）对进行身份验证的数据包交换。
For example, consider three Babel speakers with one interface each, configured with the following CSAs:
例如，考虑三个具有一个接口的巴贝尔扬声器，配置如下CSAs：
o speaker A: (hash algorithm H1; key SK1), (hash algorithm H1; key SK2)
o 演讲者A：（散列算法H1；密钥SK1），（散列算法H1；密钥SK2）
o speaker B: (hash algorithm H1; key SK1)
o 演讲者B：（散列算法H1；密钥SK1）
o speaker C: (hash algorithm H1; key SK2)
o 演讲者C：（散列算法H1；密钥SK2）
Packets sent by A would contain two HMAC TLVs each. Packets sent by B and C would contain one HMAC TLV each. A and B would authenticate the exchange between themselves, using H1 and SK1; A and C would use H1 and SK2; B and C would discard each other's packets.
A发送的数据包将分别包含两个HMAC TLV。B和C发送的数据包将分别包含一个HMAC TLV。A和B将使用H1和SK1对它们之间的交换进行身份验证；A和C将使用H1和SK2；B和C会丢弃彼此的数据包。
Consider a similar set of speakers configured with different CSAs:
考虑用不同的CSAs配置的一组类似的扬声器：
o speaker D: (hash algorithm H2; key SK3), (hash algorithm H3; key SK4)
o 说话人D：（散列算法H2；密钥SK3），（散列算法H3；密钥SK4）
o speaker E: (hash algorithm H2; key SK3), (hash algorithm H4; keys SK5 and SK6)
o 发言者E：（散列算法H2；密钥SK3），（散列算法H4；密钥SK5和SK6）
o speaker F: (hash algorithm H3; keys SK4 and SK7), (hash algorithm H5; key SK8)
o 扬声器F：（散列算法H3；密钥SK4和SK7），（散列算法H5；密钥SK8）
Packets sent by D would contain two HMAC TLVs each. Packets sent by E and F would contain three HMAC TLVs each. D and E would authenticate the exchange between themselves, using H2 and SK3; D and F would use H3 and SK4; E and F would discard each other's packets. The simultaneous use of H4, SK5, and SK6 by E, as well as the use of SK7, H5, and SK8 by F (for their own purposes), would remain insignificant to D.
D发送的数据包将分别包含两个HMAC TLV。E和F发送的数据包将分别包含三个HMAC TLV。D和E将使用H2和SK3验证它们之间的交换；D和F将使用H3和SK4；E和F将丢弃彼此的数据包。E同时使用H4、SK5和SK6，以及F同时使用SK7、H5和SK8（出于各自的目的），对D来说仍然无关紧要。
An operator implementing multi-domain authentication should keep in mind that values of MaxDigestsIn and MaxDigestsOut may be different both within the same Babel speaker and across different speakers. Since the minimum value of both parameters is 2 (see Sections 3.4 and 3.5), when more than two authentication domains are configured simultaneously it is advisable to confirm that every involved speaker can handle a sufficient number of HMAC results for both sending and receiving.
实现多域身份验证的操作员应记住，MaxDigestsIn和MaxDigestsOut的值在同一个巴别塔扬声器内和不同扬声器之间可能不同。由于两个参数的最小值均为2（见第3.4节和第3.5节），因此当同时配置两个以上的认证域时，建议确认每个相关的说话人都可以处理足够数量的HMAC结果，用于发送和接收。
The recommended method of Babel speaker configuration for multi-domain authentication is to not only use a different authentication key for each domain but also a separate CSA for each domain, even when hash algorithms are the same. This allows for fair competition between CSAs and sometimes limits the consequences of a possible misconfiguration to the scope of one CSA. See also item (f) of Section 8.
对于多域身份验证，Babel speaker配置的推荐方法是，不仅为每个域使用不同的身份验证密钥，而且为每个域使用单独的CSA，即使哈希算法相同。这允许CSA之间的公平竞争，有时将可能的错误配置的后果限制在一个CSA的范围内。另见第8节第（f）项。
It is common in practice to consider a migration to the authenticated exchange of routing information only after the network has already been deployed and put into active use. Performing the migration in a way without regular traffic interruption is typically demanded, and this specification allows a smooth migration using the RxAuthRequired interface parameter defined in Section 3.1. This measure is similar to the "transition mode" suggested in Section 5 of [OSPF3-AUTH-BIS].
在实践中，只有在网络已经部署并投入使用之后才考虑迁移到路由信息的认证交换。通常要求以无常规通信中断的方式执行迁移，本规范允许使用第3.1节中定义的RxAuthRequired接口参数进行平滑迁移。该措施类似于[OSPF3-AUTH-BIS]第5节中建议的“过渡模式”。
An operator performing the migration needs to arrange configuration changes as follows:
执行迁移的操作员需要按如下方式安排配置更改：
1. Decide on particular hash algorithm(s) and key(s) to be used.
1. 决定要使用的特定哈希算法和密钥。
2. Identify all speakers and their involved interfaces that need to be migrated to authenticated exchange.
2. 确定需要迁移到经过身份验证的exchange的所有演讲者及其相关接口。
3. For each of the speakers and the interfaces to be reconfigured, first set the RxAuthRequired parameter to FALSE, then configure necessary CSA(s).
3. 对于要重新配置的每个扬声器和接口，首先将RxAuthRequired参数设置为FALSE，然后配置必要的CSA。
4. Examine the speakers to confirm that Babel packets are successfully authenticated according to the configuration (for instance, by examining ANM table entries and authentication-specific statistics; see Figure 1 in Appendix A), and address any discrepancies before proceeding further.
4. 检查扬声器，确认Babel数据包已根据配置成功通过身份验证（例如，通过检查ANM表条目和特定于身份验证的统计数据；参见附录A中的图1），并在继续之前解决任何差异。
5. For each of the speakers and the reconfigured interfaces, set the RxAuthRequired parameter to TRUE.
5. 对于每个扬声器和重新配置的接口，将RxAuthRequired参数设置为TRUE。
Likewise, temporarily setting RxAuthRequired to FALSE can be used to migrate smoothly from an authenticated packet exchange back to an unauthenticated one.
同样，可以使用临时将RxAuthRequired设置为FALSE来顺利地从经过身份验证的数据包交换迁移回未经身份验证的数据包交换。
This specification employs a common concept of multiple authentication keys coexisting for a given interface, with two independent lifetime ranges associated with each key (one for sending and another for receiving). It is typically recommended that the keys be configured using finite lifetimes, adding new keys before the old keys expire. However, it is obviously possible for all keys to expire for a given interface (for sending, receiving, or both). Possible ways of addressing this situation raise their own concerns:
本规范采用了一个通用概念，即给定接口共存多个身份验证密钥，每个密钥有两个独立的生存期范围（一个用于发送，另一个用于接收）。通常建议使用有限的生命周期来配置密钥，在旧密钥过期之前添加新密钥。然而，对于给定的接口（用于发送、接收或两者），所有密钥显然都可能过期。解决这种情况的可能方法引起了他们自己的关注：
o Automatic switching to unauthenticated protocol exchange. This behaviour invalidates the initial purposes of authentication and is commonly viewed as unacceptable ([RIP2-AUTH] Section 5.1, [OSPF2-AUTH] Section 3.2, and [OSPF3-AUTH-BIS] Section 3).
o 自动切换到未经验证的协议交换。这种行为使身份验证的初始目的无效，通常被视为不可接受（[RIP2-AUTH]第5.1节、[OSPF2-AUTH]第3.2节和[OSPF3-AUTH-BIS]第3节）。
o Stopping routing information exchange over the interface. This behaviour is likely to impact regular traffic routing and is commonly viewed as "not advisable" ([RIP2-AUTH], [OSPF2-AUTH], and [OSPF3-AUTH]), although [OSPF3-AUTH-BIS] is different in this regard.
o 正在停止通过接口进行路由信息交换。这种行为可能会影响常规流量路由，通常被视为“不可取”（[RIP2-AUTH]、[OSPF2-AUTH]和[OSPF3-AUTH]），尽管[OSPF3-AUTH-BIS]在这方面有所不同。
o The use of the "most recently expired" key over its intended lifetime range. This behaviour is recommended for implementation in [RIP2-AUTH], [OSPF2-AUTH], and [OSPF3-AUTH] but not in [OSPF3-AUTH-BIS]. Such use of this key may become a problem, due to an offline cryptographic attack (see item (f) of Section 8) or a compromise of the key. In addition, distinguishing a recently expired key from a key that has never been used may be impossible after a router restart.
o “最近过期”密钥在其预期寿命范围内的使用。建议在[RIP2-AUTH]、[OSPF2-AUTH]和[OSPF3-AUTH]中实现此行为，但不在[OSPF3-AUTH-BIS]中实现。由于离线加密攻击（见第8节第（f）项）或密钥泄露，此密钥的使用可能会成为问题。此外，在路由器重新启动后，可能无法区分最近过期的密钥和从未使用过的密钥。
The design of this mechanism prevents automatic switching to unauthenticated exchange and is consistent with similar authentication mechanisms in this regard, but since the best choice between two other options depends on local site policy, this decision
此机制的设计可防止自动切换到未经身份验证的exchange，并与这方面的类似身份验证机制一致，但由于两个其他选项之间的最佳选择取决于本地站点策略，因此此决定
is left up to the operator rather than the implementor (in a way resembling the "fail secure" configuration knob described in Section 5.1 of [RIP2-AUTH]).
由操作员而不是实施者决定（类似于[RIP2-AUTH]第5.1节所述的“故障安全”配置旋钮）。
Although the deriving procedure does not allow for any exceptions in the filtering of expired keys (Section 5.2 item 2), the operator can trivially enforce one of the two remaining behaviour options through local key-management procedures. In particular, when using the key over its intended lifetime is preferable to regular traffic disruption, the operator would explicitly leave the old key expiry time open until the new key is added to the router configuration. In the opposite case, the operator would always configure the old key with a finite lifetime and bear associated risks.
尽管衍生程序不允许在过滤过期密钥（第5.2节第2项）时出现任何异常情况，但操作员可以通过本地密钥管理程序轻松实施剩余两个行为选项中的一个。特别是，当在其预期寿命内使用密钥优于常规通信中断时，操作员将明确地保持旧密钥到期时间打开，直到新密钥添加到路由器配置。在相反的情况下，操作员总是将旧密钥配置为有限寿命，并承担相关风险。
The use of this mechanism implies requirements common to the use of shared authentication keys, including, but not limited to:
此机制的使用意味着共享身份验证密钥的共同使用要求，包括但不限于：
o holding the keys secret,
o 把钥匙保密，
o including sufficient amounts of random bits into each key,
o 在每个密钥中包含足够数量的随机位，
o rekeying on a regular basis, and
o 定期更新密钥，以及
o never reusing a used key for a different purpose.
o 切勿将使用过的密钥用于其他目的。
That said, proper design and implementation of a key-management policy are out of the scope of this work. Many publications on this subject exist and should be used for this purpose (BCP 107 [RFC4107], BCP 132 [RFC4962], and [RFC6039] are suggested as starting points).
这就是说，正确设计和实施关键管理政策不在本工作范围之内。关于这一主题的许多出版物已经存在并应用于此目的（建议将BCP 107[RFC4107]、BCP 132[RFC4962]和[RFC6039]作为起点）。
It is possible for a network that exercises rollover of authentication keys to experience accidental expiration of all the keys for a network interface, as discussed at greater length in Section 7.4. With that and the guidance of Section 5.1 of [RIP2-AUTH] in mind, in such an event the Babel speaker MUST send a "last key expired" notification to the operator (e.g., via syslog, SNMP, and/or other implementation-specific means), most likely in relation to item (b) of Section 5.5. Also, any actual occurrence of an authentication key expiration MUST cause a security event to be logged by the implementation. The log item MUST include at least a note that the authentication key has expired, the Babel routing protocol instance(s) affected, the network interface(s) affected, the LocalKeyID that is affected, and the current date/time. Operators are encouraged to check such logs as an operational security practice.
如第7.4节中更详细的讨论，对于执行认证密钥滚动的网络，可能会遇到网络接口的所有密钥意外过期的情况。考虑到这一点以及[RIP2-AUTH]第5.1节的指导，在这种情况下，巴别塔扬声器必须向操作员发送“最后一个密钥过期”通知（例如，通过系统日志、SNMP和/或其他特定于实施的方式），最有可能与第5.5节（b）项有关。此外，任何实际发生的身份验证密钥过期都必须导致实现记录安全事件。日志项必须至少包含一条注释，说明身份验证密钥已过期、受影响的Babel路由协议实例、受影响的网络接口、受影响的LocalKeyID以及当前日期/时间。鼓励操作员检查此类日志，作为操作安全实践。
Considering particular attacks being in scope or out of scope on one hand and measures taken to protect against particular in-scope attacks on the other, the original Babel protocol and this authentication mechanism are in line with similar datagram-based routing protocols and their respective mechanisms. In particular, the primary concerns addressed are:
考虑到一方面存在范围内或范围外的特定攻击，另一方面采取措施防止特定范围内攻击，原始Babel协议和该认证机制符合类似的基于数据报的路由协议及其各自的机制。特别是，所涉及的主要问题是：
a. Peer Entity Authentication
a. 对等实体认证
The Babel speaker authentication mechanism defined herein is believed to be as strong as the class itself to which it belongs. This specification is built on fundamental concepts implemented for authentication of similar routing protocols: per-packet authentication, the use of the HMAC construction, and the use of shared keys. Although this design approach does not address all possible concerns, it is so far known to be sufficient for most practical cases.
本文定义的巴别塔说话人认证机制被认为与它所属的类本身一样强大。本规范建立在为类似路由协议的身份验证而实现的基本概念之上：每包身份验证、HMAC结构的使用和共享密钥的使用。尽管这种设计方法并没有解决所有可能的问题，但到目前为止，已知它对于大多数实际情况是足够的。
b. Data Integrity
b. 数据完整性
Meaningful parts of a Babel datagram are the contents of the Babel packet (in the definition of Section 4.2 of [BABEL]) and the source address of the datagram (Section 3.5.3 of [BABEL]). This mechanism authenticates both parts, using the HMAC construction, so that making any meaningful change to an authenticated packet after it has been emitted by the sender should be as hard as attacking the HMAC construction itself or successfully recovering the authentication key.
巴别塔数据报的有意义部分是巴别塔数据包的内容（在[Babel]第4.2节的定义中）和数据报的源地址（在[Babel]第3.5.3节中）。该机制使用HMAC构造对这两个部分进行身份验证，因此，在发送方发出经过身份验证的数据包后，对其进行任何有意义的更改都应该与攻击HMAC构造本身或成功恢复身份验证密钥一样困难。
Note well that any trailing data of the Babel datagram is not meaningful in the scope of the original specification and does not belong to the Babel packet. Integrity of the trailing data is thus not protected by this mechanism. At the same time, although any TLV extra data is also not meaningful in the same scope, its integrity is protected, since this extra data is a part of the Babel packet (see Figure 2 in Appendix A).
请注意，Babel数据报的任何后续数据在原始规范的范围内都没有意义，并且不属于Babel数据包。因此，尾随数据的完整性不受此机制的保护。同时，尽管任何TLV额外数据在同一范围内也没有意义，但其完整性受到保护，因为该额外数据是Babel数据包的一部分（参见附录a中的图2）。
c. Denial of Service
c. 拒绝服务
Proper deployment of this mechanism in a Babel network significantly increases the efforts required for an attacker to feed arbitrary Babel packets into a protocol exchange (with the intent of attacking a particular Babel speaker or disrupting the exchange of regular traffic in a routing domain). It also protects the neighbour table from being flooded with forged speaker entries.
在Babel网络中正确部署此机制会显著增加攻击者将任意Babel数据包馈送到协议交换中所需的努力（目的是攻击特定Babel扬声器或中断路由域中的常规流量交换）。它还可以防止邻居表中充斥着伪造的说话人条目。
At the same time, this protection comes with a price of CPU time being spent on HMAC computations. This may be a concern for low-performance CPUs combined with high-speed interfaces, as sometimes seen in embedded systems and hardware routers. The MaxDigestsIn parameter, which is used to limit the maximum amount of CPU time spent on a single received Babel packet, addresses this concern to some extent.
同时，这种保护的代价是在HMAC计算上花费CPU时间。这可能是与高速接口相结合的低性能CPU的一个问题，有时在嵌入式系统和硬件路由器中可以看到这一点。MaxDigestsIn参数用于限制在单个接收到的Babel数据包上花费的最大CPU时间，在某种程度上解决了这个问题。
d. Reflection Attacks
d. 反射攻击
Given the approach discussed in item (b), the only potential reflection attack on this mechanism could be replaying exact copies of Babel packets back to the sender from the same source address. The mitigation in this case is straightforward and is discussed in Section 5.4.
考虑到第（b）项中讨论的方法，对该机制的唯一潜在反射攻击可能是将Babel数据包的精确副本从同一源地址重放回发送方。这种情况下的缓解措施很简单，第5.4节对此进行了讨论。
The following in-scope concern is only partially addressed:
以下范围内的问题仅得到部分解决：
e. Replay Attacks
e. 攻击回放
This specification establishes a basic replay protection measure (see Section 3.6), defines a timeout parameter affecting its strength (see Section 3.7), and outlines implementation methods also affecting protection strength in several ways (see Section 5.1). The implementor's choice of the timeout value and particular implementation methods may be suboptimal due to, for example, insufficient hardware resources of the Babel speaker.
本规范确立了基本的重放保护措施（见第3.6节），定义了影响其强度的超时参数（见第3.7节），并概述了以多种方式影响保护强度的实施方法（见第5.1节）。例如，由于巴别塔扬声器的硬件资源不足，实现者对超时值和特定实现方法的选择可能是次优的。
Furthermore, it may be possible that an operator configures the timeout and the methods to address particular local specifics, and this further weakens the protection. An operator concerned about replay attack protection strength should understand these factors and their meaning in a given network segment.
此外，操作员可能配置超时和方法以解决特定的本地细节，这进一步削弱了保护。关注重放攻击防护强度的运营商应了解这些因素及其在给定网段中的意义。
That said, a particular form of replay attack on this mechanism remains possible anyway. Whether there are two or more network segments using the same CSA and there is an adversary that captures Babel packets on one segment and replays on another (and vice versa, due to the bidirectional reachability requirement for neighbourship), some of the speakers on one such segment will detect the "virtual" neighbours from another and may prefer them for some destinations. This applies even more so as Babel doesn't require a common pre-configured network prefix between neighbours.
也就是说，无论如何，对这种机制的一种特殊形式的重放攻击仍然是可能的。无论是否有两个或多个网段使用同一CSA，并且是否有对手在一个网段上捕获Babel数据包并在另一个网段上重播（反之亦然，由于邻域关系的双向可达性要求），其中一个网段上的一些扬声器都会检测到“虚拟”邻居来自另一个国家，在某些目的地可能更喜欢他们。这一点更加适用，因为Babel不需要在邻居之间预先配置一个公共网络前缀。
A reliable solution to this particular problem, which Section 4.5 of [RFC7186] discusses as well, is not currently known. It is recommended that the operators use distinct CSAs for distinct network segments.
[RFC7186]第4.5节也讨论了该特定问题的可靠解决方案，目前尚不清楚。建议运营商对不同的网段使用不同的CSA。
The following in-scope concerns are not addressed:
未解决以下范围内的问题：
f. Offline Cryptographic Attacks
f. 脱机加密攻击
This mechanism is obviously subject to offline cryptographic attacks. As soon as an attacker has obtained a copy of an authenticated Babel packet of interest (which gets easier to do in wireless networks), he has all of the parameters of the authentication-specific processing performed by the sender, except for authentication key(s) and the choice of particular hash algorithm(s). Since digest lengths of common hash algorithms are well known and can be matched with those seen in the packet, the complexity of this attack is essentially that of the authentication key attack.
此机制显然会受到脱机加密攻击。一旦攻击者获得感兴趣的经过身份验证的Babel数据包的副本（在无线网络中更容易做到），他就拥有发送方执行的身份验证特定处理的所有参数，除了身份验证密钥和特定哈希算法的选择。由于常见散列算法的摘要长度是众所周知的，并且可以与数据包中看到的长度相匹配，因此这种攻击的复杂性本质上是身份验证密钥攻击的复杂性。
Viewing the cryptographic strength of particular hash algorithms as a concern of its own, the main practical means of resisting offline cryptographic attacks on this mechanism are periodic rekeying and the use of strong keys with a sufficient number of random bits.
将特定散列算法的密码强度视为其自身的一个关注点，抵抗该机制的离线密码攻击的主要实用方法是周期性密钥更新和使用具有足够数量随机位的强密钥。
It is important to understand that in the case of multiple keys being used within a single interface (for multi-domain authentication or during a key rollover) the strength of the combined configuration would be that of the weakest key, since only one successful HMAC test is required for an authentic packet. Operators concerned about offline cryptographic attacks should enforce the same strength policy for all keys used for a given interface.
重要的是要理解，在单个接口内使用多个密钥的情况下（用于多域身份验证或密钥翻转期间），组合配置的强度将是最弱密钥的强度，因为真实数据包只需要一次成功的HMAC测试。担心离线加密攻击的操作员应该对给定接口使用的所有密钥执行相同的强度策略。
Note that a special pathological case is possible with this mechanism. Whenever two or more authentication keys are configured for a given interface such that all keys share the same AuthKeyOctets and the same HashAlgo, but LocalKeyID modulo 2^16 is different for each key, these keys will not be treated as duplicate (Section 5.2 item 4), but an HMAC result computed for a given packet will be the same for each of these keys. In the case of the sending procedure, this can produce multiple HMAC TLVs with exactly the same value of the Digest field but different values of the KeyID field. In this case, the attacker will see that the keys are the same, even without knowledge of
注意，这种机制可能导致特殊的病理情况。每当为给定接口配置两个或多个身份验证密钥时，所有密钥共享相同的AuthKeyOctets和相同的HashAlgo，但每个密钥的LocalKeyID模2^16不同，这些密钥将不会被视为重复密钥（第5.2节第4项），但是，为给定数据包计算的HMAC结果对于这些密钥中的每个密钥都是相同的。在发送过程中，这会产生多个HMAC TLV，其摘要字段的值完全相同，但KeyID字段的值不同。在这种情况下，攻击者将看到密钥是相同的，即使不知道
the key itself. The reuse of authentication keys is not the intended use case of this mechanism and should be strongly avoided.
钥匙本身。身份验证密钥的重用不是此机制的预期用途，应极力避免。
g. Non-repudiation
g. 不可抵赖
This specification relies on the use of shared keys. There is no timestamp infrastructure and no key-revocation mechanism defined to address the compromise of a shared key. Establishing the time that a particular authentic Babel packet was generated is thus not possible. Proving that a particular Babel speaker had actually sent a given authentic packet is also impossible as soon as the shared key is claimed compromised. Even if the shared key is not compromised, reliably identifying the speaker that had actually sent a given authentic Babel packet is not possible. Since any of the speakers sharing a key can impersonate any other speaker sharing the same key, it is only possible to prove that the speaker belongs to the group sharing the key.
此规范依赖于共享密钥的使用。没有时间戳基础设施，也没有定义密钥撤销机制来解决共享密钥的泄露问题。因此，无法确定生成特定真实巴别塔数据包的时间。一旦共享密钥被泄露，证明特定的巴别塔说话者确实发送了给定的真实数据包也是不可能的。即使共享密钥没有泄露，也无法可靠地识别实际发送了给定真实巴别塔数据包的说话人。由于共享密钥的任何说话人都可以模拟共享同一密钥的任何其他说话人，因此只能证明该说话人属于共享密钥的组。
h. Confidentiality Violations
h. 违反保密规定
The original Babel protocol does not encrypt any of the information contained in its packets. The contents of a Babel packet are trivial to decode and thus can reveal network topology details. This mechanism does not improve this situation in any way. Since routing protocol messages are not the only kind of information subject to confidentiality concerns, a complete solution to this problem is likely to include measures based on the channel security model, such as IPsec and Wi-Fi Protected Access 2 (WPA2) at the time of this writing.
最初的Babel协议不加密其数据包中包含的任何信息。巴别塔数据包的内容不易解码，因此可以揭示网络拓扑细节。这一机制并没有以任何方式改善这种情况。由于路由协议消息不是唯一受保密性影响的信息，因此，此问题的完整解决方案可能包括基于信道安全模型的措施，如在撰写本文时的IPsec和Wi-Fi Protected Access 2（WPA2）。
i. Key Management
i. 密钥管理
Any authentication key exchange/distribution concerns are out of scope. However, the internal representation of authentication keys (see Section 3.8) allows implementations to use such diverse key-management techniques as manual configuration, a provisioning system, a key-management protocol, or any other means that comply with this specification.
任何身份验证密钥交换/分发问题都超出范围。然而，认证密钥的内部表示（见第3.8节）允许实现使用各种密钥管理技术，如手动配置、供应系统、密钥管理协议或符合本规范的任何其他方式。
j. Message Deletion
j. 消息删除
Any message deletion attacks are out of scope. Since a datagram deleted by an attacker cannot be distinguished from a datagram naturally lost in transmission, and since datagram-based routing protocols are designed to withstand a certain loss of packets,
任何消息删除攻击都超出范围。由于攻击者删除的数据报无法与传输过程中自然丢失的数据报区分开来，并且基于数据报的路由协议设计用于承受一定的数据包丢失，
the currently established practice is treating authentication purely as a per-packet function, without any added detection of lost packets.
目前确立的做法是将身份验证纯粹视为每个数据包的功能，而不增加对丢失数据包的检测。
At the time of publication of this document, the Babel TLV Types namespace did not have an IANA registry. TLV types 11 and 12 were assigned (see Table 1 in Appendix A) to the TS/PC and HMAC TLV types by Juliusz Chroboczek, designer of the original Babel protocol. Therefore, this document has no IANA actions.
在本文档发布时，Babel TLV类型命名空间没有IANA注册表。原始巴贝尔协议设计者Juliusz Chroboczek将TLV类型11和12分配给TS/PC和HMAC TLV类型（见附录A中的表1）。因此，本文件没有IANA行动。
Thanks to Randall Atkinson and Matthew Fanto for their comprehensive work on [RIP2-AUTH] that initiated a series of publications on routing protocol authentication, including this one. This specification adopts many concepts belonging to the whole series.
感谢Randall Atkinson和Matthew Fanto在[RIP2-AUTH]方面所做的全面工作，他们开创了一系列关于路由协议认证的出版物，包括这本。本规范采用了属于整个系列的许多概念。
Thanks to Juliusz Chroboczek, Gabriel Kerneis, and Matthieu Boutier. This document incorporates many technical and editorial corrections based on their feedback. Thanks to all contributors to Babel, because this work would not be possible without the prior works. Thanks to Dominic Mulligan for editorial proofreading of this document. Thanks to Riku Hietamaki for suggesting the test vectors section.
多亏了朱利叶斯·克洛博切克、加布里埃尔·克内斯和马蒂厄·布蒂埃。本文件包含了许多基于反馈的技术和编辑更正。感谢巴贝尔的所有贡献者，因为没有之前的作品，这项工作是不可能的。感谢Dominic Mulligan对本文件进行编辑校对。感谢Riku Hietamaki推荐测试向量部分。
Thanks to Joel Halpern, Jim Schaad, Randall Atkinson, and Stephen Farrell for providing (in chronological order) valuable feedback on earlier versions of this document.
感谢Joel Halpern、Jim Schaad、Randall Atkinson和Stephen Farrell（按时间顺序）提供了关于本文档早期版本的宝贵反馈。
Thanks to Jim Gettys and Dave Taht for developing the CeroWrt wireless router project and collaborating on many integration issues. A practical need for Babel authentication emerged during research based on CeroWrt that eventually became the very first use case of this mechanism.
感谢Jim Gettys和Dave Taht开发CeroWrt无线路由器项目并在许多集成问题上进行合作。在基于CeroWrt的研究中出现了对Babel认证的实际需求，这最终成为该机制的第一个用例。
Thanks to Kunihiro Ishiguro and Paul Jakma for establishing the GNU Zebra and Quagga routing software projects, respectively. Thanks to Werner Koch, the author of Libgcrypt. The very first implementation of this mechanism was made on a base of Quagga and Libgcrypt.
感谢石黑邦弘和保罗·雅克玛分别建立了GNU Zebra和Quagga路由软件项目。感谢《Libgcrypt》的作者沃纳·科赫。该机制的第一个实现是在Quagga和Libgcrypt的基础上实现的。
[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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[FIPS-198] National Institute of Standards and Technology, "The Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 198-1, July 2008.
[FIPS-198]国家标准与技术研究所，“密钥散列消息认证码（HMAC）”，FIPS PUB 198-12008年7月。
[BABEL] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, April 2011.
[BABEL]Chroboczek，J.，“BABEL路由协议”，RFC6126，2011年4月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931]Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005.
[RFC4030]Stapp，M.和T.Lemon，“动态主机配置协议（DHCP）中继代理选项的身份验证子选项”，RFC 4030，2005年3月。
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，2005年6月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270]Hoffman，P.和B.Schneier，“对互联网协议中加密哈希的攻击”，RFC 42702005年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RIP2-AUTH] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic Authentication", RFC 4822, February 2007.
[RIP2-AUTH]Atkinson，R.和M.Fanto，“RIPv2加密认证”，RFC 4822，2007年2月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176]Chiba，M.，Dommety，G.，Eklund，M.，Mitton，D.，和B.Aboba，“远程认证拨号用户服务（RADIUS）的动态授权扩展”，RFC 51762008年1月。
[ISIS-AUTH-A] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[ISIS-AUTH-A]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，2008年10月。
[ISIS-AUTH-B] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, February 2009.
[ISIS-AUTH-B]Bhatia，M.，Manral，V.，Li，T.，Atkinson，R.，White，R.，和M.Fanto，“IS-IS通用密码认证”，RFC 5310，2009年2月。
[OSPF2-AUTH] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[OSPF2-AUTH]Bhatia，M.，Manral，V.，Fanto，M.，White，R.，Barnes，M.，Li，T.，和R.Atkinson，“OSPFv2 HMAC-SHA加密认证”，RFC 5709，2009年10月。
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues with Existing Cryptographic Protection Methods for Routing Protocols", RFC 6039, October 2010.
[RFC6039]Manral，V.，Bhatia，M.，Jaeggli，J.，和R.White，“路由协议现有加密保护方法的问题”，RFC 6039，2010年10月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]Turner，S.和L.Chen，“MD5消息摘要和HMAC-MD5算法的更新安全注意事项”，RFC 61512011年3月。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC6194]Polk，T.，Chen，L.，Turner，S.，和P.Hoffman，“SHA-0和SHA-1消息摘要算法的安全考虑”，RFC 61942011年3月。
[OSPF3-AUTH] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012.
[OSPF3-AUTH]Bhatia，M.，Manral，V.，和A.Lindem，“OSPFv3支持认证拖车”，RFC 65062012年2月。
[RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012.
[RFC6709]Carpenter，B.，Aboba，B.，和S.Cheshire，“协议扩展的设计考虑”，RFC 6709，2012年9月。
[BABEL-EXTENSION] Chroboczek, J., "Extension Mechanism for the Babel Routing Protocol", Work in Progress, June 2014.
[BABEL-EXTENSION]Chroboczek，J.，“BABEL路由协议的扩展机制”，正在进行的工作，2014年6月。
[OSPF3-AUTH-BIS] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, March 2014.
[OSPF3-AUTH-BIS]Bhatia，M.，Manral，V.，和A.Lindem，“OSPFv3支持认证拖车”，RFC 71662014年3月。
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)", RFC 7183, April 2014.
[RFC7183]Herberg，U.，Dearlove，C.，和T.Clausen，“邻域发现协议（NHDP）和优化链路状态路由协议版本2（OLSRv2）的完整性保护”，RFC 7183，2014年4月。
[RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for the Neighborhood Discovery Protocol (NHDP)", RFC 7186, April 2014.
[RFC7186]Yi，J.，Herberg，U.，和T.Clausen，“邻里发现协议（NHDP）的安全威胁”，RFC 7186，2014年4月。
+-------------------------------------------------------------+
| authentication-specific statistics |
+-------------------------------------------------------------+
^ | ^
| v |
| +-----------------------------------------------+ |
| | system operator | |
| +-----------------------------------------------+ |
| ^ | ^ | ^ | ^ | ^ | |
| | v | | | | | | | v |
+---+ +---------+ | | | | | | +---------+ +---+
| |->| ANM | | | | | | | | LocalTS |->| |
| R |<-| table | | | | | | | | LocalPC |<-| T |
| x | +---------+ | v | v | v +---------+ | x |
| | +----------------+ +---------+ +----------------+ | |
| p | | MaxDigestsIn | | | | MaxDigestsOut | | p |
| r |<-| ANM timeout | | CSAs | | |->| r |
| o | | RxAuthRequired | | | | | | o |
| c | +----------------+ +---------+ +----------------+ | c |
| e | +-------------+ | | +-------------+ | e |
| s | | Rx ESAs | | | | Tx ESAs | | s |
| s |<-| (temporary) |<----+ +---->| (temporary) |->| s |
| i | +-------------+ +-------------+ | i |
| n | +------------------------------+----------------+ | n |
| g | | instance of | output buffers |=>| g |
| |=>| the original +----------------+ | |
| | | protocol | source address |->| |
+---+ +------------------------------+----------------+ +---+
/\ | ||
|| v \/
+-------------------------------------------------------------+
| network stack |
+-------------------------------------------------------------+
/\ || /\ || /\ || /\ ||
|| \/ || \/ || \/ || \/
+---------+ +---------+ +---------+ +---------+
| speaker | | speaker | ... | speaker | | speaker |
+---------+ +---------+ +---------+ +---------+
+-------------------------------------------------------------+
| authentication-specific statistics |
+-------------------------------------------------------------+
^ | ^
| v |
| +-----------------------------------------------+ |
| | system operator | |
| +-----------------------------------------------+ |
| ^ | ^ | ^ | ^ | ^ | |
| | v | | | | | | | v |
+---+ +---------+ | | | | | | +---------+ +---+
| |->| ANM | | | | | | | | LocalTS |->| |
| R |<-| table | | | | | | | | LocalPC |<-| T |
| x | +---------+ | v | v | v +---------+ | x |
| | +----------------+ +---------+ +----------------+ | |
| p | | MaxDigestsIn | | | | MaxDigestsOut | | p |
| r |<-| ANM timeout | | CSAs | | |->| r |
| o | | RxAuthRequired | | | | | | o |
| c | +----------------+ +---------+ +----------------+ | c |
| e | +-------------+ | | +-------------+ | e |
| s | | Rx ESAs | | | | Tx ESAs | | s |
| s |<-| (temporary) |<----+ +---->| (temporary) |->| s |
| i | +-------------+ +-------------+ | i |
| n | +------------------------------+----------------+ | n |
| g | | instance of | output buffers |=>| g |
| |=>| the original +----------------+ | |
| | | protocol | source address |->| |
+---+ +------------------------------+----------------+ +---+
/\ | ||
|| v \/
+-------------------------------------------------------------+
| network stack |
+-------------------------------------------------------------+
/\ || /\ || /\ || /\ ||
|| \/ || \/ || \/ || \/
+---------+ +---------+ +---------+ +---------+
| speaker | | speaker | ... | speaker | | speaker |
+---------+ +---------+ +---------+ +---------+
Flow of control data : --->
Flow of Babel datagrams/packets: ===>
Flow of control data : --->
Flow of Babel datagrams/packets: ===>
Figure 1: Interaction Diagram
图1：交互图
P
|<---------------------------->| (D1)
| B |
| |<------------------------->|
| | |
+--+-----+-----+...+-----+-----+--+ P: Babel packet
|H |some |some | |some |some |T | H: Babel packet header
| |TLV |TLV | |TLV |TLV | | B: Babel packet body
| | | | | | | | T: optional trailing data block
+--+-----+-----+...+-----+-----+--+
P
|<---------------------------->| (D1)
| B |
| |<------------------------->|
| | |
+--+-----+-----+...+-----+-----+--+ P: Babel packet
|H |some |some | |some |some |T | H: Babel packet header
| |TLV |TLV | |TLV |TLV | | B: Babel packet body
| | | | | | | | T: optional trailing data block
+--+-----+-----+...+-----+-----+--+
P
|<----------------------------------------------------->| (D2)
| B |
| |<-------------------------------------------------->|
| | |
+--+-----+-----+...+-----+-----+------+------+...+------+--+
|H |some |some | |some |some |TS/PC |HMAC | |HMAC |T |
| |TLV |TLV | |TLV |TLV |TLV |TLV 1 | |TLV n | |
| | | | | | | | | | | |
+--+-----+-----+...+-----+-----+------+------+...+------+--+
P
|<----------------------------------------------------->| (D2)
| B |
| |<-------------------------------------------------->|
| | |
+--+-----+-----+...+-----+-----+------+------+...+------+--+
|H |some |some | |some |some |TS/PC |HMAC | |HMAC |T |
| |TLV |TLV | |TLV |TLV |TLV |TLV 1 | |TLV n | |
| | | | | | | | | | | |
+--+-----+-----+...+-----+-----+------+------+...+------+--+
P
|<----------------------------------------------------->| (D3)
| B |
| |<-------------------------------------------------->|
| | |
+--+------+------+...+------+-----+-----+...+-----+-----+--+
|H |TS/PC |HMAC | |HMAC |some |some | |some |some |T |
| |TLV |TLV 1 | |TLV n |TLV |TLV | |TLV |TLV | |
| | | | | | | | | | | |
+--+------+------+...+------+-----+-----+...+-----+-----+--+
P
|<----------------------------------------------------->| (D3)
| B |
| |<-------------------------------------------------->|
| | |
+--+------+------+...+------+-----+-----+...+-----+-----+--+
|H |TS/PC |HMAC | |HMAC |some |some | |some |some |T |
| |TLV |TLV 1 | |TLV n |TLV |TLV | |TLV |TLV | |
| | | | | | | | | | | |
+--+------+------+...+------+-----+-----+...+-----+-----+--+
P
|<------------------------------------------------------------>| (D4)
| B |
| |<--------------------------------------------------------->|
| | |
+--+-----+------+-----+------+...+-----+------+...+------+-----+--+
|H |some |HMAC |some |HMAC | |some |HMAC | |TS/PC |some |T |
| |TLV |TLV 1 |TLV |TLV 2 | |TLV |TLV n | |TLV |TLV | |
| | | | | | | | | | | | |
+--+-----+------+-----+------+...+-----+------+...+------+-----+--+
P
|<------------------------------------------------------------>| (D4)
| B |
| |<--------------------------------------------------------->|
| | |
+--+-----+------+-----+------+...+-----+------+...+------+-----+--+
|H |some |HMAC |some |HMAC | |some |HMAC | |TS/PC |some |T |
| |TLV |TLV 1 |TLV |TLV 2 | |TLV |TLV n | |TLV |TLV | |
| | | | | | | | | | | | |
+--+-----+------+-----+------+...+-----+------+...+------+-----+--+
Figure 2: Babel Datagram Structure
图2:Babel数据报结构
+-------+-------------------------+---------------+
| Value | Name | Reference |
+-------+-------------------------+---------------+
| 0 | Pad1 | [BABEL] |
| 1 | PadN | [BABEL] |
| 2 | Acknowledgement Request | [BABEL] |
| 3 | Acknowledgement | [BABEL] |
| 4 | Hello | [BABEL] |
| 5 | IHU | [BABEL] |
| 6 | Router-Id | [BABEL] |
| 7 | Next Hop | [BABEL] |
| 8 | Update | [BABEL] |
| 9 | Route Request | [BABEL] |
| 10 | Seqno Request | [BABEL] |
| 11 | TS/PC | this document |
| 12 | HMAC | this document |
+-------+-------------------------+---------------+
+-------+-------------------------+---------------+
| Value | Name | Reference |
+-------+-------------------------+---------------+
| 0 | Pad1 | [BABEL] |
| 1 | PadN | [BABEL] |
| 2 | Acknowledgement Request | [BABEL] |
| 3 | Acknowledgement | [BABEL] |
| 4 | Hello | [BABEL] |
| 5 | IHU | [BABEL] |
| 6 | Router-Id | [BABEL] |
| 7 | Next Hop | [BABEL] |
| 8 | Update | [BABEL] |
| 9 | Route Request | [BABEL] |
| 10 | Seqno Request | [BABEL] |
| 11 | TS/PC | this document |
| 12 | HMAC | this document |
+-------+-------------------------+---------------+
Table 1: Babel TLV Types 0 through 12
表1:Babel TLV类型0至12
+--------------+-----------------------------+-------------------+
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
+--------------+-----------------------------+-------------------+
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:14 | 20 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
+--------------+-----------------------------+-------------------+
+--------------+-----------------------------+-------------------+
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
+--------------+-----------------------------+-------------------+
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:14 | 20 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
+--------------+-----------------------------+-------------------+
Table 2: A Babel Packet without Authentication TLVs
表2：没有认证TLV的Babel数据包
+---------------+-------------------------------+-------------------+
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
+---------------+-------------------------------+-------------------+
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:4c | 76 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
| [TLV] Type | 0b | 11 (TS/PC) |
| [TLV] Length | 06 | 6 octets |
| PacketCounter | 00:01 | 1 |
| Timestamp | 52:1d:7e:8b | 1377664651 |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:c8 | 200 |
| Digest | fe:80:00:00:00:00:00:00:0a:11 | padding |
| | 96:ff:fe:1c:10:c8:00:00:00:00 | |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:64 | 100 |
| Digest | fe:80:00:00:00:00:00:00:0a:11 | padding |
| | 96:ff:fe:1c:10:c8:00:00:00:00 | |
+---------------+-------------------------------+-------------------+
+---------------+-------------------------------+-------------------+
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
+---------------+-------------------------------+-------------------+
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:4c | 76 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
| [TLV] Type | 0b | 11 (TS/PC) |
| [TLV] Length | 06 | 6 octets |
| PacketCounter | 00:01 | 1 |
| Timestamp | 52:1d:7e:8b | 1377664651 |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:c8 | 200 |
| Digest | fe:80:00:00:00:00:00:00:0a:11 | padding |
| | 96:ff:fe:1c:10:c8:00:00:00:00 | |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:64 | 100 |
| Digest | fe:80:00:00:00:00:00:00:0a:11 | padding |
| | 96:ff:fe:1c:10:c8:00:00:00:00 | |
+---------------+-------------------------------+-------------------+
Table 3: A Babel Packet with Each HMAC TLV Padded Using IPv6 Address
fe80::0a11:96ff:fe1c:10c8
Table 3: A Babel Packet with Each HMAC TLV Padded Using IPv6 Address
fe80::0a11:96ff:fe1c:10c8
+---------------+-------------------------------+-------------------+
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
+---------------+-------------------------------+-------------------+
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:4c | 76 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
| [TLV] Type | 0b | 11 (TS/PC) |
| [TLV] Length | 06 | 6 octets |
| PacketCounter | 00:01 | 1 |
| Timestamp | 52:1d:7e:8b | 1377664651 |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:c8 | 200 |
| Digest | c6:f1:06:13:30:3c:fa:f3:eb:5d | HMAC result |
| | 60:3a:ed:fd:06:55:83:f7:ee:79 | |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:64 | 100 |
| Digest | df:32:16:5e:d8:63:16:e5:a6:4d | HMAC result |
| | c7:73:e0:b5:22:82:ce:fe:e2:3c | |
+---------------+-------------------------------+-------------------+
+---------------+-------------------------------+-------------------+
| Packet field | Packet octets (hexadecimal) | Meaning (decimal) |
+---------------+-------------------------------+-------------------+
| Magic | 2a | 42 |
| Version | 02 | version 2 |
| Body length | 00:4c | 76 octets |
| [TLV] Type | 04 | 4 (Hello) |
| [TLV] Length | 06 | 6 octets |
| Reserved | 00:00 | no meaning |
| Seqno | 09:25 | 2341 |
| Interval | 01:90 | 400 (4.00 s) |
| [TLV] Type | 08 | 8 (Update) |
| [TLV] Length | 0a | 10 octets |
| AE | 00 | 0 (wildcard) |
| Flags | 40 | default router-id |
| Plen | 00 | 0 bits |
| Omitted | 00 | 0 bits |
| Interval | ff:ff | infinity |
| Seqno | 68:21 | 26657 |
| Metric | ff:ff | infinity |
| [TLV] Type | 0b | 11 (TS/PC) |
| [TLV] Length | 06 | 6 octets |
| PacketCounter | 00:01 | 1 |
| Timestamp | 52:1d:7e:8b | 1377664651 |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:c8 | 200 |
| Digest | c6:f1:06:13:30:3c:fa:f3:eb:5d | HMAC result |
| | 60:3a:ed:fd:06:55:83:f7:ee:79 | |
| [TLV] Type | 0c | 12 (HMAC) |
| [TLV] Length | 16 | 22 octets |
| KeyID | 00:64 | 100 |
| Digest | df:32:16:5e:d8:63:16:e5:a6:4d | HMAC result |
| | c7:73:e0:b5:22:82:ce:fe:e2:3c | |
+---------------+-------------------------------+-------------------+
Table 4: A Babel Packet with Each HMAC TLV Containing an HMAC Result
表4：每个HMAC TLV包含HMAC结果的Babel数据包
The test vectors below may be used to verify the correctness of some procedures performed by an implementation of this mechanism, namely:
以下测试向量可用于验证由该机制的实现执行的某些程序的正确性，即：
o appending TS/PC and HMAC TLVs to the Babel packet body,
o 将TS/PC和HMAC TLV附加到Babel包体，
o padding the HMAC TLV(s),
o 填充HMAC TLV，
o computation of the HMAC result(s), and
o HMAC结果的计算，以及
o placement of the result(s) in the TLV(s).
o 将结果放置在TLV中。
This verification isn't exhaustive. There are other important implementation aspects that would require testing methods of their own.
这种验证并非详尽无遗。还有其他重要的实现方面需要自己的测试方法。
The test vectors were produced as follows.
测试载体的产生如下。
1. A Babel speaker with a network interface with IPv6 link-local address fe80::0a11:96ff:fe1c:10c8 was configured to use two CSAs for the interface:
1. 具有IPv6链路本地地址fe80:：0a11:96ff:fe1c:10c8的网络接口的巴别塔扬声器配置为使用两个CSA作为接口：
* CSA1={HashAlgo=RIPEMD-160, KeyChain={{LocalKeyID=200, AuthKeyOctets=Key26}}}
* CSA1={HashAlgo=RIPEMD-160，KeyChain={{LocalKeyID=200，AuthKeyOctets=Key26}}
* CSA2={HashAlgo=SHA-1, KeyChain={{LocalKeyId=100, AuthKeyOctets=Key70}}}
* CSA2={HashAlgo=SHA-1，KeyChain={{LocalKeyId=100，AuthKeyOctets=Key70}}
The authentication keys above are:
上面的身份验证密钥是：
* Key26 in ASCII:
* ASCII中的键26：
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
* Key26 in hexadecimal:
* 十六进制键26：
41:42:43:44:45:46:47:48:49:4a:4b:4c:4d:4e:4f:50
51:52:53:54:55:56:57:58:59:5a
41:42:43:44:45:46:47:48:49:4a:4b:4c:4d:4e:4f:50
51:52:53:54:55:56:57:58:59:5a
* Key70 in ASCII:
* ASCII中的键70：
This=key=is=exactly=70=octets=long.=ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567
This=key=is=exactly=70=octets=long.=ABCDEFGHIJKLMNOPQRSTUVWXYZ01234567
* Key70 in hexadecimal:
* 十六进制键70：
54:68:69:73:3d:6b:65:79:3d:69:73:3d:65:78:61:63
74:6c:79:3d:37:30:3d:6f:63:74:65:74:73:3d:6c:6f
6e:67:2e:3d:41:42:43:44:45:46:47:48:49:4a:4b:4c
4d:4e:4f:50:51:52:53:54:55:56:57:58:59:5a:30:31
32:33:34:35:36:37
54:68:69:73:3d:6b:65:79:3d:69:73:3d:65:78:61:63
74:6c:79:3d:37:30:3d:6f:63:74:65:74:73:3d:6c:6f
6e:67:2e:3d:41:42:43:44:45:46:47:48:49:4a:4b:4c
4d:4e:4f:50:51:52:53:54:55:56:57:58:59:5a:30:31
32:33:34:35:36:37
The length of each key was picked to relate (using the terms listed in Section 2.4) to the properties of its respective hash algorithm as follows:
选择每个键的长度（使用第2.4节中列出的术语）与其各自哈希算法的属性相关，如下所示：
* the digest length (L) of both RIPEMD-160 and SHA-1 is 20 octets,
* RIPEMD-160和SHA-1的摘要长度（L）均为20个八位字节，
* the internal block size (B) of both RIPEMD-160 and SHA-1 is 64 octets,
* RIPEMD-160和SHA-1的内部块大小（B）均为64个八位字节，
* the length of Key26 (26) is greater than L but less than B, and
* 键26（26）的长度大于L但小于B，并且
* the length of Key70 (70) is greater than B (and thus greater than L).
* 键70（70）的长度大于B（因此大于L）。
KeyStartAccept, KeyStopAccept, KeyStartGenerate, and KeyStopGenerate were set to make both authentication keys valid.
KeyStartAccept、Keyspaccept、KeyStartGenerate和KeyspGenerate已设置为使这两个身份验证密钥都有效。
2. The instance of the original protocol of the speaker produced a Babel packet (PktO) to be sent from the interface. Table 2 provides a decoding of PktO, the contents of which are below:
2. 说话人的原始协议实例产生了一个巴别塔数据包（PktO），从接口发送。表2提供了PktO的解码，其内容如下：
2a:02:00:14:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff
2a:02:00:14:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff
3. The authentication mechanism appended one TS/PC TLV and two HMAC TLVs to the packet body, updated the "Body length" packet header field, and padded the Digest field of the HMAC TLVs, using the link-local IPv6 address of the interface and the necessary amount of zeroes. Table 3 provides a decoding of the resulting temporary packet (PktT), the contents of which are below:
3. 身份验证机制将一个TS/PC TLV和两个HMAC TLV附加到数据包正文，更新“正文长度”数据包头字段，并使用接口的链路本地IPv6地址和必要数量的零填充HMAC TLV的摘要字段。表3提供了结果临时数据包（PktT）的解码，其内容如下：
2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b
0c:16:00:c8:fe:80:00:00:00:00:00:00:0a:11:96:ff
fe:1c:10:c8:00:00:00:00:0c:16:00:64:fe:80:00:00
00:00:00:00:0a:11:96:ff:fe:1c:10:c8:00:00:00:00
2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b
0c:16:00:c8:fe:80:00:00:00:00:00:00:0a:11:96:ff
fe:1c:10:c8:00:00:00:00:0c:16:00:64:fe:80:00:00
00:00:00:00:0a:11:96:ff:fe:1c:10:c8:00:00:00:00
4. The authentication mechanism produced two HMAC results, performing the computations as follows:
4. 认证机制产生两个HMAC结果，执行如下计算：
* For H=RIPEMD-160, K=Key26, and Text=PktT, the HMAC result is:
* 对于H=RIPEMD-160、K=Key26和Text=PktT，HMAC结果为：
c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a:ed:fd:06:55
83:f7:ee:79
c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a:ed:fd:06:55
83:f7:ee:79
* For H=SHA-1, K=Key70, and Text=PktT, the HMAC result is:
* 对于H=SHA-1、K=Key70和Text=PktT，HMAC结果为：
df:32:16:5e:d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82
ce:fe:e2:3c
df:32:16:5e:d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82
ce:fe:e2:3c
5. The authentication mechanism placed each HMAC result into its respective HMAC TLV, producing the final authenticated Babel packet (PktA), which was eventually sent from the interface.
5. 身份验证机制将每个HMAC结果放入其各自的HMAC TLV中，生成最终经过身份验证的Babel数据包（PktA），该数据包最终从接口发送。
Table 4 provides a decoding of PktA, the contents of which are below:
表4提供了PktA的解码，其内容如下：
2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b
0c:16:00:c8:c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a
ed:fd:06:55:83:f7:ee:79:0c:16:00:64:df:32:16:5e
d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82:ce:fe:e2:3c
2a:02:00:4c:04:06:00:00:09:25:01:90:08:0a:00:40
00:00:ff:ff:68:21:ff:ff:0b:06:00:01:52:1d:7e:8b
0c:16:00:c8:c6:f1:06:13:30:3c:fa:f3:eb:5d:60:3a
ed:fd:06:55:83:f7:ee:79:0c:16:00:64:df:32:16:5e
d8:63:16:e5:a6:4d:c7:73:e0:b5:22:82:ce:fe:e2:3c
Interpretation of this process is to be done differently for the sending and receiving directions (see Figure 1).
对于发送和接收方向，对该过程的解释是不同的（见图1）。
For the sending direction, given a Babel speaker configured using the IPv6 address and the sequence of CSAs as described above, the implementation SHOULD (see notes in Section 5.3) produce exactly the temporary packet PktT if the original protocol instance produces exactly the packet PktO to be sent from the interface. If the temporary packet exactly matches PktT, the HMAC results computed afterwards MUST exactly match the respective results above, and the final authenticated packet MUST exactly match PktA above.
对于发送方向，给定使用IPv6地址和如上所述的CSA序列配置的巴别塔扬声器，如果原始协议实例精确生成要从接口发送的数据包PktT，则实现应（参见第5.3节中的注释）精确生成临时数据包PktT。如果临时数据包与PktT完全匹配，则随后计算的HMAC结果必须与上面的相应结果完全匹配，并且最终经过身份验证的数据包必须与上面的PktA完全匹配。
For the receiving direction, given a Babel speaker configured using the sequence of CSAs as described above (but a different IPv6 address), the implementation MUST (assuming that the TS/PC check didn't fail) produce exactly the temporary packet PktT above if its network stack receives through the interface exactly the packet PktA above from the source IPv6 address above. The first HMAC result computed afterwards MUST match the first result above. The receiving procedure doesn't compute the second HMAC result in this case, but if the implementor decides to compute it anyway for verification purposes, it MUST exactly match the second result above.
对于接收方向，给定使用如上所述的CSA序列配置的巴别塔扬声器（但不同的IPv6地址），实现必须（假设TS/PC检查没有失败）如果其网络堆栈通过接口从上面的源IPv6地址接收到上面的数据包PktA，则生成上面的临时数据包PktT。随后计算的第一个HMAC结果必须与上述第一个结果匹配。在这种情况下，接收过程不会计算第二个HMAC结果，但是如果实现者出于验证目的决定计算它，那么它必须与上面的第二个结果完全匹配。
Author's Address
作者地址
Denis Ovsienko Yandex 16, Leo Tolstoy St. Moscow 119021 Russia
Denis Ovsienko Yandex 16，列夫·托尔斯泰圣莫斯科119021俄罗斯
EMail: infrastation@yandex.ru
EMail: infrastation@yandex.ru