summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8261.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8261.txt')
-rw-r--r--doc/rfc/rfc8261.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc8261.txt b/doc/rfc/rfc8261.txt
new file mode 100644
index 0000000..0c80bd7
--- /dev/null
+++ b/doc/rfc/rfc8261.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Tuexen
+Request for Comments: 8261 Muenster Univ. of Appl. Sciences
+Category: Standards Track R. Stewart
+ISSN: 2070-1721 Netflix, Inc.
+ R. Jesup
+ WorldGate Communications
+ S. Loreto
+ Ericsson
+ November 2017
+
+
+ Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets
+
+Abstract
+
+ The Stream Control Transmission Protocol (SCTP) is a transport
+ protocol originally defined to run on top of the network protocols
+ IPv4 or IPv6. This document specifies how SCTP can be used on top of
+ the Datagram Transport Layer Security (DTLS) protocol. Using the
+ encapsulation method described in this document, SCTP is unaware of
+ the protocols being used below DTLS; hence, explicit IP addresses
+ cannot be used in the SCTP control chunks. As a consequence, the
+ SCTP associations carried over DTLS can only be single-homed.
+
+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 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8261.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tuexen, et al. Standards Track [Page 1]
+
+RFC 8261 SCTP over DTLS November 2017
+
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://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.
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Encapsulation and Decapsulation Procedure . . . . . . . . . . 3
+ 4. General Considerations . . . . . . . . . . . . . . . . . . . 4
+ 5. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 4
+ 6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tuexen, et al. Standards Track [Page 2]
+
+RFC 8261 SCTP over DTLS November 2017
+
+
+1. Overview
+
+ The Stream Control Transmission Protocol (SCTP) as defined in
+ [RFC4960] is a transport protocol running on top of the network
+ protocols IPv4 [RFC0791] or IPv6 [RFC8200]. This document specifies
+ how SCTP is used on top of the Datagram Transport Layer Security
+ (DTLS) protocol. DTLS 1.0 is defined in [RFC4347], and the latest
+ version when this RFC was published, DTLS 1.2, is defined in
+ [RFC6347]. This encapsulation is used, for example, within the
+ WebRTC protocol suite (see [RTC-OVERVIEW] for an overview) for
+ transporting non-SRTP data between browsers. The architecture of
+ this stack is described in [DATA-CHAN].
+
+ +----------+
+ | SCTP |
+ +----------+
+ | DTLS |
+ +----------+
+ | ICE/UDP |
+ +----------+
+
+ Figure 1: Basic Stack Diagram
+
+ This encapsulation of SCTP over DTLS over UDP or ICE/UDP (see
+ [RFC5245]) can provide a NAT traversal solution in addition to
+ confidentiality, source authentication, and integrity-protected
+ transfers. Please note that using ICE does not necessarily imply
+ that a different packet format is used on the wire.
+
+ Please note that the procedures defined in [RFC6951] for dealing with
+ the UDP port numbers do not apply here. When using the encapsulation
+ defined in this document, SCTP is unaware about the protocols used
+ below DTLS.
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Encapsulation and Decapsulation Procedure
+
+ When an SCTP packet is provided to the DTLS layer, the complete SCTP
+ packet, consisting of the SCTP common header and a number of SCTP
+ chunks, is handled as the payload of the application-layer protocol
+ of DTLS. When the DTLS layer has processed a DTLS record containing
+
+
+
+Tuexen, et al. Standards Track [Page 3]
+
+RFC 8261 SCTP over DTLS November 2017
+
+
+ a message of the application-layer protocol, the payload is passed to
+ the SCTP layer. The SCTP layer expects an SCTP common header
+ followed by a number of SCTP chunks.
+
+4. General Considerations
+
+ An implementation of SCTP over DTLS MUST implement and use a path
+ maximum transmission unit (MTU) discovery method that functions
+ without ICMP to provide SCTP/DTLS with an MTU estimate. An
+ implementation of "Packetization Layer Path MTU Discovery" [RFC4821]
+ either in SCTP or DTLS is RECOMMENDED.
+
+ The path MTU discovery is performed by SCTP when SCTP over DTLS is
+ used for data channels (see Section 5 of [DATA-CHAN]).
+
+5. DTLS Considerations
+
+ The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD
+ support the most recently published version of DTLS, which was DTLS
+ 1.2 [RFC6347] when this RFC was published. In the absence of a
+ revision to this document, the latter requirement applies to all
+ future versions of DTLS when they are published as RFCs. This
+ document will only be revised if a revision to DTLS or SCTP makes a
+ revision to the encapsulation necessary.
+
+ SCTP performs segmentation and reassembly based on the path MTU.
+ Therefore, the DTLS layer MUST NOT use any compression algorithm.
+
+ The DTLS MUST support sending messages larger than the current path
+ MTU. This might result in sending IP-level fragmented messages.
+
+ If path MTU discovery is performed by the DTLS layer, the method
+ described in [RFC4821] MUST be used. For probe packets, the
+ extension defined in [RFC6520] MUST be used.
+
+ If path MTU discovery is performed by the SCTP layer and IPv4 is used
+ as the network-layer protocol, the DTLS implementation SHOULD allow
+ the DTLS user to enforce that the corresponding IPv4 packet is sent
+ with the Don't Fragment (DF) bit set. If controlling the DF bit is
+ not possible (for example, due to implementation restrictions), a
+ safe value for the path MTU has to be used by the SCTP stack. It is
+ RECOMMENDED that the safe value not exceed 1200 bytes. Please note
+ that [RFC1122] only requires that end hosts be able to reassemble
+ fragmented IP packets up to 576 bytes in length.
+
+ The DTLS implementation SHOULD allow the DTLS user to set the
+ Differentiated Services Code Point (DSCP) used for IP packets being
+ sent (see [RFC2474]). This requires the DTLS implementation to pass
+
+
+
+Tuexen, et al. Standards Track [Page 4]
+
+RFC 8261 SCTP over DTLS November 2017
+
+
+ the value through and the lower layer to allow setting this value.
+ If the lower layer does not support setting the DSCP, then the DTLS
+ user will end up with the default value used by the protocol stack.
+ Please note that only a single DSCP value can be used for all packets
+ belonging to the same SCTP association.
+
+ Using Explicit Congestion Notification (ECN) in SCTP requires the
+ DTLS layer to pass the ECN bits through and its lower layer to expose
+ access to them for sent and received packets (see [RFC3168]). The
+ implementations of DTLS and its lower layer have to provide this
+ support. If this is not possible (for example, due to implementation
+ restrictions), ECN can't be used by SCTP.
+
+6. SCTP Considerations
+
+ This section describes the usage of the base protocol and the
+ applicability of various SCTP extensions.
+
+6.1. Base Protocol
+
+ This document uses SCTP [RFC4960] with the following restrictions,
+ which are required to reflect that the lower layer is DTLS instead of
+ IPv4 and IPv6 and that SCTP does not deal with the IP addresses or
+ the transport protocol used below DTLS:
+
+ o A DTLS connection MUST be established before an SCTP association
+ can be set up.
+
+ o Multiple SCTP associations MAY be multiplexed over a single DTLS
+ connection. The SCTP port numbers are used for multiplexing and
+ demultiplexing the SCTP associations carried over a single DTLS
+ connection.
+
+ o All SCTP associations are single-homed, because DTLS does not
+ expose any address management to its upper layer. Therefore, it
+ is RECOMMENDED to set the SCTP parameter path.max.retrans to
+ association.max.retrans.
+
+ o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or
+ IPv6 Address parameters. The INIT chunk MUST NOT contain the
+ Supported Address Types parameter.
+
+ o The implementation MUST NOT rely on processing ICMP or ICMPv6
+ packets, since the SCTP layer most likely is unable to access the
+ SCTP common header in the plain text of the packet, which
+ triggered the sending of the ICMP or ICMPv6 packet. This applies
+ in particular to path MTU discovery when performed by SCTP.
+
+
+
+
+Tuexen, et al. Standards Track [Page 5]
+
+RFC 8261 SCTP over DTLS November 2017
+
+
+ o If the SCTP layer is notified about a path change by its lower
+ layers, SCTP SHOULD retest the path MTU and reset the congestion
+ state to the initial state. The window-based congestion control
+ method specified in [RFC4960] resets the congestion window and
+ slow-start threshold to their initial values.
+
+6.2. Padding Extension
+
+ When the SCTP layer performs path MTU discovery as specified in
+ [RFC4821], the padding extension defined in [RFC4820] MUST be
+ supported and used for probe packets (HEARTBEAT chunks bundled with
+ PADDING chunks [RFC4820]).
+
+6.3. Dynamic Address Reconfiguration Extension
+
+ If the dynamic address reconfiguration extension defined in [RFC5061]
+ is used, ASCONF chunks MUST use wildcard addresses only.
+
+6.4. SCTP Authentication Extension
+
+ The SCTP authentication extension defined in [RFC4895] can be used
+ with DTLS encapsulation, but does not provide any additional benefit.
+
+6.5. Partial Reliability Extension
+
+ Partial reliability as defined in [RFC3758] can be used in
+ combination with DTLS encapsulation. It is also possible to use
+ additional Partially Reliable Stream Control Transmission Protocol
+ (PR-SCTP) policies, for example, the ones defined in [RFC7496].
+
+6.6. Stream Reset Extension
+
+ The SCTP stream reset extension defined in [RFC6525] can be used with
+ DTLS encapsulation. It is used to reset SCTP streams and add SCTP
+ streams during the lifetime of the SCTP association.
+
+6.7. Interleaving of Large User Messages
+
+ SCTP as defined in [RFC4960] does not support the interleaving of
+ large user messages that need to be fragmented and reassembled by the
+ SCTP layer. The protocol extension defined in [RFC8260] overcomes
+ this limitation and can be used with DTLS encapsulation.
+
+7. IANA Considerations
+
+ This document does not require any IANA actions.
+
+
+
+
+
+Tuexen, et al. Standards Track [Page 6]
+
+RFC 8261 SCTP over DTLS November 2017
+
+
+8. Security Considerations
+
+ Security considerations for DTLS are specified in [RFC4347] and for
+ SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP
+ and DTLS introduces no new security considerations.
+
+ SCTP should not process the IP addresses used for the underlying
+ communication since DTLS provides no guarantees about them.
+
+ It should be noted that the inability to process ICMP or ICMPv6
+ messages does not add any security issue. When SCTP is carried over
+ a connection-less lower layer like IPv4, IPv6, or UDP, processing of
+ these messages is required to protect other nodes not supporting
+ SCTP. Since DTLS provides a connection-oriented lower layer, this
+ kind of protection is not necessary.
+
+9. References
+
+9.1. Normative References
+
+ [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122,
+ DOI 10.17487/RFC1122, October 1989,
+ <https://www.rfc-editor.org/info/rfc1122>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, DOI 10.17487/RFC4347, April 2006,
+ <https://www.rfc-editor.org/info/rfc4347>.
+
+ [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
+ Parameter for the Stream Control Transmission Protocol
+ (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
+ <https://www.rfc-editor.org/info/rfc4820>.
+
+ [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+ Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
+ <https://www.rfc-editor.org/info/rfc4821>.
+
+ [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
+ RFC 4960, DOI 10.17487/RFC4960, September 2007,
+ <https://www.rfc-editor.org/info/rfc4960>.
+
+
+
+
+
+Tuexen, et al. Standards Track [Page 7]
+
+RFC 8261 SCTP over DTLS November 2017
+
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
+ January 2012, <https://www.rfc-editor.org/info/rfc6347>.
+
+ [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport
+ Layer Security (TLS) and Datagram Transport Layer Security
+ (DTLS) Heartbeat Extension", RFC 6520,
+ DOI 10.17487/RFC6520, February 2012,
+ <https://www.rfc-editor.org/info/rfc6520>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+9.2. Informative References
+
+ [DATA-CHAN]
+ Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
+ Channels", Work in Progress, draft-ietf-rtcweb-data-
+ channel-13, January 2015.
+
+ [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ DOI 10.17487/RFC0791, September 1981,
+ <https://www.rfc-editor.org/info/rfc791>.
+
+ [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
+ "Definition of the Differentiated Services Field (DS
+ Field) in the IPv4 and IPv6 Headers", RFC 2474,
+ DOI 10.17487/RFC2474, December 1998,
+ <https://www.rfc-editor.org/info/rfc2474>.
+
+ [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+ of Explicit Congestion Notification (ECN) to IP",
+ RFC 3168, DOI 10.17487/RFC3168, September 2001,
+ <https://www.rfc-editor.org/info/rfc3168>.
+
+ [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
+ Conrad, "Stream Control Transmission Protocol (SCTP)
+ Partial Reliability Extension", RFC 3758,
+ DOI 10.17487/RFC3758, May 2004,
+ <https://www.rfc-editor.org/info/rfc3758>.
+
+ [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
+ "Authenticated Chunks for the Stream Control Transmission
+ Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August
+ 2007, <https://www.rfc-editor.org/info/rfc4895>.
+
+
+
+
+
+Tuexen, et al. Standards Track [Page 8]
+
+RFC 8261 SCTP over DTLS November 2017
+
+
+ [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
+ Kozuka, "Stream Control Transmission Protocol (SCTP)
+ Dynamic Address Reconfiguration", RFC 5061,
+ DOI 10.17487/RFC5061, September 2007,
+ <https://www.rfc-editor.org/info/rfc5061>.
+
+ [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
+ (ICE): A Protocol for Network Address Translator (NAT)
+ Traversal for Offer/Answer Protocols", RFC 5245,
+ DOI 10.17487/RFC5245, April 2010,
+ <https://www.rfc-editor.org/info/rfc5245>.
+
+ [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
+ Transmission Protocol (SCTP) Stream Reconfiguration",
+ RFC 6525, DOI 10.17487/RFC6525, February 2012,
+ <https://www.rfc-editor.org/info/rfc6525>.
+
+ [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
+ Control Transmission Protocol (SCTP) Packets for End-Host
+ to End-Host Communication", RFC 6951,
+ DOI 10.17487/RFC6951, May 2013,
+ <https://www.rfc-editor.org/info/rfc6951>.
+
+ [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
+ "Additional Policies for the Partially Reliable Stream
+ Control Transmission Protocol Extension", RFC 7496,
+ DOI 10.17487/RFC7496, April 2015,
+ <https://www.rfc-editor.org/info/rfc7496>.
+
+ [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", STD 86, RFC 8200,
+ DOI 10.17487/RFC8200, July 2017,
+ <https://www.rfc-editor.org/info/rfc8200>.
+
+ [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
+ "Stream Schedulers and User Message Interleaving for the
+ Stream Control Transmission Protocol", RFC 8260, November
+ 2017.
+
+ [RTC-OVERVIEW]
+ Alvestrand, H., "Overview: Real Time Protocols for
+ Browser-based Applications", Work in Progress, draft-ietf-
+ rtcweb-overview-18, March 2017.
+
+
+
+
+
+
+
+
+Tuexen, et al. Standards Track [Page 9]
+
+RFC 8261 SCTP over DTLS November 2017
+
+
+Acknowledgments
+
+ The authors wish to thank David Black, Benoit Claise, Spencer
+ Dawkins, Francis Dupont, Gorry Fairhurst, Stephen Farrell, Christer
+ Holmberg, Barry Leiba, Eric Rescorla, Tom Taylor, Joe Touch, and
+ Magnus Westerlund for their invaluable comments.
+
+Authors' Addresses
+
+ Michael Tuexen
+ Muenster University of Applied Sciences
+ Stegerwaldstrasse 39
+ 48565 Steinfurt
+ Germany
+
+ Email: tuexen@fh-muenster.de
+
+
+ Randall R. Stewart
+ Netflix, Inc.
+ Chapin, SC 29036
+ United States of America
+
+ Email: randall@lakerest.net
+
+
+ Randell Jesup
+ WorldGate Communications
+ 3800 Horizon Blvd, Suite #103
+ Trevose, PA 19053-4947
+ United States of America
+
+ Phone: +1-215-354-5166
+ Email: randell-ietf@jesup.org
+
+
+ Salvatore Loreto
+ Ericsson
+ Hirsalantie 11
+ Jorvas 02420
+ Finland
+
+ Email: Salvatore.Loreto@ericsson.com
+
+
+
+
+
+
+
+
+Tuexen, et al. Standards Track [Page 10]
+