doc: Add RFC documents

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]
+