idnits 2.17.1 draft-ietf-tsvwg-sctp-dtls-encaps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-08 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-05 == Outdated reference: A later version (-03) exists of draft-stewart-tsvwg-sctp-ndata-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 Internet-Draft Muenster Univ. of Appl. Sciences 4 Intended status: Standards Track R. Stewart 5 Expires: April 23, 2014 Adara Networks 6 R. Jesup 7 WorldGate Communications 8 S. Loreto 9 Ericsson 10 October 20, 2013 12 DTLS Encapsulation of SCTP Packets 13 draft-ietf-tsvwg-sctp-dtls-encaps-02.txt 15 Abstract 17 The Stream Control Transmission Protocol (SCTP) is a transport 18 protocol originally defined to run on top of the network protocols 19 IPv4 or IPv6. This document specifies how SCTP can be used on top of 20 the Datagram Transport Layer Security (DTLS) protocol. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 23, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Encapsulation and Decapsulation Procedure . . . . . . . . . . 3 59 4. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 5. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 3 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 1.1. Overview 71 The Stream Control Transmission Protocol (SCTP) as defined in 72 [RFC4960] is a transport protocol running on top of the network 73 protocols IPv4 or IPv6. This document specifies how SCTP is used on 74 top of the Datagram Transport Layer Security (DTLS) protocol. This 75 encapsulation is used for example within the RTCWeb protocol suite 76 (see [I-D.ietf-rtcweb-overview] for an overview) for transporting 77 non-media data between browsers. The architecture of this stack is 78 described in [I-D.ietf-rtcweb-data-channel]. 80 1.2. Terminology 82 This document uses the following terms: 84 Association: An SCTP association. 86 Stream: A unidirectional stream of an SCTP association. It is 87 uniquely identified by a stream identifier. 89 1.3. Abbreviations 91 DTLS: Datagram Transport Layer Security. 93 MTU: Maximum Transmission Unit. 95 PPID: Payload Protocol Identifier. 97 SCTP: Stream Control Transmission Protocol. 99 TCP: Transmission Control Protocol. 101 TLS: Transport Layer Security. 103 2. Conventions 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Encapsulation and Decapsulation Procedure 111 When an SCTP packet is sent down to the DTLS layer, the complete SCTP 112 packet, consisting of the SCTP common header and a number of SCTP 113 chunks, MUST be handled as the payload of the application layer 114 protocol of DTLS. When the DTLS layer has processed a DTLS record 115 containing a message of the application layer protocol, the payload 116 MUST be given up to the SCTP layer. The SCTP layer expects an SCTP 117 common header followed by a number of SCTP chunks. 119 4. DTLS Considerations 121 The DTLS implementation MUST be based on [RFC6347]. 123 If path MTU discovery is performed by the DTLS layer, the method 124 described in [RFC4821] MUST be used. For probe packets, the 125 extension defined in [RFC6520] MUST be used. 127 If path MTU discovery is performed by the SCTP layer and IPv4 is used 128 as the network layer protocol, the DTLS implementation MUST allow the 129 DTLS user to enforce that the corresponding IPv4 packet is sent with 130 the DF bit set. 132 SCTP performs segmentation and reassembly based on the path MTU. 133 Therefore the DTLS layer MUST NOT use any compression algorithm. 135 The DTLS MUST support sending messages larger than the current path 136 MTU. This might result in sending IP level fragmented messages. 138 5. SCTP Considerations 139 5.1. Base Protocol 141 SCTP as specified in [RFC4960] is used. However, the following 142 restrictions are necessary to reflect that the lower layer is the 143 connection oriented protocol DTLS instead of the connection less 144 protocol IPv4 and IPv6: 146 o A DTLS connection MUST be established before an SCTP association 147 can be set up. 149 o All associations MUST be single-homed. 151 o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or 152 IPv6 Address parameters. The INIT chunk MUST NOT contain the 153 Supported Address Types parameter. 155 o The implementation MUST NOT rely on processing ICMP or ICMPv6 156 packets. This applies in particular to path MTU discovery when 157 performed by SCTP. 159 5.2. Padding Extension 161 The padding extension defined in [RFC4820] MUST be supported and used 162 for probe packets when performing path MTU discovery as specified in 163 [RFC4821]. 165 5.3. Dynamic Address Reconfiguration Extension 167 If the dynamic address reconfiguration extension defined in [RFC5061] 168 is used, only wildcard addresses MUST be used in ASCONF chunks. 170 5.4. SCTP Authentication Extension 172 The SCTP authentication extension defined in [RFC4895] can be used 173 with DTLS encapsulation, but does not require any additional benefit. 175 5.5. Partial Reliability Extension 177 Partial reliability as defined in [RFC3758] can be used in 178 combination with DTLS encapsulation. It is also possible to use 179 additional PR-SCTP policies. 181 5.6. Stream Reset Extension 183 The SCTP stream reset extension defined in [RFC6525] can be used with 184 DTLS encapsulation. It is used to reset streams and add streams 185 during the lifetime of the SCTP association. 187 5.7. Interleaving of Large User Message 189 SCTP as defined in [RFC4960] does not support the interleaving of 190 large user messages that need to be fragmented and reassembled by the 191 SCTP layer. The protocol extension defined in 192 [I-D.stewart-tsvwg-sctp-ndata] overcomes this limitation can can be 193 used with DTLS encapsulation. 195 6. IANA Considerations 197 This document requires no actions from IANA. 199 7. Security Considerations 201 Security considerations for DTLS are specified in [RFC6347] and for 202 SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP 203 and DTLS introduces no new security considerations. 205 8. Acknowledgments 207 The authors wish to thank Gorry Fairhurst for his invaluable 208 comments. 210 9. References 212 9.1. Normative References 214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 215 Requirement Levels", BCP 14, RFC 2119, March 1997. 217 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 218 Parameter for the Stream Control Transmission Protocol 219 (SCTP)", RFC 4820, March 2007. 221 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 222 Discovery", RFC 4821, March 2007. 224 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 225 4960, September 2007. 227 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 228 Security Version 1.2", RFC 6347, January 2012. 230 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 231 Layer Security (TLS) and Datagram Transport Layer Security 232 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 234 9.2. Informative References 236 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 237 Conrad, "Stream Control Transmission Protocol (SCTP) 238 Partial Reliability Extension", RFC 3758, May 2004. 240 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 241 "Authenticated Chunks for the Stream Control Transmission 242 Protocol (SCTP)", RFC 4895, August 2007. 244 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 245 Kozuka, "Stream Control Transmission Protocol (SCTP) 246 Dynamic Address Reconfiguration", RFC 5061, September 247 2007. 249 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 250 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 251 6525, February 2012. 253 [I-D.ietf-rtcweb-overview] 254 Alvestrand, H., "Overview: Real Time Protocols for Brower- 255 based Applications", draft-ietf-rtcweb-overview-08 (work 256 in progress), September 2013. 258 [I-D.ietf-rtcweb-data-channel] 259 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data 260 Channels", draft-ietf-rtcweb-data-channel-05 (work in 261 progress), July 2013. 263 [I-D.stewart-tsvwg-sctp-ndata] 264 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A 265 New Data Chunk for Stream Control Transmission Protocol", 266 draft-stewart-tsvwg-sctp-ndata-02 (work in progress), July 267 2013. 269 Authors' Addresses 271 Michael Tuexen 272 Muenster University of Applied Sciences 273 Stegerwaldstrasse 39 274 48565 Steinfurt 275 DE 277 Email: tuexen@fh-muenster.de 278 Randall R. Stewart 279 Adara Networks 280 Chapin, SC 29036 281 US 283 Email: randall@lakerest.net 285 Randell Jesup 286 WorldGate Communications 287 3800 Horizon Blvd, Suite #103 288 Trevose, PA 19053-4947 289 US 291 Phone: +1-215-354-5166 292 Email: randell_ietf@jesup.org 294 Salvatore Loreto 295 Ericsson 296 Hirsalantie 11 297 Jorvas 02420 298 FI 300 Email: Salvatore.Loreto@ericsson.com