Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 5776 A. Francillon
Category: Experimental S. Faurite
ISSN: 2070-1721 INRIA
April 2010
Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 5776 A. Francillon
Category: Experimental S. Faurite
ISSN: 2070-1721 INRIA
April 2010
Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
在异步分层编码（ALC）和面向NACK的可靠多播（NORM）协议中使用定时高效流丢失容忍认证（TESLA）
Abstract
摘要
This document details the Timed Efficient Stream Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document.
本文档详细介绍了定时高效流丢失容忍认证（TESLA）包源认证和包完整性验证协议及其在异步分层编码（ALC）和面向NACK的可靠多播（NORM）内容交付协议中的集成。本文档仅考虑会话发送方生成的数据包的身份验证/完整性验证。接收方发送的数据包的认证和完整性验证（如有）不在本文件范围内。
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 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc5776.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5776.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 6
1.2. Conventions Used in This Document . . . . . . . . . . . . 7
1.3. Terminology and Notations . . . . . . . . . . . . . . . . 7
1.3.1. Notations and Definitions Related to Cryptographic
Functions . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2. Notations and Definitions Related to Time . . . . . . 8
2. Using TESLA with ALC and NORM: General Operations . . . . . . 9
2.1. ALC and NORM Specificities That Impact TESLA . . . . . . . 9
2.2. Bootstrapping TESLA . . . . . . . . . . . . . . . . . . . 10
2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism . . 10
2.2.2. Bootstrapping TESLA with an In-Band Mechanism . . . . 11
2.3. Setting Up a Secure Time Synchronization . . . . . . . . . 11
2.3.1. Direct Time Synchronization . . . . . . . . . . . . . 12
2.3.2. Indirect Time Synchronization . . . . . . . . . . . . 12
2.4. Determining the Delay Bounds . . . . . . . . . . . . . . . 13
2.4.1. Delay Bound Calculation in Direct Time
Synchronization Mode . . . . . . . . . . . . . . . . . 14
2.4.2. Delay Bound Calculation in Indirect Time
Synchronization Mode . . . . . . . . . . . . . . . . . 14
2.5. Cryptographic Parameter Values . . . . . . . . . . . . . . 15
3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 16
3.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 16
3.1.1. Time Intervals . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Key Chains . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3. Time Interval Schedule . . . . . . . . . . . . . . . . 20
3.1.4. Timing Parameters . . . . . . . . . . . . . . . . . . 20
3.2. TESLA Signaling Messages . . . . . . . . . . . . . . . . . 21
3.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 21
3.2.2. Direct Time Synchronization Response . . . . . . . . . 22
3.3. TESLA Authentication Information . . . . . . . . . . . . . 22
3.3.1. Authentication Tags . . . . . . . . . . . . . . . . . 23
3.3.2. Digital Signatures . . . . . . . . . . . . . . . . . . 23
3.3.3. Group MAC Tags . . . . . . . . . . . . . . . . . . . . 24
3.4. Format of TESLA Messages and Authentication Tags . . . . . 25
3.4.1. Format of a Bootstrap Information Message . . . . . . 26
3.4.2. Format of a Direct Time Synchronization Response . . . 31
3.4.3. Format of a Standard Authentication Tag . . . . . . . 32
3.4.4. Format of an Authentication Tag without Key
Disclosure . . . . . . . . . . . . . . . . . . . . . . 33
3.4.5. Format of an Authentication Tag with a "New Key
Chain" Commitment . . . . . . . . . . . . . . . . . . 34
3.4.6. Format of an Authentication Tag with a "Last Key
of Old Chain" Disclosure . . . . . . . . . . . . . . . 35
4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 36
4.1. Verification of the Authentication Information . . . . . . 36
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 6
1.2. Conventions Used in This Document . . . . . . . . . . . . 7
1.3. Terminology and Notations . . . . . . . . . . . . . . . . 7
1.3.1. Notations and Definitions Related to Cryptographic
Functions . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2. Notations and Definitions Related to Time . . . . . . 8
2. Using TESLA with ALC and NORM: General Operations . . . . . . 9
2.1. ALC and NORM Specificities That Impact TESLA . . . . . . . 9
2.2. Bootstrapping TESLA . . . . . . . . . . . . . . . . . . . 10
2.2.1. Bootstrapping TESLA with an Out-Of-Band Mechanism . . 10
2.2.2. Bootstrapping TESLA with an In-Band Mechanism . . . . 11
2.3. Setting Up a Secure Time Synchronization . . . . . . . . . 11
2.3.1. Direct Time Synchronization . . . . . . . . . . . . . 12
2.3.2. Indirect Time Synchronization . . . . . . . . . . . . 12
2.4. Determining the Delay Bounds . . . . . . . . . . . . . . . 13
2.4.1. Delay Bound Calculation in Direct Time
Synchronization Mode . . . . . . . . . . . . . . . . . 14
2.4.2. Delay Bound Calculation in Indirect Time
Synchronization Mode . . . . . . . . . . . . . . . . . 14
2.5. Cryptographic Parameter Values . . . . . . . . . . . . . . 15
3. Sender Operations . . . . . . . . . . . . . . . . . . . . . . 16
3.1. TESLA Parameters . . . . . . . . . . . . . . . . . . . . . 16
3.1.1. Time Intervals . . . . . . . . . . . . . . . . . . . . 16
3.1.2. Key Chains . . . . . . . . . . . . . . . . . . . . . . 16
3.1.3. Time Interval Schedule . . . . . . . . . . . . . . . . 20
3.1.4. Timing Parameters . . . . . . . . . . . . . . . . . . 20
3.2. TESLA Signaling Messages . . . . . . . . . . . . . . . . . 21
3.2.1. Bootstrap Information . . . . . . . . . . . . . . . . 21
3.2.2. Direct Time Synchronization Response . . . . . . . . . 22
3.3. TESLA Authentication Information . . . . . . . . . . . . . 22
3.3.1. Authentication Tags . . . . . . . . . . . . . . . . . 23
3.3.2. Digital Signatures . . . . . . . . . . . . . . . . . . 23
3.3.3. Group MAC Tags . . . . . . . . . . . . . . . . . . . . 24
3.4. Format of TESLA Messages and Authentication Tags . . . . . 25
3.4.1. Format of a Bootstrap Information Message . . . . . . 26
3.4.2. Format of a Direct Time Synchronization Response . . . 31
3.4.3. Format of a Standard Authentication Tag . . . . . . . 32
3.4.4. Format of an Authentication Tag without Key
Disclosure . . . . . . . . . . . . . . . . . . . . . . 33
3.4.5. Format of an Authentication Tag with a "New Key
Chain" Commitment . . . . . . . . . . . . . . . . . . 34
3.4.6. Format of an Authentication Tag with a "Last Key
of Old Chain" Disclosure . . . . . . . . . . . . . . . 35
4. Receiver Operations . . . . . . . . . . . . . . . . . . . . . 36
4.1. Verification of the Authentication Information . . . . . . 36
4.1.1. Processing the Group MAC Tag . . . . . . . . . . . . . 36
4.1.2. Processing the Digital Signature . . . . . . . . . . . 37
4.1.3. Processing the Authentication Tag . . . . . . . . . . 37
4.2. Initialization of a Receiver . . . . . . . . . . . . . . . 38
4.2.1. Processing the Bootstrap Information Message . . . . . 38
4.2.2. Performing Time Synchronization . . . . . . . . . . . 38
4.3. Authentication of Received Packets . . . . . . . . . . . . 40
4.3.1. Discarding Unnecessary Packets Earlier . . . . . . . . 43
4.4. Flushing the Non-Authenticated Packets of a Previous
Key Chain . . . . . . . . . . . . . . . . . . . . . . . . 43
5. Integration in the ALC and NORM Protocols . . . . . . . . . . 44
5.1. Authentication Header Extension Format . . . . . . . . . . 44
5.2. Use of Authentication Header Extensions . . . . . . . . . 45
5.2.1. EXT_AUTH Header Extension of Type Bootstrap
Information . . . . . . . . . . . . . . . . . . . . . 45
5.2.2. EXT_AUTH Header Extension of Type Authentication
Tag . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.3. EXT_AUTH Header Extension of Type Direct Time
Synchronization Request . . . . . . . . . . . . . . . 49
5.2.4. EXT_AUTH Header Extension of Type Direct Time
Synchronization Response . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 50
6.1. Dealing with DoS Attacks . . . . . . . . . . . . . . . . . 50
6.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 51
6.2.1. Impacts of Replay Attacks on TESLA . . . . . . . . . . 51
6.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 52
6.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 53
6.3. Security of the Back Channel . . . . . . . . . . . . . . . 53
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 56
4.1.1. Processing the Group MAC Tag . . . . . . . . . . . . . 36
4.1.2. Processing the Digital Signature . . . . . . . . . . . 37
4.1.3. Processing the Authentication Tag . . . . . . . . . . 37
4.2. Initialization of a Receiver . . . . . . . . . . . . . . . 38
4.2.1. Processing the Bootstrap Information Message . . . . . 38
4.2.2. Performing Time Synchronization . . . . . . . . . . . 38
4.3. Authentication of Received Packets . . . . . . . . . . . . 40
4.3.1. Discarding Unnecessary Packets Earlier . . . . . . . . 43
4.4. Flushing the Non-Authenticated Packets of a Previous
Key Chain . . . . . . . . . . . . . . . . . . . . . . . . 43
5. Integration in the ALC and NORM Protocols . . . . . . . . . . 44
5.1. Authentication Header Extension Format . . . . . . . . . . 44
5.2. Use of Authentication Header Extensions . . . . . . . . . 45
5.2.1. EXT_AUTH Header Extension of Type Bootstrap
Information . . . . . . . . . . . . . . . . . . . . . 45
5.2.2. EXT_AUTH Header Extension of Type Authentication
Tag . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2.3. EXT_AUTH Header Extension of Type Direct Time
Synchronization Request . . . . . . . . . . . . . . . 49
5.2.4. EXT_AUTH Header Extension of Type Direct Time
Synchronization Response . . . . . . . . . . . . . . . 49
6. Security Considerations . . . . . . . . . . . . . . . . . . . 50
6.1. Dealing with DoS Attacks . . . . . . . . . . . . . . . . . 50
6.2. Dealing With Replay Attacks . . . . . . . . . . . . . . . 51
6.2.1. Impacts of Replay Attacks on TESLA . . . . . . . . . . 51
6.2.2. Impacts of Replay Attacks on NORM . . . . . . . . . . 52
6.2.3. Impacts of Replay Attacks on ALC . . . . . . . . . . . 53
6.3. Security of the Back Channel . . . . . . . . . . . . . . . 53
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 56
Many applications using multicast and broadcast communications require that each receiver be able to authenticate the source of any packet it receives as well as the integrity of these packets. This is the case with ALC [RFC5775] and NORM [RFC5740], two Content Delivery Protocols (CDPs) designed to transfer objects (e.g., files) reliably between a session's sender and several receivers. The NORM protocol is based on bidirectional transmissions. Each receiver acknowledges data received or, in case of packet erasures, asks for retransmissions. On the opposite, the ALC protocol is based on purely unidirectional transmissions. Reliability is achieved by means of the cyclic transmission of the content within a carousel and/or by the use of proactive Forward Error Correction (FEC) codes. 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.
许多使用多播和广播通信的应用程序要求每个接收器能够验证其接收的任何数据包的来源以及这些数据包的完整性。ALC[RFC5775]和NORM[RFC5740]就是这种情况，这两种内容交付协议（CDP）设计用于在会话的发送方和多个接收方之间可靠地传输对象（例如文件）。NORM协议基于双向传输。每个接收器确认接收到的数据，或者在数据包擦除的情况下，请求重新传输。相反，ALC协议基于纯粹的单向传输。通过在转盘内循环传输内容和/或通过使用主动前向纠错（FEC）码来实现可靠性。这两个协议的共同点是，它们在应用程序级别上运行，在擦除通道（例如，互联网）之上，数据包在传输过程中可能会丢失（擦除）。
The goal of this document is to counter attacks where an attacker impersonates the ALC or NORM session's sender and injects forged packets to the receivers, thereby corrupting the objects reconstructed by the receivers.
本文档的目标是反击攻击者模仿ALC或NORM会话的发送方并向接收方注入伪造数据包，从而破坏接收方重建的对象的攻击。
Preventing this attack is much more complex in the case of group communications than it is with unicast communications. Indeed, with unicast communications, a simple solution exists: the sender and the receiver share a secret key to compute a Message Authentication Code (MAC) of all messages exchanged. This is no longer feasible in the case of multicast and broadcast communications since sharing a group key between the sender and all receivers implies that any group member can impersonate the sender and send forged messages to other receivers.
与单播通信相比，在组通信中防止这种攻击要复杂得多。事实上，对于单播通信，存在一个简单的解决方案：发送方和接收方共享一个密钥来计算所有交换消息的消息认证码（MAC）。这在多播和广播通信的情况下不再可行，因为在发送方和所有接收方之间共享组密钥意味着任何组成员都可以模拟发送方并向其他接收方发送伪造消息。
The usual solution to provide the source authentication and message integrity services in the case of multicast and broadcast communications consists of relying on asymmetric cryptography and using digital signatures. Yet, this solution is limited by high computational costs and high transmission overheads. The Timed Efficient Stream Loss-tolerant Authentication (TESLA) protocol is an alternative solution that provides the two required services, while being compatible with high-rate transmissions over lossy channels.
在多播和广播通信的情况下，提供源认证和消息完整性服务的通常解决方案包括依赖非对称加密和使用数字签名。然而，这种解决方案受到高计算成本和高传输开销的限制。定时高效流丢失容忍认证（TESLA）协议是一种替代解决方案，它提供两种所需的服务，同时兼容有损信道上的高速传输。
This document explains how to integrate the TESLA source authentication and packet integrity protocol to the ALC and NORM CDP. Any application built on top of ALC and NORM will directly benefit from the services offered by TESLA at the transport layer. In particular, this is the case of File Delivery over Unidirectional Transport (FLUTE).
本文档说明了如何将特斯拉源认证和数据包完整性协议集成到ALC和NORM CDP中。任何建立在ALC和NORM之上的应用程序都将直接受益于特斯拉在传输层提供的服务。特别是，这是通过单向传输（FLUTE）进行文件传递的情况。
For more information on the TESLA protocol and its principles, please refer to [RFC4082] and [Perrig04]. For more information on ALC and NORM, please refer to [RFC5775], [RFC5651], and [RFC5740], respectively. For more information on FLUTE, please refer to [RMT-FLUTE].
有关特斯拉协议及其原则的更多信息，请参考[RFC4082]和[Perrig04]。有关ALC和NORM的更多信息，请分别参考[RFC5775]、[RFC5651]和[RFC5740]。有关长笛的更多信息，请参阅[RMT-FLUTE]。
This specification only considers the authentication and integrity verification of the packets generated by the session's sender. This specification does not consider the packets that may be sent by receivers, for instance, NORM's feedback packets. [RMT-SIMPLE-AUTH] describes several techniques that can be used to that purpose. Since this is usually a low-rate flow (unlike the downstream flow), using computing intensive techniques like digital signatures, possibly combined with a Group MAC scheme, is often acceptable. Finally, Section 5 explains how to use several authentication schemes in a given session thanks to the "ASID" (Authentication Scheme IDentifier) field.
此规范仅考虑会话发送方生成的数据包的身份验证和完整性验证。该规范不考虑接收机可能发送的分组，例如，范数的反馈分组。[RMT-SIMPLE-AUTH]介绍了几种可用于此目的的技术。由于这通常是一个低速率流（与下游流不同），使用诸如数字签名之类的计算密集型技术（可能与组MAC方案相结合）通常是可以接受的。最后，第5节解释了由于“ASID”（身份验证方案标识符）字段，如何在给定会话中使用多个身份验证方案。
This specification relies on several external mechanisms, for instance:
本规范依赖于几种外部机制，例如：
o to communicate securely the public key or a certificate for the session's sender (Section 2.2.2);
o 为会话发送方安全地传递公钥或证书（第2.2.2节）；
o to communicate securely and confidentially the group key, K_g, used by the Group MAC feature, when applicable (Section 3.3.3). In some situations, this group key will have to be periodically refreshed;
o 在适用的情况下，以安全保密的方式与组MAC功能使用的组密钥K_g进行通信（第3.3.3节）。在某些情况下，必须定期刷新此组密钥；
o to perform secure time synchronization in indirect mode (Section 2.3.2) or in direct mode (Section 2.3.1) to carry the request/response messages with ALC, which is purely unidirectional;
o 在间接模式（第2.3.2节）或直接模式（第2.3.1节）下执行安全时间同步，以使用ALC传输请求/响应消息，这纯粹是单向的；
These mechanisms are required in order to bootstrap TESLA at a sender and at a receiver and must be deployed in parallel to TESLA. Besides, the randomness of the Primary Key of the key chain (Section 3.1.2) is vital to the security of TESLA. Therefore, the sender needs an appropriate mechanism to generate this random key.
这些机制是在发送方和接收方引导特斯拉所必需的，必须与特斯拉并行部署。此外，钥匙链主键的随机性（第3.1.2节）对特斯拉的安全至关重要。因此，发送方需要适当的机制来生成此随机密钥。
Several technical details of TESLA, like the most appropriate way to alternate between the transmission of a key disclosure and a commitment to a new key chain, or the transmission of a key disclosure and the last key of the previous key chain, or the disclosure of a key and the compact flavor that does not disclose any key, are specific to the target use case (Section 3.1.2). For
特斯拉的一些技术细节，如在传递钥匙披露和承诺新钥匙链之间，或传递钥匙披露和上一个钥匙链的最后一把钥匙之间，或传递钥匙披露和不泄露任何钥匙的紧凑风格之间，最合适的交替方式，特定于目标用例（第3.1.2节）。对于
instance, it depends on the number of packets sent per time interval, on the desired robustness and the acceptable transmission overhead, which can only be optimized after taking into account the use-case specificities.
例如，它取决于每个时间间隔发送的数据包数量、期望的健壮性和可接受的传输开销，只有在考虑到用例特定性后才能对其进行优化。
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.
本文件中使用了以下符号和定义。
Notations and definitions related to cryptographic functions [RFC4082][RFC4383]:
与加密函数相关的符号和定义[RFC4082][RFC4383]：
o PRF is the Pseudo Random Function;
o PRF是伪随机函数；
o MAC is the Message Authentication Code;
o MAC是消息认证码；
o HMAC is the keyed-Hash Message Authentication Code;
o HMAC是密钥哈希消息认证码；
o F is the one-way function used to create the key chain (Section 3.1.2.1);
o F是用于创建钥匙链的单向函数（第3.1.2.1节）；
o F' is the one-way function used to derive the HMAC keys (Section 3.1.2.1);
o F'是用于推导HMAC键的单向函数（第3.1.2.1节）；
o n_p is the length, in bits, of the F function's output. This is therefore the length of the keys in the key chain;
o n_p是F函数输出的长度，以位为单位。因此，这是钥匙链中钥匙的长度；
o n_f is the length, in bits, of the F' function's output. This is therefore the length of the HMAC keys;
o n_f是f'函数输出的长度，以位为单位。因此，这是HMAC键的长度；
o n_m is the length, in bits, of the truncated output of the MAC [RFC2104]. Only the n_m most significant bits of the MAC output are kept;
o n_m是MAC[RFC2104]的截断输出的长度（以位为单位）。仅保留MAC输出的nμm最高有效位；
o N is the length of a key chain. There are N+1 keys in a key chain: K_0, K_1, ..., K_N. When several chains are used, all the chains MUST have the same length and keys are numbered consecutively, following the time interval numbering;
o N是钥匙链的长度。一个钥匙链中有N+1个钥匙：K_0，K_1，…，K_N。当使用多个钥匙链时，所有钥匙链必须具有相同的长度，并且钥匙按照时间间隔编号连续编号；
o n_c is the number of keys in a key chain. Therefore, n_c = N+1;
o n_c是钥匙链中钥匙的数量。因此，n_c=n+1；
o n_tx_lastkey is the number of additional intervals during which the last key of the old key chain SHOULD be sent, after switching to a new key chain and after waiting for the disclosure delay d. These extra transmissions take place after the interval during which the last key is normally disclosed. The n_tx_lastkey value is either 0 (no extra disclosure) or larger. This parameter is sender specific and is not communicated to the receiver;
o n_tx_lastkey是在切换到新钥匙链并等待披露延迟d后，应发送旧钥匙链最后一个钥匙的额外间隔数。这些额外的传输发生在最后一把钥匙正常公开的时间间隔之后。n_tx_lastkey值为0（无额外披露）或更大。此参数特定于发送方，不与接收方通信；
o n_tx_newkcc is the number of intervals during which the commitment to a new key chain SHOULD be sent, before switching to the new key chain. The n_tx_newkcc value is either 0 (no commitment sent within authentication tags) or larger. This parameter is sender specific and is not communicated to the receiver;
o n_tx_newkcc是在切换到新密钥链之前，发送新密钥链承诺的间隔数。n_tx_newkcc值为0（身份验证标记内未发送承诺）或更大。此参数特定于发送方，不与接收方通信；
o K_g is a shared group key, communicated to all group members, confidentially, during the TESLA bootstrapping (Section 2.2);
o K_g是一个共享的组密钥，在特斯拉自举（第2.2节）过程中以保密方式传达给所有组成员；
o n_w is the length, in bits, of the truncated output of the MAC of the optional group authentication scheme: only the n_w most significant bits of the MAC output are kept. n_w is typically small, a multiple of 32 bits (e.g., 32 bits).
o n_w是可选组身份验证方案的MAC截断输出的长度（以位为单位）：仅保留MAC输出的n_w最高有效位。n_w通常很小，是32位（例如32位）的倍数。
Notations and definitions related to time:
与时间相关的符号和定义：
o i is the time interval index. Interval numbering starts at 0 and increases consecutively. Since the interval index is stored as a 32-bit unsigned integer, wrapping to 0 might take place in long sessions.
o i是时间间隔指数。间隔编号从0开始，并连续增加。由于间隔索引存储为32位无符号整数，因此在长会话中可能会换行为0。
o t_s is the sender local time value at some absolute time (in NTP timestamp format);
o t_s是某个绝对时间的发送方本地时间值（NTP时间戳格式）；
o t_r is the receiver local time value at the same absolute time (in NTP timestamp format);
o t_r是同一绝对时间的接收机本地时间值（NTP时间戳格式）；
o T_0 is the start time corresponding to the beginning of the session, i.e., the beginning of time interval 0 (in NTP timestamp format);
o T_0是对应于会话开始的开始时间，即时间间隔0的开始（以NTP时间戳格式）；
o T_int is the interval duration (in milliseconds);
o T_int是间隔持续时间（以毫秒为单位）；
o d is the key disclosure delay (in number of intervals);
o d是密钥披露延迟（间隔数）；
o D_t is the upper bound of the lag of the receiver's clock with respect to the clock of the sender;
o D_t是接收方时钟相对于发送方时钟滞后的上限；
o S_sr is an estimated bound of the clock drift between the sender and a receiver throughout the duration of the session;
o S_sr是整个会话期间发送方和接收方之间时钟漂移的估计界；
o D^O_t is the upper bound of the lag of the sender's clock with respect to the time reference in indirect time synchronization mode;
o D^Ot是在间接时间同步模式下，发送方时钟相对于时间基准的滞后上限；
o D^R_t is the upper bound of the lag of the receiver's clock with respect to the time reference in indirect time synchronization mode;
o D^R\t是在间接时间同步模式下，接收器时钟相对于时间基准的滞后上限；
o D_err is an upper bound of the time error between all the time references, in indirect time synchronization mode;
o D_err是间接时间同步模式下所有时间参考之间的时间误差上限；
o NTP timestamp format consists in a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits, and the fraction part in the last 32 bits [RFC1305].
o NTP时间戳格式包含一个64位无符号定点数字，相对于1900年1月1日的0h，以秒为单位。整数部分位于前32位，小数部分位于后32位[RFC1305]。
The ALC and NORM protocols have features and requirements that largely impact the way TESLA can be used.
ALC和NORM协议的特点和要求在很大程度上影响了特斯拉的使用方式。
In the case of ALC:
对于自动高度控制：
o ALC is massively scalable: nothing in the protocol specification limits the number of receivers that join a session. Therefore, an ALC session potentially includes a huge number (e.g., millions or more) of receivers;
o ALC具有很大的可扩展性：协议规范中没有任何内容限制加入会话的接收器数量。因此，ALC会话可能包括大量（例如，数百万或更多）接收机；
o ALC can work on top of purely unidirectional transport channels: this is one of the assets of ALC, and examples of unidirectional channels include satellite (even if a back channel might exist in some use cases) and broadcasting networks like Digital Video Broadcasting - Handhelds / Satellite services to Handhelds (DVB-H/SH);
o ALC可以在纯单向传输信道上工作：这是ALC的资产之一，单向信道的示例包括卫星（即使在某些用例中可能存在反向信道）和广播网络，如数字视频广播-手持设备/手持设备的卫星服务（DVB-H/SH）；
o ALC defines an on-demand content delivery model [RFC5775] where receivers can arrive at any time, at their own discretion, download the content and leave the session. Other models (e.g., push or streaming) are also defined;
o ALC定义了一种按需内容交付模型[RFC5775]，在该模型中，接收者可以随时自行决定下载内容并离开会话。还定义了其他模型（例如推送或流式传输）；
o ALC sessions are potentially very long: a session can last several days or months during which the content is continuously transmitted within a carousel. The content can be either static (e.g., a software update) or dynamic (e.g., a web site).
o ALC会话可能非常长：一个会话可以持续几天或几个月，在此期间，内容在转盘中连续传输。内容可以是静态的（例如，软件更新）或动态的（例如，网站）。
Depending on the use case, some of the above features may not apply. For instance, ALC can also be used over a bidirectional channel or with a limited number of receivers.
根据使用情况，上述某些功能可能不适用。例如，ALC还可以在双向信道上使用，或者与有限数量的接收机一起使用。
In the case of NORM:
对于NORM：
o NORM has been designed for medium-size sessions: indeed, NORM relies on feedback messages and the sender may collapse if the feedback message rate is too high;
o NORM是为中型会话设计的：事实上，NORM依赖于反馈消息，如果反馈消息率过高，发送方可能崩溃；
o NORM requires a bidirectional transport channel: the back channel is not necessarily a high-data rate channel since the control traffic sent over it by a single receiver is an order of magnitude lower than the downstream traffic. Networks with an asymmetric connectivity (e.g., a high-rate satellite downlink and a low-rate return channel) are appropriate.
o NORM需要双向传输信道：后向信道不一定是高数据速率信道，因为单接收机通过其发送的控制通信量比下游通信量低一个数量级。具有非对称连接的网络（例如，高速卫星下行链路和低速返回信道）是合适的。
In order to initialize the TESLA component at a receiver, the sender MUST communicate some key information in a secure way, so that the receiver can check the source of the information and its integrity. Two general methods are possible:
为了在接收者处初始化特斯拉组件，发送者必须以安全的方式传递一些关键信息，以便接收者能够检查信息的来源及其完整性。有两种通用方法：
o by using an out-of-band mechanism, or
o 通过使用带外机制，或
o by using an in-band mechanism.
o 通过使用带内机构。
The current specification does not recommend any mechanism to bootstrap TESLA. Choosing between an in-band and out-of-band scheme is left to the implementer, depending on the target use case. However, it is RECOMMENDED that TESLA implementations support the use of the in-band mechanism for interoperability purposes.
当前规范不推荐任何机制引导特斯拉。根据目标用例，带内和带外方案由实现者选择。但是，建议特斯拉实施支持使用带内机制实现互操作性。
For instance, [RFC4442] describes the use of the MIKEY (Multimedia Internet Keying) protocol to bootstrap TESLA. As a side effect, MIKEY also provides a loose time synchronization feature from which TESLA can benefit. Other solutions, for instance, based on an extended session description, are possible, on the condition that these solutions provide the required security level.
例如，[RFC4442]描述了使用MIKEY（多媒体互联网密钥）协议引导特斯拉。作为一个副作用，MIKEY还提供了一个松散的时间同步功能，特斯拉可以从中受益。例如，基于扩展会话描述的其他解决方案是可能的，条件是这些解决方案提供所需的安全级别。
This specification describes an in-band mechanism. In some use cases, it might be desired that bootstrapping take place without requiring the use of an additional external mechanism. For instance, each device may feature a clock with a known time-drift that is negligible in front of the time accuracy required by TESLA, and each device may embed the public key of the sender. It is also possible that the use case does not feature a bidirectional channel that prevents the use of out-of-band protocols like MIKEY. For these two examples, the exchange of a bootstrap information message (described in Section 3.4.1) and the knowledge of a few additional parameters (listed below) are sufficient to bootstrap TESLA at a receiver.
本规范描述带内机构。在某些用例中，可能需要在不需要使用额外外部机制的情况下进行引导。例如，每个设备可以具有在特斯拉要求的时间精度之前可忽略的已知时间漂移的时钟，并且每个设备可以嵌入发送方的公钥。用例也可能没有双向通道，以防止使用像MIKEY这样的带外协议。对于这两个示例，引导信息消息的交换（如第3.4.1节所述）和一些附加参数的知识（如下所列）足以在接收器引导特斯拉。
Some parameters cannot be communicated in-band. In particular:
某些参数无法在频带内通信。特别地：
o the sender or group controller MUST either communicate the public key of the sender or a certificate (which also means that a PKI has been set up) to all receivers, so that each receiver be able to verify the signature of the bootstrap message and direct time synchronization response messages (when applicable).
o 发送方或组控制器必须将发送方的公钥或证书（这也意味着已建立PKI）传递给所有接收方，以便每个接收方能够验证引导消息和直接时间同步响应消息的签名（如果适用）。
o when time synchronization is performed with NTP/SNTP (Simple Network Time Protocol), the sender or group controller MUST communicate the list of valid NTP/SNTP servers to all the session members (sender included), so that they are all able to synchronize themselves on the same NTP/SNTP servers.
o 当使用NTP/SNTP（简单网络时间协议）执行时间同步时，发送方或组控制器必须将有效NTP/SNTP服务器的列表传达给所有会话成员（包括发送方），以便他们都能够在相同的NTP/SNTP服务器上同步自己。
o when the Group MAC feature is used, the sender or group controller MUST communicate the K_g group key to all the session members (sender included). This group key may be periodically refreshed.
o 使用组MAC功能时，发送方或组控制器必须将K_g组密钥传递给所有会话成员（包括发送方）。此组密钥可以定期刷新。
The way these parameters are communicated is out of the scope of this document.
这些参数的传达方式超出了本文件的范围。
The security offered by TESLA heavily relies on time. Therefore, the session's sender and each receiver need to be time synchronized in a secure way. To that purpose, two general methods exist:
特斯拉提供的安全性在很大程度上依赖于时间。因此，会话的发送方和每个接收方需要以安全的方式进行时间同步。为此目的，有两种通用方法：
o direct time synchronization, and
o 直接时间同步，以及
o indirect time synchronization.
o 间接时间同步。
It is also possible that a given session includes receivers that use the direct time synchronization mode while others use the indirect time synchronization mode.
给定会话还可能包括使用直接时间同步模式的接收机，而其他接收机使用间接时间同步模式。
When direct time synchronization is used, each receiver asks the sender for a time synchronization. To that purpose, a receiver sends a direct time synchronization request (Section 4.2.2.1). The sender then directly answers each request with a direct time synchronization response (Section 3.4.2), signing this reply. Upon receiving this response, a receiver first verifies the signature, and then calculates an upper bound of the lag of his clock with respect to the clock of the sender, D_t. The details on how to calculate D_t are given in Section 2.4.1.
当使用直接时间同步时，每个接收者都会要求发送者进行时间同步。为此，接收器发送直接时间同步请求（第4.2.2.1节）。然后，发送方通过直接时间同步响应（第3.4.2节）直接回答每个请求，并签署此回复。在接收到该响应后，接收方首先验证签名，然后计算其时钟相对于发送方时钟的延迟上限D_t。第2.4.1节给出了有关如何计算D_t的详细信息。
This synchronization method is both simple and secure. Yet, there are two potential issues:
这种同步方法既简单又安全。然而，有两个潜在问题：
o a bidirectional channel must exist between the sender and each receiver, and
o 发送方和每个接收方之间必须存在双向信道，并且
o the sender may collapse if the incoming request rate is too high.
o 如果传入请求速率过高，发送方可能崩溃。
Relying on direct time synchronization is not expected to be an issue with NORM since (1) bidirectional communications already take place, and (2) NORM scalability is anyway limited. Yet, it can be required that a mechanism, that is out of the scope of this document, be used to spread the transmission of direct time synchronization request messages over time if there is a risk that the sender may collapse.
依赖直接时间同步预计不会成为NORM的问题，因为（1）双向通信已经发生，（2）NORM的可伸缩性无论如何都是有限的。但是，如果存在发送方可能崩溃的风险，则可能需要使用一种不在本文档范围内的机制来随时间扩展直接时间同步请求消息的传输。
But direct time synchronization is potentially incompatible with ALC since (1) there might not be a back channel, and (2) there are potentially a huge number of receivers and therefore a risk that the sender will collapse.
但直接时间同步可能与ALC不兼容，因为（1）可能没有反向通道，（2）可能存在大量接收器，因此存在发送方崩溃的风险。
When indirect time synchronization is used, the sender and each receiver must synchronize securely via an external time reference. Several possibilities exist:
当使用间接时间同步时，发送方和每个接收方必须通过外部时间参考安全地同步。存在几种可能性：
o sender and receivers can synchronize through an NTPv3 (Network Time Protocol version 3) [RFC1305] hierarchy of servers. The authentication mechanism of NTPv3 MUST be used in order to authenticate each NTP message individually. It prevents, for instance, an attacker from impersonating an NTP server;
o 发送方和接收方可以通过服务器的NTPv3（网络时间协议版本3）[RFC1305]层次结构进行同步。必须使用NTPv3的身份验证机制来单独验证每个NTP消息。例如，它可以防止攻击者模拟NTP服务器；
o they can synchronize through an NTPv4 (Network Time Protocol version 4) [NTP-NTPv4] hierarchy of servers. The Autokey security protocol of NTPv4 MUST be used in order to authenticate each NTP message individually;
o 它们可以通过服务器的NTPv4（网络时间协议版本4）[NTP-NTPv4]层次结构进行同步。必须使用NTPv4的自动密钥安全协议来单独验证每个NTP消息；
o they can synchronize through an SNTPv4 (Simple Network Time Protocol version 4) [RFC4330] hierarchy of servers. The authentication features of SNTPv4 must then be used. Note that TESLA only needs a loose (but secure) time synchronization, which is in line with the time synchronization service offered by SNTP;
o 它们可以通过服务器的SNTPv4（简单网络时间协议版本4）[RFC4330]层次结构进行同步。然后必须使用SNTPv4的身份验证功能。请注意，特斯拉只需要松散（但安全）的时间同步，这符合SNTP提供的时间同步服务；
o they can synchronize through a GPS or Galileo (or similar) device that also provides a high precision time reference. Spoofing attacks on the GPS system have recently been reported. Depending on the use case, the security achieved will or will not be acceptable;
o 它们可以通过GPS或伽利略（或类似）设备进行同步，该设备也可以提供高精度的时间基准。最近有报道称对GPS系统进行了欺骗攻击。根据用例，实现的安全性将被接受或不被接受；
o they can synchronize thanks to a dedicated hardware, embedded on each sender and receiver, that provides a clock with a time-drift that is negligible in front of the TESLA time accuracy requirements. This feature enables a device to synchronize its embedded clock with the official time reference from time to time (in an extreme case once, at manufacturing time), and then to remain autonomous for a duration that depends on the known maximum clock drift.
o 由于在每个发送器和接收器上嵌入了专用硬件，它们可以进行同步，该硬件提供的时钟的时间漂移在特斯拉时间精度要求之前可以忽略不计。此功能使设备能够不时地（在极端情况下，在制造时一次）将其嵌入式时钟与官方时间基准同步，然后根据已知的最大时钟漂移在一段时间内保持自主。
A bidirectional channel is required by the NTP/SNTP schemes. On the opposite, with the GPS/Galileo and high precision clock schemes, no such assumption is made. In situations where ALC is used on purely unidirectional transport channels (Section 2.1), using the NTP/SNTP schemes is not possible. Another aspect is the scalability requirement of ALC, and to a lesser extent of NORM. From this point of view, the above mechanisms usually do not raise any problem, unlike the direct time synchronization schemes. Therefore, using indirect time synchronization can be a good choice. It should be noted that the NTP/SNTP schemes assume that each client trusts the sender and accepts aligning its NTP/SNTP configuration to that of the sender. If this assumption does not hold, the sender SHOULD offer an alternative solution.
NTP/SNTP方案需要双向信道。相反，在GPS/Galileo和高精度时钟方案中，没有做出这样的假设。在纯单向传输信道上使用ALC的情况下（第2.1节），不可能使用NTP/SNTP方案。另一个方面是ALC的可伸缩性需求，在较小程度上是标准的。从这个角度来看，与直接时间同步方案不同，上述机制通常不会引起任何问题。因此，使用间接时间同步是一个不错的选择。应该注意的是，NTP/SNTP方案假设每个客户端都信任发送方，并接受将其NTP/SNTP配置与发送方的配置对齐。如果这一假设不成立，发送方应提供另一种解决方案。
The details on how to calculate an upper bound of the lag of a receiver's clock with respect to the clock of the sender, D_t, are given in Section 2.4.2.
第2.4.2节详细介绍了如何计算接收器时钟相对于发送器时钟的延迟上限D_t。
Let us assume that a secure time synchronization has been set up. This section explains how to define the various timing parameters that are used during the authentication of received packets.
假设已经设置了安全的时间同步。本节说明如何定义在对接收到的数据包进行身份验证期间使用的各种定时参数。
In direct time synchronization mode, synchronization between a receiver and the sender follows the following protocol [RFC4082]:
在直接时间同步模式下，接收器和发送器之间的同步遵循以下协议[RFC4082]：
o The receiver sends a direct time synchronization request message to the sender, that includes t_r, the receiver local time at the moment of sending (Section 4.2.2.1).
o 接收方向发送方发送直接时间同步请求消息，其中包括发送时的接收方本地时间（第4.2.2.1节）。
o Upon receipt of this message, the sender records its local time, t_s, and sends to the receiver a direct time synchronization response that includes t_r (taken from the request) and t_s, signing this reply (Section 3.4.2).
o 收到此消息后，发送方记录其本地时间t_s，并向接收方发送一个直接时间同步响应，该响应包括t_r（取自请求）和t_s，并签署此回复（第3.4.2节）。
o Upon receiving this response, the receiver first verifies that he actually sent a request with t_r and then checks the signature. Then he calculates D_t = t_s - t_r + S_sr, where S_sr is an estimated bound of the clock drift between the sender and the receiver throughout the duration of the session. This document does not specify how S_sr is estimated.
o 在收到此响应后，接收方首先验证他是否确实发送了带有t_r的请求，然后检查签名。然后，他计算D_t=t_s-t_r+s_sr，其中s_sr是整个会话期间发送方和接收方之间时钟漂移的估计界。本文件未说明S_sr的估算方法。
After this initial synchronization, at any point throughout the session, the receiver knows that: T_s < T_r + D_t, where T_s is the current time at the sender and T_r is the current time at the receiver.
在这个初始同步之后，在整个会话的任何一点上，接收方都知道：T_s<T_r+D_T，其中T_s是发送方的当前时间，T_r是接收方的当前时间。
In indirect time synchronization, the sender and the receivers must synchronize indirectly using one or several time references.
在间接时间同步中，发送方和接收方必须使用一个或多个时间参考间接同步。
Let us assume that there is a single time reference.
让我们假设有一个单一的时间参考。
1. The sender calculates D^O_t, the upper bound of the lag of the sender's clock with respect to the time reference. This D^O_t value is then communicated to the receivers (Section 3.2.1).
1. 发送方计算D^O\t，即发送方时钟相对于时间基准滞后的上限。然后将该D^O\t值传达给接收器（第3.2.1节）。
2. Similarly, a receiver R calculates D^R_t, the upper bound of the lag of the receiver's clock with respect to the time reference.
2. 类似地，接收器R计算D^R\t，即接收器时钟相对于时间基准的延迟的上限。
3. Then, for receiver R, the overall upper bound of the lag of the receiver's clock with respect to the clock of the sender, D_t, is the sum: D_t = D^O_t + D^R_t.
3. 然后，对于接收器R，接收器时钟相对于发送器时钟的滞后的总上限D_t为和：D_t=D^O_t+D^R_t。
The D^O_t and D^R_t calculation depends on the time synchronization mechanism used (Section 2.3.2). In some cases, the synchronization scheme specifications provide these values. In other cases, these parameters can be calculated by means of a scheme similar to the one specified in Section 2.4.1, for instance, when synchronization is achieved via a group controller [RFC4082].
D^O\t和D^R\t的计算取决于所使用的时间同步机制（第2.3.2节）。在某些情况下，同步方案规范提供这些值。在其他情况下，可通过类似于第2.4.1节规定的方案计算这些参数，例如，通过组控制器实现同步[RFC4082]。
Let us now assume that there are several time references (e.g., several NTP/SNTP servers). The sender and receivers first synchronize with the various time references, independently. It results in D^O_t and D^R_t. Let D_err be an upper bound of the time error between all of the time references. Then, the overall value of D_t within receiver R is set to the sum: D_t = D^O_t + D^R_t + D_err.
现在让我们假设存在多个时间参考（例如，多个NTP/SNTP服务器）。发送方和接收方首先独立地与各种时间参考同步。它会导致D^O\t和D^R\t。设D_err为所有时间引用之间的时间误差上限。然后，接收器R内的D_t的总值被设置为总和：D_t=D^O_t+D^R_t+D_err。
In some cases, the D_t value is part of the time synchronization scheme specifications. For instance, NTPv3 [RFC1305] defines algorithms that are "capable of accuracies in the order of a millisecond, even after extended periods when synchronization to primary reference sources has been lost". In practice, depending on the NTP server stratum, the accuracy might be a little bit worse. In that case, D_t = security_factor * (1ms + 1ms), where the security_factor is meant to compensate several sources of inaccuracy in NTP. The choice of the security_factor value is left to the implementer, depending on the target use case.
在某些情况下，D_t值是时间同步方案规范的一部分。例如，NTPv3[RFC1305]定义了“即使在与主要参考源失去同步的延长时间之后，也能达到毫秒级精度”的算法。实际上，根据NTP服务器层的不同，准确性可能会稍差一些。在这种情况下，D_t=安全系数*（1ms+1ms），其中安全系数用于补偿NTP中的多个不准确源。安全系数值的选择留给实现者，具体取决于目标用例。
The F (resp. F') function output length is given by the n_p (resp. n_f) parameter. The n_p and n_f values depend on the PRF function chosen, as specified below:
F（resp.F'）函数输出长度由n_p（resp.n_F）参数给出。n_p和n_f值取决于所选的PRF函数，如下所述：
+------------------------+---------------------+
| PRF name | n_p and n_f |
+------------------------+---------------------+
| HMAC-SHA-1 | 160 bits (20 bytes) |
| HMAC-SHA-224 | 224 bits (28 bytes) |
| HMAC-SHA-256 (default) | 256 bits (32 bytes) |
| HMAC-SHA-384 | 384 bits (48 bytes) |
| HMAC-SHA-512 | 512 bits (64 bytes) |
+------------------------+---------------------+
+------------------------+---------------------+
| PRF name | n_p and n_f |
+------------------------+---------------------+
| HMAC-SHA-1 | 160 bits (20 bytes) |
| HMAC-SHA-224 | 224 bits (28 bytes) |
| HMAC-SHA-256 (default) | 256 bits (32 bytes) |
| HMAC-SHA-384 | 384 bits (48 bytes) |
| HMAC-SHA-512 | 512 bits (64 bytes) |
+------------------------+---------------------+
The computing of regular MAC (resp. Group MAC) makes use of the n_m (resp. n_w) parameter, i.e., the length of the truncated output of the function. The n_m and n_w values depend on the MAC function chosen, as specified below:
正则MAC（resp.Group MAC）的计算利用n_m（resp.n_w）参数，即函数的截断输出的长度。n_m和n_w值取决于所选的MAC函数，如下所述：
+------------------------+---------------------+-------------------+
| MAC name | n_m (regular MAC) | n_w (Group MAC) |
+------------------------+---------------------+-------------------+
| HMAC-SHA-1 | 80 bits (10 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-224 | 112 bits (14 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-256 (default) | 128 bits (16 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-384 | 192 bits (24 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-512 | 256 bits (32 bytes) | 32 bits (4 bytes) |
+------------------------+---------------------+-------------------+
+------------------------+---------------------+-------------------+
| MAC name | n_m (regular MAC) | n_w (Group MAC) |
+------------------------+---------------------+-------------------+
| HMAC-SHA-1 | 80 bits (10 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-224 | 112 bits (14 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-256 (default) | 128 bits (16 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-384 | 192 bits (24 bytes) | 32 bits (4 bytes) |
| HMAC-SHA-512 | 256 bits (32 bytes) | 32 bits (4 bytes) |
+------------------------+---------------------+-------------------+
This section describes the TESLA operations at a sender. For more information on the TESLA protocol and its principles, please refer to [RFC4082][Perrig04].
本节描述了特斯拉在发送方的操作。有关特斯拉协议及其原则的更多信息，请参考[RFC4082][Perrig04]。
The sender divides the time into uniform intervals of duration T_int. Time interval numbering starts at 0 and is incremented consecutively. The interval index MUST be stored in an unsigned 32-bit integer so that wrapping to 0 takes place only after 2^^32 intervals. For instance, if T_int is equal to 0.5 seconds, then wrapping takes place after approximately 68 years.
发送方将时间划分为持续时间T_int的统一间隔。时间间隔编号从0开始，并连续递增。间隔索引必须存储在无符号32位整数中，以便仅在2^^32个间隔后才会换行到0。例如，如果T_int等于0.5秒，则包装将在大约68年后进行。
The sender computes a one-way key chain of n_c = N+1 keys, and assigns one key from the chain to each interval, consecutively but in reverse order. Key numbering starts at 0 and is incremented consecutively, following the time interval numbering: K_0, K_1, ..., K_N.
发送方计算n_c=n+1个密钥的单向密钥链，并将该链中的一个密钥按相反顺序连续分配给每个间隔。密钥编号从0开始，并在时间间隔编号之后连续递增：K_0，K_1，…，K_N。
In order to compute this chain, the sender must first select a Primary Key, K_N, and a PRF function, f (Section 7, TESLA-PRF). The randomness of the Primary Key, K_N, is vital to the security and no one should be able to guess it.
为了计算该链，发送方必须首先选择主键K_N和PRF函数f（第7节，特斯拉-PRF）。主键K_N的随机性对安全性至关重要，任何人都不应该猜到它。
The function F is a one-way function that is defined as: F(k) = f_k(0), where f_k(0) is the result of the application of the PRF f to k and 0. When f is an HMAC (Section 7), k is used as the key, and 0 as the message, using the algorithm described in [RFC2104].
函数F是一个单向函数，其定义为：F（k）=F_k（0），其中F_k（0）是将PRF应用于k和0的结果。当f是HMAC（第7节）时，使用[RFC2104]中描述的算法，k用作密钥，0用作消息。
Similarly, the function F' is a one-way function that is defined as: F'(k) = f_k(1), where f_k(1) is the result of the application of the same PRF f to k and 1.
类似地，函数F'是定义为：F’（k）=F_k（1）的单向函数，其中F_k（1）是将相同的PRF应用于k和1的结果。
The sender then computes all the keys of the chain, recursively, starting with K_N, using: K_{i-1} = F(K_i). Therefore, K_i = F^{N-i}(K_N), where F^i(x) is the execution of function F with the argument x, i times. The receiver can then compute any value in the key chain from K_N, even if it does not have intermediate values [RFC4082]. The key for MAC calculation can then be derived from the corresponding K_i key by K'_i = F'(K_i).
然后，发送方使用：K_{i-1}=F（K_i）递归地从K_N开始计算链的所有键。因此，K_i=F^{N-i}（K_N），其中F^i（x）是带参数x的函数F的执行，i次。然后，接收方可以从K_N计算密钥链中的任何值，即使它没有中间值[RFC4082]。然后，可以通过K''u i＝F'（K_i）从相应的K_i密钥导出用于MAC计算的密钥。
The key chain has a finite length, N, which corresponds to a maximum
time duration of (N + 1) * T_int. The content delivery session has a
duration T_delivery, which may either be known in advance, or not. A
first solution consists in having a single key chain of an
appropriate length, so that the content delivery session finishes
before the end of the key chain, i.e., T_delivery <= (N + 1) * T_int.
But the longer the key chain, the higher the memory and computation
required to cope with it. Another solution consists in switching to
a new key chain, of the same length, when necessary [Perrig04].
The key chain has a finite length, N, which corresponds to a maximum
time duration of (N + 1) * T_int. The content delivery session has a
duration T_delivery, which may either be known in advance, or not. A
first solution consists in having a single key chain of an
appropriate length, so that the content delivery session finishes
before the end of the key chain, i.e., T_delivery <= (N + 1) * T_int.
But the longer the key chain, the higher the memory and computation
required to cope with it. Another solution consists in switching to
a new key chain, of the same length, when necessary [Perrig04].
When several key chains are needed, all of them MUST be of the same length. Switching from the current key chain to the next one requires that a commitment to the new key chain be communicated in a secure way to the receiver. This can be done by using either an out-of-band mechanism or an in-band mechanism. This document only specifies the in-band mechanism.
当需要多个钥匙链时，所有钥匙链的长度必须相同。从当前密钥链切换到下一个密钥链需要以安全的方式向接收方传达对新密钥链的承诺。这可以通过使用带外机制或带内机制来实现。本文档仅指定带内机制。
< -------- old key chain --------- >||< -------- new key chain --...
+-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+
0 1 .. N-2 N-1 N || N+1 N+2 N+3 N+4 N+5
||
Key disclosures: ||
N/A N/A .. K_N-4 K_N-3 K_N-2 || K_N-1 K_N K_N+1 K_N+2 K_N+3
| || | |
|< -------------- >|| |< ------------- >|
Additional key F(K_N+1) || K_N
disclosures (commitment to || (last key of the
(in parallel): the new chain) || old chain)
< -------- old key chain --------- >||< -------- new key chain --...
+-----+-----+ .. +-----+-----+-----+||+-----+-----+-----+-----+-----+
0 1 .. N-2 N-1 N || N+1 N+2 N+3 N+4 N+5
||
Key disclosures: ||
N/A N/A .. K_N-4 K_N-3 K_N-2 || K_N-1 K_N K_N+1 K_N+2 K_N+3
| || | |
|< -------------- >|| |< ------------- >|
Additional key F(K_N+1) || K_N
disclosures (commitment to || (last key of the
(in parallel): the new chain) || old chain)
Figure 1: Switching to the Second Key Chain with the In-Band
Mechanism, Assuming That d=2, n_tx_newkcc=3, n_tx_lastkey=3
Figure 1: Switching to the Second Key Chain with the In-Band
Mechanism, Assuming That d=2, n_tx_newkcc=3, n_tx_lastkey=3
Figure 1 illustrates the switch to the new key chain, using the in-band mechanism. Let us say that the old key chain stops at K_N and the new key chain starts at K_{N+1} (i.e., F(K_{N+1}) and K_N are two different keys). Then, the sender includes the commitment F(K_{N+1}) to the new key chain into packets authenticated with the old key chain (see Section 3.4.5). This commitment SHOULD be sent during n_tx_newkcc time intervals before the end of the old key chain. Since several packets are usually sent during an interval, the sender SHOULD alternate between sending a disclosed key of the old key chain and the commitment to the new key chain. The details of how to alternate between the disclosure and commitment are out of the scope of this document.
图1显示了使用带内机制切换到新密钥链的过程。假设旧的密钥链在K_N处停止，新的密钥链从K_{N+1}处开始（即F（K_{N+1}）和K_N是两个不同的密钥）。然后，发送方将对新密钥链的承诺F（K_{N+1}）包含到使用旧密钥链进行身份验证的数据包中（参见第3.4.5节）。此承诺应在旧密钥链结束之前的n_tx_newkcc时间间隔内发送。由于通常在一个时间间隔内发送多个数据包，发送方应在发送旧密钥链的公开密钥和向新密钥链提交密钥之间进行切换。如何在披露和承诺之间交替的细节不在本文件范围内。
The receiver will keep the commitment until the key K_{N+1} is disclosed, at interval N+1+d. Then, the receiver will be able to test the validity of that key by computing F(K_{N+1}) and comparing it to the commitment.
接收机将保持承诺，直到以间隔N+1+d公开密钥K{N+1}。然后，接收器将能够通过计算F（K_{N+1}）并将其与承诺进行比较来测试该密钥的有效性。
When the key chain is changed, it becomes impossible to recover a previous key from the old key chain. This is a problem if the receiver lost the packets disclosing the last key of the old key chain. A solution consists in re-sending the last key, K_N, of the old key chain (see Section 3.4.6). This SHOULD be done during n_tx_lastkey additional time intervals after the end of the time interval where K_N is disclosed. Since several packets are usually sent during an interval, the sender SHOULD alternate between sending a disclosed key of the new key chain, and the last key of the old key chain. The details of how to alternate between the two disclosures are out of the scope of this document.
更改密钥链时，无法从旧密钥链恢复以前的密钥。如果接收方丢失了泄露旧密钥链最后一个密钥的数据包，则会出现此问题。解决方案包括重新发送旧钥匙链的最后一把钥匙K_N（见第3.4.6节）。这应该在公开K_n的时间间隔结束后的n_tx_lastkey额外时间间隔内完成。由于通常在一个时间间隔内发送多个数据包，发送方应交替发送新密钥链的公开密钥和旧密钥链的最后一个密钥。如何在这两种披露之间进行交替的详细信息不在本文件的范围内。
In some cases, a receiver having experienced a very long disconnection might have lost the commitment of the new chain. Therefore, this receiver will not be able to authenticate any packet related to the new chain or any of the following ones. The only solution for this receiver to catch up consists in receiving an additional bootstrap information message. This can happen by waiting for the next periodic transmission (if sent in-band) or through an external mechanism (Section 3.2.1).
在某些情况下，经历了长时间断开连接的接收者可能会失去新链的承诺。因此，此接收器将无法验证与新链或以下任何链相关的任何数据包。此接收器要赶上的唯一解决方案是接收额外的引导信息消息。这可以通过等待下一次定期传输（如果在频带内发送）或通过外部机制（第3.2.1节）实现。
When several key chains and the in-band commitment mechanism are used, a sender MUST initialize the n_tx_lastkey and n_tx_newkcc parameters in such a way that no overlapping occurs. In other words, once a sender starts transmitting commitments for a new key chain, he MUST NOT send a disclosure for the last key of the old key chain any more. Therefore, the following property MUST be verified:
当使用多个密钥链和带内承诺机制时，发送方必须初始化n_tx_lastkey和n_tx_newkcc参数，以确保不会发生重叠。换句话说，一旦发送方开始传输新密钥链的承诺，他就不能再发送旧密钥链的最后一个密钥的披露。因此，必须验证以下属性：
d + n_tx_lastkey + n_tx_newkcc <= N + 1
d + n_tx_lastkey + n_tx_newkcc <= N + 1
It is RECOMMENDED, for robustness purposes, that, once n_tx_lastkey has been chosen, then:
出于稳健性目的，建议选择n_tx_lastkey后：
n_tx_newkcc = N + 1 - n_tx_lastkey - d
n_tx_newkcc = N + 1 - n_tx_lastkey - d
In other words, the sender starts transmitting a commitment to the following key chain immediately after having sent all the disclosures of the last key of the previous key chain. Doing so increases the probability that a receiver gets a commitment for the following key chain.
换句话说，发送方在发送了前一个密钥链的最后一个密钥的所有公开信息后，立即开始向下一个密钥链发送承诺。这样做会增加接收者获得以下密钥链承诺的概率。
In any case, these two parameters are sender specific and need not be transmitted to the receivers. Of course, as explained above, the sender alternates between the disclosure of a key of the current key chain and the commitment to the new key chain (or the last key of the old key chain).
在任何情况下，这两个参数都是特定于发送方的，不需要发送给接收方。当然，如上所述，发送方在公开当前密钥链的密钥和承诺新密钥链（或旧密钥链的最后一个密钥）之间进行交替。
Since a key cannot be disclosed before the disclosure delay, d, no key will be disclosed during the first d time intervals (intervals 0 and 1 in Figure 1) of the session. To that purpose, the sender uses the Authentication Tag without Key Disclosure, Section 3.4.4. The following key chains, if any, are not concerned since they will disclose the last d keys of the previous chain.
由于在公开延迟d之前不能公开密钥，因此在会话的第一个d时间间隔（图1中的间隔0和1）期间不会公开密钥。为此，发送方使用身份验证标签而不泄露密钥，见第3.4.4节。以下钥匙链（如果有）不受关注，因为它们将公开前一个钥匙链的最后一个d钥匙。
An ALC or NORM sender may stop transmitting packets for some time. For instance, it can be the end of the session and all packets have already been sent, or the use case may consist in a succession of busy periods (when fresh objects are available) followed by silent periods. In any case, this is an issue since the authentication of the packets sent during the last d intervals requires that the associated keys be disclosed, which will take place during d additional time intervals.
ALC或NORM发送方可能会停止发送数据包一段时间。例如，它可以是会话的结束，并且所有的数据包都已经被发送，或者用例可能包括一系列的繁忙时段（当新对象可用时），然后是静默时段。在任何情况下，这都是一个问题，因为在最后d个间隔期间发送的分组的认证要求公开相关联的密钥，这将在d个额外的时间间隔期间发生。
To solve this problem, it is recommended that the sender transmit empty packets (i.e., without payload) containing the TESLA EXT_AUTH Header Extension along with a Standard Authentication Tag during at least d time intervals after the end of the regular ALC or NORM packet transmissions. The number of such packets and the duration during which they are sent must be sufficient for all receivers to receive, with a high probability, at least one packet disclosing the last useful key (i.e., the key used for the last non-empty packet sent).
为解决此问题，建议发送方在常规ALC或NORM数据包传输结束后的至少d个时间间隔内传输包含TESLA EXT_AUTH报头扩展的空数据包（即，无有效负载）以及标准认证标签。此类分组的数量和发送它们的持续时间必须足以使所有接收机以高概率接收至少一个分组，该分组公开最后一个有用密钥（即，用于发送的最后一个非空分组的密钥）。
The sender must determine the following parameters:
发送方必须确定以下参数：
o T_0, the start time corresponding to the beginning of the session, i.e., the beginning of time interval 0 (in NTP timestamp format);
o T_0，对应于会话开始的开始时间，即时间间隔0的开始（以NTP时间戳格式）；
o T_int, the interval duration (in milliseconds), usually ranging from 100 milliseconds to 1 second;
o T_int，间隔持续时间（毫秒），通常从100毫秒到1秒不等；
o d, the key disclosure delay (in number of intervals). It is the time to wait before disclosing a key;
o d、 密钥泄漏延迟（以间隔数表示）。这是在公开密钥之前等待的时间；
o N, the length of a key chain.
o N、 钥匙链的长度。
The correct choice of T_int, d, and N is crucial for the efficiency of the scheme. For instance, a T_int * d product that is too long will cause excessive delay in the authentication process. A T_int * d product that is too short prevents many receivers from verifying packets. An N * T_int product that is too small will cause the sender to switch too often to new key chains. An N that is too long with respect to the expected session duration (if known) will require the sender to compute too many useless keys. Sections 3.2 and 3.6 of [RFC4082] give general guidelines for initializing these parameters.
T_int、d和N的正确选择对方案的效率至关重要。例如，过长的T_int*d产品将导致身份验证过程中的过度延迟。太短的T_int*d产品会阻止许多接收器验证数据包。太小的N*T_int产品会导致发送者频繁切换到新的密钥链。相对于预期会话持续时间（如果已知）太长的N将要求发送方计算太多无用密钥。[RFC4082]第3.2节和第3.6节给出了初始化这些参数的一般指南。
The T_0, T_int, d, and N parameters MUST NOT be changed during the lifetime of the session. This restriction is meant to prevent introducing vulnerabilities. For instance, if a sender was authorized to change the key disclosure schedule, a receiver that did not receive the change notification would still believe in the old key disclosure schedule, thereby creating vulnerabilities [RFC4082].
在会话的生存期内，不得更改T_0、T_int、d和N参数。此限制旨在防止引入漏洞。例如，如果发送方被授权更改密钥披露计划，未收到更改通知的接收方仍会相信旧的密钥披露计划，从而产生漏洞[RFC4082]。
In indirect time synchronization mode, the sender must determine the following parameter:
在间接时间同步模式下，发送方必须确定以下参数：
o D^O_t, the upper bound of the lag of the sender's clock with respect to the time reference.
o D^O\t，发送方时钟相对于时间基准滞后的上限。
The D^O_t parameter MUST NOT be changed during the lifetime of the session.
在会话的生存期内，不得更改D^O\t参数。
At a sender, TESLA produces two types of signaling information:
在发送方，特斯拉产生两种类型的信令信息：
o The bootstrap information: it can be either sent out-of-band or in-band. In the latter case, a digitally signed packet contains all the information required to bootstrap TESLA at a receiver;
o 引导信息：可以带外发送，也可以带内发送。在后一种情况下，数字签名数据包包含在接收器引导特斯拉所需的所有信息；
o The direct time synchronization response, which enables a receiver to finish a direct time synchronization.
o 直接时间同步响应，使接收器能够完成直接时间同步。
In order to initialize the TESLA component at a receiver, the sender must communicate some key information in a secure way. This information can be sent in-band or out-of-band, as discussed in Section 2.2. In this section, we only consider the in-band scheme.
为了在接收方初始化特斯拉组件，发送方必须以安全的方式传递一些关键信息。如第2.2节所述，该信息可以带内或带外发送。在本节中，我们只考虑带内方案。
The TESLA bootstrap information message MUST be digitally signed (Section 3.3.2). The goal is to enable a receiver to check the packet source and packet integrity. Then, the bootstrap information can be:
特斯拉自举信息报文必须经过数字签名（第3.3.2节）。目标是使接收器能够检查数据包源和数据包完整性。然后，引导信息可以是：
o unicast to a receiver during a direct time synchronization request/response exchange;
o 在直接时间同步请求/响应交换期间单播到接收机；
o broadcast to all receivers. This is typically the case in indirect time synchronization mode. It can also be used in direct time synchronization mode, for instance, when a large number of clients arrive at the same time, in which case it is more efficient to answer globally.
o 向所有接收者广播。这通常是间接时间同步模式中的情况。它还可以用于直接时间同步模式，例如，当大量客户端同时到达时，在这种情况下，全局应答更有效。
Let us consider situations where the bootstrap information is broadcast. This message should be broadcast at the beginning of the session, before data packets are actually sent. This is particularly important with ALC or NORM sessions in "push" mode, when all clients join the session in advance. For improved reliability, bootstrap information might be sent a certain number of times.
让我们考虑广播引导信息的情况。此消息应在会话开始时广播，然后再实际发送数据包。在ALC或NORM会话处于“推送”模式时，当所有客户端提前加入会话时，这一点尤为重要。为了提高可靠性，引导信息可能会被发送一定次数。
A periodic broadcast of the bootstrap information message could also be useful when:
在以下情况下，引导信息消息的定期广播也很有用：
o the ALC session uses an "on-demand" mode, clients arriving at their own discretion;
o ALC会议采用“按需”模式，客户自行决定是否到达；
o some clients experience an intermittent connectivity. This is particularly important when several key chains are used in an ALC or NORM session, since there is a risk that a receiver loses all the commitments to the new key chain.
o 有些客户端会遇到间歇性连接。当ALC或NORM会话中使用多个密钥链时，这一点尤为重要，因为存在接收者失去对新密钥链的所有承诺的风险。
A balance must be found between the signaling overhead and the maximum initial waiting time at the receiver before starting the delayed authentication process. A period of a few seconds for the transmission of this bootstrap information is often a reasonable value.
在开始延迟认证过程之前，必须在信令开销和接收器处的最大初始等待时间之间找到平衡。传输此引导信息的几秒钟时间通常是一个合理的值。
In direct time synchronization, upon receipt of a synchronization request, the sender records its local time, t_s, and sends a response message that contains both t_r and t_s (Section 2.4.1). This message is unicast to the receiver. This direct time synchronization response message MUST be digitally signed in order to enable a receiver to check the packet source and packet integrity (Section 3.3.2). The receiver MUST also be able to associate this response and his request, which is the reason why t_r is included in the response message.
在直接时间同步中，在收到同步请求后，发送方记录其本地时间t_s，并发送包含t_r和t_s的响应消息（第2.4.1节）。此消息是单播到接收器的。必须对该直接时间同步响应消息进行数字签名，以使接收器能够检查数据包源和数据包完整性（第3.3.2节）。接收者还必须能够将此响应与他的请求关联起来，这就是响应消息中包含t_r的原因。
At a sender, TESLA produces three types of security tags:
在发送方，特斯拉生产三种类型的安全标签：
o an authentication tag, in case of data packets, and which contains the MAC of the packet;
o 在数据分组的情况下，认证标签，其包含分组的MAC；
o a digital signature, in case of one of the two TESLA signaling packets, namely a bootstrap information message or a direct time synchronization response; and
o 在两个TESLA信令分组之一的情况下，数字签名，即引导信息消息或直接时间同步响应；和
o an optional group authentication tag, that can be added to all the packets to mitigate attacks coming from outside of the group.
o 可选的组身份验证标签，可添加到所有数据包中，以减轻来自组外的攻击。
Because of interdependencies, their computation MUST follow a strict order:
由于相互依赖性，它们的计算必须遵循严格的顺序：
o first of all, compute the authentication tag (with data packet) or the digital signature (with signaling packet);
o 首先，计算认证标签（带数据包）或数字签名（带信令包）；
o finally, compute the Group Mac.
o 最后，计算组Mac。
All the data packets sent MUST have an authentication tag containing:
所有发送的数据包都必须有一个身份验证标签，其中包含：
o the interval index, i, which is also the index of the key used for computing the MAC of this packet;
o 区间索引i，它也是用于计算该分组的MAC的密钥的索引；
o the MAC of the message: MAC(K'_i, M), where K'_i=F'(K_i);
o 消息的MAC:MAC（K''ui，M），其中K''ui=F'（K''ui）；
o either a disclosed key (which belongs to the current key chain or the previous key chain), or a commitment to a new key chain, or no key at all.
o 公开的密钥（属于当前密钥链或以前的密钥链）或对新密钥链的承诺，或者根本没有密钥。
The computation of MAC(K'_i, M) MUST include the ALC or NORM header (with the various header extensions) and the payload (when applicable). The UDP/IP headers MUST NOT be included. During this computation, the "MAC(K'_i, M)" field of the authentication tag MUST be set to 0.
MAC（K〃u i，M）的计算必须包括ALC或NORM报头（具有各种报头扩展）和有效载荷（如适用）。不得包含UDP/IP标头。在此计算过程中，身份验证标签的“MAC（K’’i，M）”字段必须设置为0。
The bootstrap information message (with the in-band bootstrap scheme) and direct time synchronization response message (with the indirect time synchronization scheme) both need to be signed by the sender. These two messages contain a "Signature" field to hold the digital signature. The bootstrap information message also contains the "Signature Encoding Algorithm", the "Signature Cryptographic Function", and the "Signature Length" fields that enable a receiver to process the "Signature" field. Note that there are no such "Signature Encoding Algorithm", "Signature Cryptographic Function", and "Signature Length" fields in the case of a direct time synchronization response message since it is assumed that these parameters are already known (i.e., the receiver either received a bootstrap information message before or these values have been communicated out-of-band).
引导信息消息（带内引导方案）和直接时间同步响应消息（带间接时间同步方案）都需要发送方签名。这两条消息包含用于保存数字签名的“签名”字段。引导信息消息还包含“签名编码算法”、“签名加密函数”和“签名长度”字段，使接收方能够处理“签名”字段。注意，在直接时间同步响应消息的情况下，不存在这样的“签名编码算法”、“签名加密函数”和“签名长度”字段，因为假设这些参数已经已知（即，接收机在接收到引导信息消息之前或这些值已在带外通信）。
Several "Signature Encoding Algorithms" can be used, including RSASSA-PKCS1-v1_5, the default, and RSASSA-PSS (Section 7). With these encodings, SHA-256 is the default "Signature Cryptographic Function".
可以使用几种“签名编码算法”，包括RSASSA-PKCS1-v1_5（默认值）和RSASSA-PSS（第7节）。通过这些编码，SHA-256是默认的“签名加密函数”。
The computation of the signature MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP headers MUST NOT be included. During this computation, the "Signature" field MUST be set to 0 as well as the optional Group MAC, when present, since this Group MAC is calculated later.
签名的计算必须包括ALC或NORM报头（具有各种报头扩展）和有效载荷（如果适用）。不得包含UDP/IP标头。在该计算过程中，“签名”字段必须设置为0，以及可选组MAC（如果存在），因为该组MAC是稍后计算的。
More specifically, from [RFC4359]: Digital signature generation is performed as described in [RFC3447], Section 8.2.1 for RSASSA-PKCS1- v1_5 and Section 8.1.1 for 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]、第8.2.1节（适用于RSASSA-PKCS1-v1_5）和第8.1.1节（适用于RSASSA-PSS）中的说明生成数字签名。分组的认证部分用作消息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 signature MUST be prepended with between 1 and 7 bits set to zero such that the signature is a multiple of 8 bits [RFC4359]. The key size, 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 out of the scope of this document.
对于RSASSA-PKCS1-v1_5和RSASSA-PSS签名，签名的大小等于“RSA模”，除非“RSA模”不是8位的倍数。在这种情况下，签名必须在1到7位之间设置为零，以便签名是8位的倍数[RFC4359]。密钥大小实际上也等于“RSA模数”，具有重要的安全含义。[RFC4359]解释如何根据会话的最大预期生存期选择此值。此选项不在本文档的范围内。
An optional Group MAC can be used to mitigate Denial-of-Service (DoS) attacks coming from attackers that are not group members [RFC4082]. This feature assumes that a group key, K_g, is shared by the sender and all receivers. When the attacker is not a group member, the benefits of adding a Group MAC to every packet sent are threefold:
可选的组MAC可用于缓解来自非组成员的攻击者的拒绝服务（DoS）攻击[RFC4082]。此功能假定组密钥K_g由发送方和所有接收方共享。当攻击者不是组成员时，向发送的每个数据包添加组MAC的好处有三个：
o a receiver can immediately drop faked packets, without having to wait for the disclosure delay, d;
o 接收机可以立即丢弃伪造的分组，而不必等待公开延迟d；
o a sender can immediately drop faked direct time synchronization requests, and avoid checking the digital signature, a computation intensive task;
o 发送方可以立即丢弃伪造的直接时间同步请求，并避免检查数字签名，这是一项计算密集型任务；
o a receiver can immediately drop faked direct time synchronization response and bootstrap messages, without having to verify the digital signature, a computation-intensive task.
o 接收器可以立即丢弃伪造的直接时间同步响应和引导消息，而无需验证数字签名，这是一项计算密集型任务。
The computation of the Group MAC, MAC(K_g, M), MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP headers MUST NOT be included. During this computation, the "Group MAC" field MUST be set to 0. However, the digital signature (e.g., of a bootstrap message) and the "MAC" fields (e.g., of an authentication tag), when present, MUST have been
The computation of the Group MAC, MAC(K_g, M), MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP headers MUST NOT be included. During this computation, the "Group MAC" field MUST be set to 0. However, the digital signature (e.g., of a bootstrap message) and the "MAC" fields (e.g., of an authentication tag), when present, MUST have beentranslate error, please retry
calculated since they are included in the Group MAC calculation itself. Then, the sender truncates the MAC output to keep the n_w most significant bits and stores the result in the "Group MAC" field.
calculated since they are included in the Group MAC calculation itself. Then, the sender truncates the MAC output to keep the n_w most significant bits and stores the result in the "Group MAC" field.translate error, please retry
This scheme features a few limits:
该方案有几个限制：
o it is of no help if a group member (who knows K_g) impersonates the sender and sends forged messages to other receivers;
o 如果组成员（知道K_g）冒充发送者并向其他接收者发送伪造消息，则没有任何帮助；
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 TESLA authentication headers. In order to limit this problem, the length of the truncated output of the MAC, n_w, SHOULD be kept small (e.g., 32 bits) (see [RFC3711], Section 9.5). As a side effect, the authentication service is significantly weakened: the probability of any forged packet being successfully authenticated becomes one in 2^32. Since the Group MAC check is only a pre-check that must be followed by the standard TESLA authentication check, this is not considered to be an issue.
o 它增加了特斯拉认证头的大小。为了限制此问题，MAC的截断输出长度n_w应保持较小（例如32位）（参见[RFC3711]，第9.5节）。作为一个副作用，身份验证服务被大大削弱：任何伪造数据包被成功身份验证的概率变为1/2^32。由于组MAC检查只是一个必须遵循标准特斯拉认证检查的预检查，因此不认为这是一个问题。
For a given use case, the benefits brought by the Group MAC must be balanced against these limitations.
对于给定的用例，组MAC带来的好处必须与这些限制相平衡。
Note that the Group MAC function can be different from the TESLA MAC function (e.g., it can use a weaker but faster MAC function). Note also that the mechanism by which the group key, K_g, is communicated to all group members, and perhaps periodically updated, is out of the scope of this document.
请注意，组MAC功能可以不同于特斯拉MAC功能（例如，它可以使用较弱但较快的MAC功能）。还请注意，将组密钥K_g传递给所有组成员并可能定期更新的机制不在本文档的范围内。
This section specifies the format of the various kinds of TESLA messages and authentication tags sent by the session's sender. Because these TESLA messages are carried as EXT_AUTH Header Extensions of the ALC or NORM packets (Section 5), the following formats do not start on 32-bit word boundaries.
本节指定会话发送方发送的各种TESLA消息和身份验证标记的格式。由于这些特斯拉消息作为ALC或NORM数据包（第5节）的EXT_AUTH头扩展进行传输，因此以下格式不从32位字边界开始。
When bootstrap information is sent in-band, the following message is used:
在带内发送引导信息时，将使用以下消息：
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
+-+-+-+-+-+-+-+-+ ---
| V |resvd|S|G|A| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | PRF Type | MAC Func Type |Gr MAC Fun Type| | f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | i
| SigEncAlgo | SigCryptoFunc | Signature Length | | x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
| Reserved | T_int | | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | l
+ T_0 (NTP timestamp format) + | e
| | | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g
| N (Key Chain Length) | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h
| Current Interval Index i | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| |
~ Current Key Chain Commitment +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
~ Signature ~
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| |
+-+ D^O_t Extension (optional, present if A==1) +
| (NTP timestamp diff, positive if P==1, negative if P==0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+ ---
| V |resvd|S|G|A| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | PRF Type | MAC Func Type |Gr MAC Fun Type| | f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | i
| SigEncAlgo | SigCryptoFunc | Signature Length | | x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
| Reserved | T_int | | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | l
+ T_0 (NTP timestamp format) + | e
| | | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g
| N (Key Chain Length) | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h
| Current Interval Index i | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| |
~ Current Key Chain Commitment +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
~ Signature ~
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| |
+-+ D^O_t Extension (optional, present if A==1) +
| (NTP timestamp diff, positive if P==1, negative if P==0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Bootstrap Information Format
图2：引导信息格式
The format of the bootstrap information is depicted in Figure 2. The fields are:
引导信息的格式如图2所示。这些字段是：
"V" (Version) field (2 bits):
“V”（版本）字段（2位）：
The "V" field contains the version number of the protocol. For this specification, the value of 0 MUST be used.
“V”字段包含协议的版本号。对于本规范，必须使用0的值。
"Reserved" field (3 bits):
“保留”字段（3位）：
This is a reserved field that MUST be set to zero in this specification.
这是一个保留字段，在本规范中必须设置为零。
"S" (Single Key Chain) flag (1 bit):
“S”（单钥匙链）标志（1位）：
The "S" flag indicates whether this TESLA session is restricted to a single key chain (S==1) or relies on one or multiple key chains (S==0).
“S”标志表示该特斯拉会话是限于单个钥匙链（S==1）还是依赖于一个或多个钥匙链（S==0）。
"G" (Group MAC Present) flag (1 bit):
“G”（组MAC存在）标志（1位）：
The "G" flag indicates whether the Group MAC feature is used (G==1) or not (G==0). When it is used, a "Group MAC" field is added to all the packets containing a TESLA EXT_AUTH Header Extension (including this bootstrap message).
“G”标志指示是否使用组MAC功能（G==1）或不使用（G==0）。使用时，将向包含TESLA EXT_AUTH头扩展（包括此引导消息）的所有数据包添加一个“组MAC”字段。
"A" flag (1 bit):
“A”标志（1位）：
The "A" flag indicates whether the "P" flag and "D^O_t" fields are present (A==1) or not (A==0). In indirect time synchronization mode, A MUST be equal to 1 since these fields are needed.
“A”标志指示是否存在“P”标志和“D^O\t”字段（A==1）或（A==0）。在间接时间同步模式中，A必须等于1，因为需要这些字段。
"d" field (8 bits):
“d”字段（8位）：
"d" is an unsigned integer that defines the key disclosure delay (in number of intervals). d MUST be greater than or equal to 2.
“d”是一个无符号整数，用于定义密钥公开延迟（以间隔数为单位）。d必须大于或等于2。
"PRF Type" field (8 bits):
“PRF类型”字段（8位）：
The "PRF Type" is the reference number of the f function used to derive the F (for key chain) and F' (for MAC keys) functions (Section 7).
“PRF类型”是用于导出f（用于密钥链）和f（用于MAC密钥）函数的f函数的参考号（第7节）。
"MAC Function Type" field (8 bits):
“MAC功能类型”字段（8位）：
The "MAC Function Type" is the reference number of the function used to compute the MAC of the packets (Section 7).
“MAC函数类型”是用于计算分组的MAC的函数的参考号（第7节）。
"Group MAC Function Type" field (8 bits):
“组MAC功能类型”字段（8位）：
When G==1, this field contains the reference number of the cryptographic MAC function used to compute the Group MAC (Section 7). When G==0, this field MUST be set to zero.
当G==1时，此字段包含用于计算组MAC的加密MAC函数的参考号（第7节）。当G==0时，此字段必须设置为零。
"Signature Encoding Algorithm" field (8 bits):
“签名编码算法”字段（8位）：
The "Signature Encoding Algorithm" is the reference number (Section 7) of the digital signature used to authenticate this bootstrap information and included in the "Signature" field.
“签名编码算法”是数字签名的参考号（第7节），用于验证此引导信息，并包含在“签名”字段中。
"Signature Cryptographic Function" field (8 bits):
“签名加密功能”字段（8位）：
The "Signature Cryptographic Function" is the reference number (Section 7) of the cryptographic function used within the digital signature.
“签名加密函数”是数字签名中使用的加密函数的参考号（第7节）。
"Signature Length" field (16 bits):
“签名长度”字段（16位）：
The "Signature Length" is an unsigned integer that indicates the "Signature" field size in bytes in the "Signature Extension" field. This is also the signature key length, since both parameters are equal.
“签名长度”是一个无符号整数，表示“签名扩展名”字段中的“签名”字段大小（以字节为单位）。这也是签名密钥长度，因为两个参数相等。
"Reserved" fields (16 bits):
“保留”字段（16位）：
This is a reserved field that MUST be set to zero in this specification.
这是一个保留字段，在本规范中必须设置为零。
"T_int" field (16 bits):
“T_int”字段（16位）：
"T_int" is an unsigned 16-bit integer that defines the interval duration (in milliseconds).
“T_int”是一个无符号16位整数，用于定义间隔持续时间（以毫秒为单位）。
"T_0" field (64 bits):
“T_0”字段（64位）：
"T_0" is a timestamp in NTP timestamp format that indicates the beginning of the session, i.e., the beginning of time interval 0.
“T_0”是NTP时间戳格式的时间戳，表示会话的开始，即时间间隔0的开始。
"N" field (32 bits):
“N”字段（32位）：
"N" is an unsigned integer that indicates the key chain length. There are N + 1 keys per chain.
“N”是一个无符号整数，表示密钥链长度。每个链有N+1个键。
"i" (Interval Index of K_i) field (32 bits):
“i”（K_i的间隔索引）字段（32位）：
"i" is an unsigned integer that indicates the current interval index when this bootstrap information message is sent.
“i”是一个无符号整数，表示发送此引导信息消息时的当前间隔索引。
"Current Key Chain Commitment" field (variable size, padded if necessary for 32-bit word alignment):
“当前密钥链承诺”字段（可变大小，如果32位字对齐需要，则填充）：
"Key Chain Commitment" is the commitment to the current key chain, i.e., the key chain corresponding to interval i. For instance, with the first key chain, this commitment is equal to F(K_0), with the second key chain, this commitment is equal to F(K_{N+1}), etc.). If need be, this field is padded (with 0) up to a multiple of 32 bits.
“关键链承诺”是对当前关键链的承诺，即区间i对应的关键链。例如，对于第一个密钥链，这个承诺等于F（K_0），对于第二个密钥链，这个承诺等于F（K_{N+1}），等等。如果需要，此字段将被填充（0）到32位的倍数。
"Signature" field (variable size, padded if necessary for 32-bit word alignment):
“签名”字段（可变大小，如果32位字对齐需要填充）：
The "Signature" field is mandatory. It contains a digital signature of this message, as specified by the encoding algorithm, cryptographic function, and key length parameters. If the signature length is not a multiple of 32 bits, this field is padded with 0.
“签名”字段是必填字段。它包含此消息的数字签名，由编码算法、加密函数和密钥长度参数指定。如果签名长度不是32位的倍数，则此字段用0填充。
"P" flag (optional, 1 bit if present):
“P”标志（可选，如果存在，则为1位）：
The "P" flag is optional and only present if the "A" flag is equal to 1. It is only used in indirect time synchronization mode. This flag indicates whether the D^O_t NTP timestamp difference is positive (P==1) or negative (P==0).
“P”标志是可选的，仅当“A”标志等于1时才出现。它仅用于间接时间同步模式。此标志指示D^O\t NTP时间戳差是正（P==1）还是负（P==0）。
"D^O_t" field (optional, 63 bits if present):
“D^O_\t”字段（可选，如果存在63位）：
The "D^O_t" field is optional and only present if the "A" flag is equal to 1. It is only used in indirect time synchronization mode. It is the upper bound of the lag of the sender's clock with respect to the time reference. When several time references are specified (e.g., several NTP servers), then D^O_t is the maximum upper bound of the lag with each time reference. D^O_t is composed of two unsigned integers, as with NTP timestamps: the first 31 bits give the time difference in seconds and the remaining 32 bits give the sub-second time difference.
“D^O_t”字段是可选的，仅当“A”标志等于1时才出现。它仅用于间接时间同步模式。它是发送方时钟相对于时间基准滞后的上限。如果指定了多个时间参考（例如，多个NTP服务器），则D^O\t是每个时间参考的滞后的最大上限。与NTP时间戳一样，D^O\u t由两个无符号整数组成：前31位给出秒级时间差，其余32位给出亚秒级时间差。
"Group MAC" field (optional, variable length, multiple of 32 bits):
“组MAC”字段（可选，可变长度，32位的倍数）：
This field contains the Group MAC, calculated with the group key, K_g, shared by all group members. The field length, in bits, is given by n_w, which is known once the Group MAC function type is known (Section 7).
此字段包含由所有组成员共享的组密钥K_g计算的组MAC。字段长度（以位为单位）由n_w给出，一旦知道组MAC函数类型，就知道n_w（第7节）。
Note that the first byte and the following seven 32-bit words are mandatory fixed-length fields. The "Current Key Chain Commitment" and "Signature" fields are mandatory but variable-length fields. The remaining "D^O_t" and "Group MAC" fields are optional.
请注意，第一个字节和以下七个32位字是必填的固定长度字段。“当前密钥链承诺”和“签名”字段是必填字段，但长度可变。其余的“D^O_\t”和“组MAC”字段是可选的。
In order to prevent attacks, some parameters MUST NOT be changed during the lifetime of the session (Sections 3.1.3 and 3.1.4). The following table summarizes the parameter's status:
为了防止攻击，在会话的生存期内不得更改某些参数（第3.1.3节和第3.1.4节）。下表总结了参数的状态：
+--------------------------+----------------------------------------+
| Parameter | Status |
+--------------------------+----------------------------------------+
| V | set to 0 in this specification |
| S | static (during whole session) |
| G | static (during whole session) |
| A | static (during whole session) |
| T_O | static (during whole session) |
| T_int | static (during whole session) |
| d | static (during whole session) |
| N | static (during whole session) |
| D^O_t (if present) | static (during whole session) |
| PRF Type | static (during whole session) |
| MAC Function Type | static (during whole session) |
| Signature Encoding | static (during whole session) |
| Algorithm | |
| Signature Crypto. | static (during whole session) |
| Function | |
| Signature Length | static (during whole session) |
| Group MAC Func. Type | static (during whole session) |
| i | dynamic (related to current key chain) |
| K_i | dynamic (related to current key chain) |
| signature | dynamic, packet dependent |
| Group MAC (if present) | dynamic, packet dependent |
+--------------------------+----------------------------------------+
+--------------------------+----------------------------------------+
| Parameter | Status |
+--------------------------+----------------------------------------+
| V | set to 0 in this specification |
| S | static (during whole session) |
| G | static (during whole session) |
| A | static (during whole session) |
| T_O | static (during whole session) |
| T_int | static (during whole session) |
| d | static (during whole session) |
| N | static (during whole session) |
| D^O_t (if present) | static (during whole session) |
| PRF Type | static (during whole session) |
| MAC Function Type | static (during whole session) |
| Signature Encoding | static (during whole session) |
| Algorithm | |
| Signature Crypto. | static (during whole session) |
| Function | |
| Signature Length | static (during whole session) |
| Group MAC Func. Type | static (during whole session) |
| i | dynamic (related to current key chain) |
| K_i | dynamic (related to current key chain) |
| signature | dynamic, packet dependent |
| Group MAC (if present) | dynamic, packet dependent |
+--------------------------+----------------------------------------+
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_s (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
~ Signature ~
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_s (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
~ Signature ~
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of a Direct Time Synchronization Response
图3：直接时间同步响应的格式
The response to a direct time synchronization request contains the following information:
对直接时间同步请求的响应包含以下信息：
"Reserved" field (8 bits):
“保留”字段（8位）：
This is a reserved field that MUST be set to zero in this specification.
这是一个保留字段，在本规范中必须设置为零。
"t_s" (NTP timestamp, 64 bits):
“t_s”（NTP时间戳，64位）：
"t_s" is a timestamp in NTP timestamp format that corresponds to the sender local time value when receiving the direct time synchronization request message.
“t_s”是NTP时间戳格式的时间戳，在接收直接时间同步请求消息时对应于发送方本地时间值。
"t_r" (NTP timestamp, 64 bits):
“t_r”（NTP时间戳，64位）：
"t_r" is a timestamp in NTP timestamp format that contains the receiver local time value received in the direct time synchronization request message.
“t_r”是NTP时间戳格式的时间戳，包含在直接时间同步请求消息中接收的接收器本地时间值。
"Signature" field (variable size, padded if necessary for 32-bit word alignment):
“签名”字段（可变大小，如果32位字对齐需要填充）：
The "Signature" field is mandatory. It contains a digital signature of this message, as specified by the encoding algorithm, cryptographic function, and key length parameters communicated in the bootstrap information message (if applicable) or out-of-band. If the signature length is not a multiple of 32 bits, this field is padded with 0.
“签名”字段是必填字段。它包含此消息的数字签名，由引导信息消息（如果适用）或带外传输的编码算法、加密函数和密钥长度参数指定。如果签名长度不是32位的倍数，则此字段用0填充。
"Group MAC" field (optional, variable length, multiple of 32 bits):
“组MAC”字段（可选，可变长度，32位的倍数）：
This field contains the Group MAC, calculated with the group key, K_g, shared by all group members. The field length, in bits, is given by n_w, which is known once the Group MAC function type is known (Section 7).
此字段包含由所有组成员共享的组密钥K_g计算的组MAC。字段长度（以位为单位）由n_w给出，一旦知道组MAC函数类型，就知道n_w（第7节）。
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Disclosed Key K_{i-d} ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Disclosed Key K_{i-d} ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of the Standard Authentication Tag
图4：标准身份验证标签的格式
A Standard Authentication Tag is composed of the following fields:
标准身份验证标记由以下字段组成：
"Reserved" field (8 bits):
“保留”字段（8位）：
The "Reserved" field is not used in the current specification and MUST be set to zero by the sender.
“保留”字段未在当前规范中使用，发送方必须将其设置为零。
"i" (Interval Index) field (32 bits):
“i”（间隔索引）字段（32位）：
"i" is the interval index associated with the key (K'_i) used to compute the MAC of this packet.
“i”是与用于计算该分组的MAC的密钥（K〃u i）相关联的间隔索引。
"Disclosed Key" (variable size, non padded):
“公开密钥”（可变大小，非填充）：
The "Disclosed Key" is the key used for interval i-d: K_{i-d}. There is no padding between the "Disclosed Key" and "MAC(K'_i, M)" fields, and the latter MAY not start on a 32-bit boundary, depending on the n_p parameter.
“公开密钥”是用于区间i-d:K_{i-d}的密钥。“公开密钥”和“MAC（K''u i，M）”字段之间没有填充，后者可能不会在32位边界上开始，这取决于n_p参数。
"MAC(K'_i, M)" (variable size, padded if necessary for 32-bit word alignment):
“MAC（K''u i，M）”（可变大小，如果32位字对齐需要填充）：
"MAC(K'_i, M)" is the truncated message authentication code of the current packet. Only the n_m most significant bits of the MAC output are kept [RFC2104].
“MAC（K''u i，M）”是当前数据包的截断消息认证码。仅保留MAC输出的n_m最高有效位[RFC2104]。
"Group MAC" field (optional, variable length, multiple of 32 bits):
“组MAC”字段（可选，可变长度，32位的倍数）：
This field contains the Group MAC, calculated with a group key, K_g, shared by all group members. The field length is given by n_w, in bits.
此字段包含由所有组成员共享的组密钥K_g计算的组MAC。字段长度由n_w表示，单位为位。
Note that because a key cannot be disclosed before the disclosure delay, d, the sender MUST NOT use this tag during the first d intervals of the session: {0 .. d-1} (inclusive). Instead, the sender MUST use an Authentication Tag without Key Disclosure.
请注意，由于密钥不能在公开延迟d之前公开，因此发送方不得在会话的前d个间隔期间使用此标记：{0..d-1}（包括）。相反，发送方必须使用身份验证标记，而不泄露密钥。
The Authentication Tag without Key Disclosure is meant to be used in situations where a high number of packets are sent in a given time interval. In such a case, it can be advantageous to disclose the K_{i-d} key only in a subset of the packets sent, using a Standard Authentication Tag, and to use the shortened version that does not disclose the K_{i-d} key in the remaining packets. It is left to the implementer to decide how many packets should disclose the K_{i-d} key. This Authentication Tag without Key Disclosure MUST also be used during the first d intervals: {0 .. d-1} (inclusive).
不公开密钥的认证标签用于在给定时间间隔内发送大量数据包的情况。在这种情况下，使用标准认证标签仅在发送的分组的子集中公开K{i-d}密钥，并且使用不在剩余分组中公开K{i-d}密钥的缩短版本是有利的。由实现者决定应该有多少数据包公开K_{i-d}密钥。在前d个间隔期间，也必须使用此不公开密钥的身份验证标记：{0..d-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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of the Authentication Tag without Key Disclosure
图5：不公开密钥的身份验证标签的格式
3.4.5. Format of an Authentication Tag with a "New Key Chain" Commitment
3.4.5. 具有“新密钥链”承诺的身份验证标记的格式
During the last n_tx_newkcc intervals of the current key chain, the sender SHOULD send commitments to the next key chain. This is done by replacing the disclosed key of the Authentication Tag with a New Key Chain Commitment, F(K_{N+1}) (or F(K_{2N+2}) in case of a switch between the second and third key chains, etc.) Figure 6 shows the corresponding format.
在当前密钥链的最后n_tx_newkcc间隔期间，发送方应向下一个密钥链发送承诺。这是通过将认证标签的公开密钥替换为新的密钥链承诺来实现的，F（K_{N+1}）（或者在第二和第三密钥链之间切换的情况下F（K_{2N+2}），等等。图6显示了相应的格式。
Note that since there is no padding between the "F(K_{N+1})" and "MAC(K'_i, M)" fields, the latter MAY not start on a 32-bit boundary, depending on the n_p parameter.
注意，由于“F（K{N+1}）”和“MAC（K''u i，M）”字段之间没有填充，因此后者可能不会从32位边界开始，这取决于N_p参数。
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ New Key Commitment F(K_{N+1}) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ New Key Commitment F(K_{N+1}) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of the Authentication Tag with a New Key Chain Commitment
图6：具有新密钥链承诺的身份验证标签的格式
3.4.6. Format of an Authentication Tag with a "Last Key of Old Chain" Disclosure
3.4.6. 具有“旧链的最后一个密钥”的身份验证标签的格式
During the first n_tx_lastkey intervals of the new key chain after the disclosing interval, d, the sender SHOULD disclose the last key of the old key chain. This is done by replacing the disclosed key of the Authentication Tag with the Last Key of the Old Chain, K_N (or K_{2N+1} in case of a switch between the second and third key chains, etc.). Figure 7 shows the corresponding format.
在公开间隔d之后的新密钥链的第一个n_tx_lastkey间隔期间，发送方应公开旧密钥链的最后一个密钥。这是通过用旧链的最后一个密钥K_N（或者在第二和第三密钥链之间切换的情况下K_{2N+1}等）替换认证标签的公开密钥来实现的。图7显示了相应的格式。
Note that since there is no padding between the "K_N" and "MAC(K'_i, M)" fields, the latter MAY not start on a 32-bit boundary, depending on the n_p parameter.
注意，由于“K_N”和“MAC（K''u i，M）”字段之间没有填充，因此后者可能不会从32位边界开始，具体取决于N_p参数。
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Last Key of Old Chain, K_N ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Last Key of Old Chain, K_N ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MAC(K'_i, M) +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Format of the Authentication Tag with an Old Chain Last Key Disclosure
图7：带有旧链Last Key的身份验证标签的格式
This section describes the TESLA operations at a receiver.
本节描述了特斯拉在接收器上的操作。
This section details the computation steps required to verify each of the three possible authentication information of an incoming packet. The verification MUST follow a strict order:
本节详细说明验证传入数据包的三种可能身份验证信息中的每一种所需的计算步骤。验证必须遵循严格的顺序：
o first of all, if the Group MAC is present and if the session uses this feature (e.g., if the G bit is set in the bootstrap information message), then verify the Group MAC. A packet that does not contain a Group MAC tag, whereas the session uses this feature, MUST be dropped immediately. On the opposite, if a packet contains a Group MAC tag whereas the session does not use this feature, this tag MUST be ignored;
o 首先，如果组MAC存在并且会话使用此功能（例如，如果引导信息消息中设置了g位），则验证组MAC。当会话使用此功能时，必须立即丢弃不包含组MAC标记的数据包。相反，如果数据包包含一个组MAC标签，而会话不使用该功能，则必须忽略该标签；
o then, verify the digital signature (with TESLA signaling packets) or enter the TESLA authentication process (with data packets).
o 然后，验证数字签名（使用特斯拉信令包）或进入特斯拉认证过程（使用数据包）。
Upon receiving a packet containing a Group MAC tag, the receiver recomputes the Group MAC and compares it to the value carried in the packet. If the check fails, the packet MUST be dropped immediately.
在接收到包含组MAC标签的分组时，接收机重新计算组MAC并将其与分组中携带的值进行比较。如果检查失败，必须立即丢弃数据包。
More specifically, recomputing the Group MAC requires saving the value of the "Group MAC" field, setting this field to 0, and doing the same computation as a sender does (see Section 3.3.3).
更具体地说，重新计算组MAC需要保存“组MAC”字段的值，将该字段设置为0，并执行与发送方相同的计算（参见第3.3.3节）。
Upon receiving a packet containing a digital signature, the receiver verifies the signature as follows.
在接收到包含数字签名的数据包时，接收方按如下方式验证签名。
The computation of the signature MUST include the ALC or NORM header (with the various header extensions) and the payload when applicable. The UDP/IP headers MUST NOT be included. During this computation, the "Signature" field MUST be set to 0 as well as the optional Group MAC, when present.
签名的计算必须包括ALC或NORM报头（具有各种报头扩展）和有效载荷（如果适用）。不得包含UDP/IP标头。在此计算过程中，“签名”字段必须设置为0，以及可选组MAC（如果存在）。
From [RFC4359]: Digital signature verification is performed as described in [RFC3447], Section 8.2.2 (RSASSA-PKCS1-v1_5) and [RFC3447], Section 8.1.2 (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, and validates that the appropriate encoding was applied. The two SHA-256 hashes are compared, and if they are identical the validation is successful.
根据[RFC4359]：按照[RFC3447]第8.2.2节（RSASSA-PKCS1-v1_5）和[RFC3447]第8.1.2节（RSASSA-PSS）的规定执行数字签名验证。收到后，数字签名作为S传递给验证函数。数据包的认证部分用作消息M，RSA公钥作为（n，e）传递。总之（使用SHA-256时），验证函数计算已验证数据包字节的SHA-256哈希，解密数据包中的SHA-256哈希，并验证是否应用了适当的编码。比较两个SHA-256哈希，如果它们相同，则验证成功。
It is assumed that the receivers have the possibility to retrieve the sender's public key required to check this digital signature (Section 2.2). This document does not specify how the public key of the sender is communicated reliably and in a secure way to all possible receivers.
假定接收方有可能检索发送方检查该数字签名所需的公钥（第2.2节）。本文件未规定如何以安全可靠的方式将发送方的公钥传递给所有可能的接收方。
When a receiver wants to authenticate a packet using an authentication tag and when he has the key for the associated time interval (i.e., after the disclosing delay, d), the receiver recomputes the MAC and compares it to the value carried in the packet. If the check fails, the packet MUST be immediately dropped.
当接收器想要使用认证标签认证分组并且当其具有相关时间间隔的密钥时（即，在公开延迟之后，d），接收器重新计算MAC并将其与分组中携带的值进行比较。如果检查失败，必须立即丢弃数据包。
More specifically, recomputing the MAC requires saving the value of the "MAC" field, setting this field to 0, and doing the same computation as a sender does (see Section 3.3.1).
更具体地说，重新计算MAC需要保存“MAC”字段的值，将该字段设置为0，并执行与发送方相同的计算（参见第3.3.1节）。
A receiver MUST be initialized before being able to authenticate the source of incoming packets. This can be done by an out-of-band mechanism or an in-band mechanism (Section 2.2). Let us focus on the in-band mechanism. Two actions must be performed:
在能够验证传入数据包的源之前，必须初始化接收器。这可以通过带外机制或带内机制实现（第2.2节）。让我们关注带内机制。必须执行两项操作：
o receive and process a bootstrap information message, and
o 接收并处理引导信息消息，以及
o calculate an upper bound of the sender's local time. To that purpose, the receiver must perform time synchronization.
o 计算发送方本地时间的上限。为此，接收器必须执行时间同步。
A receiver must first receive a packet containing the bootstrap information, digitally signed by the sender. Once the bootstrap information has been authenticated (see Section 4.1), the receiver can initialize its TESLA component. The receiver MUST then ignore the following bootstrap information messages, if any. There is an exception though: when a new key chain is used and if a receiver missed all the commitments for this new key chain, then this receiver MUST process one of the future bootstrap information messages (if any) in order to be able to authenticate the incoming packets associated to this new key chain.
接收方必须首先接收包含引导信息的数据包，并由发送方进行数字签名。一旦引导信息经过认证（见第4.1节），接收器可以初始化其特斯拉组件。然后，接收器必须忽略以下引导信息消息（如果有）。但是有一个例外：当使用一个新的密钥链时，如果一个接收者错过了这个新密钥链的所有承诺，那么这个接收者必须处理一个未来的引导信息消息（如果有的话），以便能够验证与这个新密钥链关联的传入数据包。
Before TESLA has been initialized, a receiver MUST discard incoming packets other than the bootstrap information message and direct time synchronization response.
在TESLA初始化之前，接收器必须丢弃除引导信息消息和直接时间同步响应之外的传入数据包。
First of all, the receiver must know whether the ALC or NORM session relies on direct or indirect time synchronization. This information is communicated by an out-of-band mechanism (for instance, when describing the various parameters of an ALC or NORM session). In some cases, both mechanisms might be available and the receiver can choose the preferred technique.
首先，接收器必须知道ALC或NORM会话是依赖于直接还是间接时间同步。该信息通过带外机制传递（例如，在描述ALC或NORM会话的各种参数时）。在某些情况下，这两种机制可能都可用，并且接收器可以选择首选技术。
In the case of a direct time synchronization, a receiver MUST synchronize with the sender. To that purpose, the receiver sends a direct time synchronization request message. This message includes the local time (in NTP timestamp format) at the receiver when sending the message. This timestamp will be copied in the sender's response for the receiver to associate the response to the request.
在直接时间同步的情况下，接收方必须与发送方同步。为此，接收器发送直接时间同步请求消息。此消息包括发送消息时接收方的本地时间（NTP时间戳格式）。此时间戳将复制到发送方的响应中，以便接收方将响应与请求相关联。
The direct time synchronization request message format is the following:
直接时间同步请求消息格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ t_r (NTP timestamp) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group MAC (optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Format of a Direct Time Synchronization Request
图8：直接时间同步请求的格式
The direct time synchronization request (Figure 8) contains the following information:
直接时间同步请求（图8）包含以下信息：
"t_r" (NTP timestamp, 64 bits):
“t_r”（NTP时间戳，64位）：
"t_r" is a timestamp in NTP timestamp format that contains the receiver local time value when sending this direct time synchronization request message;
“t_r”是NTP时间戳格式的时间戳，在发送此直接时间同步请求消息时包含接收器本地时间值；
"Group MAC" field (optional, variable length, multiple of 32 bits):
“组MAC”字段（可选，可变长度，32位的倍数）：
This field contains the Group MAC, calculated with the group key, K_g, shared by all group members. The field length, in bits, is given by n_w, which is known once the Group MAC function type is known (Section 7).
此字段包含由所有组成员共享的组密钥K_g计算的组MAC。字段长度（以位为单位）由n_w给出，一旦知道组MAC函数类型，就知道n_w（第7节）。
The receiver then awaits a response message (Section 3.4.2). Upon receiving this message, the receiver:
然后，接收器等待响应消息（第3.4.2节）。收到此消息后，接收者：
checks that this response relates to the request, by comparing the "t_r" fields;
通过比较“t_r”字段，检查此响应是否与请求相关；
checks the Group MAC if present;
检查组MAC（如果存在）；
checks the signature;
检查签名；
retrieves the t_s value and calculates D_t (Section 2.4.1).
检索t_s值并计算D_t（第2.4.1节）。
Note that in an ALC session, the direct time synchronization request message is sent to the sender by an out-of-band mechanism that is not specified by the current document.
请注意，在ALC会话中，直接时间同步请求消息通过当前文档未指定的带外机制发送给发送方。
With the indirect time synchronization method, the sender MAY provide out-of-band the URL or IP address of the NTP server(s) he trusts along with an OPTIONAL certificate for each NTP server. When several NTP servers are specified, a receiver MUST choose one of them. This document does not specify how the choice is made, but for the sake of scalability, the clients SHOULD NOT use the same server if several possibilities are offered. The NTP synchronization between the NTP server and the receiver MUST be authenticated, either using the certificate provided by the server or another certificate the client may obtain for this NTP server.
使用间接时间同步方法，发送方可以提供其信任的NTP服务器的带外URL或IP地址以及每个NTP服务器的可选证书。指定多个NTP服务器时，接收器必须选择其中一个。本文档未指定如何进行选择，但为了可伸缩性，如果提供了多种可能性，则客户端不应使用同一台服务器。NTP服务器和接收器之间的NTP同步必须通过身份验证，可以使用服务器提供的证书，也可以使用客户端为此NTP服务器获得的其他证书。
Then the receiver computes the time offset between itself and the NTP server chosen. Note that the receiver does not need to update the local time, (which often requires root privileges), computing the time offset is sufficient.
然后，接收器计算自身与所选NTP服务器之间的时间偏移。注意，接收方不需要更新本地时间（通常需要root权限），计算时间偏移量就足够了。
Since the offset between the server and the time reference, D^O_t, is indicated in the bootstrap information message (or communicated out-of-band), the receiver can now calculate an upper bound of the sender's local time (Section 2.4.2).
由于服务器和时间参考之间的偏移量D^O\t在引导信息消息中指示（或在带外通信），因此接收方现在可以计算发送方本地时间的上限（第2.4.2节）。
Note that this scenario assumes that each client trusts the sender and accepts aligning its NTP configuration to that of the sender, using one of the NTP server(s) suggested. If this assumption does not hold, the client MUST NOT use the NTP indirect time synchronization method (Section 2.3.2).
请注意，此场景假设每个客户端都信任发送方，并接受使用建议的NTP服务器之一将其NTP配置与发送方的NTP配置对齐。如果该假设不成立，客户不得使用NTP间接时间同步方法（第2.3.2节）。
The receiver can now authenticate incoming packets (other than bootstrap information and direct time synchronization response packets). To that purpose, he MUST follow different steps (see [RFC4082], Section 3.5):
接收器现在可以验证传入的数据包（引导信息和直接时间同步响应数据包除外）。为此，他必须遵循不同的步骤（见[RFC4082]，第3.5节）：
1. The receiver parses the different packet headers. If none of the four TESLA authentication tags are present, the receiver MUST discard the packet. If the session is in "Single Key Chain" mode (e.g., when the "S" flag is set in the bootstrap information message), then the receiver MUST discard any packet containing an Authentication Tag with a New Key Chain Commitment or an Authentication Tag with a Last Key of Old Chain Disclosure.
1. 接收方解析不同的数据包头。如果四个特斯拉认证标签均不存在，则接收器必须丢弃该数据包。如果会话处于“单密钥链”模式（例如，当引导信息消息中设置了“S”标志时），则接收器必须丢弃包含具有新密钥链承诺的认证标签或具有旧密钥链公开的最后一个密钥的认证标签的任何包。
2. Safe packet test: When the receiver receives packet P_j, it first records the local time T at which the packet arrived. The receiver then computes an upper bound t_j on the sender's clock at the time when the packet arrived: t_j = T + D_t. The receiver
2. 安全数据包测试：当接收器接收到数据包P_j时，它首先记录数据包到达的本地时间T。然后，接收方在数据包到达时计算发送方时钟上的上界t_j：t_j＝t+D_t。接受者
then computes the highest interval the sender could possibly be in: highest_i = floor((t_j - T_0) / T_int). He also retrieves the "i" interval index from the authentication tag. The receiver can now proceed with the "safe packet" test. If highest_i < i + d, then the sender is not yet in the interval during which it discloses the key K_i. The packet is safe (but not necessarily authentic). If the test fails, the packet is unsafe, and the receiver MUST discard the packet.
然后计算发送方可能处于的最高间隔：最高i=楼层（（t_j-t_0）/t_int）。他还从身份验证标记中检索“i”间隔索引。接收器现在可以继续进行“安全数据包”测试。如果最高_i<i+d，则发送方尚未处于其公开密钥K_i的间隔内。数据包是安全的（但不一定是真实的）。如果测试失败，则数据包不安全，接收方必须丢弃数据包。
3. Group MAC test: if the optional Group MAC tag is present and if the session uses this feature, then verify the Group MAC (Section 4.1.1). If the verification fails, the packet MUST be immediately dropped. A packet that does not contain a Group MAC tag whereas the session uses this feature MUST be immediately dropped. On the opposite, if a packet contains a Group MAC tag whereas the session does not use this feature, this tag MUST be ignored.
3. 组MAC测试：如果存在可选的组MAC标签，并且会话使用此功能，则验证组MAC（第4.1.1节）。如果验证失败，则必须立即丢弃数据包。当会话使用此功能时，必须立即丢弃不包含组MAC标记的数据包。相反，如果数据包包含组MAC标记，而会话不使用此功能，则必须忽略此标记。
4. Disclosed Key processing: When the packet discloses a key (i.e., with a Standard Authentication Tag, or with an Authentication Tag with a Last Key of Old Chain Disclosure), the following tests are performed:
4. 公开密钥处理：当数据包公开密钥（即，具有标准认证标签，或具有具有旧链公开的最后一个密钥的认证标签）时，执行以下测试：
* New key index test: the receiver checks whether a legitimate key already exists with the same index (i.e., i-d). If such a legitimate key exists, the receiver compares its value with the current disclosed key and if they are identical, skips the "Unverifiable key test" and "Key verification test". If such a legitimate key exists but the values differ, the receiver MUST discard the packet.
* 新密钥索引测试：接收器检查是否已经存在具有相同索引（即，i-d）的合法密钥。如果存在这样一个合法密钥，接收器将其值与当前公开的密钥进行比较，如果它们相同，则跳过“无法验证的密钥测试”和“密钥验证测试”。如果存在这样一个合法密钥，但值不同，则接收方必须丢弃该数据包。
* Unverifiable key test: when the disclosed key index is new, it is possible that no earlier disclosed and legitimate key exists for this key chain, thereby preventing the verification of the disclosed key. This happens when the disclosed key belongs to the old key chain and no commitment to this old key chain has ever been received (e.g., because the first bootstrap packet received by a latecomer is for the current key chain, and therefore includes a commitment to the current key chain, not the previous one). When this happens, the receiver MUST ignore the disclosed key (anyway useless) and skip the Key verification test.
* 无法验证的密钥测试：当公开的密钥索引是新的时，该密钥链可能不存在先前公开的合法密钥，从而阻止对公开密钥的验证。当所公开的密钥属于旧密钥链且从未收到对此旧密钥链的承诺时（例如，因为迟到者接收到的第一个引导包是针对当前密钥链的，因此包括对当前密钥链的承诺，而不是前一个）。发生这种情况时，接收方必须忽略公开的密钥（无论如何都是无用的），并跳过密钥验证测试。
* Key verification test: If the disclosed key index is new and the key can be verified, the receiver checks the legitimacy of K_{i-d} by verifying, for some earlier disclosed and legitimate key K_v (with v < i-d), that K_v and F^{i-d-v}(K_{i-d}) are identical. In other words, the receiver
* 密钥验证测试：如果公开的密钥索引是新的，并且密钥可以被验证，那么接收方通过验证一些先前公开的合法密钥K_v（v<i-d）的K_v和F^{i-d-v}（K_{i-d}）是相同的来检查K_{i-d}的合法性。换句话说，接收者
checks the disclosed key by computing the necessary number of PRF functions to obtain a previously disclosed and legitimate (i.e., verified) key. If the key verification fails, the receiver MUST discard the packet. If the key verification succeeds, this key is said to be legitimate and is stored by the receiver, as well as all the keys between indexes v and i-d.
通过计算必要数量的PRF函数来检查公开密钥，以获得先前公开的合法（即验证）密钥。如果密钥验证失败，接收方必须丢弃数据包。如果密钥验证成功，则该密钥被认为是合法的，并由接收方存储，以及索引v和i-d之间的所有密钥。
5. When applicable, the receiver performs any congestion control related action (i.e., the ALC or NORM headers are used by the associated congestion control building block, if any), even if the packet has not yet been authenticated [RFC5651]. If this feature leads to a potential DoS attack (the attacker can send a faked packet with a wrong sequence number to simulate packet losses), it does not compromise the security features offered by TESLA and enables a rapid reaction in front of actual congestion problems.
5. 在适用的情况下，接收器执行任何与拥塞控制相关的操作（即，ALC或NORM头由相关的拥塞控制构建块使用，如果有的话），即使数据包尚未通过身份验证[RFC5651]。如果此功能导致潜在的DoS攻击（攻击者可以发送带有错误序列号的伪造数据包以模拟数据包丢失），则不会损害特斯拉提供的安全功能，并能够在实际拥塞问题面前快速做出反应。
6. The receiver then buffers the packet for a later authentication, once the corresponding key will be disclosed (after d time intervals) or deduced from another key (if all packets disclosing this key are lost). In some situations, this packet might also be discarded later, if it turns out that the receiver will never be able to deduce the associated key.
6. 一旦相应的密钥将被公开（在d个时间间隔之后）或从另一个密钥推导（如果公开该密钥的所有分组丢失），接收器随后缓冲该分组以供稍后的认证。在某些情况下，如果结果表明接收方永远无法推断出相关的密钥，则该数据包也可能在以后被丢弃。
7. Authentication test: Let v be the smallest index of the legitimate keys known by the receiver so far. For all the new keys K_w, with v < w <= i-d, that have been either disclosed by this packet (i.e., K_{i-d}) or derived by K_{i-d} (i.e., keys in interval {v+1,.. i-d-1}), the receiver verifies the authenticity of the safe packets buffered for the corresponding interval w. To authenticate one of the buffered packets P_h containing message M_h protected with a MAC that used key index w, the receiver will compute K'_w = F'(K_w) from which it can compute MAC( K'_w, M_h). If this MAC does not equal the MAC stored in the packet, the receiver MUST discard the packet. If the two MACs are equal, the packet is successfully authenticated and the receiver continues processing it.
7. 身份验证测试：设v为迄今为止接收方已知的合法密钥的最小索引。对于由该分组（即，K{i-d}）公开或由K{i-d}导出的v<w<=i-d的所有新密钥K{u w（即，间隔{v+1，…i-d-1}中的密钥），接收器验证为相应间隔w缓冲的安全分组的真实性。为了验证包含使用密钥索引w的MAC保护的消息M_h的缓冲包P_h中的一个，接收器将计算K''u w＝F'（K_w），它可以从中计算MAC（K''u w，M_h）。如果此MAC不等于数据包中存储的MAC，则接收器必须丢弃数据包。如果两个MAC相等，则成功验证数据包，接收方继续处理数据包。
8. Authenticated new key chain commitment processing: If the authenticated packet contains a new key chain commitment and if no verified commitment already exists, then the receiver stores the commitment to the new key chain. Then, if there are non-authenticated packets for a previous chain (i.e., the key chain before the current one), all these packets can be discarded (Section 4.4).
8. 经过身份验证的新密钥链承诺处理：如果经过身份验证的数据包包含新的密钥链承诺，并且如果没有已验证的承诺，则接收方将该承诺存储到新的密钥链。然后，如果前一个链（即当前链之前的密钥链）存在未经认证的数据包，则可以丢弃所有这些数据包（第4.4节）。
9. The receiver continues the ALC or NORM processing of all the packets authenticated during the authentication test.
9. 在认证测试期间，接收器继续对所有经过认证的数据包进行ALC或NORM处理。
In this specification, a receiver using TESLA MUST immediately drop unsafe packets. But the receiver MAY also decide, at any time, to continue an ALC or NORM session in unsafe (insecure) mode, ignoring TESLA extensions. There SHOULD be an explicit user action to that purpose.
在本规范中，使用特斯拉的接收器必须立即丢弃不安全的数据包。但接收方也可以在任何时候决定在不安全（不安全）模式下继续ALC或NORM会话，忽略特斯拉扩展。为此，应该有一个明确的用户操作。
Following strictly the above steps can lead to excessive processing overhead in certain situations. This is the case when a receiver receives packets for an unwanted object with the ALC or NORM protocols, i.e., an object in which the application (or the end user) explicitly mentioned it is not interested. This is also the case when a receiver receives packets for an already decoded object, or when this object has been partitioned in several blocks, for an already decoded block. When such a packet is received, which is easily identified by looking at the receiver's status for the incoming ALC or NORM packet, the receiver MUST also check that the packet is a pure data packet that does not contain any signaling information of importance for the session.
在某些情况下，严格遵循上述步骤可能会导致过度的处理开销。当接收器接收到具有ALC或NORM协议的不需要的对象的数据包时，即，应用程序（或最终用户）明确提到它不感兴趣的对象。当接收器接收到已解码对象的数据包时，或者当该对象已被划分为多个块时，对于已解码的块，情况也是如此。当接收到这样的分组时（通过查看接收器对于传入ALC或NORM分组的状态容易识别），接收器还必须检查该分组是否是不包含对会话重要的任何信令信息的纯数据分组。
With ALC, a packet containing an "A" flag ("Close Session") or a "B" flag ("Close Object") MUST NOT be discarded before having been authenticated and processed normally. Otherwise, the receiver can safely discard the incoming packet for instance just after step 1 of Section 4.3. This optimization can dramatically reduce the processing overhead by avoiding many useless authentication checks.
对于ALC，包含“a”标志（“关闭会话”）或“B”标志（“关闭对象”）的数据包在经过身份验证和正常处理之前不得丢弃。否则，接收器可以安全地丢弃传入的数据包，例如，就在第4.3节的步骤1之后。通过避免许多无用的身份验证检查，此优化可以显著减少处理开销。
In some cases, a receiver having experienced a very long disconnection might have lost all the disclosures of the last key(s) of a previous key chain. Let j be the index of this key chain for which there remains non-authenticated packets. This receiver can flush all the packets of the key chain j if he determines that:
在某些情况下，经历了长时间断开连接的接收者可能会丢失先前密钥链的最后一个密钥的所有公开信息。设j为该密钥链的索引，该密钥链仍有未经身份验证的数据包。如果该接收器确定：
o he has just switched to a chain of index j+2 (inclusive) or higher;
o 他刚刚切换到指数j+2（含）或更高的链条；
o the sender has sent a commitment to the new key chain of index j+2 (Section 3.1.2.3). This situation requires that the receiver has received a packet containing such a commitment and that he has been able to check its integrity. In some cases, it might require receiving a bootstrap information message for the current key chain.
o 发送方已向索引j+2的新密钥链发送承诺（第3.1.2.3节）。这种情况要求接收方已经收到包含这种承诺的数据包，并且能够检查其完整性。在某些情况下，可能需要接收当前密钥链的引导信息消息。
If one of the above two tests succeeds, the sender can discard all the awaiting packets since there is no way to authenticate them.
如果上述两个测试中的一个成功，发送方可以丢弃所有等待的数据包，因为无法对它们进行身份验证。
The integration of TESLA in ALC or NORM is similar and relies on the header extension mechanism defined in both protocols. More precisely, this document details the EXT_AUTH==1 header extension defined in [RFC5651].
特斯拉在ALC或NORM中的集成类似，并且依赖于两个协议中定义的头扩展机制。更准确地说，本文档详细介绍了[RFC5651]中定义的EXT_AUTH==1头扩展名。
Several fields are added in addition to the "HET" (Header Extension Type) and "HEL" (Header Extension Length) fields (Figure 9).
除了“HET”（标题扩展类型）和“HEL”（标题扩展长度）字段外，还添加了几个字段（图9）。
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 | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ ~
| Content |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ ~
| Content |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of the TESLA EXT_AUTH Header Extension
图9:TESLA EXT_AUTH头扩展的格式
The fields of the TESLA EXT_AUTH Header Extension are:
TESLA EXT_AUTH标头扩展的字段为：
"ASID" (Authentication Scheme IDentifier) field (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”值与实际身份验证方案之间的关联在会话启动时在带外定义。
"Type" field (4 bits):
“类型”字段（4位）：
The "Type" field identifies the type of TESLA information carried in this header extension. This specification defines the following types:
“类型”字段标识此标题扩展中携带的特斯拉信息类型。本规范定义了以下类型：
* 0: Bootstrap information, sent by the sender periodically or after a direct time synchronization request;
* 0：引导信息，由发送方定期或在直接时间同步请求后发送；
* 1: Standard Authentication Tag for the ongoing key chain, sent by the sender along with a packet;
* 1：正在进行的密钥链的标准认证标签，由发送方随数据包一起发送；
* 2: Authentication Tag without Key Disclosure, sent by the sender along with a packet;
* 2：无密钥泄露的认证标签，由发送方随包发送；
* 3: Authentication Tag with a New Key Chain Commitment, sent by the sender when approaching the end of a key chain;
* 3：具有新密钥链承诺的身份验证标签，在接近密钥链末端时由发送方发送；
* 4: Authentication Tag with a Last Key of Old Chain Disclosure, sent by the sender some time after moving to a new key chain;
* 4：带有旧链泄露的最后一个密钥的身份验证标签，由发送方在移动到新的密钥链后一段时间发送；
* 5: Direct time synchronization request, sent by a NORM receiver. This type of message is invalid in the case of an ALC session since ALC is restricted to unidirectional transmissions. Yet, an external mechanism may provide the direct time synchronization functionality;
* 5：直接时间同步请求，由NORM接收器发送。在ALC会话的情况下，这种类型的消息无效，因为ALC仅限于单向传输。然而，外部机制可以提供直接时间同步功能；
* 6: Direct time synchronization response, sent by a NORM sender. This type of message is invalid in the case of an ALC session since ALC is restricted to unidirectional transmissions. Yet, an external mechanism may provide the direct time synchronization functionality.
* 6：直接时间同步响应，由NORM发送方发送。在ALC会话的情况下，这种类型的消息无效，因为ALC仅限于单向传输。然而，外部机制可以提供直接时间同步功能。
"Content" field (variable length):
“内容”字段（可变长度）：
This is the TESLA information carried in the header extension, whose type is given by the "Type" field.
这是标题扩展中携带的特斯拉信息，其类型由“类型”字段给出。
Each packet sent by the session's sender MUST contain exactly one TESLA EXT_AUTH Header Extension.
会话发送方发送的每个数据包必须恰好包含一个TESLA EXT_AUTH头扩展名。
All receivers MUST recognize EXT_AUTH but MAY not be able to parse its content, for instance, because they do not support TESLA. In that case, these receivers MUST ignore the TESLA EXT_AUTH extensions. In the case of NORM, the packets sent by receivers MAY contain a direct synchronization request but MUST NOT contain any of the other five TESLA EXT_AUTH Header Extensions.
所有接收者必须识别EXT_AUTH，但可能无法解析其内容，例如，因为他们不支持TESLA。在这种情况下，这些接收器必须忽略特斯拉EXT_AUTH扩展。在NORM的情况下，接收器发送的数据包可能包含直接同步请求，但不得包含其他五个TESLA EXT_AUTH报头扩展中的任何一个。
The "bootstrap information" TESLA EXT_AUTH (Type==0) MUST be sent in a stand-alone control packet, rather than in a packet containing application data. The reason for that is the large size of this bootstrap information. By using stand-alone packets, the maximum payload size of data packets is only affected by the (mandatory) authentication information header extension.
“引导信息”TESLA EXT_AUTH（Type==0）必须在独立控制数据包中发送，而不是在包含应用程序数据的数据包中发送。原因是此引导信息的大小很大。通过使用独立数据包，数据包的最大有效负载大小仅受（强制）身份验证信息头扩展的影响。
With ALC, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a control packet, i.e., containing no encoding symbol.
对于ALC，“引导信息”特斯拉EXT_AUTH必须在控制包中发送，即不包含编码符号。
With NORM, the "bootstrap information" TESLA EXT_AUTH MUST be sent in a NORM_CMD(APPLICATION) message.
对于NORM，“引导信息”TESLA EXT_AUTH必须以NORM_CMD（应用程序）消息的形式发送。
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 (=46) | ASID | 0 | 0 | 0 |0|1|0| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | 2 | 2 | 2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1 | 3 | 128 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 0 (reserved) | T_int | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ T_0 (NTP timestamp format) + | 5
| | | 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| N (Key Chain Length) | | b
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | y
| Current Interval Index i | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
| | | s
+ + |
| | |
+ Current Key Chain Commitment + |
| (20 bytes) | |
+ + |
| | |
+ + |
| | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature . | b
. (128 bytes) . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Group 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 (=46) | ASID | 0 | 0 | 0 |0|1|0| ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| d | 2 | 2 | 2 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 1 | 3 | 128 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 0 (reserved) | T_int | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | |
+ T_0 (NTP timestamp format) + | 5
| | | 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| N (Key Chain Length) | | b
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | y
| Current Interval Index i | | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e
| | | s
+ + |
| | |
+ Current Key Chain Commitment + |
| (20 bytes) | |
+ + |
| | |
+ + |
| | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | ^ 1
+ + | 2
| | | 8
. . |
. Signature . | b
. (128 bytes) . | y
| | | t
+ + | e
| | v s
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Group MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Example: Format of the Bootstrap Information Message (Type 0) Using SHA-256/1024-Bit Signatures, the Default HMAC-SHA-256, and a Group MAC
图10：示例：使用SHA-256/1024位签名、默认HMAC-SHA-256和组MAC的引导信息消息（类型0）的格式
For instance, Figure 10 shows the bootstrap information message when using the HMAC-SHA-256 transform for the PRF, MAC, and Group MAC functions, along with SHA-256/128 byte (1024 bit) key digital signatures (which also means that the "Signature" field is 128 bytes long). The TESLA EXT_AUTH Header Extension is then 184 bytes long (i.e., 46 words of 32 bits).
例如，图10显示了当使用HMAC-SHA-256转换用于PRF、MAC和组MAC功能时的引导信息消息，以及SHA-256/128字节（1024位）密钥数字签名（这也意味着“签名”字段的长度为128字节）。TESLA EXT_AUTH标头扩展长度为184字节（即32位的46个字）。
The four "authentication tag" TESLA EXT_AUTH Header Extensions (Type 1, 2, 3, and 4) MUST be attached to the ALC or NORM packet (data or control packet) that they protect.
必须将四个“认证标签”特斯拉EXT_AUTH头扩展（类型1、2、3和4）附加到它们所保护的ALC或NORM数据包（数据或控制数据包）上。
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 (=10) | ASID | 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Disclosed Key K_{i-d} +
| (20 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| MAC(K'_i, M) |
+ (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 (=10) | ASID | 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Disclosed Key K_{i-d} +
| (20 bytes) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| MAC(K'_i, M) |
+ (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Example: Format of the Standard Authentication Tag (Type 1) Using the Default HMAC-SHA-256
图11：示例：使用默认HMAC-SHA-256的标准身份验证标记（类型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 (=5) | ASID | 2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| MAC(K'_i, M) |
+ (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 (=5) | ASID | 2 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| i (Interval Index of K'_i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| MAC(K'_i, M) |
+ (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Example: Format of the Authentication Tag without Key Disclosure (Type 2) Using the Default HMAC-SHA-256
图12：示例：使用默认HMAC-SHA-256的不公开密钥的身份验证标签格式（类型2）
For instance, Figures 11 and 12 show the format of the authentication tags, respectively with and without the K_{i-d} key disclosure, when using the (default) HMAC-SHA-256 transform for the PRF and MAC functions. In these examples, the Group MAC feature is not used.
例如，图11和图12分别显示了在对PRF和MAC函数使用（默认）HMAC-SHA-256变换时，在有和没有K_{i-d}密钥公开的情况下认证标签的格式。在这些示例中，未使用组MAC功能。
5.2.3. EXT_AUTH Header Extension of Type Direct Time Synchronization Request
5.2.3. 直接时间同步请求类型的EXT_AUTH标头扩展
With NORM, the "direct time synchronization request" TESLA EXT_AUTH (Type==7) MUST be sent by a receiver in a NORM_CMD(APPLICATION) NORM packet.
对于NORM，“直接时间同步请求”TESLA EXT_AUTH（类型==7）必须由NORM_CMD（应用程序）NORM数据包中的接收器发送。
With ALC, the "direct time synchronization request" TESLA EXT_AUTH cannot be included in an ALC packet, since ALC is restricted to unidirectional transmissions, from the session's sender to the receivers. An external mechanism must be used with ALC for carrying direct time synchronization requests to the session's sender.
使用ALC，“直接时间同步请求”特斯拉EXT_AUTH不能包含在ALC数据包中，因为ALC仅限于从会话发送方到接收方的单向传输。ALC必须使用外部机制将直接时间同步请求传送到会话的发送方。
In the case of direct time synchronization, it is RECOMMENDED that the receivers spread the transmission of direct time synchronization requests over the time (Section 2.3.1).
在直接时间同步的情况下，建议接收机在整个时间内传播直接时间同步请求的传输（第2.3.1节）。
5.2.4. EXT_AUTH Header Extension of Type Direct Time Synchronization Response
5.2.4. 直接时间同步响应类型的EXT_AUTH标头扩展
With NORM, the "direct time synchronization response" TESLA EXT_AUTH (Type==8) MUST be sent by the sender in a NORM_CMD(APPLICATION) message.
对于NORM，“直接时间同步响应”TESLA EXT_AUTH（类型==8）必须由发送方在NORM_CMD（应用程序）消息中发送。
With ALC, the "direct time synchronization response" TESLA EXT_AUTH can be sent in an ALC control packet (i.e., containing no encoding symbol) or through the external mechanism used to carry the direct time synchronization request.
使用ALC，“直接时间同步响应”特斯拉EXT_AUTH可在ALC控制包（即，不包含编码符号）中发送，或通过用于承载直接时间同步请求的外部机制发送。
[RFC4082] discusses the security of TESLA in general. These considerations apply to the present specification, namely:
[RFC4082]讨论了特斯拉的总体安全性。这些注意事项适用于本规范，即：
o great care must be taken in the timing aspects. In particular, the D_t parameter is critical and must be correctly initialized;
o 在时间方面必须非常小心。特别是，D_t参数非常关键，必须正确初始化；
o if the sender realizes that the key disclosure schedule is not appropriate, then the current session MUST be closed and a new one created. Indeed, Section 3.1.3 requires that these parameters be fixed during the whole session.
o 如果发送方意识到密钥公开计划不合适，则必须关闭当前会话并创建新会话。事实上，第3.1.3节要求在整个会议期间固定这些参数。
o when the verifier that authenticates the incoming packets and the application that uses the data are two different components, there is a risk that an attacker located between these components inject faked data. Similarly, when the verifier and the secure timing system are two different components, there is a risk that an attacker located between these components inject faked timing information. For instance, when the verifier reads the local time by means of a dedicated system call (e.g., gettimeofday()), if an attacker controls the host, he may catch the system call and return a faked time information.
o 当验证传入数据包的验证器和使用数据的应用程序是两个不同的组件时，存在位于这些组件之间的攻击者注入伪造数据的风险。类似地，当验证器和安全计时系统是两个不同的组件时，位于这些组件之间的攻击者可能会注入伪造的计时信息。例如，当验证器通过专用系统调用（例如gettimeofday（））读取本地时间时，如果攻击者控制主机，他可能捕获系统调用并返回伪造的时间信息。
The current specification discusses additional aspects with more details.
当前规范详细讨论了其他方面。
TESLA introduces new opportunities for an attacker to mount DoS attacks. For instance, an attacker can try to saturate the processing capabilities of the receiver (faked packets are easy to create but checking them requires computing a MAC over the packet or sometimes checking a digital signature as with the bootstrap and direct time synchronization response messages). An attacker can also try to saturate the receiver's memory (since authentication is delayed and non-authenticated packets will accumulate), or to make the receiver believe that a congestion has happened (since congestion control MUST be performed before authenticating incoming packets, Section 4.3).
特斯拉为攻击者提供了发动DoS攻击的新机会。例如，攻击者可以尝试饱和接收器的处理能力（伪造数据包很容易创建，但检查它们需要在数据包上计算MAC，或者有时检查数字签名，如引导和直接时间同步响应消息）。攻击者还可以尝试使接收器的内存饱和（因为身份验证被延迟，未经身份验证的数据包将累积），或者使接收器相信发生了拥塞（因为必须在验证传入数据包之前执行拥塞控制，第4.3节）。
In order to mitigate these attacks, it is RECOMMENDED to use the Group MAC scheme (Section 3.3.3). No mitigation is possible if a group member acts as an attacker with Group MAC.
为了减轻这些攻击，建议使用组MAC方案（第3.3.3节）。如果组成员充当组MAC的攻击者，则无法进行缓解。
Generally, it is RECOMMENDED that the amount of memory used to store incoming packets waiting to be authenticated be limited to a reasonable value.
通常，建议将用于存储等待验证的传入数据包的内存量限制在合理的值内。
Replay attacks, whereby an attacker stores a valid message and replays it later, can have significant impacts, depending on the message type. Two levels of impacts must be distinguished:
重放攻击，即攻击者存储有效消息并在以后重放，可能会产生重大影响，具体取决于消息类型。必须区分两个级别的影响：
o within the TESLA protocol, and
o 在特斯拉协议范围内，以及
o within the ALC or NORM protocol.
o 在ALC或NORM协议内。
Replay attacks can impact the TESLA component itself. We review here the potential impacts of such an attack depending on the TESLA message type:
重放攻击会影响特斯拉组件本身。我们在此根据特斯拉消息类型审查此类攻击的潜在影响：
o bootstrap information: Since most parameters contained in a bootstrap information message are static, replay attacks have no consequences. The fact that the "i" and "K_i" fields can be updated in subsequent bootstrap information messages does not create a problem either, since all "i" and "K_i" fields sent remain valid. Finally, a receiver that successfully initialized its TESLA component MUST ignore the following messages (see Section 4.2.1 for an exception to this rule), which voids replay attacks, unless he missed all the commitments to a new key chain (e.g., after a long disconnection) (Section 3.2.1).
o 引导信息：由于引导信息消息中包含的大多数参数都是静态的，因此重播攻击不会产生任何后果。“i”和“K_i”字段可以在后续引导信息消息中更新，这一事实也不会产生问题，因为所有发送的“i”和“K_i”字段仍然有效。最后，成功初始化其特斯拉组件的接收器必须忽略以下消息（参见第4.2.1节了解该规则的例外情况），这将使重播攻击无效，除非他错过了对新密钥链的所有承诺（例如，在长时间断开连接后）（第3.2.1节）。
o direct time synchronization request: If the Group MAC scheme is used, an attacker that is not a member of the group can replay a packet and oblige the sender to respond, which requires digitally signing the response, a time-consuming process. If the Group MAC scheme is not used, an attacker can easily forge a request anyway. In both cases, the attack will not compromise the TESLA component, but might create a DoS. If this is a concern, it is RECOMMENDED, when the Group MAC scheme is used, that the sender verify the "t_r" NTP timestamp contained in the request and respond only if this value is strictly larger than the previous one received from this receiver. When the Group MAC scheme is not used, this attack can be mitigated by limiting the number of requests per second that will be processed.
o 直接时间同步请求：如果使用组MAC方案，则非组成员的攻击者可以重播数据包并迫使发送方响应，这需要对响应进行数字签名，这是一个耗时的过程。如果不使用组MAC方案，攻击者可以轻松伪造请求。在这两种情况下，攻击都不会危及特斯拉组件，但可能会造成拒绝服务。如果这是一个问题，建议在使用组MAC方案时，发送方验证请求中包含的“t_r”NTP时间戳，并且仅当该值严格大于从该接收方接收到的前一个值时才响应。当不使用组MAC方案时，可以通过限制每秒要处理的请求数来缓解此攻击。
o direct time synchronization response: Upon receiving a response, a receiver who has no pending request MUST immediately drop the packet. If this receiver has previously issued a request, he first checks the Group MAC (if applicable), then the "t_r" field, to be sure it is a response to his request, and finally the digital signature. A replayed packet will be dropped during these verifications, without compromising the TESLA component.
o 直接时间同步响应：收到响应后，没有挂起请求的接收方必须立即丢弃数据包。如果该接收者之前发出过请求，他首先检查组MAC（如果适用），然后检查“t_r”字段，以确保这是对其请求的响应，最后检查数字签名。在这些验证过程中，将丢弃重放的数据包，而不会影响特斯拉组件。
o other messages, containing an authentication tag: Replaying a packet containing a TESLA authentication tag will never compromise the TESLA component itself (but perhaps the underlying ALC or NORM component, see below).
o 包含身份验证标签的其他消息：重放包含特斯拉身份验证标签的数据包永远不会损害特斯拉组件本身（但可能是底层ALC或NORM组件，请参见下文）。
To conclude, TESLA itself is robust in front of replay attacks.
综上所述，特斯拉自身在重放攻击面前表现强劲。
We review here 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, the congestion control protocols.
我们在此回顾重播攻击对NORM组件的潜在影响。请注意，我们不考虑可以与规范一起使用的协议，例如拥塞控制协议。
First, let us consider replay attacks within a given NORM session. NORM defines a "sequence" field that can 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. It is RECOMMENDED that a receiver check this "sequence" field and drop messages considered as replayed. Similarly, it is RECOMMENDED that a sender check this sequence, for each known receiver, and drop messages considered as replayed. In both cases, checking this "sequence" field SHOULD be done before TESLA processing of the packet: if the "sequence" field has not been corrupted, the replay attack will immediately be identified; otherwise, the packet will fail the TESLA authentication test. This analysis shows that NORM itself is robust in front of replay attacks within the same session.
首先，让我们考虑给定的规范会话中的重放攻击。NORM定义了一个“序列”字段，可用于在给定NORM会话中防止重播攻击[RFC5740]。该“序列”字段是一个16位的值，由消息发起者（发送者或接收者）设置为一个单调递增的数字，随着发送的每个标准消息而递增。建议接收者检查此“序列”字段，并删除被视为重播的消息。同样，建议发送方为每个已知接收方检查此序列，并删除被视为重播的消息。在这两种情况下，应在特斯拉处理数据包之前检查此“序列”字段：如果“序列”字段未损坏，将立即识别重放攻击；否则，数据包将无法通过特斯拉认证测试。该分析表明，NORM本身在同一会话中的重播攻击面前是鲁棒的。
Now let us consider replay attacks across several NORM sessions. Since the key chain used in each session MUST differ, a packet replayed in a subsequent session will be identified as unauthentic. Therefore, NORM is robust in front of replay attacks across different sessions.
现在让我们考虑几个规范会话中的重放攻击。由于每个会话中使用的密钥链必须不同，因此在后续会话中重播的数据包将被标识为未经验证。因此，NORM在跨不同会话的重播攻击面前是健壮的。
We review here 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, the layered or wave-based congestion control protocols.
我们在此回顾重播攻击对ALC组件的潜在影响。注意，我们不考虑可以与ALC一起使用的协议，例如，基于分层或基于波形的拥塞控制协议。
First, let us consider replay attacks within a given ALC session:
首先，让我们考虑给定ALC会话中的重放攻击：
o Regular packets containing an authentication tag: a replayed message containing an encoding symbol will be detected once authenticated, thanks to the object/block/symbol identifiers, and will be silently discarded. This kind of replay attack is only penalizing in terms of memory and processing load, but does not compromise the ALC behavior.
o 包含身份验证标签的常规数据包：包含编码符号的重放消息在通过身份验证后将被检测到，这要归功于对象/块/符号标识符，并且将被静默地丢弃。这种重放攻击仅在内存和处理负载方面受到惩罚，但不会损害ALC行为。
o Control packets containing an authentication tag: ALC control packets, by definition, do not include any encoding symbol and therefore do not include any object/block/symbol identifier that would enable a receiver to identify duplicates. However, a sender has a very limited number of reasons to send control packets. More precisely:
o 包含身份验证标签的控制数据包：根据定义，ALC控制数据包不包括任何编码符号，因此不包括使接收器能够识别重复项的任何对象/块/符号标识符。然而，发送方发送控制数据包的原因非常有限。更准确地说：
* At the end of the session, a "Close Session" ("A" flag) packet is sent. Replaying this packet has no impact since the receivers already left.
* 在会话结束时，发送“关闭会话”（“标志”）数据包。重播此数据包没有影响，因为接收者已经离开。
* 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。
This analysis shows that ALC itself is robust in front of replay attacks within the same session.
该分析表明，ALC本身在同一会话中的重播攻击面前是鲁棒的。
Now let us consider replay attacks across several ALC sessions. Since the key chain used in each session MUST differ, a packet replayed in a subsequent session will be identified as unauthentic. Therefore, ALC is robust in front of replay attacks across different sessions.
现在让我们考虑几个ALC会话的重放攻击。由于每个会话中使用的密钥链必须不同，因此在后续会话中重播的数据包将被标识为未经验证。因此，ALC在跨不同会话的重播攻击面前是健壮的。
As specified in Section 1.1, this specification does not consider the packets that may be sent by receivers, for instance, NORM's feedback packets. When a back channel is used, its security is critical to the global security, and an appropriate security mechanism MUST be used. [RMT-SIMPLE-AUTH] describes several techniques that can be used to that purpose. However, the authentication and integrity
如第1.1节所述，本规范不考虑接收机可能发送的分组，例如，范数的反馈分组。使用后台通道时，其安全性对全局安全至关重要，必须使用适当的安全机制。[RMT-SIMPLE-AUTH]介绍了几种可用于此目的的技术。但是，身份验证和完整性
verification of the packets sent by receivers on the back channel, if any, is out of the scope of this document.
本文件不包括对反向通道上接收器发送的数据包（如有）的验证。
IANA has registered the following attributes according to this document. The registries are provided by [RFC4442] under the "Timed Efficient Stream Loss-tolerant Authentication (TESLA) Parameters" registry [TESLA-REG]. Following the policies outlined in [RFC4442], the values in the range up to 240 (including 240) for the following attributes are assigned after expert review by the MSEC working group or its designated successor. The values in the range from 241 to 255 are reserved for private use.
IANA已根据本文件注册了以下属性。注册表由[RFC4442]在“定时高效流丢失容忍认证（TESLA）参数”注册表[TESLA-REG]下提供。根据[RFC4442]中概述的政策，在MSEC工作组或其指定继任者进行专家审查后，分配以下属性的最大240（包括240）范围内的值。241到255之间的值保留供私人使用。
Cryptographic Pseudo-Random Function, TESLA-PRF: All implementations MUST support HMAC-SHA-256 (default).
加密伪随机函数，TESLA-PRF：所有实现必须支持HMAC-SHA-256（默认值）。
+------------------------+-------+
| PRF name | Value |
+------------------------+-------+
| HMAC-SHA1 | 0 |
| HMAC-SHA-224 | 1 |
| HMAC-SHA-256 (default) | 2 |
| HMAC-SHA-384 | 3 |
| HMAC-SHA-512 | 4 |
+------------------------+-------+
+------------------------+-------+
| PRF name | Value |
+------------------------+-------+
| HMAC-SHA1 | 0 |
| HMAC-SHA-224 | 1 |
| HMAC-SHA-256 (default) | 2 |
| HMAC-SHA-384 | 3 |
| HMAC-SHA-512 | 4 |
+------------------------+-------+
Cryptographic Message Authentication Code (MAC) Function, TESLA-MAC: All implementations MUST support HMAC-SHA-256 (default). These MAC schemes are used both for the computing of regular MAC and the Group MAC (if applicable).
加密消息认证码（MAC）功能，TESLA-MAC：所有实现必须支持HMAC-SHA-256（默认）。这些MAC方案用于计算常规MAC和组MAC（如果适用）。
+------------------------+-------+
| MAC name | Value |
+------------------------+-------+
| HMAC-SHA1 | 0 |
| HMAC-SHA-224 | 1 |
| HMAC-SHA-256 (default) | 2 |
| HMAC-SHA-384 | 3 |
| HMAC-SHA-512 | 4 |
+------------------------+-------+
+------------------------+-------+
| MAC name | Value |
+------------------------+-------+
| HMAC-SHA1 | 0 |
| HMAC-SHA-224 | 1 |
| HMAC-SHA-256 (default) | 2 |
| HMAC-SHA-384 | 3 |
| HMAC-SHA-512 | 4 |
+------------------------+-------+
Furthermore, IANA has created two new registries. Here also, the values in the range up to 240 (including 240) for the following attributes are assigned after expert review by the MSEC working group or its designated successor. The values in the range from 241 to 255 are reserved for private use.
此外，IANA还创建了两个新的注册中心。这里，以下属性的值在MSEC工作组或其指定继任者的专家审查后分配，范围为240（包括240）。241到255之间的值保留供私人使用。
Signature Encoding Algorithm, TESLA-SIG-ALGO: All implementations MUST support RSASSA-PKCS1-v1_5 (default).
签名编码算法，TESLA-SIG-ALGO：所有实现必须支持RSASSA-PKCS1-v1_5（默认）。
+-----------------------------+-------+
| Signature Algorithm Name | Value |
+-----------------------------+-------+
| INVALID | 0 |
| RSASSA-PKCS1-v1_5 (default) | 1 |
| RSASSA-PSS | 2 |
+-----------------------------+-------+
+-----------------------------+-------+
| Signature Algorithm Name | Value |
+-----------------------------+-------+
| INVALID | 0 |
| RSASSA-PKCS1-v1_5 (default) | 1 |
| RSASSA-PSS | 2 |
+-----------------------------+-------+
Signature Cryptographic Function, TESLA-SIG-CRYPTO-FUNC: All implementations MUST support SHA-256 (default).
签名加密函数，TESLA-SIG-CRYPTO-FUNC：所有实现必须支持SHA-256（默认）。
+-----------------------------+-------+
| Cryptographic Function Name | Value |
+-----------------------------+-------+
| INVALID | 0 |
| SHA-1 | 1 |
| SHA-224 | 2 |
| SHA-256 (default) | 3 |
| SHA-384 | 4 |
| SHA-512 | 5 |
+-----------------------------+-------+
+-----------------------------+-------+
| Cryptographic Function Name | Value |
+-----------------------------+-------+
| INVALID | 0 |
| SHA-1 | 1 |
| SHA-224 | 2 |
| SHA-256 (default) | 3 |
| SHA-384 | 4 |
| SHA-512 | 5 |
+-----------------------------+-------+
The authors are grateful to Yaron Sheffer, Brian Weis, Ramu Panayappan, Ran Canetti, David L. Mills, Brian Adamson, and Lionel Giraud for their valuable comments while preparing this document. The authors are also grateful to Brian Weis for the digital signature details.
作者感谢Yaron Sheffer、Brian Weis、Ramu Panayappan、Ran Canetti、David L.Mills、Brian Adamson和Lionel Giraud在编写本文件时提出的宝贵意见。作者还感谢Brian Weis提供的数字签名细节。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[RFC1305]Mills，D.，“网络时间协议（版本3）规范，实施”，RFC1305，1992年3月。
[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月。
[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月。
[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月。
[TESLA-REG] "TESLA Parameters IANA Registry", http://www.iana.org.
[TESLA-REG]“特斯拉参数IANA注册表”，http://www.iana.org.
[NTP-NTPv4] Burbank, J., Kasch, W., Martin, J., Ed., and D. Mills, "The Network Time Protocol Version 4 Protocol And Algorithm Specification", Work in Progress, October 2009.
[NTP-NTPv4]Burbank，J.，Kasch，W.，Martin，J.，Ed.，和D.Mills，“网络时间协议版本4协议和算法规范”，正在进行的工作，2009年10月。
[Perrig04] Perrig, A. and J. Tygar, "Secure Broadcast Communication in Wired and Wireless Networks", Kluwer Academic Publishers ISBN 0-7923-7650-1, 2004.
[Perrig04]Perrig，A.和J.Tygar，“有线和无线网络中的安全广播通信”，Kluwer学术出版社ISBN 0-7923-7650-12004。
[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月。
[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月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 4330，2006年1月。
[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月。
[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006.
[RFC4383]Baugher，M.和E.Carrara，“在安全实时传输协议（SRTP）中使用定时高效流丢失容忍认证（TESLA）”，RFC 4383，2006年2月。
[RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006.
[RFC4442]Fries，S.和H.Tschofenig，“自举定时高效流丢失容忍认证（TESLA）”，RFC 4442，2006年3月。
[RMT-FLUTE] Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, August 2009.
[RMT-FLUTE]Paila，T.，Walsh，R.，Luby，M.，Lehtonen，R.，和V.Roca，“长笛-单向运输上的文件交付”，在建工程，2009年8月。
[RMT-SIMPLE-AUTH] Roca, V., "Simple Authentication Schemes for the ALC and NORM Protocols", Work in Progress, October 2009.
[RMT-SIMPLE-AUTH]Roca，V.，“ALC和NORM协议的简单认证方案”，正在进行的工作，2009年10月。
Authors' Addresses
作者地址
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/~roca/
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/~roca/
Aurelien Francillon INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
奥雷林·弗朗西隆·因里亚655，av。欧洲伊诺瓦利；蒙博诺圣伊斯梅尔塞德斯38334法国
EMail: aurelien.francillon@inria.fr
URI: http://planete.inrialpes.fr/~francill/
EMail: aurelien.francillon@inria.fr
URI: http://planete.inrialpes.fr/~francill/
Sebastien Faurite INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
塞巴斯蒂安·福瑞特因里亚655，av。欧洲伊诺瓦利；蒙博诺圣伊斯梅尔塞德斯38334法国
EMail: faurite@lcpc.fr
EMail: faurite@lcpc.fr