Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 6584 INRIA
Category: Standards Track April 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 6584 INRIA
Category: Standards Track April 2012
ISSN: 2070-1721
Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
异步分层编码（ALC）和面向NACK的可靠组播（NORM）协议的简单认证方案
Abstract
摘要
This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) protocols. The first scheme is based on RSA Digital Signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a Group-keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service.
本文介绍了四种方案，它们在异步分层编码（ALC）和面向NACK的可靠多播（NORM）协议的上下文中提供每包身份验证、完整性和反重播服务。第一个方案基于RSA数字签名。第二个方案依赖于椭圆曲线数字签名算法（ECDSA）。第三种方案依赖于组密钥消息认证码（MAC）。最后，第四个方案合并了数字签名和群方案。这些方案有不同的目标用例，它们并不都提供相同的服务。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6584.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6584.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Scope of This Document .....................................6
1.2. Terminology, Notations, and Definitions ....................6
2. Authentication Scheme Identification with the ASID Field ........7
3. RSA Digital Signature Scheme ....................................8
3.1. Authentication Header Extension Format .....................8
3.2. Parameters ................................................10
3.3. Processing ................................................11
3.3.1. Signature Processing ...............................11
3.3.2. Anti-Replay Processing .............................12
3.4. In Practice ...............................................13
4. Elliptic Curve Digital Signature Scheme ........................14
4.1. Authentication Header Extension Format ....................14
4.2. Parameters ................................................15
4.3. Processing ................................................15
4.3.1. Signature Processing ...............................15
4.3.2. Anti-Replay Processing .............................16
4.4. In Practice ...............................................16
5. Group-Keyed Message Authentication Code (MAC) Scheme ...........17
5.1. Authentication Header Extension Format ....................17
5.2. Parameters ................................................19
5.3. Processing ................................................20
5.3.1. Signature Processing ...............................20
5.3.2. Anti-Replay Processing .............................20
5.4. In Practice ...............................................20
6. Combined Use of the RSA/ECC Digital Signatures and
Group-Keyed MAC Schemes ........................................21
6.1. Authentication Header Extension Format ....................21
6.2. Parameters ................................................23
6.3. Processing ................................................23
6.3.1. Signature Processing ...............................23
6.3.2. Anti-Replay Processing .............................24
6.4. In Practice ...............................................24
7. Security Considerations ........................................25
7.1. Dealing with DoS Attacks ..................................25
7.2. Dealing with Replay Attacks ...............................26
7.2.1. Impacts of Replay Attacks on the Simple
Authentication Schemes .............................26
7.2.2. Impacts of Replay Attacks on NORM ..................26
7.2.3. Impacts of Replay Attacks on ALC ...................27
7.3. Dealing with Attacks on the Parameters Sent Out-of-Band ...28
8. Acknowledgments ................................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................29
1. Introduction ....................................................4
1.1. Scope of This Document .....................................6
1.2. Terminology, Notations, and Definitions ....................6
2. Authentication Scheme Identification with the ASID Field ........7
3. RSA Digital Signature Scheme ....................................8
3.1. Authentication Header Extension Format .....................8
3.2. Parameters ................................................10
3.3. Processing ................................................11
3.3.1. Signature Processing ...............................11
3.3.2. Anti-Replay Processing .............................12
3.4. In Practice ...............................................13
4. Elliptic Curve Digital Signature Scheme ........................14
4.1. Authentication Header Extension Format ....................14
4.2. Parameters ................................................15
4.3. Processing ................................................15
4.3.1. Signature Processing ...............................15
4.3.2. Anti-Replay Processing .............................16
4.4. In Practice ...............................................16
5. Group-Keyed Message Authentication Code (MAC) Scheme ...........17
5.1. Authentication Header Extension Format ....................17
5.2. Parameters ................................................19
5.3. Processing ................................................20
5.3.1. Signature Processing ...............................20
5.3.2. Anti-Replay Processing .............................20
5.4. In Practice ...............................................20
6. Combined Use of the RSA/ECC Digital Signatures and
Group-Keyed MAC Schemes ........................................21
6.1. Authentication Header Extension Format ....................21
6.2. Parameters ................................................23
6.3. Processing ................................................23
6.3.1. Signature Processing ...............................23
6.3.2. Anti-Replay Processing .............................24
6.4. In Practice ...............................................24
7. Security Considerations ........................................25
7.1. Dealing with DoS Attacks ..................................25
7.2. Dealing with Replay Attacks ...............................26
7.2.1. Impacts of Replay Attacks on the Simple
Authentication Schemes .............................26
7.2.2. Impacts of Replay Attacks on NORM ..................26
7.2.3. Impacts of Replay Attacks on ALC ...................27
7.3. Dealing with Attacks on the Parameters Sent Out-of-Band ...28
8. Acknowledgments ................................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................29
Many applications using multicast and broadcast communications require that each receiver be able to authenticate the source of any packet it receives, to check its integrity. For instance, ALC [RFC5775] and NORM [RFC5740] are two Content Delivery Protocols (CDPs) designed to reliably transfer objects (e.g., files) between a session's sender and several receivers.
许多使用多播和广播通信的应用程序要求每个接收器能够验证其接收的任何数据包的来源，以检查其完整性。例如，ALC[RFC5775]和NORM[RFC5740]是两种内容交付协议（CDP），设计用于在会话的发送方和多个接收方之间可靠地传输对象（例如文件）。
The NORM protocol is based on bidirectional transmissions. With NORM, each receiver acknowledges data received or, in the case of packet erasures, asks for retransmissions. On the contrary, the ALC protocol defines unidirectional transmissions. With ALC, reliability can be achieved by means of cyclic transmissions of the content within a carousel, or by the use of proactive Forward Error Correction (FEC) codes, or by the joint use of these mechanisms. Being purely unidirectional, ALC is massively scalable, while NORM is intrinsically limited in terms of the number of receivers that can be handled in a session. Both protocols have in common the fact that they operate at the application level, on top of an erasure channel (e.g., the Internet) where packets can be lost (erased) during the transmission.
NORM协议基于双向传输。使用NORM，每个接收器确认接收到的数据，或者在数据包擦除的情况下，请求重新传输。相反，ALC协议定义了单向传输。利用ALC，可以通过在转盘内循环传输内容，或者通过使用主动前向纠错（FEC）码，或者通过联合使用这些机制来实现可靠性。ALC纯粹是单向的，具有大规模可扩展性，而NORM在会话中可以处理的接收器数量方面本质上是有限的。这两个协议的共同点是，它们在应用程序级别上运行，在擦除通道（例如，互联网）之上，数据包在传输过程中可能会丢失（擦除）。
With these CDPs, an attacker might impersonate the ALC or NORM session sender and inject forged packets to the receivers, thereby corrupting the objects reconstructed by the receivers. An attacker might also impersonate a NORM session receiver and inject forged feedback packets to the NORM sender.
使用这些CDP，攻击者可能会模拟ALC或NORM会话发送方，并向接收方注入伪造数据包，从而破坏接收方重建的对象。攻击者还可能模拟NORM会话接收器并向NORM发送方注入伪造的反馈数据包。
In the case of group communications, several solutions exist to provide the receiver some guaranties on the integrity of the packets it receives and on the identity of the sender of these packets. These solutions have different features that make them more or less suited to a given use case:
在群组通信的情况下，存在几种解决方案来为接收方提供一些关于其接收的分组的完整性和这些分组的发送方的身份的保证。这些解决方案具有不同的特性，使它们或多或少适合给定的用例：
o Digital Signatures [RFC4359] (see Sections 3 and 4 of this document): This scheme is well suited to low data rate flows, when a packet sender authentication and packet integrity service is needed. However, Digital Signatures based on RSA asymmetric cryptography are limited by high computational costs and high transmission overheads. The use of ECC (Elliptic Curve Cryptography) [RFC6090] significantly relaxes these constraints. For instance, the following key lengths provide equivalent security: a 1024-bit RSA key versus a 160-bit ECC key, or a 2048-bit RSA key versus a 224-bit ECC key. However, RSA puts more load on the signer but much less load on the verifier, whereas ECC puts more similar load on both; hence, with many verifiers, more CPU is consumed overall.
o 数字签名[RFC4359]（参见本文件第3节和第4节）：当需要数据包发送方身份验证和数据包完整性服务时，该方案非常适合于低数据速率流。然而，基于RSA非对称密码体制的数字签名受到计算成本和传输开销的限制。ECC（椭圆曲线密码）[RFC6090]的使用大大放松了这些限制。例如，以下密钥长度提供了等效的安全性：1024位RSA密钥与160位ECC密钥，或2048位RSA密钥与224位ECC密钥。然而，RSA给签名者带来了更多的负载，但给验证器带来的负载却少得多，而ECC给两者带来的负载更为相似；因此，对于许多验证器，总体上会消耗更多的CPU。
o Group-keyed Message Authentication Codes (MACs) (see Section 5): This scheme is well suited to high data rate flows, when transmission overheads must be minimized. However, this scheme cannot protect against attacks coming from inside the group, where a group member impersonates the sender and sends forged messages to other receivers.
o 组键控消息认证码（MAC）（见第5节）：此方案非常适合高数据速率流，此时必须将传输开销降至最低。但是，此方案无法防止来自组内部的攻击，其中组成员模拟发送方并向其他接收方发送伪造消息。
o TESLA (Timed Efficient Stream Loss-tolerant Authentication) [RFC4082] [RFC5776]: This scheme is well suited to high data rate flows, when transmission overheads must be minimized, and when a packet sender authentication and packet integrity service is needed. The price is an increased complexity -- in particular, the need to loosely synchronize the receivers and the sender -- as well as the need to wait for the key to be disclosed before being able to authenticate a packet (i.e., the authentication check is delayed).
o TESLA（定时高效流丢失容忍认证）[RFC4082][RFC5776]：此方案非常适合高数据速率流，此时必须将传输开销降至最低，并且需要数据包发送方认证和数据包完整性服务。代价是增加了复杂性——特别是需要松散地同步接收方和发送方——以及需要等待密钥被公开，然后才能对数据包进行身份验证（即，身份验证检查被延迟）。
The following table summarizes the pros and cons of each authentication/integrity scheme used at the application/transport level (where "-" means con, "0" means neutral, and "+" means pro):
下表总结了在应用程序/传输级别使用的每个身份验证/完整性方案的优缺点（其中“-”表示con，“0”表示中立，“+”表示pro）：
+-----------------+-------------+-------------+-------------+-------+
| | RSA Digital | ECC Digital | Group-Keyed | TESLA |
| | Signature | Signature | MAC | |
+-----------------+-------------+-------------+-------------+-------+
| Sender auth and | Yes | Yes | No (group | Yes |
| packet | | | security) | |
| integrity | | | | |
| Non-delayed | Yes | Yes | Yes | No |
| authentication | | | | |
| Anti-replay | Opt | Opt | Opt | No |
| protection | | | | |
| Processing load | - | sender: -, | + | + |
| | | recv: 0 | | |
| Transmission | - | 0 | + | + |
| overhead | | | | |
| Complexity | + | + | + | - |
+-----------------+-------------+-------------+-------------+-------+
+-----------------+-------------+-------------+-------------+-------+
| | RSA Digital | ECC Digital | Group-Keyed | TESLA |
| | Signature | Signature | MAC | |
+-----------------+-------------+-------------+-------------+-------+
| Sender auth and | Yes | Yes | No (group | Yes |
| packet | | | security) | |
| integrity | | | | |
| Non-delayed | Yes | Yes | Yes | No |
| authentication | | | | |
| Anti-replay | Opt | Opt | Opt | No |
| protection | | | | |
| Processing load | - | sender: -, | + | + |
| | | recv: 0 | | |
| Transmission | - | 0 | + | + |
| overhead | | | | |
| Complexity | + | + | + | - |
+-----------------+-------------+-------------+-------------+-------+
Several authentication schemes MAY be used in the same ALC or NORM session, even on the same communication path. This is made possible through a dedicated identifier, the "ASID" (Authentication Scheme IDentifier), that is present in each HET=1 (EXT_AUTH) header extension and that tells a receiver how to interpret this HET=1 header extension. This is discussed in Section 2.
在同一ALC或NORM会话中，甚至在同一通信路径上，也可以使用多个认证方案。这是通过专用标识符“ASID”（身份验证方案标识符）实现的，该标识符存在于每个HET=1（EXT_AUTH）头扩展中，并告诉接收者如何解释该HET=1头扩展。这将在第2节中讨论。
All the applications built on top of ALC and NORM directly benefit from the source authentication and packet integrity services defined in this document. For instance, this is the case of the File Delivery over Unidirectional Transport (FLUTE) application [RMT-FLUTE], which is built on top of ALC.
所有构建在ALC和NORM之上的应用程序都直接受益于本文档中定义的源身份验证和数据包完整性服务。例如，通过单向传输（FLUTE）应用程序[RMT-FLUTE]进行文件传递就是这种情况，它构建在ALC之上。
The current specification assumes that several parameters (like keying material) are communicated out-of-band, sometimes securely, between the sender and the receivers. This is detailed in Sections 3.2, 4.2, 5.2, and 6.2.
当前的规范假设多个参数（如键控材料）在发送方和接收方之间进行带外通信，有时是安全的。第3.2、4.2、5.2和6.2节对此进行了详细说明。
[RFC5776] explains how to use TESLA in the context of the ALC and NORM protocols.
[RFC5776]解释了如何在ALC和NORM协议的上下文中使用特斯拉。
The current document specifies the use of the Digital Signature based on RSA asymmetric cryptography, the Elliptic Curve Digital Signature Algorithm (ECDSA), and Group-keyed MAC schemes. The current document also specifies the joint use of Digital Signature and Group-keyed MAC schemes.
当前文档规定了基于RSA非对称加密、椭圆曲线数字签名算法（ECDSA）和组密钥MAC方案的数字签名的使用。本文件还规定了数字签名和组密钥MAC方案的联合使用。
Unlike the TESLA scheme, this specification considers the authentication/integrity of the packets generated by the session's sender as well as those generated by the receivers (NORM).
与TESLA方案不同，本规范考虑了会话发送方和接收方生成的数据包的身份验证/完整性（NORM）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The following notations and definitions are used throughout this document:
本文件中使用了以下符号和定义：
o MAC is the Message Authentication Code;
o MAC是消息认证码；
o HMAC is the Keyed-Hash Message Authentication Code;
o HMAC是密钥哈希消息认证码；
o "sender" denotes the sender of a packet that needs the authentication/integrity check service. It can be an ALC or NORM session sender, or a NORM session receiver in the case of feedback traffic;
o “发送方”表示需要身份验证/完整性检查服务的数据包的发送方。它可以是ALC或NORM会话发送方，或者在反馈流量的情况下是NORM会话接收方；
o "receiver" denotes the receiver of a packet that needs the authentication/integrity check service. It can be an ALC or NORM session receiver, or a NORM session sender in the case of feedback traffic;
o “接收方”表示需要认证/完整性检查服务的数据包的接收方。它可以是ALC或NORM会话接收器，或者在反馈流量的情况下是NORM会话发送器；
o "ASID" is the Authentication Scheme IDentifier.
o “ASID”是身份验证方案标识符。
Key definitions for Digital Signatures are as follows:
数字签名的主要定义如下：
o The public key is used by a receiver to check a packet's signature. This key MUST be communicated to all receivers before starting the session;
o 接收方使用公钥检查数据包的签名。在开始会话之前，必须将该密钥传达给所有接收者；
o The private key is used by a sender to generate a packet's signature;
o 发送方使用私钥生成数据包的签名；
o The private key and public key length are expressed in bits. For security considerations [RFC5751], when using RSA, RSASSA-PSS, and Digital Signature Algorithm (DSA) signatures, key sizes of length strictly inferior to 1024 bits SHOULD NOT be used. Key sizes of length between 1024 and 2048 bits inclusive SHOULD be used. Key sizes of length strictly superior to 2048 bits MAY be used.
o 私钥和公钥长度以位表示。出于安全考虑[RFC5751]，在使用RSA、RSASSA-PSS和数字签名算法（DSA）签名时，不应使用长度严格小于1024位的密钥大小。应使用长度介于1024和2048位（含）之间的密钥大小。可以使用长度严格优于2048位的密钥大小。
Key definitions for Group-keyed MAC are as follows:
组密钥MAC的密钥定义如下：
o The shared group key is used by the senders and the receivers. This key MUST be communicated to all group members, confidentially, before starting the session;
o 发送方和接收方使用共享组密钥。在开始会话之前，必须以保密方式将此密钥传达给所有小组成员；
o The group key length is expressed in bits;
o 组密钥长度以位表示；
o n_m is the length of the truncated output of the MAC [RFC2104]. Only the n_m leftmost bits (most significant bits) of the MAC output are kept.
o n_m是MAC[RFC2104]的截断输出的长度。仅保留MAC输出的n_m最左边的位（最高有效位）。
As mentioned in Section 1, several authentication schemes MAY be used in the same ALC or NORM session, even on the same communication path (i.e., from a sender to a receiver, or vice versa). All the schemes mentioned in Section 1 (some of which are specified in this document) use the same HET=1 (EXT_AUTH) Authentication Header extension mechanism defined in [RFC5651]. Therefore, the same 4-bit ASID field has been reserved in all the specifications (see Sections 3.1, 4.1, 5.1, and 6.1, as well as Section 5.1 of [RFC5776]). For a given ALC or NORM session, the ASID value contained in an incoming packet enables a receiver to differentiate the actual use and format of the contents of the HET=1 (EXT_AUTH) header extension.
如第1节所述，在相同的ALC或NORM会话中，甚至在相同的通信路径上（即，从发送方到接收方，或反之亦然），也可以使用多个认证方案。第1节中提到的所有方案（其中一些在本文件中指定）都使用[RFC5651]中定义的相同HET=1（EXT_AUTH）认证头扩展机制。因此，所有规范中都保留了相同的4位ASID字段（参见[RFC5776]第3.1、4.1、5.1和6.1节以及第5.1节）。对于给定的ALC或NORM会话，传入数据包中包含的ASID值使接收方能够区分HET=1（EXT_AUTH）头扩展的实际使用和内容格式。
The association between the ASID value and the actual authentication scheme of a given ALC or NORM session is defined at session startup and communicated to all the session members by an out-of-band mechanism. This association is per ALC or NORM session, and different sessions MAY reuse the same ASID values for different authentication schemes.
ASID值与给定ALC或NORM会话的实际身份验证方案之间的关联在会话启动时定义，并通过带外机制传递给所有会话成员。此关联是针对每个ALC或NORM会话的，不同会话可以为不同的身份验证方案重用相同的ASID值。
With ALC, the ASID value is scoped by the {sender IP address; Transport Session Identifier (TSI)} tuple [RFC5651] that fully identifies an ALC session. Since [RFC5651] requires that "the TSI MUST be unique among all sessions served by the sender during the period when the session is active, and for a large period of time preceding and following when the session is active", there is no risk of confusion between different sessions. This is in line with Section 7.2.3.
对于ALC，ASID值由{sender IP address；Transport Session Identifier（TSI）}元组[RFC5651]确定范围，该元组完全标识ALC会话。由于[RFC5651]要求“在会话处于活动状态期间，发送方服务的所有会话中，TSI必须是唯一的，并且在会话处于活动状态之前和之后的很长一段时间内，TSI必须是唯一的”，因此不同会话之间不存在混淆的风险。这符合第7.2.3节。
With NORM, there is no session identifier within NORM packets. Therefore, depending on whether an Any Source Multicast (ASM) or Source Specific Multicast (SSM) group communication is used, the ASID value is scoped either by the {destination multicast address; destination port number} or {source IP address; destination multicast address; destination port number} tuple that fully identifies a NORM session [RFC5740]. Care should be taken that the above tuples remain unique, within a given scope and for a sufficient period of time preceding, during, and following when the session is active, to avoid confusion between different sessions. However, this is a recommendation for NORM sessions, rather than something specific to an authentication scheme. Note also that the ASID value is not scoped by the {source_id; instance_id} tuple, which uniquely identifies a host's participation in a NORM session, rather than the session itself (Section 7.2.2).
对于NORM，NORM数据包中没有会话标识符。因此，根据是否使用任何源多播（ASM）或源特定多播（SSM）组通信，ASID值的范围是{目的地多播地址；目的地端口号}或{源IP地址；目的地多播地址；目的地端口号}元组，该元组完全标识NORM会话[RFC5740]。应注意，在会话处于活动状态之前、期间和之后的一段时间内，上述元组在给定范围内保持唯一性，以避免不同会话之间的混淆。但是，这是针对标准会话的建议，而不是针对身份验证方案的建议。另请注意ASID值的范围不受{source_id；instance_id}元组的限制，该元组唯一标识主机参与NORM会话，而不是会话本身（第7.2.2节）。
In any case, because this ASID field is 4 bits long, there is a maximum of 16 authentication schemes per ALC or NORM session.
在任何情况下，由于此ASID字段的长度为4位，因此每个ALC或NORM会话最多有16个身份验证方案。
The integration of Digital Signatures is similar in ALC and NORM and relies on the header extension mechanism defined in both protocols. More precisely, this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651].
数字签名的集成在ALC和NORM中类似，并且依赖于两个协议中定义的头扩展机制。更准确地说，本文档详细介绍了[RFC5651]中定义的HET=1（EXT_AUTH）头扩展。
Several fields are added, in addition to the HET (Header Extension Type) and HEL (Header Extension Length) fields (Figure 1).
除了HET（标题扩展类型）和HEL（标题扩展长度）字段（图1）之外，还添加了几个字段。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the Digital Signature EXT_AUTH Header Extension
图1：数字签名EXT_AUTH头扩展的格式
The fields of the Digital Signature EXT_AUTH header extension are as follows:
数字签名EXT_AUTH标头扩展的字段如下所示：
ASID (4 bits):
ASID（4位）：
The ASID identifies the source authentication scheme or protocol in use. The association between the ASID value and the actual authentication scheme is defined out-of-band, at session startup.
ASID标识正在使用的源身份验证方案或协议。ASID值和实际身份验证方案之间的关联在会话启动时在带外定义。
rsvd (Reserved) (3 bits):
rsvd（保留）（3位）：
This is a reserved field that MUST be set to zero and ignored by receivers.
这是一个保留字段，必须设置为零并被接收器忽略。
AR (anti-replay) (1 bit):
AR（反重放）（1位）：
The AR field, when set to 0, indicates that the anti-replay service is not used. When set to 1, it indicates that the anti-replay service is used.
AR字段设置为0时，表示未使用反重播服务。设置为1时，表示使用了防重播服务。
SN (Sequence Number) (8 or 40 bits):
序列号（序列号）（8或40位）：
The SN field contains an optional Sequence Number. When AR = 0, this is an 8-bit field that MUST be set to zero. No anti-replay mechanism is used in that case. When AR = 1, this is a 40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be considered by the anti-replay mechanism.
序列号字段包含可选序列号。当AR=0时，这是一个必须设置为零的8位字段。在这种情况下不使用反重放机制。当AR=1时，这是一个40位字段（32位+8位），反重放机制必须考虑所有40位。
Signature (variable size, multiple of 32 bits):
签名（可变大小，32位的倍数）：
The Signature field contains a Digital Signature of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits.
签名字段包含消息的数字签名。如果需要，此字段将被填充（0）到32位的倍数。
Several parameters MUST be initialized by an out-of-band mechanism. The sender or group controller
几个参数必须由带外机制初始化。发送方或组控制器
o MUST communicate its public key, for each receiver to be able to verify the signature of the packets received. For security reasons [RFC5751], the use of key sizes between 1024 and 2048 bits inclusive is RECOMMENDED. Key sizes inferior to 1024 bits SHOULD NOT be used. Key sizes above 2048 bits MAY be used. As a side effect, the receivers also know the key length and the signature length, the two parameters being equal;
o 必须传递其公钥，以便每个接收器能够验证所接收数据包的签名。出于安全原因[RFC5751]，建议使用1024到2048位（含）之间的密钥大小。不应使用小于1024位的密钥大小。可以使用2048位以上的密钥大小。作为副作用，接收方还知道密钥长度和签名长度，这两个参数相等；
o MAY communicate a certificate (which also means that a PKI has been set up), for each receiver to be able to check the sender's public key;
o 可以传送证书（这也意味着已经建立了PKI），以便每个接收者能够检查发送者的公钥；
o MUST communicate the signature-encoding algorithm. For instance, [RFC3447] defines the RSASSA-PKCS1-v1_5 and RSASSA-PSS algorithms that are usually used for that purpose;
o 必须与签名编码算法通信。例如，[RFC3447]定义了通常用于此目的的RSASSA-PKCS1-v1_5和RSASSA-PSS算法；
o MUST communicate the One-way Hash Function -- for instance, SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512. Because of security threats on SHA-1, the use of SHA-256 is RECOMMENDED [RFC6194];
o 必须传递单向散列函数——例如，SHA-1、SHA-224、SHA-256、SHA-384或SHA-512。由于SHA-1的安全威胁，建议使用SHA-256[RFC6194]；
o MUST associate a value to the ASID field of the EXT_AUTH header extension (Section 3.1);
o 必须将一个值与EXT_AUTH标头扩展的ASID字段相关联（第3.1节）；
o MUST communicate whether or not the anti-replay service is used for this session.
o 必须告知此会话是否使用了反重播服务。
These parameters MUST be communicated to all receivers before they can authenticate the incoming packets. For instance, it can be communicated in the session description, or initialized in a static way on the receivers, or communicated by means of an appropriate protocol. The details of this out-of-band mechanism are beyond the scope of this document.
必须将这些参数传递给所有接收器，然后才能对传入的数据包进行身份验证。例如，它可以在会话描述中通信，或者在接收机上以静态方式初始化，或者通过适当的协议进行通信。此带外机制的详细信息超出了本文档的范围。
The computation of the Digital Signature, using the private key, MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers MUST NOT be included. During this computation, the Signature field MUST be set to 0.
使用私钥的数字签名计算必须包括ALC或NORM头（具有各种头扩展）和有效载荷（如果适用）。不得包含UDP/IP/MAC标头。在此计算过程中，签名字段必须设置为0。
Several signature-encoding algorithms can be used, including RSASSA-PKCS1-v1_5 and RSASSA-PSS. With these encodings, several one-way hash functions can be used, like SHA-256.
可以使用几种签名编码算法，包括RSASSA-PKCS1-v1_5和RSASSA-PSS。通过这些编码，可以使用几个单向散列函数，如SHA-256。
First, let us consider a packet sender. More specifically, as noted in [RFC4359], Digital Signature generation is performed as described in Section 8.2.1 of [RFC3447] (RSASSA-PKCS1-v1_5) and in Section 8.1.1 of [RFC3447] (RSASSA-PSS). The authenticated portion of the packet is used as the message M, which is passed to the signature generation function. The signer's RSA private key is passed as K. In summary (when SHA-256 is used), the signature generation process computes a SHA-256 hash of the authenticated packet bytes, signs the SHA-256 hash using the private key, and encodes the result with the specified RSA encoding type. This process results in a value S, which is the Digital Signature to be included in the packet.
首先，让我们考虑一个数据包发送器。更具体地说，如[RFC4359]中所述，按照[RFC3447]（RSASSA-PKCS1-v1_5）第8.2.1节和[RFC3447]（RSASSA-PSS）第8.1.1节的说明执行数字签名生成。分组的认证部分用作消息M，消息M被传递给签名生成函数。签名者的RSA私钥作为K传递。总之（当使用SHA-256时），签名生成过程计算经过身份验证的数据包字节的SHA-256散列，使用私钥对SHA-256散列进行签名，并使用指定的RSA编码类型对结果进行编码。这个过程产生一个值S，它是要包括在数据包中的数字签名。
With RSASSA-PKCS1-v1_5 and RSASSA-PSS signatures, the size of the signature is equal to the "RSA modulus", unless the RSA modulus is not a multiple of 8 bits. In that case, the Digital Signature (also called the Integrity Check Value (ICV) in [RFC4359]) MUST be prepended with between 1 and 7 bits set to zero such that the Digital Signature is a multiple of 8 bits [RFC4359]. The key length, which in practice is also equal to the RSA modulus, has major security implications. [RFC4359] explains how to choose this value, depending on the maximum expected lifetime of the session. This choice is beyond the scope of this document.
对于RSASSA-PKCS1-v1_5和RSASSA-PSS签名，签名的大小等于“RSA模”，除非RSA模不是8位的倍数。在这种情况下，数字签名（在[RFC4359]中也称为完整性检查值（ICV））必须在1到7位之间设置为零，以便数字签名是8位[RFC4359]的倍数。密钥长度实际上也等于RSA模，具有重大的安全含义。[RFC4359]解释如何根据会话的最大预期生存期选择此值。此选项超出了本文档的范围。
Now, let us consider a receiver. As noted in [RFC4359], Digital Signature verification is performed as described in Section 8.2.2 of [RFC3447] (RSASSA-PKCS1-v1_5) and Section 8.1.2 of [RFC3447] (RSASSA-PSS). Upon receipt, the Digital Signature is passed to the verification function as S. The authenticated portion of the packet is used as the message M, and the RSA public key is passed as (n, e). In summary (when SHA-256 is used), the verification function computes a SHA-256 hash of the authenticated packet bytes, decrypts the SHA-256 hash in the packet using the sender's public key, and
现在，让我们考虑一个接收器。如[RFC4359]所述，数字签名验证按照[RFC3447]（RSASSA-PKCS1-v1_5）第8.2.2节和[RFC3447]（RSASSA-PSS）第8.1.2节所述进行。收到后，数字签名作为S传递给验证函数。数据包的认证部分用作消息M，RSA公钥作为（n，e）传递。总之（当使用SHA-256时），验证函数计算经验证的分组字节的SHA-256散列，使用发送方的公钥解密分组中的SHA-256散列，以及
validates that the appropriate encoding was applied. The two SHA-256 hashes are compared, and if they are identical, the validation is successful.
验证是否应用了适当的编码。比较两个SHA-256哈希，如果它们相同，则验证成功。
Let us assume the anti-replay service is used. The principles are similar to the Sequence Number mechanism described in [RFC4303], with the exception that the present document uses a 40-bit field that contains all the bits of the Sequence Number counter.
假设使用了反重播服务。这些原理与[RFC4303]中描述的序列号机制类似，但本文档使用包含序列号计数器所有位的40位字段除外。
At the sender, the mechanism works as follows (Section 2.2 of [RFC4303]). The sender's Sequence Number counter is initialized to 0 at session startup. The sender increments the Sequence Number counter for this session and inserts the value into the SN field. Thus, the first packet sent will contain an SN of 1. The SN value of the Authentication Header extension MUST be initialized before the signature generation process, in order to enable a receiver to check the SN value during the integrity verification process.
在发送方，该机制的工作原理如下（RFC4303第2.2节）。会话启动时，发送方的序列号计数器初始化为0。发送方增加此会话的序列号计数器，并将该值插入SN字段。因此，发送的第一个分组将包含SN为1。身份验证标头扩展的SN值必须在签名生成过程之前初始化，以便使接收方能够在完整性验证过程中检查SN值。
The sender SHOULD ensure that the counter does not cycle before inserting the new value in the SN field. Failing to follow this rule would enable an attacker to replay a packet sent during the previous cycle; i.e., it would limit the anti-replay service to a single SN cycle. Since the Sequence Number is contained in a 40-bit field, it is expected that cycling will never happen in most situations. For instance, on a 10-Gbps network, with small packets (i.e., 64 bytes long), cycling will happen after slightly more than 15 hours.
发送方应确保在SN字段中插入新值之前计数器不会循环。如果不遵守此规则，攻击者将能够重播上一个周期中发送的数据包；i、 例如，它将反重播服务限制为单个SN周期。由于序列号包含在40位字段中，因此预计在大多数情况下不会发生循环。例如，在10 Gbps网络上，对于小数据包（即64字节长），循环将在15个多小时后发生。
At the receiver, the mechanism works as follows (Section 3.4.3 and Appendix A2 of [RFC4303]). For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the session. If this preliminary check fails, the packet is discarded, thus avoiding the need for any cryptographic operations by the receiver. If the preliminary check is successful, the receiver cannot yet modify its local counter, because the integrity of the Sequence Number has not been verified at this point.
在接收器处，机构工作如下（第3.4.3节和[RFC4303]附录A2）。对于每个接收到的分组，接收器必须验证该分组包含的序列号与会话期间接收到的任何其他分组的序列号不重复。如果该初步检查失败，则丢弃该数据包，从而避免接收方进行任何加密操作。如果初步检查成功，接收器还不能修改其本地计数器，因为此时序列号的完整性尚未验证。
Duplicates are rejected through the use of a sliding receive window. The "right" edge of the window represents the highest, validated Sequence Number value received on this session. Packets that contain Sequence Numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window (how this list is managed is a local, implementation-based decision). This window limits how far out of order a packet can be, relative to the packet with the highest Sequence Number that has been authenticated so far.
通过使用滑动接收窗口拒绝重复项。窗口的“右”边缘表示此会话上接收到的最高、已验证的序列号值。包含序列号低于窗口“左”边缘的数据包将被拒绝。根据窗口内接收的数据包列表检查窗口内的数据包（如何管理该列表是一个基于本地实现的决策）。此窗口限制了数据包相对于迄今为止已通过身份验证的序列号最高的数据包的无序程度。
If the received packet falls within the window and is not a duplicate, or if the packet is to the right of the window, then the receiver proceeds to integrity verification. If the integrity check fails, the receiver MUST discard the received packet as invalid; otherwise, the receive window is updated and packet processing continues.
如果接收到的数据包落在窗口内并且不是重复的，或者如果数据包在窗口的右侧，则接收器进行完整性验证。如果完整性检查失败，接收方必须将接收到的数据包视为无效而丢弃；否则，将更新接收窗口并继续数据包处理。
Each packet sent MUST contain exactly one Digital Signature EXT_AUTH header extension. A receiver MUST drop all the packets that do not contain a Digital Signature EXT_AUTH header extension.
发送的每个数据包必须包含一个数字签名EXT_AUTH头扩展名。接收方必须丢弃所有不包含数字签名EXT_AUTH头扩展名的数据包。
All receivers MUST recognize EXT_AUTH but might not be able to parse its content, for instance, because they do not support Digital Signatures. In that case, the Digital Signature EXT_AUTH header extension is ignored.
所有接收者都必须识别EXT_AUTH，但可能无法解析其内容，例如，因为他们不支持数字签名。在这种情况下，将忽略数字签名EXT_AUTH标头扩展。
If the anti-replay mechanism is used, each packet sent MUST contain a valid Sequence Number. All the packets that fail to contain a valid Sequence Number MUST be immediately dropped.
如果使用防重播机制，则发送的每个数据包必须包含有效的序列号。必须立即丢弃所有未能包含有效序列号的数据包。
For instance, Figure 2 shows the Digital Signature EXT_AUTH header extension when using 128-byte (1024-bit) key Digital Signatures (which also means that the Signature field is 128 bytes long). The Digital Signature EXT_AUTH header extension is then 132 bytes long.
例如，图2显示了使用128字节（1024位）密钥数字签名时的数字签名EXT_AUTH头扩展（这也意味着签名字段的长度为128字节）。数字签名EXT_AUTH头扩展名的长度为132字节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=33) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature (128 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=33) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature (128 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 2: Example: Format of the Digital Signature EXT_AUTH Header Extension Using 1024-Bit Signatures, without Any Anti-Replay Protection
图2：示例：使用1024位签名的数字签名EXT_AUTH头扩展的格式，无任何反重放保护
This document focuses on the Elliptic Curve Digital Signature Algorithm (ECDSA). However, [RFC6090] describes alternative elliptic curve techniques, like KT-I signatures. The use of such alternatives is not considered in this document, but may be added in the future.
本文档重点介绍椭圆曲线数字签名算法（ECDSA）。然而，[RFC6090]描述了其他椭圆曲线技术，如KT-I签名。本文件未考虑此类替代品的使用，但可在将来添加。
The integration of ECC Digital Signatures is similar to that of RSA Digital Signatures. Several fields are added, in addition to the HET and HEL fields, as illustrated in Figure 1.
ECC数字签名的集成与RSA数字签名的集成类似。除了HET和HEL字段外，还添加了几个字段，如图1所示。
The fields of the Digital Signature EXT_AUTH header extension are as follows:
数字签名EXT_AUTH标头扩展的字段如下所示：
ASID (4 bits):
ASID（4位）：
The ASID identifies the source authentication scheme or protocol in use. The association between the ASID value and the actual authentication scheme is defined out-of-band, at session startup.
ASID标识正在使用的源身份验证方案或协议。ASID值和实际身份验证方案之间的关联在会话启动时在带外定义。
rsvd (3 bits):
rsvd（3位）：
This is a reserved field that MUST be set to zero and ignored by receivers.
这是一个保留字段，必须设置为零并被接收器忽略。
AR (1 bit):
AR（1位）：
The AR field, when set to 0, indicates that the anti-replay service is not used. When set to 1, it indicates that the anti-replay service is used.
AR字段设置为0时，表示未使用反重播服务。设置为1时，表示使用了防重播服务。
SN (8 or 40 bits):
序列号（8或40位）：
The SN field contains an optional Sequence Number. When AR = 0, this is an 8-bit field that MUST be set to zero. No anti-replay mechanism is used in that case. When AR = 1, this is a 40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be considered by the anti-replay mechanism.
序列号字段包含可选序列号。当AR=0时，这是一个必须设置为零的8位字段。在这种情况下不使用反重放机制。当AR=1时，这是一个40位字段（32位+8位），反重放机制必须考虑所有40位。
Signature (variable size, multiple of 32 bits):
签名（可变大小，32位的倍数）：
The Signature field contains a Digital Signature of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits.
签名字段包含消息的数字签名。如果需要，此字段将被填充（0）到32位的倍数。
Several parameters MUST be initialized by an out-of-band mechanism. The sender or group controller
几个参数必须由带外机制初始化。发送方或组控制器
o MUST communicate its public key, for each receiver to be able to verify the signature of the packets received. As a side effect, the receivers also know the key length and the signature length, the two parameters being equal;
o 必须传递其公钥，以便每个接收器能够验证所接收数据包的签名。作为副作用，接收方还知道密钥长度和签名长度，这两个参数相等；
o MAY communicate a certificate (which also means that a PKI has been set up), for each receiver to be able to check the sender's public key;
o 可以传送证书（这也意味着已经建立了PKI），以便每个接收者能够检查发送者的公钥；
o MUST communicate the message digest algorithm;
o 必须传达消息摘要算法；
o MUST communicate the elliptic curve;
o 要沟通椭圆曲线；
o MUST associate a value to the ASID field of the EXT_AUTH header extension (Section 3.1);
o 必须将一个值与EXT_AUTH标头扩展的ASID字段相关联（第3.1节）；
o MUST communicate whether or not the anti-replay service is used for this session.
o 必须告知此会话是否使用了反重播服务。
These parameters MUST be communicated to all receivers before they can authenticate the incoming packets. For instance, it can be communicated in the session description, or initialized in a static way on the receivers, or communicated by means of an appropriate protocol. The details of this out-of-band mechanism are beyond the scope of this document.
必须将这些参数传递给所有接收器，然后才能对传入的数据包进行身份验证。例如，它可以在会话描述中通信，或者在接收机上以静态方式初始化，或者通过适当的协议进行通信。此带外机制的详细信息超出了本文档的范围。
The computation of the ECC Digital Signature, using the private key, MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers MUST NOT be included. During this computation, the Signature field MUST be set to 0.
使用私钥的ECC数字签名的计算必须包括ALC或NORM报头（具有各种报头扩展）和有效载荷（如适用）。不得包含UDP/IP/MAC标头。在此计算过程中，签名字段必须设置为0。
Several elliptic curve groups can be used, as well as several hash algorithms. In practice, both choices are related, and there is a minimum hash algorithm size for any key length. Using a larger hash algorithm and then truncating the output is also feasible; however,
可以使用几个椭圆曲线组，以及几个哈希算法。实际上，这两种选择都是相关的，对于任何密钥长度都有一个最小哈希算法大小。使用较大的哈希算法，然后截断输出也是可行的；然而
it consumes more processing power than is necessary. In order to promote interoperability, [RFC4754] and [RFC5480] list several possible choices (see table below).
它消耗的处理能力超过了所需。为了促进互操作性，[RFC4754]和[RFC5480]列出了几种可能的选择（见下表）。
+---------------------------+--------+------------------+-----------+
| Digital Signature | Key | Message Digest | Elliptic |
| Algorithm Name [RFC4754] | Size | Algorithm | Curve |
+---------------------------+--------+------------------+-----------+
| ECDSA-256 (default) | 256 | SHA-256 | secp256r1 |
| ECDSA-384 | 384 | SHA-384 | secp384r1 |
| ECDSA-521 | 512 | SHA-512 | secp521r1 |
+---------------------------+--------+------------------+-----------+
+---------------------------+--------+------------------+-----------+
| Digital Signature | Key | Message Digest | Elliptic |
| Algorithm Name [RFC4754] | Size | Algorithm | Curve |
+---------------------------+--------+------------------+-----------+
| ECDSA-256 (default) | 256 | SHA-256 | secp256r1 |
| ECDSA-384 | 384 | SHA-384 | secp384r1 |
| ECDSA-521 | 512 | SHA-512 | secp521r1 |
+---------------------------+--------+------------------+-----------+
ECDSA-256, ECDSA-384, and ECDSA-521 are designed to offer security comparable with AES-128, AES-192, and AES-256, respectively [RFC4754]. Among them, the use of ECDSA-256/secp256r1 is RECOMMENDED.
ECDSA-256、ECDSA-384和ECDSA-521的设计可分别提供与AES-128、AES-192和AES-256相当的安全性[RFC4754]。其中，建议使用ECDSA-256/secp256r1。
The anti-replay processing follows the principles described in Section 3.3.2.
反重放处理遵循第3.3.2节所述的原则。
Each packet sent MUST contain exactly one ECC Digital Signature EXT_AUTH header extension. A receiver MUST drop all the packets that do not contain an ECC Digital Signature EXT_AUTH header extension.
发送的每个数据包必须包含一个ECC数字签名EXT_AUTH头扩展名。接收方必须丢弃所有不包含ECC数字签名EXT_AUTH头扩展的数据包。
All receivers MUST recognize EXT_AUTH but might not be able to parse its content, for instance, because they do not support ECC Digital Signatures. In that case, the Digital Signature EXT_AUTH header extension is ignored.
所有接收者必须识别EXT_AUTH，但可能无法解析其内容，例如，因为他们不支持ECC数字签名。在这种情况下，将忽略数字签名EXT_AUTH标头扩展。
If the anti-replay mechanism is used, each packet sent MUST contain a valid Sequence Number. All the packets that fail to contain a valid Sequence Number MUST be immediately dropped.
如果使用防重播机制，则发送的每个数据包必须包含有效的序列号。必须立即丢弃所有未能包含有效序列号的数据包。
For instance, Figure 3 shows the Digital Signature EXT_AUTH header extension when using ECDSA-256 (256-bit) ECC Digital Signatures. The ECC Digital Signature EXT_AUTH header extension is then 36 bytes long.
例如，图3显示了使用ECDSA-256（256位）ECC数字签名时的数字签名EXT_AUTH头扩展。ECC数字签名EXT_AUTH头扩展名的长度为36字节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=9) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 3
+ + | 2
. . |
. Signature (32 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=9) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 3
+ + | 2
. . |
. Signature (32 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 3: Example: Format of the ECC Digital Signature EXT_AUTH Header Extension Using ECDSA-256 Signatures, without Any Anti-Replay Protection
图3：示例：使用ECDSA-256签名的ECC数字签名EXT_AUTH头扩展的格式，无任何防重放保护
The integration of Group-keyed MAC is similar in ALC and NORM and relies on the header extension mechanism defined in both protocols. More precisely, this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651].
组密钥MAC的集成在ALC和NORM中类似，并且依赖于两个协议中定义的报头扩展机制。更准确地说，本文档详细介绍了[RFC5651]中定义的HET=1（EXT_AUTH）头扩展。
Several fields are added, in addition to the HET and HEL fields (Figure 4).
除了HET和HEL字段外，还添加了几个字段（图4）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Group-keyed MAC |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
~ anti-replay Sequence Number (SN) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Group-keyed MAC |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of the Group-Keyed MAC EXT_AUTH Header Extension
图4：组键控MAC EXT_AUTH头扩展的格式
The fields of the Group-keyed MAC EXT_AUTH header extension are as follows:
组键控MAC EXT_AUTH头扩展的字段如下所示：
ASID (4 bits):
ASID（4位）：
The ASID identifies the source authentication scheme or protocol in use. The association between the ASID value and the actual authentication scheme is defined out-of-band, at session startup.
ASID标识正在使用的源身份验证方案或协议。ASID值和实际身份验证方案之间的关联在会话启动时在带外定义。
rsvd (3 bits):
rsvd（3位）：
This is a reserved field that MUST be set to zero and ignored by receivers.
这是一个保留字段，必须设置为零并被接收器忽略。
AR (1 bit):
AR（1位）：
The AR field, when set to 0, indicates that the anti-replay service is not used. When set to 1, it indicates that the anti-replay service is used.
AR字段设置为0时，表示未使用反重播服务。设置为1时，表示使用了防重播服务。
SN (8 or 40 bits):
序列号（8或40位）：
The SN field contains an optional Sequence Number. When AR = 0, this is an 8-bit field that MUST be set to zero. No anti-replay mechanism is used in that case. When AR = 1, this is a 40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be considered by the anti-replay mechanism.
序列号字段包含可选序列号。当AR=0时，这是一个必须设置为零的8位字段。在这种情况下不使用反重放机制。当AR=1时，这是一个40位字段（32位+8位），反重放机制必须考虑所有40位。
Group-keyed MAC (variable size, multiple of 32 bits):
组键控MAC（可变大小，32位的倍数）：
The Group-keyed MAC field contains a truncated Group-keyed MAC of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits.
组密钥MAC字段包含消息的截断组密钥MAC。如果需要，此字段将被填充（0）到32位的倍数。
Several parameters MUST be initialized by an out-of-band mechanism. The sender or group controller
几个参数必须由带外机制初始化。发送方或组控制器
o MUST communicate the Cryptographic MAC Function -- for instance, HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512. As a side effect, with these functions, the receivers also know the key length and the non-truncated MAC output length. Because of security threats on SHA-1, the use of HMAC-SHA-256 is RECOMMENDED [RFC6194];
o 必须通信加密MAC功能——例如，HMAC-SHA-1、HMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384或HMAC-SHA-512。作为一个副作用，使用这些函数，接收器还知道密钥长度和非截断MAC输出长度。由于SHA-1上存在安全威胁，建议使用HMAC-SHA-256[RFC6194]；
o MUST communicate the length of the truncated output of the MAC, n_m, which depends on the Cryptographic MAC Function chosen. Only the n_m leftmost bits (most significant bits) of the MAC output are kept. Of course, n_m MUST be less than or equal to the key length;
o 必须传输MAC的截断输出长度n_m，这取决于所选的加密MAC函数。仅保留MAC输出的n_m最左边的位（最高有效位）。当然，n_m必须小于或等于密钥长度；
o MUST communicate the group key to the receivers, confidentially, before starting the session. This key might have to be periodically refreshed for improved robustness;
o 在开始会话之前，必须以保密方式将组密钥传达给接收者。此密钥可能必须定期刷新以提高健壮性；
o MUST associate a value to the ASID field of the EXT_AUTH header extension (Section 5.1);
o 必须将一个值与EXT_AUTH标头扩展的ASID字段相关联（第5.1节）；
o MUST communicate whether or not the anti-replay service is used for this session.
o 必须告知此会话是否使用了反重播服务。
These parameters MUST be communicated to all receivers before they can authenticate the incoming packets. For instance, it can be communicated in the session description, or initialized in a static way on the receivers, or communicated by means of an appropriate protocol (this will often be the case when periodic re-keying is required). The details of this out-of-band mechanism are beyond the scope of this document.
必须将这些参数传递给所有接收器，然后才能对传入的数据包进行身份验证。例如，它可以在会话描述中进行通信，或者在接收器上以静态方式初始化，或者通过适当的协议进行通信（当需要定期重新设置密钥时，通常会出现这种情况）。此带外机制的详细信息超出了本文档的范围。
The computation of the Group-keyed MAC, using the group key, includes the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP/MAC headers are not included. During this computation, the weak Group-keyed MAC field MUST be set to 0. Then, the sender truncates the MAC output to keep the n_m most significant bits and stores the result in the Group-keyed MAC Authentication Header.
使用组密钥的组密钥MAC的计算包括ALC或NORM报头（具有各种报头扩展）和有效载荷（如果适用）。不包括UDP/IP/MAC标头。在此计算期间，弱组键控MAC字段必须设置为0。然后，发送方截断MAC输出以保留n_m最高有效位，并将结果存储在组密钥MAC认证报头中。
Upon receiving this packet, the receiver computes the Group-keyed MAC, using the group key, and compares it to the value carried in the packet. During this computation, the Group-keyed MAC field MUST also be set to 0. If the check fails, the packet MUST be immediately dropped.
在接收到该数据包时，接收器使用组密钥计算组密钥MAC，并将其与数据包中携带的值进行比较。在此计算期间，组键控MAC字段也必须设置为0。如果检查失败，必须立即丢弃数据包。
[RFC2104] explains that it is current practice to truncate the MAC output, on condition that the truncated output length, n_m, be not less than half the length of the hash and not less than 80 bits. However, this choice is beyond the scope of this document.
[RFC2104]解释了当前的做法是截断MAC输出，条件是截断的输出长度n_m不小于散列长度的一半且不小于80位。但是，此选择超出了本文档的范围。
The anti-replay processing follows the principles described in Section 3.3.2.
反重放处理遵循第3.3.2节所述的原则。
Each packet sent MUST contain exactly one Group-keyed MAC EXT_AUTH header extension. A receiver MUST drop packets that do not contain a Group-keyed MAC EXT_AUTH header extension.
发送的每个数据包必须正好包含一个组键控MAC EXT_AUTH头扩展。接收器必须丢弃不包含组键控MAC EXT_AUTH头扩展的数据包。
All receivers MUST recognize EXT_AUTH but might not be able to parse its content, for instance, because they do not support Group-keyed MAC. In that case, the Group-keyed MAC EXT_AUTH extension is ignored.
所有接收者都必须识别EXT_AUTH，但可能无法解析其内容，例如，因为他们不支持组密钥MAC。在这种情况下，将忽略组键控的MAC EXT_AUTH扩展。
If the anti-replay mechanism is used, each packet sent MUST contain a valid Sequence Number. All the packets that fail to contain a valid Sequence Number MUST be immediately dropped.
如果使用防重播机制，则发送的每个数据包必须包含有效的序列号。必须立即丢弃所有未能包含有效序列号的数据包。
For instance, Figure 5 shows the Group-keyed MAC EXT_AUTH header extension when using HMAC-SHA-256. The Group-keyed MAC EXT_AUTH header extension is then 16 bytes long.
例如，图5显示了使用HMAC-SHA-256时的组键控MAC EXT_AUTH头扩展。组键控MAC EXT_AUTH头扩展名的长度为16字节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=4) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Group-keyed MAC (16 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=4) | ASID | 0 |0| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Group-keyed MAC (16 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example: Format of the Group-Keyed MAC EXT_AUTH Header Extension Using HMAC-SHA-256, without Any Anti-Replay Protection
图5：示例：使用HMAC-SHA-256的组键控MAC EXT_AUTH头扩展的格式，无任何防重放保护
6. Combined Use of the RSA/ECC Digital Signatures and Group-Keyed MAC Schemes
6. RSA/ECC数字签名和组密钥MAC方案的组合使用
The integration of combined RSA/ECC Digital Signatures and Group-keyed MAC schemes is similar in ALC and NORM and relies on the header extension mechanism defined in both protocols. More precisely, this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651].
组合RSA/ECC数字签名和组密钥MAC方案的集成在ALC和NORM中类似，并且依赖于两个协议中定义的头扩展机制。更准确地说，本文档详细介绍了[RFC5651]中定义的HET=1（EXT_AUTH）头扩展。
Several fields are added, in addition to the HET and HEL fields (Figure 6).
除了HET和HEL字段外，还添加了几个字段（图6）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
| anti-replay Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group-keyed MAC |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL | ASID | rsvd|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+R+ +
| anti-replay Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| Signature |
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group-keyed MAC |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of the Group-Keyed MAC EXT_AUTH Header Extension
图6：组键控MAC EXT_AUTH头扩展的格式
The fields of the Group-keyed MAC EXT_AUTH header extension are as follows:
组键控MAC EXT_AUTH头扩展的字段如下所示：
ASID (4 bits):
ASID（4位）：
The ASID identifies the source authentication scheme or protocol in use. The association between the ASID value and the actual authentication scheme is defined out-of-band, at session startup.
ASID标识正在使用的源身份验证方案或协议。ASID值和实际身份验证方案之间的关联在会话启动时在带外定义。
rsvd (3 bits):
rsvd（3位）：
This is a reserved field that MUST be set to zero and ignored by receivers.
这是一个保留字段，必须设置为零并被接收器忽略。
AR (1 bit):
AR（1位）：
The AR field MUST be set to 1, indicating that the anti-replay service is used (see Section 6.3).
AR字段必须设置为1，表示使用了反重播服务（见第6.3节）。
SN (8 or 40 bits):
序列号（8或40位）：
The SN field contains a Sequence Number. Since AR = 1, this is a 40-bit field (32 bits + 8 bits), and all of the 40 bits MUST be considered by the anti-replay mechanism.
序列号字段包含序列号。由于AR=1，这是一个40位字段（32位+8位），反重放机制必须考虑所有40位。
Signature (variable size, multiple of 32 bits):
签名（可变大小，32位的倍数）：
The Signature field contains a Digital Signature of the message. If need be, this field is padded (with 0) up to a multiple of 32 bits.
签名字段包含消息的数字签名。如果需要，此字段将被填充（0）到32位的倍数。
Group-keyed MAC (variable size, multiple of 32 bits, by default 32 bits):
组键控MAC（可变大小，32位的倍数，默认为32位）：
The Group-keyed MAC field contains a truncated Group-keyed MAC of the message.
组密钥MAC字段包含消息的截断组密钥MAC。
Several parameters MUST be initialized by an out-of-band mechanism, as defined in Sections 3.2, 4.2, and 5.2.
如第3.2、4.2和5.2节所述，必须通过带外机制初始化多个参数。
In some situations, it can be interesting to use both authentication schemes. The goal of the Group-keyed MAC is to mitigate denial-of-service (DoS) attacks coming from attackers that are not group members [RFC4082], by adding a light authentication scheme as a front-end.
在某些情况下，使用这两种身份验证方案可能会很有趣。组密钥MAC的目标是通过添加轻型身份验证方案作为前端，减轻来自非组成员的攻击者的拒绝服务（DoS）攻击[RFC4082]。
Before sending a message, the sender sets the Signature field and Group-keyed MAC field to zero. Then, the sender computes the signature as detailed in Section 3.3 or in Section 4.3 and stores the value in the Signature field. Then, the sender computes the Group-keyed MAC as detailed in Section 5.3 and stores the value in the Group-keyed MAC field. The (RSA or ECC) Digital Signature value is therefore protected by the Group-keyed MAC, which avoids DoS attacks where the attacker corrupts the Digital Signature itself.
在发送消息之前，发送方将签名字段和组密钥MAC字段设置为零。然后，发送方按照第3.3节或第4.3节的详细说明计算签名，并将值存储在签名字段中。然后，发送方按照第5.3节的详细说明计算组密钥MAC，并将该值存储在组密钥MAC字段中。因此，（RSA或ECC）数字签名值受组密钥MAC保护，从而避免了攻击者破坏数字签名本身的DoS攻击。
Upon receiving the packet, the receiver first checks the Group-keyed MAC, as detailed in Section 5.3. If the check fails, the packet MUST be immediately dropped. Otherwise, the receiver checks the Digital Signature, as detailed in Section 3.3. If the check fails, the packet MUST be immediately dropped.
接收到数据包后，接收方首先检查组密钥MAC，详见第5.3节。如果检查失败，必须立即丢弃数据包。否则，接收方将检查数字签名，详见第3.3节。如果检查失败，必须立即丢弃数据包。
This scheme features a few limits:
该方案有几个限制：
o The Group-keyed MAC is of no help if a group member (who knows the group key) impersonates the sender and sends forged messages to other receivers. DoS attacks are still feasible;
o 如果组成员（知道组密钥的人）冒充发送者并向其他接收者发送伪造消息，则组密钥MAC没有任何帮助。拒绝服务攻击仍然可行；
o It requires an additional MAC computing for each packet, both at the sender and receiver sides;
o 它需要在发送方和接收方对每个数据包进行额外的MAC计算；
o It increases the size of the Authentication Headers. In order to limit this problem, the length of the truncated output of the MAC, n_m, SHOULD be kept small (see Section 9.5 of [RFC3711]). In the current specification, n_m MUST be a multiple of 32 bits, and the default value is 32 bits. As a side effect, with n_m = 32 bits, the authentication service is significantly weakened, since the probability that any packet would be successfully forged is one in 2^32. Since the Group-keyed MAC check is only a pre-check that is followed by the standard signature authentication check, this is not considered to be an issue.
o 它增加了身份验证头的大小。为了限制此问题，MAC的截断输出长度n_m应保持较小（见[RFC3711]第9.5节）。在当前规范中，n_m必须是32位的倍数，默认值为32位。作为一个副作用，当n_m=32位时，身份验证服务被显著削弱，因为任何数据包被成功伪造的概率是2^32中的一个。由于组密钥MAC检查只是在标准签名身份验证检查之后进行的预检查，因此不认为这是一个问题。
For a given use case, the benefits brought by the Group-keyed MAC must be balanced against these limitations.
对于给定的用例，组键控MAC带来的好处必须与这些限制相平衡。
The anti-replay processing follows the principles described in Section 3.3.2. Here, an anti-replay service MUST be used. Indeed, failing to enable anti-replay protection would facilitate DoS attacks, since all replayed (but otherwise valid) packets would pass the light authentication scheme and oblige a receiver to perform a complex signature verification.
反重放处理遵循第3.3.2节所述的原则。在这里，必须使用防重播服务。事实上，如果不启用反重放保护，将有助于DoS攻击，因为所有重放（但在其他方面有效）的数据包都将通过轻型身份验证方案，并迫使接收方执行复杂的签名验证。
Each packet sent MUST contain exactly one combined Digital Signature/ Group-keyed MAC EXT_AUTH header extension. A receiver MUST drop packets that do not contain a combined Digital Signature/Group-keyed MAC EXT_AUTH header extension.
发送的每个数据包必须正好包含一个组合数字签名/组密钥MAC EXT_AUTH头扩展。接收方必须丢弃不包含组合数字签名/组密钥MAC EXT_AUTH头扩展的数据包。
All receivers MUST recognize EXT_AUTH but might not be able to parse its content, for instance, because they do not support combined Digital Signature/Group-keyed MAC. In that case, the combined Digital Signature/Group-keyed MAC EXT_AUTH extension is ignored.
所有接收者必须识别EXT_AUTH，但可能无法解析其内容，例如，因为他们不支持组合数字签名/组密钥MAC。在这种情况下，将忽略组合数字签名/组密钥MAC EXT_AUTH扩展。
Since the anti-replay mechanism MUST be used, each packet sent MUST contain a valid Sequence Number. All the packets that fail to contain a valid Sequence Number MUST be immediately dropped.
由于必须使用防重播机制，因此发送的每个数据包必须包含有效的序列号。必须立即丢弃所有未能包含有效序列号的数据包。
It is RECOMMENDED that the n_m parameter of the group authentication scheme be small, and by default equal to 32 bits (Section 6.3).
建议组身份验证方案的n_m参数较小，默认情况下等于32位（第6.3节）。
For instance, Figure 7 shows the combined Digital Signature/ Group-keyed MAC EXT_AUTH header extension when using 128-byte (1024-bit) key RSA Digital Signatures (which also means that the Signature field is 128 bytes long). The EXT_AUTH header extension is then 140 bytes long.
例如，图7显示了使用128字节（1024位）密钥RSA数字签名时的组合数字签名/组密钥MAC EXT_AUTH头扩展（这也意味着签名字段长度为128字节）。EXT_AUTH头扩展名的长度为140字节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=35) | ASID | 0 |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| anti-replay Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature (128 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Group-keyed MAC (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (=1) | HEL (=35) | ASID | 0 |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| anti-replay Sequence Number (SN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature (128 bytes) . | b
. . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Group-keyed MAC (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 7: Example: Format of the Combined RSA Digital Signature/ Group-Keyed MAC EXT_AUTH Header Extension Using 1024-Bit Signatures, with Anti-Replay Protection
图7：示例：使用1024位签名的组合RSA数字签名/组密钥MAC EXT_AUTH头扩展的格式，具有防重放保护
Let us consider packets secured through the use of a Digital Signature scheme first. Because faked packets are easy to create but checking them requires computation of a costly Digital Signature, this scheme introduces new opportunities for an attacker to mount DoS attacks. More precisely, an attacker can easily saturate the processing capabilities of the receiver.
让我们先考虑通过使用数字签名方案来确保的数据包。由于伪造数据包很容易创建，但检查它们需要计算昂贵的数字签名，因此该方案为攻击者提供了发动DoS攻击的新机会。更准确地说，攻击者很容易使接收器的处理能力饱和。
In order to mitigate these attacks, it is RECOMMENDED that the combined Digital Signature/Group-keyed MAC scheme (Section 6.3) be used. However, no mitigation is possible if a group member acts as an attacker. Additionally, even if checking a Group-keyed MAC is
为了减轻这些攻击，建议使用组合数字签名/组密钥MAC方案（第6.3节）。但是，如果组成员充当攻击者，则不可能进行缓解。此外，即使检查组键控MAC
significantly faster than checking a Digital Signature, there are practical limits on how many Group-keyed MACs can be checked per time unit. Therefore, it is RECOMMENDED that limiting the number of authentication checks per time unit be done when the number of incoming packets that fail the authentication check exceeds a given threshold (i.e., in the case of a DoS attack).
比检查数字签名快得多的是，每个时间单位可以检查多少组密钥MAC有实际限制。因此，建议在未通过身份验证检查的传入数据包数量超过给定阈值（即，在DoS攻击的情况下）时，限制每个时间单位的身份验证检查数量。
The RECOMMENDED action of limiting the number of checks per time unit under (presumed) attack situations can be extended to the other authentication schemes.
在（假定）攻击情况下限制每个时间单位的检查次数的建议操作可以扩展到其他身份验证方案。
Replay attacks involve an attacker storing a valid message and replaying it later. It is RECOMMENDED that the anti-replay service defined in this document be used with the signature and Group-keyed MAC solutions, and this anti-replay service MUST be used in the case of a combined use of signatures and Group-keyed MAC schemes (see Section 6.3.2).
重播攻击涉及攻击者存储有效消息并在以后重播。建议将本文件中定义的反重放服务与签名和组密钥MAC解决方案一起使用，并且必须在签名和组密钥MAC方案组合使用的情况下使用该反重放服务（见第6.3.2节）。
The following section details some of the potential consequences of not using anti-replay protection.
以下部分详细介绍了不使用防重放保护的一些潜在后果。
Since all the above authentication schemes are stateless, replay attacks have no impact on these schemes.
由于上述所有身份验证方案都是无状态的，重放攻击对这些方案没有影响。
In this subsection, we review the potential impacts of a replay attack on the NORM component. Note that we do not consider here the protocols that could be used along with NORM -- for instance, congestion control protocols.
在本小节中，我们将回顾重播攻击对NORM组件的潜在影响。请注意，我们不考虑可以与规范一起使用的协议，例如拥塞控制协议。
First, let us consider replay attacks within a given NORM session. As NORM is a stateful protocol, replaying a packet may have consequences.
首先，让我们考虑给定的规范会话中的重放攻击。由于NORM是一个有状态协议，重播数据包可能会产生后果。
NORM defines a "sequence" field that may be used to protect against replay attacks [RFC5740] within a given NORM session. This sequence field is a 16-bit value that is set by the message originator (sender or receiver) as a monotonically increasing number incremented with each NORM message transmitted. Using this field for anti-replay protection would be possible if there is no wrapping to zero, i.e., would only be possible if at most 65535 packets are sent; this may be true for some use cases but not for the general case. Using this
NORM定义了一个“序列”字段，可用于在给定NORM会话中防止重播攻击[RFC5740]。该序列字段是一个16位的值，由消息发起者（发送者或接收者）设置为一个单调递增的数字，随着发送的每个NORM消息而递增。如果没有包装到零，则可以使用此字段进行防重放保护，即，仅当最多发送65535个数据包时才可能；这可能适用于某些用例，但不适用于一般情况。用这个
field for anti-replay protection would also be possible if the keying material is updated before wrapping to zero happens; this may be true for some use cases but not for the general case.
如果在包装到零之前更新了键控材料，则也可以使用防重放保护字段；这可能适用于某些用例，但不适用于一般情况。
Now, let us consider replay attacks across several NORM sessions. A host participating in a NORM session is uniquely identified by the {source_id; instance_id} tuple. Therefore, when a given host participates in several NORM sessions, it is RECOMMENDED that instance_id be changed for each NORM instance. It is also RECOMMENDED, when the Group-keyed MAC authentication/integrity check scheme is used, that the shared group key be changed across sessions. Therefore, NORM can be made robust when confronted with replay attacks across different sessions.
现在，让我们考虑几个规范会话中的重放攻击。参与NORM会话的主机由{source\u id；instance\u id}元组唯一标识。因此，当给定主机参与多个NORM会话时，建议为每个NORM实例更改实例id。当使用组密钥MAC身份验证/完整性检查方案时，还建议跨会话更改共享组密钥。因此，当遇到跨不同会话的重播攻击时，NORM可以变得健壮。
In this subsection, we review the potential impacts of a replay attack on the ALC component. Note that we do not consider here the protocols that could be used along with ALC -- for instance, layered or wave-based congestion control protocols.
在本小节中，我们将回顾重播攻击对ALC组件的潜在影响。注意，我们不考虑可以与ALC一起使用的协议，例如，基于分层或基于波形的拥塞控制协议。
First, let us consider replay attacks within a given ALC session:
首先，让我们考虑给定ALC会话中的重放攻击：
o Replayed encoding symbol: A replayed encoding symbol (coming from a replayed data packet) is detected, thanks to the object/block/ symbol identifiers, and is silently discarded.
o 重放编码符号：由于对象/块/符号标识符，检测到重放的编码符号（来自重放的数据包），并自动丢弃。
o Replayed control information:
o 重播的控制信息：
* At the end of the session, a "close session" (A flag) packet is sent. Replaying a packet containing this flag has no impact, since the receivers have already left the session.
* 在会话结束时，发送“关闭会话”（标志）数据包。重播包含此标志的数据包不会产生影响，因为接收方已经离开会话。
* Similarly, replaying a packet containing a "close object" (B flag) has no impact, since this object is probably already marked as closed by the receiver.
* 类似地，重放包含“close object”（B标志）的数据包也没有影响，因为接收方可能已经将该对象标记为close。
* Timing information sent as part of a Layered Coding Transport (LCT) EXT_TIME header extension [RFC5651] may be more sensitive to replay attacks. For instance, replaying a packet containing an ERT (Expected Residual Time) may mislead a receiver to believe an object transmission will continue for some time whereas the transmission of symbols for this object is about to stop. Replaying a packet containing a Sender Current Time (SCT) is easily identified if the receiver verifies that time progresses upon receiving such EXT_TIME header extensions.
* 作为分层编码传输（LCT）EXT_TIME报头扩展[RFC5651]的一部分发送的定时信息可能对重播攻击更敏感。例如，重放包含ERT（预期剩余时间）的分组可能误导接收机相信对象传输将持续一段时间，而该对象的符号传输即将停止。如果接收者在接收到这样的EXT_时间报头扩展时验证时间进展，则重放包含发送者当前时间（SCT）的数据包很容易被识别。
Replaying a packet containing a Session Last Changed (SLC) is easily identified if the receiver verifies the chronology upon receiving such EXT_TIME header extensions.
如果接收者在接收到这种EXT_时间报头扩展时验证了时间顺序，那么重放包含最后更改的会话（SLC）的数据包很容易识别。
This analysis shows that ALC might be, to a limited extent, sensitive to replay attacks within the same session if timing information is used. Otherwise, ALC is robust when confronted with replay attacks within the same session.
该分析表明，如果使用定时信息，ALC可能在一定程度上对同一会话内的重播攻击敏感。否则，ALC在同一会话中遇到重播攻击时是健壮的。
Now, let us consider replay attacks across several ALC sessions. An ALC session is uniquely identified by the {sender IP address; TSI} tuple. Therefore, when a given sender creates several sessions, the TSI MUST be changed for each ALC session, so that each TSI is unique among all active sessions of this sender and for a long period of time preceding and following when the session is active [RFC5651]. Therefore, ALC can be made robust when confronted with replay attacks across different sessions. Of course, when the Group-keyed MAC authentication/integrity check scheme is used, the shared group key SHOULD be changed across sessions if the set of receivers changes.
现在，让我们考虑几个ALC会话的重放攻击。ALC会话由{sender IP address；TSI}元组唯一标识。因此，当给定发送方创建多个会话时，必须为每个ALC会话更改TSI，以便每个TSI在该发送方的所有活动会话中是唯一的，并且在会话活动前后的很长一段时间内是唯一的[RFC5651]。因此，当遇到跨不同会话的重播攻击时，ALC可以变得健壮。当然，当使用组密钥MAC身份验证/完整性检查方案时，如果接收器集发生变化，则应在会话间更改共享组密钥。
This specification requires that several parameters be communicated to the receiver(s) via an out-of-band mechanism that is beyond the scope of this document. This is in particular the case for the mapping between an ASID value and the associated authentication scheme (Section 1). Since this mapping is critical, this information SHOULD be carried in a secure way from the sender to the receiver(s).
本规范要求通过超出本文件范围的带外机制将多个参数传送给接收器。ASID值和相关认证方案之间的映射尤其如此（第1节）。由于此映射非常重要，因此应以安全的方式将此信息从发送方传送到接收方。
The author is grateful to the authors of [RFC4303], [RFC4359], [RFC4754], and [RFC5480]; their documents inspired several sections of the present document. The author is also grateful to all the IESG members, and in particular to David Harrington, Stephen Farrell, and Sean Turner for their very detailed reviews.
作者感谢[RFC4303]、[RFC4359]、[RFC4754]和[RFC5480]的作者；他们的文件启发了本文件的几个章节。作者还感谢IESG的所有成员，特别是David Harrington、Stephen Farrell和Sean Turner的详细评论。
[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月。
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5651]Luby，M.，Watson，M.，和L.Vicisano，“分层编码传输（LCT）构建块”，RFC 5651，2009年10月。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009.
[RFC5740]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向NACK的可靠多播（NORM）传输协议”，RFC 57402009年11月。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[RFC5775]Luby，M.，Watson，M.，和L.Vicisano，“异步分层编码（ALC）协议实例化”，RFC 5775，2010年4月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4359]Weis，B.“在封装安全有效载荷（ESP）和身份验证头（AH）中使用RSA/SHA-1签名”，RFC 4359，2006年1月。
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007.
[RFC4754]Fu，D.和J.Solinas，“使用椭圆曲线数字签名算法（ECDSA）的IKE和IKEv2认证”，RFC 4754，2007年1月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 54802009年3月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 5776, April 2010.
[RFC5776]Roca，V.，Francillon，A.，和S.Faurite，“在异步分层编码（ALC）和面向NACK的可靠多播（NORM）协议中使用定时高效流丢失容忍认证（TESLA）”，RFC 5776，2010年4月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 60902011年2月。
[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月。
[RMT-FLUTE] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, March 2012.
[RMT-FLUTE]Paila，T.，Walsh，R.，Luby，M.，Roca，V.，和R.Lehtonen，“长笛-单向运输上的文件交付”，在建工程，2012年3月。
Author's Address
作者地址
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
Vincent Roca INRIA 655，av。欧洲伊诺瓦利；蒙博诺圣伊斯梅尔塞德斯38334法国
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/