Internet Engineering Task Force (IETF) M. Tuexen
Request for Comments: 6083 R. Seggelmann
Category: Standards Track Muenster Univ. of Applied Sciences
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
January 2011
Internet Engineering Task Force (IETF) M. Tuexen
Request for Comments: 6083 R. Seggelmann
Category: Standards Track Muenster Univ. of Applied Sciences
ISSN: 2070-1721 E. Rescorla
RTFM, Inc.
January 2011
Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)
流控制传输协议（SCTP）的数据报传输层安全性（DTLS）
Abstract
摘要
This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP).
本文档描述了数据报传输层安全（DTLS）协议在流控制传输协议（SCTP）上的使用。
DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.
SCTP上的DTLS为使用SCTP作为传输协议的应用程序提供通信隐私，并允许客户机/服务器应用程序以防止窃听和检测篡改或消息伪造的方式进行通信。
Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions.
通过SCTP使用DTL的应用程序可以使用SCTP及其扩展提供的几乎所有传输功能。
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/rfc6083.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6083.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol, as defined in [RFC4347], over the Stream Control Transmission Protocol (SCTP), as defined in [RFC4960].
本文件描述了[RFC4347]中定义的数据报传输层安全（DTLS）协议在[RFC4960]中定义的流控制传输协议（SCTP）上的使用。
DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.
SCTP上的DTLS为使用SCTP作为传输协议的应用程序提供通信隐私，并允许客户机/服务器应用程序以防止窃听和检测篡改或消息伪造的方式进行通信。
Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions.
通过SCTP使用DTL的应用程序可以使用SCTP及其扩展提供的几乎所有传输功能。
TLS, from which DTLS was derived, is designed to run on top of a byte-stream-oriented transport protocol providing a reliable, in-sequence delivery. Thus, TLS is currently mainly being used on top of the Transmission Control Protocol (TCP), as defined in [RFC0793].
TLS是DTLS的发源地，它被设计为运行在面向字节流的传输协议之上，提供可靠的顺序传递。因此，TLS目前主要用于[RFC0793]中定义的传输控制协议（TCP）之上。
TLS over SCTP as described in [RFC3436] has some serious limitations:
[RFC3436]中所述的SCTP上的TLS有一些严重的限制：
o It does not support the unordered delivery of SCTP user messages.
o 它不支持SCTP用户消息的无序传递。
o It does not support partial reliability as defined in [RFC3758].
o 它不支持[RFC3758]中定义的部分可靠性。
o It only supports the usage of the same number of streams in both directions.
o 它只支持在两个方向上使用相同数量的流。
o It uses a TLS connection for every bidirectional stream, which requires a substantial amount of resources and message exchanges if a large number of streams is used.
o 它为每个双向流使用TLS连接，如果使用大量流，则需要大量资源和消息交换。
DTLS over SCTP as described in this document overcomes these limitations of TLS over SCTP. In particular, DTLS/SCTP supports:
本文档中所述的基于SCTP的DTLS克服了基于SCTP的TLS的这些限制。特别是，DTLS/SCTP支持：
o preservation of message boundaries.
o 保留消息边界。
o a large number of unidirectional and bidirectional streams.
o 大量单向和双向流。
o ordered and unordered delivery of SCTP user messages.
o SCTP用户消息的有序和无序传递。
o the partial reliability extension as defined in [RFC3758].
o [RFC3758]中定义的部分可靠性扩展。
o the dynamic address reconfiguration extension as defined in [RFC5061].
o [RFC5061]中定义的动态地址重新配置扩展。
However, the following limitations still apply:
但是，以下限制仍然适用：
o The maximum user message size is 2^14 bytes, which is the DTLS limit.
o 最大用户消息大小为2^14字节，这是DTLS限制。
o The DTLS user cannot perform the SCTP-AUTH key management because this is done by the DTLS layer.
o DTLS用户无法执行SCTP-AUTH密钥管理，因为这是由DTLS层完成的。
The method described in this document requires that the SCTP implementation supports the optional feature of fragmentation of SCTP user messages as defined in [RFC4960] and the SCTP authentication extension defined in [RFC4895].
本文档中描述的方法要求SCTP实现支持[RFC4960]中定义的SCTP用户消息分段的可选功能和[RFC4895]中定义的SCTP身份验证扩展。
This document uses the following terms:
本文件使用以下术语：
Association: An SCTP association.
协会：SCTP协会。
Stream: A unidirectional stream of an SCTP association. It is uniquely identified by a stream identifier.
流：SCTP关联的单向流。它由流标识符唯一标识。
DTLS: Datagram Transport Layer Security
DTLS：数据报传输层安全性
MTU: Maximum Transmission Unit
最大传输单位
PPID: Payload Protocol Identifier
PPID：有效负载协议标识符
SCTP: Stream Control Transmission Protocol
SCTP：流控制传输协议
TCP: Transmission Control Protocol
传输控制协议
TLS: Transport Layer Security
传输层安全
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document is based on [RFC4347], and it is expected that DTLS/ SCTP as described in this document will work with future versions of DTLS.
本文件基于[RFC4347]，预计本文件中所述的DTLS/SCTP将与未来版本的DTLS一起使用。
DTLS limits the DTLS user message size to the current Path MTU minus the header sizes. For the purposes of running over SCTP, the DTLS path MTU MUST be considered to be 2^14.
DTLS将DTLS用户消息大小限制为当前路径MTU减去头大小。为了在SCTP上运行，必须将DTLS路径MTU视为2^14。
The replay detection of DTLS may result in the DTLS layer dropping messages. Since DTLS/SCTP provides a reliable service if requested by the application, replay detection cannot be used. Therefore, replay detection of DTLS MUST NOT be used.
DTLS的重放检测可能导致DTLS层丢弃消息。由于DTLS/SCTP在应用程序请求时提供可靠的服务，因此无法使用重播检测。因此，不得使用DTL的重播检测。
SCTP provides Path MTU discovery and fragmentation/reassembly for user messages. According to Section 3.2, DTLS can send maximum sized messages. Therefore, Path MTU discovery of DTLS MUST NOT be used.
SCTP为用户消息提供路径MTU发现和分段/重组。根据第3.2节，DTL可以发送最大大小的消息。因此，不能使用DTL的路径MTU发现。
SCTP provides a reliable and in-sequence transport service for DTLS messages that require it. See Section 4.4. Therefore, DTLS procedures for retransmissions MUST NOT be used.
SCTP为需要它的DTLS消息提供可靠的顺序传输服务。见第4.4节。因此，不得使用用于重新传输的DTLS程序。
The supported maximum length of SCTP user messages MUST be at least 2^14 + 2048 + 13 = 18445 bytes (2^14 + 2048 is the maximum length of the DTLSCiphertext.fragment, and 13 is the size of the DTLS record header). In particular, the SCTP implementation MUST support fragmentation of user messages.
支持的SCTP用户消息的最大长度必须至少为2^14+2048+13=18445字节（2^14+2048是DTLSCiphertext.fragment的最大长度，13是DTLS记录头的大小）。特别是，SCTP实现必须支持用户消息的分段。
Every SCTP user message MUST consist of exactly one DTLS record.
每个SCTP用户消息必须仅包含一条DTLS记录。
Each DTLS connection MUST be established and terminated within the same SCTP association. A DTLS connection MUST NOT span multiple SCTP associations.
每个DTLS连接必须在同一SCTP关联中建立和终止。DTLS连接不能跨越多个SCTP关联。
Application protocols using DTLS over SCTP SHOULD register and use a separate payload protocol identifier (PPID) and SHOULD NOT reuse the PPID that they registered for running directly over SCTP.
在SCTP上使用DTL的应用程序协议应注册并使用单独的有效负载协议标识符（PPID），并且不应重用它们注册用于直接在SCTP上运行的PPID。
Using the same PPID does not harm as long as the application can determine whether or not DTLS is used. However, for protocol analyzers, for example, it is much easier if a separate PPID is used.
只要应用程序能够确定是否使用DTLS，使用相同的PPID不会造成损害。然而，例如，对于协议分析器，如果使用单独的PPID，则更容易。
This means, in particular, that there is no specific PPID for DTLS.
这特别意味着DTL没有特定的PPID。
All DTLS messages of the ChangeCipherSpec, Alert, or Handshake protocol MUST be transported on stream 0 with unlimited reliability and with the ordered delivery feature.
ChangeCipherSpec、Alert或Handshake协议的所有DTLS消息必须在流0上传输，具有无限可靠性和有序传递功能。
DTLS messages of the ApplicationData protocol SHOULD use multiple streams other than stream 0; they MAY use stream 0 for everything if they do not care about minimizing head of line blocking.
ApplicationData协议的DTLS消息应使用流0以外的多个流；如果他们不关心最小化线头阻塞，那么他们可能会对所有事情使用流0。
DATA chunks of SCTP MUST be sent in an authenticated way as described in [RFC4895]. Other chunks MAY be sent in an authenticated way. This makes sure that an attacker cannot modify the stream in which a message is sent or affect the ordered/unordered delivery of the message.
SCTP的数据块必须按照[RFC4895]中所述的经过身份验证的方式发送。其他块可以以经过身份验证的方式发送。这可确保攻击者无法修改发送消息的流或影响消息的有序/无序传递。
If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST also be sent in an authenticated way as described in [RFC4895]. This makes sure that it is not possible for an attacker to drop messages and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this dropping.
如果使用[RFC3758]中定义的PR-SCTP，则还必须按照[RFC4895]中所述的身份验证方式发送前向TSN块。这可确保攻击者不可能丢弃消息并使用伪造的FORWARD-TSN、SACK和/或SHUTDOWN块来隐藏此丢弃。
DTLS supports renegotiation, and therefore this feature is also available by DTLS/SCTP. It is up to the upper layer to use/allow it or not. Application writers should be aware that allowing renegotiations may result in changes of security parameters.
DTLS支持重新协商，因此DTLS/SCTP也可以使用此功能。是否使用/允许由上层决定。应用程序编写者应该知道，允许重新协商可能会导致安全参数的更改。
A DTLS implementation discards DTLS messages from older epochs after some time, as described in Section 4.1 of [RFC4347]. This is not acceptable when the DTLS user performs a reliable data transfer. To avoid discarding messages, the following procedures are required.
如[RFC4347]第4.1节所述，DTLS实现会在一段时间后丢弃旧时代的DTLS消息。当DTLS用户执行可靠的数据传输时，这是不可接受的。为避免丢弃邮件，需要执行以下步骤。
Before sending a ChangeCipherSpec message, all outstanding SCTP user messages MUST have been acknowledged by the SCTP peer and MUST NOT be revoked by the SCTP peer.
在发送ChangeCipherSpec消息之前，所有未完成的SCTP用户消息必须已被SCTP对等方确认，并且不得被SCTP对等方撤销。
Prior to processing a received ChangeCipherSpec, all other received SCTP user messages that are buffered in the SCTP layer MUST be read and processed by DTLS.
在处理接收到的ChangeCipherSpec之前，DTL必须读取并处理SCTP层中缓冲的所有其他接收到的SCTP用户消息。
User messages that arrive between ChangeCipherSpec and Finished messages and use the new epoch have probably passed the Finished message and MUST be buffered by DTLS until the Finished message is read.
在ChangeCipherSpec和Finished messages之间到达并使用新纪元的用户消息可能已通过Finished message，必须由DTL进行缓冲，直到读取Finished message。
The endpoint-pair shared secret for Shared Key Identifier 0 is empty and MUST be used when establishing a DTLS connection. Whenever the master key changes, a 64-byte shared secret is derived from every master secret and provided as a new endpoint-pair shared secret by using the exporter described in [RFC5705]. The exporter MUST use the
共享密钥标识符0的端点对共享密钥为空，在建立DTLS连接时必须使用。每当主密钥发生更改时，就会从每个主密钥中派生出一个64字节的共享密钥，并使用[RFC5705]中所述的导出器作为新的端点对共享密钥提供。出口商必须使用
label given in Section 5 and no context. The new Shared Key Identifier MUST be the old Shared Key Identifier incremented by 1. If the old one is 65535, the new one MUST be 1.
第5节中给出的标签，无上下文。新共享密钥标识符必须是递增1的旧共享密钥标识符。如果旧的是65535，那么新的必须是1。
Before sending the Finished message, the active SCTP-AUTH key MUST be switched to the new one.
在发送完成的消息之前，必须将激活的SCTP-AUTH密钥切换到新密钥。
Once the corresponding Finished message from the peer has been received, the old SCTP-AUTH key SHOULD be removed.
一旦收到来自对等方的相应完成消息，应删除旧的SCTP-AUTH密钥。
To prevent DTLS from discarding DTLS user messages while it is shutting down, a CloseNotify message MUST only be sent after all outstanding SCTP user messages have been acknowledged by the SCTP peer and MUST NOT still be revoked by the SCTP peer.
为防止DTLS在关闭时丢弃DTLS用户消息，只有在SCTP对等方确认所有未完成的SCTP用户消息后，才能发送CloseNotify消息，并且SCTP对等方不得撤销该消息。
Prior to processing a received CloseNotify, all other received SCTP user messages that are buffered in the SCTP layer MUST be read and processed by DTLS.
在处理收到的CloseNotify之前，DTL必须读取并处理SCTP层中缓冲的所有其他收到的SCTP用户消息。
IANA added a value to the TLS Exporter Label registry as described in [RFC5705]. The label is "EXPORTER_DTLS_OVER_SCTP".
IANA向TLS Exporter标签注册表添加了一个值，如[RFC5705]所述。标签是“出口商超过SCTP”。
The security considerations given in [RFC4347], [RFC4895], and [RFC4960] also apply to this document.
[RFC4347]、[RFC4895]和[RFC4960]中给出的安全注意事项也适用于本文档。
It is possible to authenticate DTLS endpoints based on IP addresses in certificates. SCTP associations can use multiple addresses per SCTP endpoint. Therefore, it is possible that DTLS records will be sent from a different IP address than that originally authenticated. This is not a problem provided that no security decisions are made based on that IP address. This is a special case of a general rule: all decisions should be based on the peer's authenticated identity, not on its transport layer identity.
可以根据证书中的IP地址对DTLS端点进行身份验证。SCTP关联可以为每个SCTP端点使用多个地址。因此，DTLS记录可能会从与最初经过身份验证的IP地址不同的IP地址发送。这不是一个问题，前提是没有基于该IP地址做出安全决策。这是一般规则的一个特例：所有决策都应该基于对等方的已验证身份，而不是其传输层身份。
For each message, the SCTP user also provides a stream identifier, a flag to indicate whether the message is sent ordered or unordered, and a payload protocol identifier. Although DTLS can be used to provide privacy for the actual user message, none of these three are protected by DTLS. They are sent as clear text, because they are part of the SCTP DATA chunk header.
对于每条消息，SCTP用户还提供流标识符、指示消息是按顺序发送还是按无序发送的标志以及有效负载协议标识符。尽管DTL可用于为实际用户消息提供隐私，但这三种消息都不受DTL的保护。它们以明文形式发送，因为它们是SCTP数据块头的一部分。
DTLS supports cipher suites that contain a NULL cipher algorithm. Negotiating a NULL cipher algorithm will not provide communications privacy for applications and will not provide privacy for user messages.
DTLS支持包含空密码算法的密码套件。协商空密码算法不会为应用程序提供通信隐私，也不会为用户消息提供隐私。
The authors wish to thank Anna Brunstrom, Lars Eggert, Gorry Fairhurst, Ian Goldberg, Alfred Hoenes, Carsten Hohendorf, Stefan Lindskog, Daniel Mentz, and Sean Turner for their invaluable comments.
作者希望感谢安娜·布伦斯特罗姆、拉尔斯·艾格特、戈里·费尔赫斯特、伊恩·戈德伯格、阿尔弗雷德·霍恩斯、卡斯滕·霍亨多夫、斯特凡·林德斯科格、丹尼尔·门茨和肖恩·特纳的宝贵评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]Stewart，R.，Ramalho，M.，Xie，Q.，Tuexen，M.，和P.Conrad，“流控制传输协议（SCTP）部分可靠性扩展”，RFC 3758，2004年5月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]Rescorla，E.和N.Modadugu，“数据报传输层安全”，RFC 4347，2006年4月。
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, August 2007.
[RFC4895]Tuexen，M.，Stewart，R.，Lei，P.，和E.Rescorla，“流控制传输协议（SCTP）的认证块”，RFC 48952007年8月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010.
[RFC5705]Rescorla，E.“传输层安全（TLS）关键材料导出器”，RFC 57052010年3月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
[RFC3436]Jungmaier，A.，Rescorla，E.，和M.Tuexen，“流控制传输协议上的传输层安全”，RFC 3436，2002年12月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061]Stewart，R.，Xie，Q.，Tuexen，M.，Maruyama，S.，和M.Kozuka，“流控制传输协议（SCTP）动态地址重新配置”，RFC 50612007年9月。
Authors' Addresses
作者地址
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
米迦勒TuxEN明斯特应用科学大学StigalddSTR。39 48565德国斯坦福德
EMail: tuexen@fh-muenster.de
EMail: tuexen@fh-muenster.de
Robin Seggelmann Muenster University of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
罗宾.塞格曼明斯特应用科学大学39 48565德国斯坦福德
EMail: seggelmann@fh-muenster.de
EMail: seggelmann@fh-muenster.de
Eric Rescorla RTFM, Inc. 2064 Edgewood Drive Palo Alto, CA 94303 USA
Eric Rescorla RTFM，Inc.美国加利福尼亚州帕洛阿尔托埃奇伍德大道2064号，邮编94303
EMail: ekr@networkresonance.com
EMail: ekr@networkresonance.com