Network Working Group E. Rescorla
Request for Comments: 4347 RTFM, Inc.
Category: Standards Track N. Modadugu
Stanford University
April 2006
Network Working Group E. Rescorla
Request for Comments: 4347 RTFM, Inc.
Category: Standards Track N. Modadugu
Stanford University
April 2006
Datagram Transport Layer Security
数据报传输层安全
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies Version 1.0 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.
本文件规定了数据报传输层安全（DTLS）协议的1.0版。DTLS协议为数据报协议提供通信隐私。该协议允许客户机/服务器应用程序以防止窃听、篡改或消息伪造的方式进行通信。DTLS协议基于传输层安全（TLS）协议，并提供等效的安全保证。DTLS协议保留了底层传输的数据报语义。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................3
2. Usage Model .....................................................3
3. Overview of DTLS ................................................4
3.1. Loss-Insensitive Messaging .................................4
3.2. Providing Reliability for Handshake ........................4
3.2.1. Packet Loss .........................................5
3.2.2. Reordering ..........................................5
3.2.3. Message Size ........................................5
3.3. Replay Detection ...........................................6
4. Differences from TLS ............................................6
4.1. Record Layer ...............................................6
4.1.1. Transport Layer Mapping .............................7
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................3
2. Usage Model .....................................................3
3. Overview of DTLS ................................................4
3.1. Loss-Insensitive Messaging .................................4
3.2. Providing Reliability for Handshake ........................4
3.2.1. Packet Loss .........................................5
3.2.2. Reordering ..........................................5
3.2.3. Message Size ........................................5
3.3. Replay Detection ...........................................6
4. Differences from TLS ............................................6
4.1. Record Layer ...............................................6
4.1.1. Transport Layer Mapping .............................7
4.1.1.1. PMTU Discovery .............................8
4.1.2. Record Payload Protection ...........................9
4.1.2.1. MAC ........................................9
4.1.2.2. Null or Standard Stream Cipher .............9
4.1.2.3. Block Cipher ..............................10
4.1.2.4. New Cipher Suites .........................10
4.1.2.5. Anti-replay ...............................10
4.2. The DTLS Handshake Protocol ...............................11
4.2.1. Denial of Service Countermeasures ..................11
4.2.2. Handshake Message Format ...........................13
4.2.3. Message Fragmentation and Reassembly ...............15
4.2.4. Timeout and Retransmission .........................15
4.2.4.1. Timer Values ..............................18
4.2.5. ChangeCipherSpec ...................................19
4.2.6. Finished Messages ..................................19
4.2.7. Alert Messages .....................................19
4.3. Summary of new syntax .....................................19
4.3.1. Record Layer .......................................20
4.3.2. Handshake Protocol .................................20
5. Security Considerations ........................................21
6. Acknowledgements ...............................................22
7. IANA Considerations ............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
4.1.1.1. PMTU Discovery .............................8
4.1.2. Record Payload Protection ...........................9
4.1.2.1. MAC ........................................9
4.1.2.2. Null or Standard Stream Cipher .............9
4.1.2.3. Block Cipher ..............................10
4.1.2.4. New Cipher Suites .........................10
4.1.2.5. Anti-replay ...............................10
4.2. The DTLS Handshake Protocol ...............................11
4.2.1. Denial of Service Countermeasures ..................11
4.2.2. Handshake Message Format ...........................13
4.2.3. Message Fragmentation and Reassembly ...............15
4.2.4. Timeout and Retransmission .........................15
4.2.4.1. Timer Values ..............................18
4.2.5. ChangeCipherSpec ...................................19
4.2.6. Finished Messages ..................................19
4.2.7. Alert Messages .....................................19
4.3. Summary of new syntax .....................................19
4.3.1. Record Layer .......................................20
4.3.2. Handshake Protocol .................................20
5. Security Considerations ........................................21
6. Acknowledgements ...............................................22
7. IANA Considerations ............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
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]. It therefore cannot be used to secure unreliable datagram traffic.
TLS[TLS]是用于保护网络流量的最广泛部署的协议。它广泛用于保护Web流量和电子邮件协议，如IMAP[IMAP]和POP[POP]。TLS的主要优点是它提供了一个透明的面向连接的通道。因此，通过在应用层和传输层之间插入TLS，很容易保护应用协议。但是，TLS必须运行在可靠的传输通道上——通常是TCP[TCP]。因此，它不能用于保护不可靠的数据报流量。
However, over the past few years 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 [RFC2401]. 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. SIP, for instance, uses a subset of S/MIME to
然而，在过去几年中，越来越多的应用层协议被设计为使用UDP传输。特别地，诸如会话发起协议（SIP）[SIP]和电子游戏协议等协议越来越流行。（请注意，SIP可以在TCP和UDP上运行，但在某些情况下UDP更可取）。目前，这些应用程序的设计者面临着许多不令人满意的选择。首先，他们可以使用IPsec[RFC2401]。然而，由于[WHYIPSEC]中详述的许多原因，这仅适用于某些应用。其次，他们可以设计定制的应用层安全协议。例如，SIP使用S/MIME的子集
secure its traffic. 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 requires a large amount of effort to design -- in contrast to the relatively small amount of effort required to run the protocol over TLS.
确保交通安全。不幸的是，尽管应用层安全协议通常提供优越的安全属性（例如，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. Thus, a datagram-compatible variant of TLS would be very desirable. This memo describes such a protocol: 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。因此，TLS的数据报兼容变体将是非常理想的。本备忘录描述了这样一种协议：数据报传输层安全（DTLS）。DTL被刻意设计为尽可能类似于TLS，既可以最小化新的安全发明，又可以最大限度地提高代码和基础设施的重用量。
In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" 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". 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, and 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's traffic encryption layer does not allow independent decryption of individual records. If record N is not received, then record N+1 cannot be decrypted.
1. TLS的流量加密层不允许对单个记录进行独立解密。如果未收到记录N，则无法解密记录N+1。
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 (CBC state, stream cipher key stream) is chained between records.
1. 加密上下文（CBC状态，流密码密钥流）在记录之间链接。
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提供，但序列号在记录中是隐式的。
The fix for both of these problems is straightforward and well known from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1 [TLS11] is already adding explicit CBC state to TLS records. DTLS borrows that mechanism and adds explicit sequence numbers.
这两个问题的解决方法都很简单，大家都知道IPsec ESP[ESP]：将显式状态添加到记录中。TLS 1.1[TLS11]已经在向TLS记录添加显式CBC状态。DTLS借用了这种机制并添加了显式序列号。
The TLS handshake is a lockstep cryptographic handshake. Messages must be transmitted and received in a defined order, and any other order is an error. Clearly, this is incompatible with reordering and
TLS握手是一种锁步加密握手。消息必须按照定义的顺序发送和接收，任何其他顺序都是错误的。显然，这与重新排序和
message loss. In addition, TLS handshake messages are potentially larger than any given datagram, thus creating the problem of fragmentation. DTLS must provide fixes for both of these problems.
消息丢失。此外，TLS握手消息可能比任何给定的数据报都大，因此会产生碎片问题。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. The server also maintains a retransmission timer and retransmits when that timer expires.
一旦客户机传输了ClientHello消息，它希望看到来自服务器的Helloverify请求。但是，如果服务器的消息丢失，客户端会知道ClientHello或HelloVerifyRequest已丢失并重新传输。当服务器接收到重新传输时，它知道重新传输。服务器还维护一个重新传输计时器，并在该计时器过期时重新传输。
Note: timeout and retransmission do not apply to the HelloVerifyRequest, because this requires creating state on the server.
注意：超时和重新传输不适用于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 up 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 fragmentation is not
TLS和DTLS握手消息可能非常大（理论上最多为2^24-1字节，实际上是很多KB）。相比之下，如果不进行分段，UDP数据报通常限制在<1500字节
desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. 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.
渴望的为了补偿此限制，每个DTLS握手消息可以在多个DTLS记录上分段。每个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.1 [TLS11]. Where we do not explicitly call out differences, DTLS is the same as in [TLS11].
如第3节所述，DTLS有意与TLS非常相似。因此，我们没有将DTLS作为一个新协议来表示，而是将其表示为TLS1.1[TLS11]中的一系列增量。当我们没有明确指出差异时，DTL与[TLS11]中的相同。
The DTLS record layer is extremely similar to that of TLS 1.1. 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.1非常相似。唯一的变化是在记录中包含一个显式序列号。此序列号允许收件人正确验证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.1 record.
与TLS 1.1记录中的类型字段等效的类型。
version The version of the protocol being employed. This document describes DTLS Version 1.0, which uses the version { 254, 255 }. The version value of 254.255 is the 1's complement of DTLS Version 1.0. This maximal spacing between TLS and DTLS version
版本正在使用的协议的版本。本文档描述了DTLS版本1.0，它使用版本{254，255}。版本值254.255是DTLS版本1.0的1的补充。TLS和DTLS版本之间的最大间距
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.)
数字可确保两个协议中的记录易于区分。应该注意的是，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.1 record. As in TLS 1.1, the length should not exceed 2^14.
长度与TLS 1.1记录中的长度字段相同。与TLS 1.1一样，长度不应超过2^14。
fragment Identical to the fragment field of a TLS 1.1 record.
片段与TLS 1.1记录的片段字段相同。
DTLS uses an explicit sequence number, rather than an implicit one, carried in the sequence_number field of the record. As with TLS, the sequence number is set to zero after each ChangeCipherSpec message is sent.
DTLS使用显式序列号，而不是隐式序列号，在记录的序列号字段中携带。与TLS一样，在发送每个ChangeCipherSpec消息后，序列号设置为零。
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 the ChangeCipherSpec messages 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 and we therefore do not expect this to be a problem.
如果连续执行几次握手，则线路上可能有多条具有相同序列号但来自不同密码状态的记录。“历元”字段允许收件人区分此类数据包。历元编号最初为零，每次发送ChangeCipherSpec消息时都会递增。为了确保任何给定的序列/历元对都是唯一的，实现不得允许在TCP最大段生存期的两倍内重用相同的历元值。在实践中，TLS实现很少重新握手，因此我们不认为这是一个问题。
Each DTLS record MUST fit within a single datagram. In order to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD determine the MTU and send records smaller than the MTU. DTLS implementations SHOULD provide a way for applications to determine the value of the PMTU (or, alternately, the maximum application datagram size, which is the PMTU minus the DTLS per-record overhead). If the application attempts to send a record larger than the MTU, the DTLS implementation SHOULD generate an error, thus avoiding sending a packet which will be fragmented.
每个DTLS记录必须适合单个数据报。为了避免IP碎片[MOGUL]，DTLS实现应该确定MTU并发送小于MTU的记录。DTLS实现应该为应用程序提供一种方法来确定PMTU的值（或者，最大应用程序数据报大小，即PMTU减去每个记录的DTLS开销）。如果应用程序试图发送比MTU大的记录，DTLS实现应生成一个错误，从而避免发送将被分段的数据包。
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 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, and 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. In the future, a DTLS-DCCP mapping may be specified to provide optimal behavior for this interaction.
一些传输，如DCCP，为通过它们传输的流量提供拥塞控制。如果拥塞窗口足够窄，则DTLS握手重传可能被保持而不是立即传输，这可能导致超时和伪重传。当通过此类传输使用DTL时，应注意不要超出可能的拥塞窗口。将来，可以指定DTLS-DCCP映射来为该交互提供最佳行为。
In general, DTLS's philosophy is to avoid dealing with PMTU issues. The general strategy is to start with a conservative MTU and then update it if events during the handshake or actual application data transport phase require it.
一般来说，DTLS的理念是避免处理PMTU问题。一般策略是从保守的MTU开始，然后在握手或实际应用程序数据传输阶段的事件需要时更新它。
The PMTU SHOULD be initialized from the interface MTU that will be used to send packets. If the DTLS implementation receives an RFC 1191 [RFC1191] ICMP Destination Unreachable message with the "fragmentation needed and DF set" Code (otherwise known as Datagram Too Big), it should decrease its PMTU estimate to that given in the ICMP message. A DTLS implementation SHOULD allow the application to occasionally reset its PMTU estimate. The DTLS implementation SHOULD also allow applications to control the status of the DF bit. These controls allow the application to perform PMTU discovery. RFC 1981 [RFC1981] procedures SHOULD be followed for IPv6.
PMTU应从用于发送数据包的接口MTU初始化。如果DTLS实现接收到RFC 1191[RFC1191]ICMP目的地不可到达消息，且带有“需要碎片且DF设置”代码（也称为数据报过大），则应将其PMTU估计值降低至ICMP消息中给出的值。DTLS实现应允许应用程序偶尔重置其PMTU估计值。DTLS实现还应允许应用程序控制DF位的状态。这些控件允许应用程序执行PMTU发现。IPv6应遵循RFC 1981[RFC1981]程序。
One special case is the DTLS handshake system. Handshake messages should be set with DF set. Because some firewalls and routers screen out ICMP messages, it is difficult for the handshake layer to distinguish packet loss from an overlarge PMTU estimate. In order to allow connections under these circumstances, DTLS implementations SHOULD back off handshake packet size during the retransmit backoff described in Section 4.2.4. For instance, if a large packet is being sent, after 3 retransmits the handshake layer might choose to fragment the handshake message on retransmission. In general, choice of a conservative initial MTU will avoid this problem.
一种特殊情况是DTLS握手系统。握手信息应使用DF set设置。由于一些防火墙和路由器屏蔽了ICMP消息，握手层很难区分数据包丢失和过大的PMTU估计。为了在这些情况下允许连接，DTLS实现应在第4.2.4节所述的重新传输退避期间退避握手数据包大小。例如，如果发送一个大数据包，在3次重传之后，握手层可能会选择在重传时对握手消息进行分段。通常，选择保守的初始MTU可以避免此问题。
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.1. 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.1相同。但是，用于计算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, 255 } for DTLS 1.0.
TLS MAC计算在协议版本号上参数化，在DTLS的情况下，协议版本号是有线版本，即DTLS 1.0的{254，255}。
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 data with bad MACs. If a DTLS implementation chooses to generate an alert when it receives a message with an invalid MAC, it MUST generate bad_record_mac alert with level fatal and terminate its connection state.
通常，DTLS实现应该悄悄地丢弃带有坏MAC的数据。如果DTLS实现在接收到带有无效MAC的消息时选择生成警报，则必须生成级别为致命的bad_record_MAC警报并终止其连接状态。
The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher.
DTLS空密码的执行方式与TLS 1.1空密码完全相同。
The only stream cipher described in TLS 1.1 is RC4, which cannot be randomly accessed. RC4 MUST NOT be used with DTLS.
TLS 1.1中描述的唯一流密码是RC4，它不能被随机访问。RC4不得与DTL一起使用。
DTLS block cipher encryption and decryption are performed exactly as with TLS 1.1.
DTLS分组密码加密和解密的执行与TLS 1.1完全相同。
Upon registration, new TLS cipher suites MUST indicate whether they are suitable for DTLS usage and what, if any, adaptations must be made.
注册后，新的TLS密码套件必须说明它们是否适合DTLS使用，以及必须进行哪些修改（如有）。
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 [RFC 2402].
DTLS记录包含一个序列号以提供重播保护。序列号验证应使用以下滑动窗口程序进行，从[RFC 2402]第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 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.)
通过使用滑动接收窗口拒绝重复项。（如何实现窗口是一个局部问题，但以下文本描述了实现必须展示的功能。）必须支持最小窗口大小32，但首选窗口大小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 Appendix C of [RFC 2401].
窗口的“右”边缘表示此会话上接收到的最高已验证序列号值。包含序列号低于窗口“左”边缘的记录将被拒绝。根据窗口内接收的数据包列表检查窗口内的数据包。[RFC 2401]的附录C中描述了基于位掩码的有效检查方法。
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验证成功时，才会更新接收窗口。
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 fragmentation.
2. 修改握手头以处理消息丢失、重新排序和碎片。
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.1.
除了这些例外，DTLS消息格式、流和逻辑与TLS 1.1相同。
Datagram security protocols are extremely susceptible to a variety of denial of service (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 [IKE]. 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[IKE]使用的无状态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..32>; // 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..32>; // 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..32>;
} HelloVerifyRequest;
struct {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
The HelloVerifyRequest message type is hello_verify_request(3).
HelloVerifyRequest消息类型为hello\u verify\u请求（3）。
The server_version field is defined as in TLS.
服务器版本字段在TLS中定义为。
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.
当响应Helloverify请求时，客户端必须使用与原始ClientHello中相同的参数值（版本、随机、会话id、密码套件、压缩方法）。服务器应使用这些值生成其cookie，并在收到cookie时验证它们是否正确。服务器在HelloVerifyRequest中必须使用与发送ServerHello时相同的版本号。收到ServerHello后，客户端必须验证服务器版本值是否匹配。
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: Cookie = HMAC(Secret, Client-IP, Client-Parameters)
DTLS服务器应以这样的方式生成cookie，即可以在不保留服务器上任何每个客户端状态的情况下对cookie进行验证。一种技术是拥有一个随机生成的秘密并生成Cookie，如下所示：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.
当接收到第二个ClientHello时，服务器可以验证Cookie是否有效，以及客户端是否可以在给定的IP地址接收数据包。
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 choose not to do a cookie exchange when a session is resumed. Clients MUST be prepared to do a cookie exchange with every handshake.
DTLS服务器应该在执行新握手时执行cookie交换。如果服务器在放大不成问题的环境中运行，则可以将服务器配置为不执行cookie交换。但是，默认情况下应执行交换。此外，服务器可以选择在会话恢复时不进行cookie交换。客户必须准备好在每次握手时交换cookie。
If HelloVerifyRequest is used, the initial ClientHello and HelloVerifyRequest are not included in the calculation of the verify_data for the Finished message.
如果使用HelloVerifyRequest，则初始ClientHello和HelloVerifyRequest不包括在已完成消息的verify_数据的计算中。
In order to support message loss, reordering, and fragmentation, DTLS modifies the TLS 1.1 handshake header:
为了支持消息丢失、重新排序和分段，DTLS修改了TLS 1.1握手头：
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;
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;
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. When a message is retransmitted, the same message_seq value is used. For example:
每一方在每次握手中发送的第一条消息始终具有消息_seq=0。每当生成每个新消息时，消息_seq值都会增加一。重发消息时，使用相同的消息顺序值。例如：
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
DTLS实现维护（至少在概念上）下一个接收顺序计数器。此计数器最初设置为零。接收到消息时，如果其序列号与next_receive_seq匹配，next_receive_seq将递增，消息将被删除
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).
处理。如果序列号小于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.
如第4.1.1节所述，每个DTLS消息必须适合单个传输层数据报。但是，握手消息可能大于最大记录大小。因此，DTLS提供了一种机制，用于在多个记录上分割握手消息。
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 labelled 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 during path MTU discovery.
当DTLS实现接收到握手消息片段时，它必须对其进行缓冲，直到它拥有整个握手消息。DTLS实现必须能够处理重叠的片段范围。这允许发送方在路径MTU发现期间以较小的片段大小重新传输握手消息。
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 | -------------------------------+
| |
+-----------+
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。
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
虽然计时器值是实现的选择，但错误处理计时器可能导致严重的拥塞问题；例如，如果DTLS的许多实例提前超时，并且在拥挤的链路上重新传输过快。实现应该使用初始计时器值
of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double the value at each retransmission, up to no less than the RFC 2988 maximum of 60 seconds. Note that we recommend a 1-second timer rather than the 3-second RFC 2988 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.
1秒（RFC 2988[RFC2988]中定义的最小值），并在每次重传时加倍，最多不小于RFC 2988最大值60秒。请注意，为了提高时间敏感应用程序的延迟，我们建议使用1秒计时器，而不是3秒RFC 2988默认值。因为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.
与TLS一样，ChangeCipherSpec消息在技术上不是握手消息，但为了超时和重新传输，必须将其视为与相关完成消息相同的航班的一部分。
Finished messages have the same format as in TLS. However, in order to remove sensitivity to 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 Finished MAC.
完成的消息与TLS中的格式相同。然而，为了消除对碎片的敏感性，必须将完成的MAC计算为每个握手消息都作为单个碎片发送。请注意，在使用cookie交换的情况下，完成的MAC中不得包含初始ClientHello和HelloVerifyRequest。
Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake. However, a DTLS implementation 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实现应生成新的警报消息。实现应该检测对等方何时持续发送错误消息，并在检测到此类错误行为后终止本地连接状态。
This section includes specifications for the data structures that have changed between TLS 1.1 and DTLS.
本节包括TLS 1.1和DTL之间更改的数据结构规范。
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;
} 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;
} 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
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;
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..32>; // 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..32>; // New field
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
struct {
ProtocolVersion server_version;
opaque cookie<0..32>;
} HelloVerifyRequest;
This document describes a variant of TLS 1.1 and therefore most of the security considerations are the same as those of TLS 1.1 [TLS11], described in Appendices D, E, and F.
本文件描述了TLS 1.1的一个变体，因此大多数安全注意事项与附录D、E和F中描述的TLS 1.1[TLS11]的安全注意事项相同。
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 which do not use this cookie exchange are still vulnerable to DoS. In particular, DTLS servers which 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。
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. Helpful comments on the document were also received from Mark Allman, Jari Arkko, Joel Halpern, Ted Hardie, and Allison Mankin.
作者感谢Dan Boneh、Eu Jin Goh、Russ Housley、Constantine Sapuntzakis和Hovav Shacham对DTL设计的讨论和评论。感谢我们关于DTLS的原始NDSS论文[DTLS]的匿名NDSS审稿人的评论。另外，感谢史蒂夫·肯特的反馈，帮助澄清了许多要点。关于PMTU的章节摘自DCCP规范[DCCP]。Pasi Eronen对本规范进行了详细审查。Mark Allman、Jari Arkko、Joel Halpern、Ted Hardie和Allison Mankin也对该文件提出了有益的意见。
This document uses the same identifier space as TLS [TLS11], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS.
本文档使用与TLS[TLS11]相同的标识符空间，因此不需要新的IANA注册表。为TLS分配新标识符时，作者必须指定它们是否适用于DTL。
This document defines a new handshake message, hello_verify_request, whose value has been allocated from the TLS HandshakeType registry defined in [TLS11]. The value "3" has been assigned by the IANA.
本文档定义了一个新的握手消息hello_verify_request，其值已从[TLS11]中定义的TLS握手类型注册表中分配。IANA已指定值“3”。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[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月。
[AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES" http://cr.yp.to/antiforgery/cachetiming-20050414.pdf.
[AESCACHE]Bernstein，D.J.，“AES上的缓存定时攻击”http://cr.yp.to/antiforgery/cachetiming-20050414.pdf.
[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[DCCP] Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram Congestion Control Protocol", Work in Progress, 10 March 2005.
[DCCP]Kohler，E.，Handley，M.，Floyd，S.，Padhye，J.，“数据报拥塞控制协议”，正在进行的工作，2005年3月10日。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[DTLS] Modadugu, N., Rescorla, E., "The Design and Implementation of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004.
[DTLS]Modadugu，N.，Rescorla，E.，“数据报TLS的设计和实现”，ISO NDSS 2004年会议记录，2004年2月。
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[IKE]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
Kaufman，C.，“因特网密钥交换（IKEv2）协议”，RFC 4306，2005年12月。
[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, "ICMP Security Failures Messages", RFC 2521, March 1999.
[PHOTURIS]Karn，P.和W.Simpson，“ICMP安全故障消息”，RFC 25211999年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月。
[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月。
[SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[SCTP]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[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月。
[WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress, October 2003.
[WHYIPSEC]Bellovin，S.，“IPsec使用授权指南”，正在进行的工作，2003年10月。
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 Computer Science Department Stanford University 353 Serra Mall Stanford, CA 94305
加利福尼亚州斯坦福市塞拉广场353号斯坦福大学纳贡德拉·莫达杜古计算机科学系94305
EMail: nagendra@cs.stanford.edu
EMail: nagendra@cs.stanford.edu
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。