idnits 2.17.1 draft-ietf-tsvwg-sctp-dtls-encaps-01.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 (July 15, 2013) is 3938 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 (-03) exists of draft-stewart-tsvwg-sctp-ndata-01 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-06 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-04 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 R. Jesup 3 Internet-Draft WorldGate Communications 4 Intended status: Standards Track S. Loreto 5 Expires: January 16, 2014 Ericsson 6 R. Stewart 7 Adara Networks 8 M. Tuexen 9 Muenster Univ. of Appl. Sciences 10 July 15, 2013 12 DTLS Encapsulation of SCTP Packets 13 draft-ietf-tsvwg-sctp-dtls-encaps-01.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 January 16, 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 5. SCTP Considerations 137 5.1. Base Protocol 139 SCTP as specified in [RFC4960] is used. However, the following 140 restrictions are necessary to reflect that the lower layer is the 141 connection oriented protocol DTLS instead of the connection less 142 protocol IPv4 and IPv6: 144 o A DTLS connection MUST be established before an SCTP association 145 can be set up. 147 o All associations MUST be single-homed. 149 o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or 150 IPv6 Address parameters. The INIT chunk MUST NOT contain the 151 Supported Address Types parameter. 153 o The implementation MUST NOT rely on processing ICMP or ICMPv6 154 packets. This applies in particular to path MTU discovery when 155 performed by SCTP. 157 5.2. Padding Extension 159 The padding extension defined in [RFC4820] MUST be supported and used 160 for probe packets when performing path MTU discovery as specified in 161 [RFC4821]. 163 5.3. Dynamic Address Reconfiguration Extension 165 If the dynamic address reconfiguration extension defined in [RFC5061] 166 is used, only wildcard addresses MUST be used in ASCONF chunks. 168 5.4. SCTP Authentication Extension 170 The SCTP authentication extension defined in [RFC4895] can be used 171 with DTLS encapsulation, but does not require any additional benefit. 173 5.5. Partial Reliability Extension 175 Partial reliability as defined in [RFC3758] can be used in 176 combination with DTLS encapsulation. It is also possible to use 177 additional PR-SCTP policies. 179 5.6. Stream Reset Extension 181 The SCTP stream reset extension defined in [RFC6525] can be used with 182 DTLS encapsulation. It is used to reset streams and add streams 183 during the lifetime of the SCTP association. 185 5.7. Interleaving of Large User Message 187 SCTP as defined in [RFC4960] does not support the interleaving of 188 large user messages that need to be fragmented and reassembled by the 189 SCTP layer. The protocol extension defined in 190 [I-D.stewart-tsvwg-sctp-ndata] overcomes this limitation can can be 191 used with DTLS encapsulation. 193 6. IANA Considerations 195 This document requires no actions from IANA. 197 7. Security Considerations 199 Security considerations for DTLS are specified in [RFC6347] and for 200 SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP 201 and DTLS introduces no new security considerations. 203 8. Acknowledgments 205 The authors wish to thank Gorry Fairhurst for his invaluable 206 comments. 208 9. References 210 9.1. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, March 1997. 215 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 216 Conrad, "Stream Control Transmission Protocol (SCTP) 217 Partial Reliability Extension", RFC 3758, May 2004. 219 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 220 Parameter for the Stream Control Transmission Protocol 221 (SCTP)", RFC 4820, March 2007. 223 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 224 Discovery", RFC 4821, March 2007. 226 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 227 4960, September 2007. 229 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 230 Kozuka, "Stream Control Transmission Protocol (SCTP) 231 Dynamic Address Reconfiguration", RFC 5061, September 232 2007. 234 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 235 Security Version 1.2", RFC 6347, January 2012. 237 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 238 Layer Security (TLS) and Datagram Transport Layer Security 239 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 241 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 242 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 243 6525, February 2012. 245 [I-D.stewart-tsvwg-sctp-ndata] 246 Stewart, R., Tuexen, M., and S. Loreto, "A New Data Chunk 247 for Stream Control Transmission Protocol", draft-stewart- 248 tsvwg-sctp-ndata-01 (work in progress), February 2013. 250 9.2. Informative References 252 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 253 "Authenticated Chunks for the Stream Control Transmission 254 Protocol (SCTP)", RFC 4895, August 2007. 256 [I-D.ietf-rtcweb-overview] 257 Alvestrand, H., "Overview: Real Time Protocols for Brower- 258 based Applications", draft-ietf-rtcweb-overview-06 (work 259 in progress), February 2013. 261 [I-D.ietf-rtcweb-data-channel] 262 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data 263 Channels", draft-ietf-rtcweb-data-channel-04 (work in 264 progress), February 2013. 266 Authors' Addresses 268 Randell Jesup 269 WorldGate Communications 270 3800 Horizon Blvd, Suite #103 271 Trevose, PA 19053-4947 272 US 274 Phone: +1-215-354-5166 275 Email: randell_ietf@jesup.org 277 Salvatore Loreto 278 Ericsson 279 Hirsalantie 11 280 Jorvas 02420 281 FI 283 Email: Salvatore.Loreto@ericsson.com 284 Randall R. Stewart 285 Adara Networks 286 Chapin, SC 29036 287 US 289 Email: randall@lakerest.net 291 Michael Tuexen 292 Muenster University of Applied Sciences 293 Stegerwaldstrasse 39 294 48565 Steinfurt 295 DE 297 Email: tuexen@fh-muenster.de