Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 6347 RTFM, Inc.
Obsoletes: 4347 N. Modadugu
Category: Standards Track Google, Inc.
ISSN: 2070-1721 January 2012
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 6347 RTFM, Inc.
Obsoletes: 4347 N. Modadugu
Category: Standards Track Google, Inc.
ISSN: 2070-1721 January 2012
Datagram Transport Layer Security Version 1.2
数据报传输层安全版本1.2
Abstract
摘要
This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2.
本文件规定了数据报传输层安全（DTLS）协议的1.2版。DTLS协议为数据报协议提供通信隐私。该协议允许客户机/服务器应用程序以防止窃听、篡改或消息伪造的方式进行通信。DTLS协议基于传输层安全（TLS）协议，并提供等效的安全保证。DTLS协议保留了底层传输的数据报语义。本文档更新了DTLS 1.0以与TLS 1.2版配合使用。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6347.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6347.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................4
1.1. Requirements Terminology ...................................5
2. Usage Model .....................................................5
3. Overview of DTLS ................................................5
3.1. Loss-Insensitive Messaging .................................6
3.2. Providing Reliability for Handshake ........................6
3.2.1. Packet Loss .........................................6
3.2.2. Reordering ..........................................7
3.2.3. Message Size ........................................7
3.3. Replay Detection ...........................................7
4. Differences from TLS ............................................7
4.1. Record Layer ...............................................8
4.1.1. Transport Layer Mapping ............................10
4.1.1.1. PMTU Issues ...............................10
4.1.2. Record Payload Protection ..........................12
4.1.2.1. MAC .......................................12
4.1.2.2. Null or Standard Stream Cipher ............13
4.1.2.3. Block Cipher ..............................13
4.1.2.4. AEAD Ciphers ..............................13
4.1.2.5. New Cipher Suites .........................13
4.1.2.6. Anti-Replay ...............................13
4.1.2.7. Handling Invalid Records ..................14
4.2. The DTLS Handshake Protocol ...............................14
4.2.1. Denial-of-Service Countermeasures ..................15
4.2.2. Handshake Message Format ...........................18
4.2.3. Handshake Message Fragmentation and Reassembly .....19
4.2.4. Timeout and Retransmission .........................20
4.2.4.1. Timer Values ..............................24
4.2.5. ChangeCipherSpec ...................................25
4.2.6. CertificateVerify and Finished Messages ............25
4.2.7. Alert Messages .....................................25
4.2.8. Establishing New Associations with Existing
Parameters .........................................25
4.3. Summary of New Syntax .....................................26
4.3.1. Record Layer .......................................26
4.3.2. Handshake Protocol .................................27
5. Security Considerations ........................................27
6. Acknowledgments ................................................28
7. IANA Considerations ............................................28
8. Changes since DTLS 1.0 .........................................29
9. References .....................................................30
9.1. Normative References ......................................30
9.2. Informative References ....................................31
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
2. Usage Model .....................................................5
3. Overview of DTLS ................................................5
3.1. Loss-Insensitive Messaging .................................6
3.2. Providing Reliability for Handshake ........................6
3.2.1. Packet Loss .........................................6
3.2.2. Reordering ..........................................7
3.2.3. Message Size ........................................7
3.3. Replay Detection ...........................................7
4. Differences from TLS ............................................7
4.1. Record Layer ...............................................8
4.1.1. Transport Layer Mapping ............................10
4.1.1.1. PMTU Issues ...............................10
4.1.2. Record Payload Protection ..........................12
4.1.2.1. MAC .......................................12
4.1.2.2. Null or Standard Stream Cipher ............13
4.1.2.3. Block Cipher ..............................13
4.1.2.4. AEAD Ciphers ..............................13
4.1.2.5. New Cipher Suites .........................13
4.1.2.6. Anti-Replay ...............................13
4.1.2.7. Handling Invalid Records ..................14
4.2. The DTLS Handshake Protocol ...............................14
4.2.1. Denial-of-Service Countermeasures ..................15
4.2.2. Handshake Message Format ...........................18
4.2.3. Handshake Message Fragmentation and Reassembly .....19
4.2.4. Timeout and Retransmission .........................20
4.2.4.1. Timer Values ..............................24
4.2.5. ChangeCipherSpec ...................................25
4.2.6. CertificateVerify and Finished Messages ............25
4.2.7. Alert Messages .....................................25
4.2.8. Establishing New Associations with Existing
Parameters .........................................25
4.3. Summary of New Syntax .....................................26
4.3.1. Record Layer .......................................26
4.3.2. Handshake Protocol .................................27
5. Security Considerations ........................................27
6. Acknowledgments ................................................28
7. IANA Considerations ............................................28
8. Changes since DTLS 1.0 .........................................29
9. References .....................................................30
9.1. Normative References ......................................30
9.2. Informative References ....................................31
TLS [TLS] is the most widely deployed protocol for securing network traffic. It is widely used for protecting Web traffic and for e-mail protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of TLS is that it provides a transparent connection-oriented channel. Thus, it is easy to secure an application protocol by inserting TLS between the application layer and the transport layer. However, TLS must run over a reliable transport channel -- typically TCP [TCP]. Therefore, it cannot be used to secure unreliable datagram traffic.
TLS[TLS]是用于保护网络流量的最广泛部署的协议。它广泛用于保护Web流量和电子邮件协议，如IMAP[IMAP]和POP[POP]。TLS的主要优点是它提供了一个透明的面向连接的通道。因此，通过在应用层和传输层之间插入TLS，很容易保护应用协议。但是，TLS必须运行在可靠的传输通道上——通常是TCP[TCP]。因此，它不能用于保护不可靠的数据报流量。
An increasing number of application layer protocols have been designed that use UDP transport. In particular, protocols such as the Session Initiation Protocol (SIP) [SIP] and electronic gaming protocols are increasingly popular. (Note that SIP can run over both TCP and UDP, but that there are situations in which UDP is preferable.) Currently, designers of these applications are faced with a number of unsatisfactory choices. First, they can use IPsec [RFC4301]. However, for a number of reasons detailed in [WHYIPSEC], this is only suitable for some applications. Second, they can design a custom application layer security protocol. Unfortunately, although application layer security protocols generally provide superior security properties (e.g., end-to-end security in the case of S/MIME), they typically require a large amount of effort to design -- in contrast to the relatively small amount of effort required to run the protocol over TLS.
越来越多的应用层协议被设计为使用UDP传输。特别地，诸如会话发起协议（SIP）[SIP]和电子游戏协议之类的协议越来越流行。（请注意，SIP可以在TCP和UDP上运行，但在某些情况下UDP更可取。）目前，这些应用程序的设计者面临着许多不令人满意的选择。首先，他们可以使用IPsec[RFC4301]。然而，由于[WHYIPSEC]中详述的许多原因，这仅适用于某些应用。其次，他们可以设计定制的应用层安全协议。不幸的是，尽管应用层安全协议通常提供优越的安全属性（例如，S/MIME情况下的端到端安全性），但它们通常需要大量的设计工作——而在TLS上运行协议所需的工作相对较少。
In many cases, the most desirable way to secure client/server applications would be to use TLS; however, the requirement for datagram semantics automatically prohibits use of TLS. This memo describes a protocol for this purpose: Datagram Transport Layer Security (DTLS). DTLS is deliberately designed to be as similar to TLS as possible, both to minimize new security invention and to maximize the amount of code and infrastructure reuse.
在许多情况下，保护客户机/服务器应用程序的最理想方式是使用TLS；然而，对数据报语义的要求自动禁止使用TLS。本备忘录描述了用于此目的的协议：数据报传输层安全（DTLS）。DTL被刻意设计为尽可能类似于TLS，既可以最小化新的安全发明，又可以最大限度地提高代码和基础设施的重用量。
DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This document introduces a new version of DTLS, DTLS 1.2, which is defined as a series of deltas to TLS 1.2 [TLS12]. There is no DTLS 1.1; that version number was skipped in order to harmonize version numbers with TLS. This version also clarifies some confusing points in the DTLS 1.0 specification.
DTLS 1.0[DTLS1]最初定义为[TLS11]中的增量。本文档介绍了DTLS的新版本DTLS 1.2，定义为TLS 1.2[TLS12]的一系列增量。没有DTLS 1.1；为了使版本号与TLS一致，跳过了该版本号。此版本还澄清了DTLS 1.0规范中的一些混淆点。
Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of course), just as TLS 1.2 implementations can interoperate with previous versions of TLS (see Appendix E.1 of [TLS12] for details), with the exception that there is no DTLS version of SSLv2 or SSLv3, so backward compatibility issues for those protocols do not apply.
同时使用DTLS 1.2和DTLS 1.0的实现可以与只使用DTLS 1.0的实现进行互操作（当然使用DTLS 1.0），正如TLS 1.2实现可以与TLS的早期版本进行互操作（有关详细信息，请参见[TLS12]的附录E.1），但没有SSLv2或SSLv3的DTLS版本，因此，这些协议的向后兼容性问题不适用。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [REQ].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[REQ]中的说明进行解释。
The DTLS protocol is designed to secure data between communicating applications. It is designed to run in application space, without requiring any kernel modifications.
DTLS协议旨在保护通信应用程序之间的数据安全。它被设计为在应用程序空间中运行，不需要任何内核修改。
Datagram transport does not require or provide reliable or in-order delivery of data. The DTLS protocol preserves this property for payload data. Applications such as media streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data. The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or re-ordered data traffic.
数据报传输不需要或不提供可靠或有序的数据传输。DTLS协议为有效负载数据保留此属性。由于传输数据的延迟敏感性，媒体流、互联网电话和在线游戏等应用程序使用数据报传输进行通信。当DTLS协议用于安全通信时，此类应用程序的行为保持不变，因为DTLS协议不会补偿丢失或重新排序的数据通信。
The basic design philosophy of DTLS is to construct "TLS over datagram transport". The reason that TLS cannot be used directly in datagram environments is simply that packets may be lost or reordered. TLS has no internal facilities to handle this kind of unreliability; therefore, TLS implementations break when rehosted on datagram transport. The purpose of DTLS is to make only the minimal changes to TLS required to fix this problem. To the greatest extent possible, DTLS is identical to TLS. Whenever we need to invent new mechanisms, we attempt to do so in such a way that preserves the style of TLS.
DTLS的基本设计理念是构建“基于数据报传输的TLS”。TLS不能直接用于数据报环境的原因很简单，数据包可能丢失或重新排序。TLS没有处理此类不可靠性的内部设施；因此，TLS实现在数据报传输上重新承载时中断。DTLS的目的是仅对TLS进行修复此问题所需的最小更改。尽可能地，DTLS与TLS相同。每当我们需要发明新的机制时，我们都试图以保留TLS风格的方式来实现。
Unreliability creates problems for TLS at two levels:
不可靠性会在两个层面上给TLS带来问题：
1. TLS does not allow independent decryption of individual records. Because the integrity check depends on the sequence number, if record N is not received, then the integrity check on record N+1 will be based on the wrong sequence number and thus will fail. (Note that prior to TLS 1.1, there was no explicit IV and so decryption would also fail.)
1. TLS不允许对单个记录进行独立解密。由于完整性检查取决于序列号，如果未收到记录N，则记录N+1上的完整性检查将基于错误的序列号，因此将失败。（请注意，在TLS 1.1之前，没有显式IV，因此解密也会失败。）
2. The TLS handshake layer assumes that handshake messages are delivered reliably and breaks if those messages are lost.
2. TLS握手层假定握手消息是可靠传递的，如果这些消息丢失，则会中断。
The rest of this section describes the approach that DTLS uses to solve these problems.
本节的其余部分描述了DTLS用于解决这些问题的方法。
In TLS's traffic encryption layer (called the TLS Record Layer), records are not independent. There are two kinds of inter-record dependency:
在TLS的流量加密层（称为TLS记录层）中，记录不是独立的。有两种记录间依赖关系：
1. Cryptographic context (stream cipher key stream) is retained between records.
1. 在记录之间保留加密上下文（流密码密钥流）。
2. Anti-replay and message reordering protection are provided by a MAC that includes a sequence number, but the sequence numbers are implicit in the records.
2. 反重播和消息重新排序保护由包含序列号的MAC提供，但序列号在记录中是隐式的。
DTLS solves the first problem by banning stream ciphers. DTLS solves the second problem by adding explicit sequence numbers.
DTLS通过禁止流密码解决了第一个问题。DTLS通过添加显式序列号解决了第二个问题。
The TLS handshake is a lockstep cryptographic handshake. Messages must be transmitted and received in a defined order; any other order is an error. Clearly, this is incompatible with reordering and message loss. In addition, TLS handshake messages are potentially larger than any given datagram, thus creating the problem of IP fragmentation. DTLS must provide fixes for both of these problems.
TLS握手是一种锁步加密握手。信息必须按照规定的顺序发送和接收；任何其他顺序都是错误的。显然，这与重新排序和消息丢失不兼容。此外，TLS握手消息可能比任何给定的数据报都大，因此会产生IP碎片问题。DTL必须为这两个问题提供修复。
DTLS uses a simple retransmission timer to handle packet loss. The following figure demonstrates the basic concept, using the first phase of the DTLS handshake:
DTLS使用一个简单的重传计时器来处理数据包丢失。下图使用DTLS握手的第一阶段演示了基本概念：
Client Server
------ ------
ClientHello ------>
Client Server
------ ------
ClientHello ------>
X<-- HelloVerifyRequest (lost)
X<--HelloVerifyRequest（丢失）
[Timer Expires]
[计时器过期]
ClientHello ------>
(retransmit)
ClientHello ------>
(retransmit)
Once the client has transmitted the ClientHello message, it expects to see a HelloVerifyRequest from the server. However, if the server's message is lost, the client knows that either the ClientHello or the HelloVerifyRequest has been lost and retransmits. When the server receives the retransmission, it knows to retransmit.
一旦客户机传输了ClientHello消息，它希望看到来自服务器的Helloverify请求。但是，如果服务器的消息丢失，客户端会知道ClientHello或HelloVerifyRequest已丢失并重新传输。当服务器接收到重新传输时，它知道重新传输。
The server also maintains a retransmission timer and retransmits when that timer expires.
服务器还维护一个重新传输计时器，并在该计时器过期时重新传输。
Note that timeout and retransmission do not apply to the HelloVerifyRequest, because this would require creating state on the server. The HelloVerifyRequest is designed to be small enough that it will not itself be fragmented, thus avoiding concerns about interleaving multiple HelloVerifyRequests.
请注意，超时和重新传输不适用于HelloVerifyRequest，因为这需要在服务器上创建状态。HelloVerifyRequest被设计为足够小，以至于它本身不会被分割，从而避免了交叉处理多个HelloVerifyRequest的问题。
In DTLS, each handshake message is assigned a specific sequence number within that handshake. When a peer receives a handshake message, it can quickly determine whether that message is the next message it expects. If it is, then it processes it. If not, it queues it for future handling once all previous messages have been received.
在DTLS中，每个握手消息在该握手中被分配一个特定的序列号。当对等方收到握手消息时，它可以快速确定该消息是否是它期望的下一条消息。如果是，那么它会处理它。如果没有，则在接收到所有以前的消息后，它会将其排队以备将来处理。
TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to <1500 bytes if IP fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records, each of which is intended to fit in a single IP datagram. Each DTLS handshake message contains both a fragment offset and a fragment length. Thus, a recipient in possession of all bytes of a handshake message can reassemble the original unfragmented message.
TLS和DTLS握手消息可能非常大（理论上最多为2^24-1字节，实际上是很多KB）。相反，如果不需要IP分段，UDP数据报通常限制在<1500字节。为了补偿此限制，每个DTLS握手消息可以在多个DTLS记录上分段，每个DTLS记录都旨在适合单个IP数据报。每个DTLS握手消息都包含片段偏移量和片段长度。因此，拥有握手消息的所有字节的接收者可以重新组合原始的未分段消息。
DTLS optionally supports record replay detection. The technique used is the same as in IPsec AH/ESP, by maintaining a bitmap window of received records. Records that are too old to fit in the window and records that have previously been received are silently discarded. The replay detection feature is optional, since packet duplication is not always malicious, but can also occur due to routing errors. Applications may conceivably detect duplicate packets and accordingly modify their data transmission strategy.
DTLS可选地支持记录重播检测。使用的技术与IPsec AH/ESP中的相同，通过维护接收记录的位图窗口。太旧而无法放入窗口的记录和以前收到的记录将被自动丢弃。重播检测功能是可选的，因为数据包复制并不总是恶意的，但也可能由于路由错误而发生。可以想象，应用程序可以检测重复分组并相应地修改其数据传输策略。
As mentioned in Section 3, DTLS is intentionally very similar to TLS. Therefore, instead of presenting DTLS as a new protocol, we present it as a series of deltas from TLS 1.2 [TLS12]. Where we do not explicitly call out differences, DTLS is the same as in [TLS12].
如第3节所述，DTLS有意与TLS非常相似。因此，我们没有将DTLS作为一个新协议来表示，而是将其表示为TLS1.2[TLS12]中的一系列增量。当我们没有明确指出差异时，DTL与[TLS12]中的相同。
The DTLS record layer is extremely similar to that of TLS 1.2. The only change is the inclusion of an explicit sequence number in the record. This sequence number allows the recipient to correctly verify the TLS MAC. The DTLS record format is shown below:
DTLS记录层与TLS 1.2非常相似。唯一的变化是在记录中包含一个显式序列号。此序列号允许收件人正确验证TLS MAC。DTLS记录格式如下所示：
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
type Equivalent to the type field in a TLS 1.2 record.
与TLS 1.2记录中的类型字段等效的类型。
version The version of the protocol being employed. This document describes DTLS version 1.2, which uses the version { 254, 253 }. The version value of 254.253 is the 1's complement of DTLS version 1.2. This maximal spacing between TLS and DTLS version numbers ensures that records from the two protocols can be easily distinguished. It should be noted that future on-the-wire version numbers of DTLS are decreasing in value (while the true version number is increasing in value.)
版本正在使用的协议的版本。本文档描述了DTLS版本1.2，它使用版本{254，253}。版本值254.253是DTLS版本1.2的1的补充。TLS和DTLS版本号之间的最大间隔确保了两个协议中的记录可以很容易区分。应该注意的是，DTL的未来在线版本号的值正在减少（而真实版本号的值正在增加）
epoch A counter value that is incremented on every cipher state change.
历元每次密码状态更改时递增的计数器值。
sequence_number The sequence number for this record.
sequence\u number此记录的序列号。
length Identical to the length field in a TLS 1.2 record. As in TLS 1.2, the length should not exceed 2^14.
长度与TLS 1.2记录中的长度字段相同。与TLS 1.2一样，长度不应超过2^14。
fragment Identical to the fragment field of a TLS 1.2 record.
片段与TLS 1.2记录的片段字段相同。
DTLS uses an explicit sequence number, rather than an implicit one, carried in the sequence_number field of the record. Sequence numbers are maintained separately for each epoch, with each sequence_number initially being 0 for each epoch. For instance, if a handshake message from epoch 0 is retransmitted, it might have a sequence number after a message from epoch 1, even if the message from epoch 1
DTLS使用显式序列号，而不是隐式序列号，在记录的序列号字段中携带。序列号为每个历元单独维护，每个历元的序列号最初为0。例如，如果重新传输来自历元0的握手消息，则它可能在来自历元1的消息之后有一个序列号，即使来自历元1的消息
was transmitted first. Note that some care needs to be taken during the handshake to ensure that retransmitted messages use the right epoch and keying material.
这是第一次传播。请注意，在握手过程中需要特别小心，以确保重新传输的消息使用正确的历元和键控材料。
If several handshakes are performed in close succession, there might be multiple records on the wire with the same sequence number but from different cipher states. The epoch field allows recipients to distinguish such packets. The epoch number is initially zero and is incremented each time a ChangeCipherSpec message is sent. In order to ensure that any given sequence/epoch pair is unique, implementations MUST NOT allow the same epoch value to be reused within two times the TCP maximum segment lifetime. In practice, TLS implementations rarely rehandshake; therefore, we do not expect this to be a problem.
如果连续执行几次握手，则线路上可能有多条具有相同序列号但来自不同密码状态的记录。“历元”字段允许收件人区分此类数据包。历元编号最初为零，并且在每次发送ChangeCipherSpec消息时递增。为了确保任何给定的序列/历元对都是唯一的，实现不得允许在TCP最大段生存期的两倍内重用相同的历元值。在实践中，TLS实现很少重新处理；因此，我们不认为这是一个问题。
Note that because DTLS records may be reordered, a record from epoch 1 may be received after epoch 2 has begun. In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems they MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP [TCP] to allow for packet reordering. (Note that the intention here is that implementors use the current guidance from the IETF for MSL, not that they attempt to interrogate the MSL that the system TCP stack is using.) Until the handshake has completed, implementations MUST accept packets from the old epoch.
请注意，由于DTLS记录可能会被重新排序，因此在第2个历元开始之后，可能会收到来自第1个历元的记录。一般来说，实现应该丢弃来自早期时代的数据包，但是如果数据包丢失导致明显的问题，它们可以选择保留来自早期时代的键控材料，直到为TCP[TCP]指定的默认MSL，以允许数据包重新排序。（注意，这里的意图是实现者使用IETF针对MSL的当前指导，而不是试图询问系统TCP堆栈正在使用的MSL。）在握手完成之前，实现必须接受来自旧时代的数据包。
Conversely, it is possible for records that are protected by the newly negotiated context to be received prior to the completion of a handshake. For instance, the server may send its Finished message and then start transmitting data. Implementations MAY either buffer or discard such packets, though when DTLS is used over reliable transports (e.g., SCTP), they SHOULD be buffered and processed once the handshake completes. Note that TLS's restrictions on when packets may be sent still apply, and the receiver treats the packets as if they were sent in the right order. In particular, it is still impermissible to send data prior to completion of the first handshake.
相反，受新协商上下文保护的记录可能在握手完成之前被接收。例如，服务器可以发送完成的消息，然后开始传输数据。实现可以缓冲或丢弃此类数据包，但当通过可靠传输（例如，SCTP）使用DTL时，应在握手完成后对其进行缓冲和处理。请注意，TLS对何时发送数据包的限制仍然适用，并且接收方将数据包视为按照正确的顺序发送。特别是，仍然不允许在第一次握手完成之前发送数据。
Note that in the special case of a rehandshake on an existing association, it is safe to process a data packet immediately, even if the ChangeCipherSpec or Finished messages have not yet been received provided that either the rehandshake resumes the existing session or that it uses exactly the same security parameters as the existing association. In any other case, the implementation MUST wait for the receipt of the Finished message to prevent downgrade attack.
请注意，在现有关联上的rehandshake的特殊情况下，即使尚未收到ChangeCipherSpec或Finished消息，只要rehandshake恢复现有会话或使用与现有关联完全相同的安全参数，也可以安全地立即处理数据包。在任何其他情况下，实现必须等待收到完成的消息，以防止降级攻击。
As in TLS, implementations MUST either abandon an association or rehandshake prior to allowing the sequence number to wrap.
在TLS中，实现必须在允许序列号包装之前放弃关联或重新handshake。
Similarly, implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association, terminating the old association as described in Section 4.2.8. In practice, implementations rarely rehandshake repeatedly on the same channel, so this is not likely to be an issue.
类似地，实现必须不允许对历元进行包装，而是必须建立新的关联，如第4.2.8节所述终止旧关联。在实践中，实现很少在同一个通道上重复地重新握手，因此这不太可能成为问题。
Each DTLS record MUST fit within a single datagram. In order to avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer.
每个DTLS记录必须适合单个数据报。为了避免IP碎片，DTLS记录层的客户端应尝试调整记录的大小，使其符合从记录层获得的任何PMTU估计值。
Note that unlike IPsec, DTLS records do not contain any association identifiers. Applications must arrange to multiplex between associations. With UDP, this is presumably done with the host/port number.
请注意，与IPsec不同，DTLS记录不包含任何关联标识符。应用程序必须安排在关联之间进行多路传输。对于UDP，这可能是通过主机/端口号完成的。
Multiple DTLS records may be placed in a single datagram. They are simply encoded consecutively. The DTLS record framing is sufficient to determine the boundaries. Note, however, that the first byte of the datagram payload must be the beginning of a record. Records may not span datagrams.
多个DTLS记录可以放在一个数据报中。它们只是连续编码。DTLS记录帧足以确定边界。但是，请注意，数据报有效负载的第一个字节必须是记录的开头。记录不能跨越数据报。
Some transports, such as DCCP [DCCP] provide their own sequence numbers. When carried over those transports, both the DTLS and the transport sequence numbers will be present. Although this introduces a small amount of inefficiency, the transport layer and DTLS sequence numbers serve different purposes; therefore, for conceptual simplicity, it is superior to use both sequence numbers. In the future, extensions to DTLS may be specified that allow the use of only one set of sequence numbers for deployment in constrained environments.
有些传输，如DCCP[DCCP]提供它们自己的序列号。通过这些传输时，DTL和传输序列号都将出现。虽然这带来了少量的低效，但传输层和DTLS序列号的用途不同；因此，为了概念上的简单性，最好同时使用两个序列号。将来，可能会指定DTL的扩展，只允许在受限环境中使用一组序列号进行部署。
Some transports, such as DCCP, provide congestion control for traffic carried over them. If the congestion window is sufficiently narrow, DTLS handshake retransmissions may be held rather than transmitted immediately, potentially leading to timeouts and spurious retransmission. When DTLS is used over such transports, care should be taken not to overrun the likely congestion window. [DCCPDTLS] defines a mapping of DTLS to DCCP that takes these issues into account.
一些传输，如DCCP，为通过它们传输的流量提供拥塞控制。如果拥塞窗口足够窄，则DTLS握手重传可能被保持而不是立即传输，这可能导致超时和伪重传。当通过此类传输使用DTL时，应注意不要超出可能的拥塞窗口。[DCCPDTLS]定义了DTLS到DCCP的映射，该映射考虑了这些问题。
In general, DTLS's philosophy is to leave PMTU discovery to the application. However, DTLS cannot completely ignore PMTU for three reasons:
通常，DTLS的理念是将PMTU的发现留给应用程序。但是，DTLS不能完全忽略PMTU，原因有三：
- The DTLS record framing expands the datagram size, thus lowering the effective PMTU from the application's perspective.
- DTLS记录帧扩展了数据报的大小，从而从应用程序的角度降低了有效的PMTU。
- In some implementations, the application may not directly talk to the network, in which case the DTLS stack may absorb ICMP [RFC1191] "Datagram Too Big" indications or ICMPv6 [RFC4443] "Packet Too Big" indications.
- 在一些实现中，应用程序可能不会直接与网络通信，在这种情况下，DTLS堆栈可能会吸收ICMP[RFC1191]“数据报太大”指示或ICMPv6[RFC4443]“数据包太大”指示。
- The DTLS handshake messages can exceed the PMTU.
- DTLS握手消息可能超过PMTU。
In order to deal with the first two issues, the DTLS record layer SHOULD behave as described below.
为了处理前两个问题，DTLS记录层的行为应如下所述。
If PMTU estimates are available from the underlying transport protocol, they should be made available to upper layer protocols. In particular:
如果可从底层传输协议获得PMTU估计值，则应将其提供给上层协议。特别地：
- For DTLS over UDP, the upper layer protocol SHOULD be allowed to obtain the PMTU estimate maintained in the IP layer.
- 对于UDP上的DTL，应允许上层协议获取IP层中维护的PMTU估计值。
- For DTLS over DCCP, the upper layer protocol SHOULD be allowed to obtain the current estimate of the PMTU.
- 对于DCCP上的DTL，应允许上层协议获取PMTU的当前估计值。
- For DTLS over TCP or SCTP, which automatically fragment and reassemble datagrams, there is no PMTU limitation. However, the upper layer protocol MUST NOT write any record that exceeds the maximum record size of 2^14 bytes.
- 对于TCP或SCTP上的DTL，它们自动分割和重新组装数据报，没有PMTU限制。但是，上层协议不能写入任何超过最大记录大小2^14字节的记录。
The DTLS record layer SHOULD allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing. Note that this number is only an estimate because of block padding and the potential use of DTLS compression.
DTLS记录层应允许上层协议发现DTLS处理预期的记录扩展量。注意，由于块填充和DTLS压缩的潜在使用，这个数字只是一个估计值。
If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in Section 14 of [DCCP]), then the DTLS record layer MUST inform the upper layer protocol of the error.
如果存在传输协议指示（通过ICMP或通过[DCCP]第14节中的拒绝发送数据报），则DTLS记录层必须将错误通知上层协议。
The DTLS record layer SHOULD NOT interfere with upper layer protocols performing PMTU discovery, whether via [RFC1191] or [RFC4821] mechanisms. In particular:
DTLS记录层不应通过[RFC1191]或[RFC4821]机制干扰上层协议执行PMTU发现。特别地：
- Where allowed by the underlying transport protocol, the upper layer protocol SHOULD be allowed to set the state of the DF bit (in IPv4) or prohibit local fragmentation (in IPv6).
- 在底层传输协议允许的情况下，应允许上层协议设置DF位的状态（在IPv4中）或禁止本地分段（在IPv6中）。
- If the underlying transport protocol allows the application to request PMTU probing (e.g., DCCP), the DTLS record layer should honor this request.
- 如果基础传输协议允许应用程序请求PMTU探测（例如DCCP），则DTLS记录层应满足该请求。
The final issue is the DTLS handshake protocol. From the perspective of the DTLS record layer, this is merely another upper layer protocol. However, DTLS handshakes occur infrequently and involve only a few round trips; therefore, the handshake protocol PMTU handling places a premium on rapid completion over accurate PMTU discovery. In order to allow connections under these circumstances, DTLS implementations SHOULD follow the following rules:
最后一个问题是DTLS握手协议。从DTLS记录层的角度来看，这只是另一个上层协议。然而，DTLS握手很少发生，并且只涉及少数往返；因此，握手协议PMTU处理比准确的PMTU发现更注重快速完成。为了在这些情况下允许连接，DTLS实现应遵循以下规则：
- If the DTLS record layer informs the DTLS handshake layer that a message is too big, it SHOULD immediately attempt to fragment it, using any existing information about the PMTU.
- 如果DTLS记录层通知DTLS握手层消息太大，它应该立即尝试使用任何关于PMTU的现有信息对其进行分段。
- If repeated retransmissions do not result in a response, and the PMTU is unknown, subsequent retransmissions SHOULD back off to a smaller record size, fragmenting the handshake message as appropriate. This standard does not specify an exact number of retransmits to attempt before backing off, but 2-3 seems appropriate.
- 如果重复的重新传输不会导致响应，并且PMTU未知，则后续的重新传输应退回到较小的记录大小，并酌情对握手消息进行分段。本标准未规定退后前尝试的准确重传次数，但2-3次似乎合适。
Like TLS, DTLS transmits data as a series of protected records. The rest of this section describes the details of that format.
与TLS一样，DTL将数据作为一系列受保护的记录进行传输。本节其余部分将介绍该格式的详细信息。
The DTLS MAC is the same as that of TLS 1.2. However, rather than using TLS's implicit sequence number, the sequence number used to compute the MAC is the 64-bit value formed by concatenating the epoch and the sequence number in the order they appear on the wire. Note that the DTLS epoch + sequence number is the same length as the TLS sequence number.
DTLS MAC与TLS 1.2相同。但是，用于计算MAC的序列号不是使用TLS的隐式序列号，而是按照历元和序列号在导线上出现的顺序连接而成的64位值。请注意，DTLS历元+序列号的长度与TLS序列号的长度相同。
TLS MAC calculation is parameterized on the protocol version number, which, in the case of DTLS, is the on-the-wire version, i.e., {254, 253} for DTLS 1.2.
TLS MAC计算在协议版本号上参数化，在DTLS的情况下，协议版本号是有线版本，即DTLS 1.2的{254，253}。
Note that one important difference between DTLS and TLS MAC handling is that in TLS, MAC errors must result in connection termination. In DTLS, the receiving implementation MAY simply discard the offending record and continue with the connection. This change is possible because DTLS records are not dependent on each other in the way that TLS records are.
请注意，DTLS和TLS MAC处理之间的一个重要区别是，在TLS中，MAC错误必须导致连接终止。在DTLS中，接收实现可以简单地丢弃有问题的记录并继续连接。这种变化是可能的，因为DTLS记录彼此之间的依赖性与TLS记录的依赖性不同。
In general, DTLS implementations SHOULD silently discard records with bad MACs or that are otherwise invalid. They MAY log an error. If a DTLS implementation chooses to generate an alert when it receives a message with an invalid MAC, it MUST generate a bad_record_mac alert
一般来说，DTLS实现应该悄悄地丢弃具有坏MAC或其他无效的记录。他们可能会记录一个错误。如果DTLS实现在接收到带有无效MAC的消息时选择生成警报，则必须生成坏记录MAC警报
with level fatal and terminate its connection state. Note that because errors do not cause connection termination, DTLS stacks are more efficient error type oracles than TLS stacks. Thus, it is especially important that the advice in Section 6.2.3.2 of [TLS12] be followed.
具有致命级别并终止其连接状态。请注意，由于错误不会导致连接终止，因此DTLS堆栈比TLS堆栈更有效。因此，遵循[TLS12]第6.2.3.2节中的建议尤为重要。
The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL cipher.
DTLS空密码的执行方式与TLS 1.2空密码完全相同。
The only stream cipher described in TLS 1.2 is RC4, which cannot be randomly accessed. RC4 MUST NOT be used with DTLS.
TLS 1.2中描述的唯一流密码是RC4，它不能被随机访问。RC4不得与DTL一起使用。
DTLS block cipher encryption and decryption are performed exactly as with TLS 1.2.
DTLS分组密码加密和解密的执行与TLS 1.2完全相同。
TLS 1.2 introduced authenticated encryption with additional data (AEAD) cipher suites. The existing AEAD cipher suites, defined in [ECCGCM] and [RSAGCM], can be used with DTLS exactly as with TLS 1.2.
TLS 1.2引入了带有附加数据的认证加密（AEAD）密码套件。[ECCGCM]和[RSAGCM]中定义的现有AEAD密码套件可以与TLS 1.2一样与DTL一起使用。
Upon registration, new TLS cipher suites MUST indicate whether they are suitable for DTLS usage and what, if any, adaptations must be made (see Section 7 for IANA considerations).
注册后，新的TLS密码套件必须说明它们是否适合DTLS使用，以及必须进行哪些修改（IANA注意事项见第7节）。
DTLS records contain a sequence number to provide replay protection. Sequence number verification SHOULD be performed using the following sliding window procedure, borrowed from Section 3.4.3 of [ESP].
DTLS记录包含一个序列号以提供重播保护。序列号验证应使用以下滑动窗口程序进行，从[ESP]第3.4.3节中借用。
The receiver packet counter for this session MUST be initialized to zero when the session is established. For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the life of this session. This SHOULD be the first check applied to a packet after it has been matched to a session, to speed rejection of duplicate records.
建立会话时，此会话的接收器数据包计数器必须初始化为零。对于每个接收到的记录，接收方必须验证该记录包含的序列号是否与此会话期间接收到的任何其他记录的序列号不重复。这应该是在数据包与会话匹配后应用于数据包的第一次检查，以加快重复记录的拒绝。
Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit.) A minimum window size of 32 MUST be supported, but a
通过使用滑动接收窗口拒绝重复项。（如何实现窗口是一个局部问题，但以下文本描述了实现必须展示的功能。）必须支持最小窗口大小32，但
window size of 64 is preferred and SHOULD be employed as the default. Another window size (larger than the minimum) MAY be chosen by the receiver. (The receiver does not notify the sender of the window size.)
窗口大小为64是首选，应作为默认值使用。接收器可以选择另一个窗口大小（大于最小值）。（接收者不会将窗口大小通知发送者。）
The "right" edge of the window represents the highest validated sequence number value received on this session. Records that contain sequence numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a list of received packets within the window. An efficient means for performing this check, based on the use of a bit mask, is described in Section 3.4.3 of [ESP].
窗口的“右”边缘表示此会话上接收到的最高已验证序列号值。包含序列号低于窗口“左”边缘的记录将被拒绝。根据窗口内接收的数据包列表检查窗口内的数据包。[ESP]第3.4.3节描述了基于位掩码的有效检查方法。
If the received record falls within the window and is new, or if the packet is to the right of the window, then the receiver proceeds to MAC verification. If the MAC validation fails, the receiver MUST discard the received record as invalid. The receive window is updated only if the MAC verification succeeds.
如果接收到的记录落在窗口内并且是新的，或者如果数据包在窗口的右侧，则接收器进行MAC验证。如果MAC验证失败，接收器必须将接收到的记录视为无效而丢弃。仅当MAC验证成功时，才会更新接收窗口。
Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; however, an error MAY be logged for diagnostic purposes. Implementations which choose to generate an alert instead, MUST generate fatal level alerts to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error. Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED for such transports.
与TLS不同，DTLS在面对无效记录（例如，无效格式、长度、MAC等）时具有弹性。一般来说，无效记录应该被悄悄地丢弃，从而保留关联；但是，出于诊断目的，可能会记录错误。选择生成警报的实现必须生成致命级别的警报，以避免攻击者反复探测实现以查看其如何响应各种类型的错误的攻击。请注意，如果DTLS在UDP上运行，则任何执行此操作的实现都极易受到拒绝服务（DoS）攻击，因为UDP伪造非常容易。因此，不建议此类运输采用这种做法。
If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts because an attacker will have difficulty forging a datagram that will not be rejected by the transport layer.
如果DTL通过抗伪造的传输（例如SCTP和SCTP-AUTH）传输，则发送警报更安全，因为攻击者很难伪造传输层不会拒绝的数据报。
DTLS uses all of the same handshake messages and flows as TLS, with three principal changes:
DTLS使用与TLS相同的所有握手消息和流，但有三个主要变化：
1. A stateless cookie exchange has been added to prevent denial-of-service attacks.
1. 添加了无状态cookie交换以防止拒绝服务攻击。
2. Modifications to the handshake header to handle message loss, reordering, and DTLS message fragmentation (in order to avoid IP fragmentation).
2. 修改握手报头以处理消息丢失、重新排序和DTLS消息碎片（以避免IP碎片）。
3. Retransmission timers to handle message loss.
3. 用于处理消息丢失的重传计时器。
With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.2.
除了这些例外，DTLS消息格式、流和逻辑与TLS 1.2相同。
Datagram security protocols are extremely susceptible to a variety of DoS attacks. Two attacks are of particular concern:
数据报安全协议极易受到各种DoS攻击。有两起袭击事件特别令人关注：
1. An attacker can consume excessive resources on the server by transmitting a series of handshake initiation requests, causing the server to allocate state and potentially to perform expensive cryptographic operations.
1. 攻击者可以通过发送一系列握手启动请求来消耗服务器上的过多资源，从而导致服务器分配状态并可能执行昂贵的加密操作。
2. An attacker can use the server as an amplifier by sending connection initiation messages with a forged source of the victim. The server then sends its next message (in DTLS, a Certificate message, which can be quite large) to the victim machine, thus flooding it.
2. 攻击者可以通过发送带有伪造受害者来源的连接启动消息，将服务器用作放大器。然后，服务器将其下一条消息（在DTLS中是一条证书消息，可能非常大）发送到受害机器，从而使其泛滥。
In order to counter both of these attacks, DTLS borrows the stateless cookie technique used by Photuris [PHOTURIS] and IKE [IKEv2]. When the client sends its ClientHello message to the server, the server MAY respond with a HelloVerifyRequest message. This message contains a stateless cookie generated using the technique of [PHOTURIS]. The client MUST retransmit the ClientHello with the cookie added. The server then verifies the cookie and proceeds with the handshake only if it is valid. This mechanism forces the attacker/client to be able to receive the cookie, which makes DoS attacks with spoofed IP addresses difficult. This mechanism does not provide any defense against DoS attacks mounted from valid IP addresses.
为了对抗这两种攻击，DTLS借用了Photuris[Photuris]和IKE[IKEv2]使用的无状态cookie技术。当客户端向服务器发送ClientHello消息时，服务器可能会响应HelloVerifyRequest消息。此消息包含使用[PHOTURIS]技术生成的无状态cookie。客户端必须重新传输添加了cookie的ClientHello。然后，服务器验证cookie，并仅在握手有效时进行握手。这种机制迫使攻击者/客户端能够接收cookie，这使得使用伪造IP地址的DoS攻击变得困难。此机制不提供任何针对从有效IP地址装载的DoS攻击的防御。
The exchange is shown below:
交流情况如下：
Client Server
------ ------
ClientHello ------>
Client Server
------ ------
ClientHello ------>
<----- HelloVerifyRequest
(contains cookie)
<----- HelloVerifyRequest
(contains cookie)
ClientHello ------>
(with cookie)
ClientHello ------>
(with cookie)
[Rest of handshake]
[握手的其余部分]
DTLS therefore modifies the ClientHello message to add the cookie value.
因此，DTLS修改ClientHello消息以添加cookie值。
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..2^8-1>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..2^8-1>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
When sending the first ClientHello, the client does not have a cookie yet; in this case, the Cookie field is left empty (zero length).
发送第一个ClientHello时，客户端还没有cookie；在这种情况下，Cookie字段保留为空（长度为零）。
The definition of HelloVerifyRequest is as follows:
HelloVerifyRequest的定义如下：
struct {
ProtocolVersion server_version;
opaque cookie<0..2^8-1>;
} HelloVerifyRequest;
struct {
ProtocolVersion server_version;
opaque cookie<0..2^8-1>;
} HelloVerifyRequest;
The HelloVerifyRequest message type is hello_verify_request(3).
HelloVerifyRequest消息类型为hello\u verify\u请求（3）。
The server_version field has the same syntax as in TLS. However, in order to avoid the requirement to do version negotiation in the initial handshake, DTLS 1.2 server implementations SHOULD use DTLS version 1.0 regardless of the version of TLS that is expected to be negotiated. DTLS 1.2 and 1.0 clients MUST use the version solely to indicate packet formatting (which is the same in both DTLS 1.2 and 1.0) and not as part of version negotiation. In particular, DTLS 1.2 clients MUST NOT assume that because the server uses version 1.0 in the HelloVerifyRequest that the server is not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than DTLS 1.2.
server_version字段的语法与TLS中的相同。但是，为了避免在初始握手时进行版本协商的要求，DTLS 1.2服务器实现应该使用DTLS 1.0版本，而不管预期协商的TLS版本是什么。DTLS 1.2和1.0客户端必须仅使用版本来指示数据包格式（DTLS 1.2和1.0中的格式相同），而不是作为版本协商的一部分。特别是，DTLS 1.2客户端不能假设服务器在Helloverify请求中使用1.0版，因此服务器不是DTLS 1.2，或者它最终将协商DTLS 1.0而不是DTLS 1.2。
When responding to a HelloVerifyRequest, the client MUST use the same parameter values (version, random, session_id, cipher_suites, compression_method) as it did in the original ClientHello. The server SHOULD use those values to generate its cookie and verify that they are correct upon cookie receipt. The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. Upon receipt of the ServerHello, the client MUST verify that the server version values match. In order to avoid sequence number duplication in case of multiple HelloVerifyRequests, the server MUST use the record sequence number in the ClientHello as the record sequence number in the HelloVerifyRequest.
在响应Helloverify请求时，客户端必须使用与原始ClientHello中相同的参数值（版本、随机、会话id、密码套件、压缩方法）。服务器应使用这些值生成其cookie，并在收到cookie时验证它们是否正确。服务器在HelloVerifyRequest中必须使用与发送ServerHello时相同的版本号。收到ServerHello后，客户端必须验证服务器版本值是否匹配。为了避免多个Helloverify请求中的序列号重复，服务器必须使用ClientHello中的记录序列号作为Helloverify请求中的记录序列号。
Note: This specification increases the cookie size limit to 255 bytes for greater future flexibility. The limit remains 32 for previous versions of DTLS.
注意：该规范将cookie大小限制增加到255字节，以提高将来的灵活性。对于以前版本的DTL，限制仍为32。
The DTLS server SHOULD generate cookies in such a way that they can be verified without retaining any per-client state on the server. One technique is to have a randomly generated secret and generate cookies as:
DTLS服务器应以这样的方式生成cookie，即可以在不保留服务器上任何每个客户端状态的情况下对cookie进行验证。一种技术是随机生成一个秘密并生成cookie，如下所示：
Cookie = HMAC(Secret, Client-IP, Client-Parameters)
Cookie=HMAC（机密、客户端IP、客户端参数）
When the second ClientHello is received, the server can verify that the Cookie is valid and that the client can receive packets at the given IP address. In order to avoid sequence number duplication in case of multiple cookie exchanges, the server MUST use the record sequence number in the ClientHello as the record sequence number in its initial ServerHello. Subsequent ServerHellos will only be sent after the server has created state and MUST increment normally.
当接收到第二个ClientHello时，服务器可以验证Cookie是否有效，以及客户端是否可以在给定的IP地址接收数据包。为了避免在多个cookie交换的情况下重复序列号，服务器必须使用ClientHello中的记录序列号作为其初始ServerHello中的记录序列号。后续ServerHello仅在服务器创建状态后发送，并且必须正常递增。
One potential attack on this scheme is for the attacker to collect a number of cookies from different addresses and then reuse them to attack the server. The server can defend against this attack by changing the Secret value frequently, thus invalidating those cookies. If the server wishes that legitimate clients be able to handshake through the transition (e.g., they received a cookie with Secret 1 and then sent the second ClientHello after the server has changed to Secret 2), the server can have a limited window during which it accepts both secrets. [IKEv2] suggests adding a version number to cookies to detect this case. An alternative approach is simply to try verifying with both secrets.
对该方案的一种潜在攻击是，攻击者从不同的地址收集大量cookie，然后重用这些cookie来攻击服务器。服务器可以通过频繁更改机密值来抵御此攻击，从而使这些cookie无效。如果服务器希望合法客户端能够通过转换进行握手（例如，他们接收到一个包含机密1的cookie，然后在服务器更改为机密2后发送第二个ClientHello），则服务器可以有一个有限的窗口，在此期间它接受两个机密。[IKEv2]建议在cookie中添加一个版本号以检测此情况。另一种方法是尝试用两个秘密进行验证。
DTLS servers SHOULD perform a cookie exchange whenever a new handshake is being performed. If the server is being operated in an environment where amplification is not a problem, the server MAY be configured not to perform a cookie exchange. The default SHOULD be that the exchange is performed, however. In addition, the server MAY
DTLS服务器应该在执行新握手时执行cookie交换。如果服务器在放大不成问题的环境中运行，则可以将服务器配置为不执行cookie交换。但是，默认情况下应执行交换。此外，服务器可以
choose not to do a cookie exchange when a session is resumed. Clients MUST be prepared to do a cookie exchange with every handshake.
选择在会话恢复时不进行cookie交换。客户必须准备好在每次握手时交换cookie。
If HelloVerifyRequest is used, the initial ClientHello and HelloVerifyRequest are not included in the calculation of the handshake_messages (for the CertificateVerify message) and verify_data (for the Finished message).
如果使用HelloVerifyRequest，则初始ClientHello和HelloVerifyRequest不包括在握手_消息（对于CertificateVerify消息）和验证_数据（对于完成的消息）的计算中。
If a server receives a ClientHello with an invalid cookie, it SHOULD treat it the same as a ClientHello with no cookie. This avoids race/deadlock conditions if the client somehow gets a bad cookie (e.g., because the server changes its cookie signing key).
如果服务器接收到带有无效cookie的ClientHello，则应将其视为没有cookie的ClientHello。如果客户端以某种方式获得了错误的cookie（例如，因为服务器更改了其cookie签名密钥），这将避免出现争用/死锁情况。
Note to implementors: This may result in clients receiving multiple HelloVerifyRequest messages with different cookies. Clients SHOULD handle this by sending a new ClientHello with a cookie in response to the new HelloVerifyRequest.
实现者注意：这可能会导致客户端使用不同的cookie接收多个HelloVerifyRequest消息。客户端应该通过发送一个新的ClientHello和一个cookie来响应新的Helloverify请求来处理这个问题。
In order to support message loss, reordering, and message fragmentation, DTLS modifies the TLS 1.2 handshake header:
为了支持消息丢失、重新排序和消息分段，DTLS修改了TLS 1.2握手头：
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case hello_verify_request: HelloVerifyRequest; // New type
case server_hello: ServerHello;
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case hello_verify_request: HelloVerifyRequest; // New type
case server_hello: ServerHello;
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
The first message each side transmits in each handshake always has message_seq = 0. Whenever each new message is generated, the message_seq value is incremented by one. Note that in the case of a
每一方在每次握手中发送的第一条消息始终具有消息_seq=0。每当生成每个新消息时，消息_seq值都会增加一。请注意，在
rehandshake, this implies that the HelloRequest will have message_seq = 0 and the ServerHello will have message_seq = 1. When a message is retransmitted, the same message_seq value is used. For example:
rehandshake，这意味着HelloRequest将有消息_seq=0，而ServerHello将有消息_seq=1。重发消息时，使用相同的消息顺序值。例如：
Client Server
------ ------
ClientHello (seq=0) ------>
Client Server
------ ------
ClientHello (seq=0) ------>
X<-- HelloVerifyRequest (seq=0) (lost)
X<--HelloVerifyRequest（seq=0）（丢失）
[Timer Expires]
[计时器过期]
ClientHello (seq=0) ------>
(retransmit)
ClientHello (seq=0) ------>
(retransmit)
<------ HelloVerifyRequest (seq=0)
<------ HelloVerifyRequest (seq=0)
ClientHello (seq=1) ------>
(with cookie)
ClientHello (seq=1) ------>
(with cookie)
<------ ServerHello (seq=1)
<------ Certificate (seq=2)
<------ ServerHelloDone (seq=3)
<------ ServerHello (seq=1)
<------ Certificate (seq=2)
<------ ServerHelloDone (seq=3)
[Rest of handshake]
[握手的其余部分]
Note, however, that from the perspective of the DTLS record layer, the retransmission is a new record. This record will have a new DTLSPlaintext.sequence_number value.
然而，请注意，从DTLS记录层的角度来看，重传是一个新记录。此记录将有一个新的DTLSPlaintext.sequence_数值。
DTLS implementations maintain (at least notionally) a next_receive_seq counter. This counter is initially set to zero. When a message is received, if its sequence number matches next_receive_seq, next_receive_seq is incremented and the message is processed. If the sequence number is less than next_receive_seq, the message MUST be discarded. If the sequence number is greater than next_receive_seq, the implementation SHOULD queue the message but MAY discard it. (This is a simple space/bandwidth tradeoff).
DTLS实现维护（至少在概念上）下一个接收顺序计数器。此计数器最初设置为零。接收到消息时，如果其序列号与next_receive_seq匹配，next_receive_seq将递增并处理该消息。如果序列号小于next_receive_seq，则必须丢弃该消息。如果序列号大于next_receive_seq，则实现应将消息排入队列，但可能会丢弃它。（这是一个简单的空间/带宽权衡）。
As noted in Section 4.1.1, each DTLS message MUST fit within a single transport layer datagram. However, handshake messages are potentially bigger than the maximum record size. Therefore, DTLS provides a mechanism for fragmenting a handshake message over a number of records, each of which can be transmitted separately, thus avoiding IP fragmentation.
如第4.1.1节所述，每个DTLS消息必须适合单个传输层数据报。但是，握手消息可能大于最大记录大小。因此，DTLS提供了一种机制，用于在多个记录上对握手消息进行分段，每个记录可以单独传输，从而避免IP分段。
When transmitting the handshake message, the sender divides the message into a series of N contiguous data ranges. These ranges MUST NOT be larger than the maximum handshake fragment size and MUST jointly contain the entire handshake message. The ranges SHOULD NOT overlap. The sender then creates N handshake messages, all with the same message_seq value as the original handshake message. Each new message is labeled with the fragment_offset (the number of bytes contained in previous fragments) and the fragment_length (the length of this fragment). The length field in all messages is the same as the length field of the original message. An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length.
在传输握手消息时，发送方将消息划分为一系列N个连续的数据范围。这些范围不得大于最大握手片段大小，并且必须共同包含整个握手消息。范围不应重叠。然后，发送方创建N条握手消息，所有消息都具有与原始握手消息相同的message_seq值。每个新消息都标有fragment_offset（先前片段中包含的字节数）和fragment_length（此片段的长度）。所有消息中的长度字段与原始消息的长度字段相同。未分段消息是一种退化情况，其片段_偏移量=0，片段_长度=长度。
When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message. DTLS implementations MUST be able to handle overlapping fragment ranges. This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes.
当DTLS实现接收到握手消息片段时，它必须对其进行缓冲，直到它拥有整个握手消息。DTLS实现必须能够处理重叠的片段范围。这允许发送方在PMTU估计值发生变化时，以较小的片段大小重新传输握手消息。
Note that as with TLS, multiple handshake messages may be placed in the same DTLS record, provided that there is room and that they are part of the same flight. Thus, there are two acceptable ways to pack two DTLS messages into the same datagram: in the same record or in separate records.
请注意，与TLS一样，多个握手消息可以放在同一DTLS记录中，前提是有空间并且它们是同一航班的一部分。因此，有两种可接受的方法将两条DTLS消息打包到同一数据报中：在同一记录中或在单独的记录中。
DTLS messages are grouped into a series of message flights, according to the diagrams below. Although each flight of messages may consist of a number of messages, they should be viewed as monolithic for the purpose of timeout and retransmission.
根据下图，DTLS消息被分组为一系列消息飞行。尽管每一段消息可能由许多消息组成，但为了超时和重新传输的目的，它们应被视为整体消息。
Client Server
------ ------
Client Server
------ ------
ClientHello --------> Flight 1
ClientHello --------> Flight 1
<------- HelloVerifyRequest Flight 2
<------- HelloVerifyRequest Flight 2
ClientHello --------> Flight 3
ClientHello --------> Flight 3
ServerHello \
Certificate* \
ServerKeyExchange* Flight 4
CertificateRequest* /
<-------- ServerHelloDone /
ServerHello \
Certificate* \
ServerKeyExchange* Flight 4
CertificateRequest* /
<-------- ServerHelloDone /
Certificate* \
ClientKeyExchange \
CertificateVerify* Flight 5
[ChangeCipherSpec] /
Finished --------> /
Certificate* \
ClientKeyExchange \
CertificateVerify* Flight 5
[ChangeCipherSpec] /
Finished --------> /
[ChangeCipherSpec] \ Flight 6
<-------- Finished /
[ChangeCipherSpec] \ Flight 6
<-------- Finished /
Figure 1. Message Flights for Full Handshake
图1。完全握手的消息航班
Client Server
------ ------
Client Server
------ ------
ClientHello --------> Flight 1
ClientHello --------> Flight 1
ServerHello \
[ChangeCipherSpec] Flight 2
<-------- Finished /
ServerHello \
[ChangeCipherSpec] Flight 2
<-------- Finished /
[ChangeCipherSpec] \Flight 3
Finished --------> /
[ChangeCipherSpec] \Flight 3
Finished --------> /
Figure 2. Message Flights for Session-Resuming Handshake (No Cookie Exchange)
图2。会话恢复握手的消息航班（无Cookie交换）
DTLS uses a simple timeout and retransmission scheme with the following state machine. Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer.
DTLS使用一个简单的超时和重传方案以及以下状态机。因为DTLS客户端发送第一条消息（ClientHello），所以它们在准备状态下启动。DTLS服务器在等待状态下启动，但缓冲区为空且没有重传计时器。
+-----------+
| PREPARING |
+---> | | <--------------------+
| | | |
| +-----------+ |
| | |
| | Buffer next flight |
| | |
| \|/ |
| +-----------+ |
| | | |
| | SENDING |<------------------+ |
| | | | | Send
| +-----------+ | | HelloRequest
Receive | | | |
next | | Send flight | | or
flight | +--------+ | |
| | | Set retransmit timer | | Receive
| | \|/ | | HelloRequest
| | +-----------+ | | Send
| | | | | | ClientHello
+--)--| WAITING |-------------------+ |
| | | | Timer expires | |
| | +-----------+ | |
| | | | |
| | | | |
| | +------------------------+ |
| | Read retransmit |
Receive | | |
last | | |
flight | | |
| | |
\|/\|/ |
|
+-----------+ |
| | |
| FINISHED | -------------------------------+
| |
+-----------+
| /|\
| |
| |
+---+
+-----------+
| PREPARING |
+---> | | <--------------------+
| | | |
| +-----------+ |
| | |
| | Buffer next flight |
| | |
| \|/ |
| +-----------+ |
| | | |
| | SENDING |<------------------+ |
| | | | | Send
| +-----------+ | | HelloRequest
Receive | | | |
next | | Send flight | | or
flight | +--------+ | |
| | | Set retransmit timer | | Receive
| | \|/ | | HelloRequest
| | +-----------+ | | Send
| | | | | | ClientHello
+--)--| WAITING |-------------------+ |
| | | | Timer expires | |
| | +-----------+ | |
| | | | |
| | | | |
| | +------------------------+ |
| | Read retransmit |
Receive | | |
last | | |
flight | | |
| | |
\|/\|/ |
|
+-----------+ |
| | |
| FINISHED | -------------------------------+
| |
+-----------+
| /|\
| |
| |
+---+
Read retransmit Retransmit last flight
读取重新传输重新传输上次航班
Figure 3. DTLS Timeout and Retransmission State Machine
图3。DTLS超时和重传状态机
The state machine has three basic states.
状态机有三种基本状态。
In the PREPARING state, the implementation does whatever computations are necessary to prepare the next flight of messages. It then buffers them up for transmission (emptying the buffer first) and enters the SENDING state.
在准备状态下，实现执行准备下一次消息飞行所需的任何计算。然后，它将它们缓冲起来进行传输（首先清空缓冲区），并进入发送状态。
In the SENDING state, the implementation transmits the buffered flight of messages. Once the messages have been sent, the implementation then enters the FINISHED state if this is the last flight in the handshake. Or, if the implementation expects to receive more messages, it sets a retransmit timer and then enters the WAITING state.
在发送状态下，实现传输消息的缓冲传输。消息发送后，如果这是握手中的最后一次飞行，则实现将进入完成状态。或者，如果实现希望接收更多消息，则设置重传计时器，然后进入等待状态。
There are three ways to exit the WAITING state:
有三种方法可以退出等待状态：
1. The retransmit timer expires: the implementation transitions to the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state.
1. 重传计时器过期：实现转换到发送状态，在发送状态下重传航班，重置重传计时器，并返回等待状态。
2. The implementation reads a retransmitted flight from the peer: the implementation transitions to the SENDING state, where it retransmits the flight, resets the retransmit timer, and returns to the WAITING state. The rationale here is that the receipt of a duplicate message is the likely result of timer expiry on the peer and therefore suggests that part of one's previous flight was lost.
2. 实现从对等方读取重新传输的航班：实现转换到发送状态，在发送状态下重新传输航班，重置重新传输计时器，并返回等待状态。这里的基本原理是，接收到重复消息可能是对等方计时器过期的结果，因此表明先前航班的一部分丢失。
3. The implementation receives the next flight of messages: if this is the final flight of messages, the implementation transitions to FINISHED. If the implementation needs to send a new flight, it transitions to the PREPARING state. Partial reads (whether partial messages or only some of the messages in the flight) do not cause state transitions or timer resets.
3. 实现将接收下一个消息段：如果这是最后一个消息段，则实现将转换为FINISHED。如果实现需要发送新航班，它将转换到准备状态。部分读取（无论是部分消息还是航班中的部分消息）不会导致状态转换或计时器重置。
Because DTLS clients send the first message (ClientHello), they start in the PREPARING state. DTLS servers start in the WAITING state, but with empty buffers and no retransmit timer.
因为DTLS客户端发送第一条消息（ClientHello），所以它们在准备状态下启动。DTLS服务器在等待状态下启动，但缓冲区为空且没有重传计时器。
When the server desires a rehandshake, it transitions from the FINISHED state to the PREPARING state to transmit the HelloRequest. When the client receives a HelloRequest, it transitions from FINISHED to PREPARING to transmit the ClientHello.
当服务器需要重新握手时，它会从完成状态转换到准备状态以传输HelloRequest。当客户端接收到HelloRequest时，它将从完成转换为准备传输ClientHello。
In addition, for at least twice the default MSL defined for [TCP], when in the FINISHED state, the node that transmits the last flight (the server in an ordinary handshake or the client in a resumed handshake) MUST respond to a retransmit of the peer's last flight
此外，对于为[TCP]定义的至少两倍默认MSL，当处于完成状态时，传输最后一个航班的节点（普通握手中的服务器或恢复握手中的客户端）必须响应对等方最后一个航班的重新传输
with a retransmit of the last flight. This avoids deadlock conditions if the last flight gets lost. This requirement applies to DTLS 1.0 as well, and though not explicit in [DTLS1], it was always required for the state machine to function correctly. To see why this is necessary, consider what happens in an ordinary handshake if the server's Finished message is lost: the server believes the handshake is complete but it actually is not. As the client is waiting for the Finished message, the client's retransmit timer will fire and it will retransmit the client's Finished message. This will cause the server to respond with its own Finished message, completing the handshake. The same logic applies on the server side for the resumed handshake.
最后一次航班的重发。这样可以避免最后一次航班丢失时出现死锁情况。这一要求也适用于DTLS 1.0，尽管在[DTLS1]中没有明确说明，但状态机始终需要正确运行。要知道为什么这是必要的，考虑一下如果服务器的完成消息丢失，普通握手中会发生什么：服务器相信握手完成了，但实际上不是。当客户端正在等待完成的消息时，客户端的重新传输计时器将启动，它将重新传输客户端完成的消息。这将导致服务器以自己完成的消息响应，完成握手。对于恢复的握手，同样的逻辑也适用于服务器端。
Note that because of packet loss, it is possible for one side to be sending application data even though the other side has not received the first side's Finished message. Implementations MUST either discard or buffer all application data packets for the new epoch until they have received the Finished message for that epoch. Implementations MAY treat receipt of application data with a new epoch prior to receipt of the corresponding Finished message as evidence of reordering or packet loss and retransmit their final flight immediately, shortcutting the retransmission timer.
注意，由于分组丢失，即使另一方没有接收到第一方的完成消息，也有可能一方正在发送应用程序数据。实现必须丢弃或缓冲新纪元的所有应用程序数据包，直到它们收到该纪元的完成消息。实现可以将在接收到相应的完成消息之前接收到具有新纪元的应用程序数据视为重新排序或分组丢失的证据，并立即重新传输其最终飞行，从而缩短重新传输计时器。
Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems; for example, if many instances of a DTLS time out early and retransmit too quickly on a congested link. Implementations SHOULD use an initial timer value of 1 second (the minimum defined in RFC 6298 [RFC6298]) and double the value at each retransmission, up to no less than the RFC 6298 maximum of 60 seconds. Note that we recommend a 1-second timer rather than the 3-second RFC 6298 default in order to improve latency for time-sensitive applications. Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal.
虽然计时器值是实现的选择，但错误处理计时器可能导致严重的拥塞问题；例如，如果DTLS的许多实例提前超时，并且在拥挤的链路上重新传输过快。实现应使用1秒的初始计时器值（RFC 6298[RFC6298]中定义的最小值），并在每次重传时将该值加倍，最多不小于RFC 6298的最大值60秒。请注意，我们建议使用1秒的计时器，而不是3秒的RFC 6298默认计时器，以改善时间敏感应用程序的延迟。因为DTL只使用重传进行握手，而不使用数据流，所以对拥塞的影响应该是最小的。
Implementations SHOULD retain the current timer value until a transmission without loss occurs, at which time the value may be reset to the initial value. After a long period of idleness, no less than 10 times the current timer value, implementations may reset the timer to the initial value. One situation where this might occur is when a rehandshake is used after substantial data transfer.
实现应保留当前定时器值，直到发生无损耗传输，此时该值可重置为初始值。在长时间闲置（不少于当前计时器值的10倍）后，实施可能会将计时器重置为初始值。可能发生这种情况的一种情况是，在大量数据传输之后使用重新握手。
As with TLS, the ChangeCipherSpec message is not technically a handshake message but MUST be treated as part of the same flight as the associated Finished message for the purposes of timeout and retransmission. This creates a potential ambiguity because the order of the ChangeCipherSpec cannot be established unambiguously with respect to the handshake messages in case of message loss.
与TLS一样，ChangeCipherSpec消息在技术上不是握手消息，但为了超时和重新传输，必须将其视为与相关完成消息相同的航班的一部分。这会造成潜在的歧义，因为在消息丢失的情况下，无法明确地确定ChangeCipherSpec相对于握手消息的顺序。
This is not a problem with any current TLS mode because the expected set of handshake messages logically preceeding the ChangeCipherSpec is predictable from the rest of the handshake state. However, future modes MUST take care to avoid creating ambiguity.
这对于任何当前TLS模式都不是问题，因为在ChangeCipherSpec之前的预期握手消息集可以从握手状态的其余部分预测。然而，未来的模式必须注意避免产生歧义。
CertificateVerify and Finished messages have the same format as in TLS. Hash calculations include entire handshake messages, including DTLS-specific fields: message_seq, fragment_offset, and fragment_length. However, in order to remove sensitivity to handshake message fragmentation, the Finished MAC MUST be computed as if each handshake message had been sent as a single fragment. Note that in cases where the cookie exchange is used, the initial ClientHello and HelloVerifyRequest MUST NOT be included in the CertificateVerify or Finished MAC computations.
CertificateVerify和Finished消息的格式与TLS中的格式相同。散列计算包括整个握手消息，包括DTL特定字段：message_seq、fragment_offset和fragment_length。然而，为了消除对握手消息碎片的敏感性，必须计算完成的MAC，就像每个握手消息都作为单个碎片发送一样。请注意，在使用cookie交换的情况下，CertificateVerify或完成的MAC计算中不得包含初始ClientHello和HelloverIfy请求。
Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake. However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert message if the offending record is received again (e.g., as a retransmitted handshake message). Implementations SHOULD detect when a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected.
请注意，警报消息根本不会重新传输，即使它们发生在握手的上下文中。但是，如果再次收到违规记录（例如，作为重新传输的握手消息），通常会发出警报的DTLS实现应生成新的警报消息。实现应该检测对等方何时持续发送错误消息，并在检测到此类错误行为后终止本地连接状态。
If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is possible that a client will silently abandon one connection and then initiate another with the same parameters (e.g., after a reboot). This will appear to the server as a new handshake with epoch=0. In cases where a server believes it has an existing association on a given host/port quartet and it receives an epoch=0 ClientHello, it SHOULD proceed with a new handshake but MUST NOT destroy the existing association until the client has demonstrated reachability either by completing a cookie exchange or by completing a complete handshake
如果DTLS客户机-服务器对的配置方式使重复连接发生在同一主机/端口上，则客户机可能会自动放弃一个连接，然后使用相同的参数启动另一个连接（例如，重新启动后）。这将在服务器上显示为一次新的握手，历元=0。如果服务器认为它在给定的主机/端口上有一个现有关联，并且它接收到一个epoch=0 ClientHello，那么它应该继续进行一次新的握手，但在客户端通过完成cookie交换或完成一次完整的握手来证明其可达性之前，不能破坏现有关联
including delivering a verifiable Finished message. After a correct Finished message is received, the server MUST abandon the previous association to avoid confusion between two valid associations with overlapping epochs. The reachability requirement prevents off-path/blind attackers from destroying associations merely by sending forged ClientHellos.
包括传递可验证的已完成消息。在收到正确的完成消息后，服务器必须放弃以前的关联，以避免混淆具有重叠年代的两个有效关联。可达性要求可防止非路径/盲攻击者仅通过发送伪造的ClientHello来破坏关联。
This section includes specifications for the data structures that have changed between TLS 1.2 and DTLS 1.2. See [TLS12] for the definition of this syntax.
本节包括TLS 1.2和DTLS 1.2之间更改的数据结构规范。有关此语法的定义，请参见[TLS12]。
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSCompressed.length];
} DTLSCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
opaque fragment[DTLSCompressed.length];
} DTLSCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
select (CipherSpec.cipher_type) {
case block: GenericBlockCipher;
case aead: GenericAEADCipher; // New field
} fragment;
} DTLSCiphertext;
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch; // New field
uint48 sequence_number; // New field
uint16 length;
select (CipherSpec.cipher_type) {
case block: GenericBlockCipher;
case aead: GenericAEADCipher; // New field
} fragment;
} DTLSCiphertext;
enum {
hello_request(0), client_hello(1), server_hello(2),
hello_verify_request(3), // New field
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255) } HandshakeType;
enum {
hello_request(0), client_hello(1), server_hello(2),
hello_verify_request(3), // New field
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255) } HandshakeType;
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case hello_verify_request: HelloVerifyRequest; // New field
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body; } Handshake;
struct {
HandshakeType msg_type;
uint24 length;
uint16 message_seq; // New field
uint24 fragment_offset; // New field
uint24 fragment_length; // New field
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case hello_verify_request: HelloVerifyRequest; // New field
case certificate:Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done:ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body; } Handshake;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..2^8-1>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>; } ClientHello;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
opaque cookie<0..2^8-1>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>; } ClientHello;
struct {
ProtocolVersion server_version;
opaque cookie<0..2^8-1>; } HelloVerifyRequest;
struct {
ProtocolVersion server_version;
opaque cookie<0..2^8-1>; } HelloVerifyRequest;
This document describes a variant of TLS 1.2; therefore, most of the security considerations are the same as those of TLS 1.2 [TLS12], described in Appendices D, E, and F.
本文件描述了TLS 1.2的一个变体；因此，大多数安全注意事项与附录D、E和F中描述的TLS 1.2[TLS12]的安全注意事项相同。
The primary additional security consideration raised by DTLS is that of denial of service. DTLS includes a cookie exchange designed to protect against denial of service. However, implementations that do not use this cookie exchange are still vulnerable to DoS. In particular, DTLS servers that do not use the cookie exchange may be used as attack amplifiers even if they themselves are not experiencing DoS. Therefore, DTLS servers SHOULD use the cookie exchange unless there is good reason to believe that amplification is not a threat in their environment. Clients MUST be prepared to do a cookie exchange with every handshake.
DTLS提出的主要附加安全考虑是拒绝服务。DTLS包括一个cookie交换，旨在防止拒绝服务。但是，不使用此cookie交换的实现仍然容易受到DoS的攻击。特别是，不使用cookie交换的DTLS服务器可能被用作攻击放大器，即使它们本身没有遇到DoS。因此，DTLS服务器应该使用cookie交换，除非有充分的理由相信放大在其环境中不是威胁。客户必须准备好在每次握手时交换cookie。
Unlike TLS implementations, DTLS implementations SHOULD NOT respond to invalid records by terminating the connection. See Section 4.1.2.7 for details on this.
与TLS实现不同，DTLS实现不应通过终止连接来响应无效记录。详见第4.1.2.7节。
The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley, Constantine Sapuntzakis, and Hovav Shacham for discussions and comments on the design of DTLS. Thanks to the anonymous NDSS reviewers of our original NDSS paper on DTLS [DTLS] for their comments. Also, thanks to Steve Kent for feedback that helped clarify many points. The section on PMTU was cribbed from the DCCP specification [DCCP]. Pasi Eronen provided a detailed review of this specification. Peter Saint-Andre provided the list of changes in Section 8. Helpful comments on the document were also received from Mark Allman, Jari Arkko, Mohamed Badra, Michael D'Errico, Adrian Farrell, Joel Halpern, Ted Hardie, Charlia Kaufman, Pekka Savola, Allison Mankin, Nikos Mavrogiannopoulos, Alexey Melnikov, Robin Seggelmann, Michael Tuexen, Juho Vaha-Herttua, and Florian Weimer.
作者感谢Dan Boneh、Eu Jin Goh、Russ Housley、Constantine Sapuntzakis和Hovav Shacham对DTL设计的讨论和评论。感谢我们关于DTLS的原始NDSS论文[DTLS]的匿名NDSS审稿人的评论。另外，感谢史蒂夫·肯特的反馈，帮助澄清了许多要点。关于PMTU的章节摘自DCCP规范[DCCP]。Pasi Eronen对本规范进行了详细审查。彼得·圣安德烈在第8节中提供了变更清单。马克·奥尔曼、贾里·阿尔科、穆罕默德·巴德拉、迈克尔·德里科、阿德里安·法雷尔、乔尔·哈尔佩恩、特德·哈迪、查莉亚·考夫曼、佩卡·萨沃拉、埃里森·曼金、尼科斯·马夫罗吉安诺普洛斯、亚历克西·梅尔尼科夫、罗宾·塞格尔曼、迈克尔·图森、朱霍·瓦哈·赫图和弗洛里安·魏默也对该文件发表了有益的评论。
This document uses the same identifier space as TLS [TLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS. IANA has modified all TLS parameter registries to add a DTLS-OK flag, indicating whether the specification may be used with DTLS. At the time of publication, all of the [TLS12] registrations except the following are suitable for DTLS. The full table of registrations is available at [IANA].
本文档使用与TLS[TLS12]相同的标识符空间，因此不需要新的IANA注册表。为TLS分配新标识符时，作者必须指定它们是否适用于DTL。IANA修改了所有TLS参数注册表，以添加DTLS-OK标志，指示该规范是否可用于DTLS。在发布时，除以下内容外，所有[TLS12]注册均适用于DTL。注册的完整表格可在[IANA]上查阅。
From the TLS Cipher Suite Registry:
从TLS密码套件注册表：
0x00,0x03 TLS_RSA_EXPORT_WITH_RC4_40_MD5 [RFC4346]
0x00,0x04 TLS_RSA_WITH_RC4_128_MD5 [RFC5246]
0x00,0x05 TLS_RSA_WITH_RC4_128_SHA [RFC5246]
0x00,0x17 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 [RFC4346]
0x00,0x03 TLS_RSA_EXPORT_WITH_RC4_40_MD5 [RFC4346]
0x00,0x04 TLS_RSA_WITH_RC4_128_MD5 [RFC5246]
0x00,0x05 TLS_RSA_WITH_RC4_128_SHA [RFC5246]
0x00,0x17 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 [RFC4346]
0x00,0x18 TLS_DH_anon_WITH_RC4_128_MD5 [RFC5246]
0x00,0x20 TLS_KRB5_WITH_RC4_128_SHA [RFC2712]
0x00,0x24 TLS_KRB5_WITH_RC4_128_MD5 [RFC2712]
0x00,0x28 TLS_KRB5_EXPORT_WITH_RC4_40_SHA [RFC2712]
0x00,0x2B TLS_KRB5_EXPORT_WITH_RC4_40_MD5 [RFC2712]
0x00,0x8A TLS_PSK_WITH_RC4_128_SHA [RFC4279]
0x00,0x8E TLS_DHE_PSK_WITH_RC4_128_SHA [RFC4279]
0x00,0x92 TLS_RSA_PSK_WITH_RC4_128_SHA [RFC4279]
0xC0,0x02 TLS_ECDH_ECDSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x07 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x0C TLS_ECDH_RSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x11 TLS_ECDHE_RSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x16 TLS_ECDH_anon_WITH_RC4_128_SHA [RFC4492]
0xC0,0x33 TLS_ECDHE_PSK_WITH_RC4_128_SHA [RFC5489]
0x00,0x18 TLS_DH_anon_WITH_RC4_128_MD5 [RFC5246]
0x00,0x20 TLS_KRB5_WITH_RC4_128_SHA [RFC2712]
0x00,0x24 TLS_KRB5_WITH_RC4_128_MD5 [RFC2712]
0x00,0x28 TLS_KRB5_EXPORT_WITH_RC4_40_SHA [RFC2712]
0x00,0x2B TLS_KRB5_EXPORT_WITH_RC4_40_MD5 [RFC2712]
0x00,0x8A TLS_PSK_WITH_RC4_128_SHA [RFC4279]
0x00,0x8E TLS_DHE_PSK_WITH_RC4_128_SHA [RFC4279]
0x00,0x92 TLS_RSA_PSK_WITH_RC4_128_SHA [RFC4279]
0xC0,0x02 TLS_ECDH_ECDSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x07 TLS_ECDHE_ECDSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x0C TLS_ECDH_RSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x11 TLS_ECDHE_RSA_WITH_RC4_128_SHA [RFC4492]
0xC0,0x16 TLS_ECDH_anon_WITH_RC4_128_SHA [RFC4492]
0xC0,0x33 TLS_ECDHE_PSK_WITH_RC4_128_SHA [RFC5489]
From the TLS Exporter Label Registry:
从TLS Exporter标签注册表：
client EAP encryption [RFC5216]
ttls keying material [RFC5281]
ttls challenge [RFC5281]
client EAP encryption [RFC5216]
ttls keying material [RFC5281]
ttls challenge [RFC5281]
This document defines a new handshake message, hello_verify_request, whose value has been allocated from the TLS HandshakeType registry defined in [TLS12]. The value "3" has been assigned by the IANA.
本文档定义了一个新的握手消息hello_verify_request，其值已从[TLS12]中定义的TLS握手类型注册表中分配。IANA已指定值“3”。
This document reflects the following changes since DTLS 1.0 [DTLS1].
本文档反映了自DTLS 1.0[DTLS1]以来的以下更改。
- Updated to match TLS 1.2 [TLS12].
- 更新以匹配TLS 1.2[TLS12]。
- Addition of AEAD Ciphers in Section 4.1.2.3 (tracking changes in TLS 1.2.
- 在第4.1.2.3节中添加AEAD密码（跟踪TLS 1.2中的更改。
- Clarifications regarding sequence numbers and epochs in Section 4.1 and a clear procedure for dealing with state loss in Section 4.2.8.
- 第4.1节中关于序列号和年代的澄清，以及第4.2.8节中处理状态丢失的明确程序。
- Clarifications and more detailed rules regarding Path MTU issues in Section 4.1.1.1. Clarification of the fragmentation text throughout.
- 第4.1.1.1节中关于Path MTU问题的澄清和更详细的规则。对整个文本的澄清。
- Clarifications regarding handling of invalid records in Section 4.1.2.7.
- 第4.1.2.7节中关于无效记录处理的澄清。
- A new paragraph describing handling of invalid cookies at the end of Section 4.2.1.
- 在第4.2.1节末尾，新增了一段描述无效cookie处理的内容。
- Some new text describing how to avoid handshake deadlock conditions at the end of Section 4.2.4.
- 第4.2.4节末尾描述如何避免握手死锁情况的一些新文本。
- Some new text about CertificateVerify messages in Section 4.2.6.
- 第4.2.6节中关于CertificateVerify消息的一些新文本。
- A prohibition on epoch wrapping in Section 4.1.
- 第4.1节中禁止包装。
- Clarification of the IANA requirements and the explicit requirement for a new IANA registration flag for each parameter.
- 澄清IANA要求，明确要求为每个参数设置新的IANA注册标志。
- Added a record sequence number mirroring technique for handling repeated ClientHello messages.
- 添加了用于处理重复ClientHello消息的记录序列号镜像技术。
- Recommend a fixed version number for HelloVerifyRequest.
- 为HelloVerifyRequest推荐固定版本号。
- Numerous editorial changes.
- 许多编辑上的变化。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ]Bradner，S.，“在RFC中用于指示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, June 2011.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 62982011年6月。
[RSAGCM] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008.
[RSAGCM]Salowey，J.，Choudhury，A.，和D.McGrew，“用于TLS的AES伽罗瓦计数器模式（GCM）密码套件”，RFC 5288，2008年8月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS12]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[DCCP] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[DCCP]Kohler，E.，Handley，M.，和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 4340，2006年3月。
[DCCPDTLS] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008.
[DCCPDTLS]Phelan，T.，“数据报拥塞控制协议（DCCP）上的数据报传输层安全性（DTLS）”，RFC 5238，2008年5月。
[DTLS] Modadugu, N. and E. Rescorla, "The Design and Implementation of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004.
[DTLS]Modadugu，N.和E.Rescorla，“数据报TLS的设计和实现”，ISO NDSS 2004年会议记录，2004年2月。
[DTLS1] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[DTLS1]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[ECCGCM] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, August 2008.
[ECCGCM]Rescorla，E.“具有SHA-256/384和AES伽罗瓦计数器模式（GCM）的TLS椭圆曲线密码套件”，RFC 5289，2008年8月。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[IANA] IANA, "Transport Layer Security (TLS) Parameters", http://www.iana.org/assignments/tls-parameters.
[IANA]IANA，“传输层安全（TLS）参数”，http://www.iana.org/assignments/tls-parameters.
[IKEv2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[IKEv2]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Erenen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[PHOTURIS]Karn，P.和W.Simpson，“PHOTURIS:会话密钥管理协议”，RFC2521999年3月。
[POP] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[TLS11] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS11]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[WHYIPSEC] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", BCP 146, RFC 5406, February 2009.
[WHYIPSEC]Bellovin，S.，“指定IPsec版本2使用的指南”，BCP 146，RFC 5406，2009年2月。
Authors' Addresses
作者地址
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303
Eric Rescorla RTFM，Inc.加利福尼亚州帕洛阿尔托埃奇伍德大道2064号，邮编94303
EMail: ekr@rtfm.com
EMail: ekr@rtfm.com
Nagendra Modadugu Google, Inc.
纳贡德拉·莫达杜古谷歌公司。
EMail: nagendra@cs.stanford.edu
EMail: nagendra@cs.stanford.edu