idnits 2.17.1 draft-ietf-tsvwg-sctp-dtls-encaps-03.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 (February 7, 2014) is 3728 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-06 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-00 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: August 11, 2014 Adara Networks 6 R. Jesup 7 WorldGate Communications 8 S. Loreto 9 Ericsson 10 February 7, 2014 12 DTLS Encapsulation of SCTP Packets 13 draft-ietf-tsvwg-sctp-dtls-encaps-03.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 August 11, 2014. 39 Copyright Notice 41 Copyright (c) 2014 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 defined 75 in [RFC6347]. This encapsulation is used for example within the 76 RTCWeb protocol suite (see [I-D.ietf-rtcweb-overview] for an 77 overview) for transporting non-media data between browsers. The 78 architecture of this stack is described in 79 [I-D.ietf-rtcweb-data-channel]. 81 1.2. Terminology 83 This document uses the following terms: 85 Association: An SCTP association. 87 Stream: A unidirectional stream of an SCTP association. It is 88 uniquely identified by a stream identifier. 90 1.3. Abbreviations 92 DTLS: Datagram Transport Layer Security. 94 MTU: Maximum Transmission Unit. 96 PPID: Payload Protocol Identifier. 98 SCTP: Stream Control Transmission Protocol. 100 TCP: Transmission Control Protocol. 102 TLS: Transport Layer Security. 104 2. Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Encapsulation and Decapsulation Procedure 112 When an SCTP packet is sent down to the DTLS layer, the complete SCTP 113 packet, consisting of the SCTP common header and a number of SCTP 114 chunks, MUST be handled as the payload of the application layer 115 protocol of DTLS. When the DTLS layer has processed a DTLS record 116 containing a message of the application layer protocol, the payload 117 MUST be given up to the SCTP layer. The SCTP layer expects an SCTP 118 common header followed by a number of SCTP chunks. 120 4. DTLS Considerations 122 The DTLS implementation MUST be based on [RFC6347]. 124 If path MTU discovery is performed by the DTLS layer, the method 125 described in [RFC4821] MUST be used. For probe packets, the 126 extension defined in [RFC6520] MUST be used. 128 If path MTU discovery is performed by the SCTP layer and IPv4 is used 129 as the network layer protocol, the DTLS implementation MUST allow the 130 DTLS user to enforce that the corresponding IPv4 packet is sent with 131 the DF bit set. 133 SCTP performs segmentation and reassembly based on the path MTU. 134 Therefore the DTLS layer MUST NOT use any compression algorithm. 136 The DTLS MUST support sending messages larger than the current path 137 MTU. This might result in sending IP level fragmented messages. 139 5. SCTP Considerations 141 5.1. Base Protocol 143 SCTP as specified in [RFC4960] is used. However, the following 144 restrictions are necessary to reflect that the lower layer is the 145 connection-oriented protocol DTLS instead of the connection less 146 protocol IPv4 and IPv6: 148 o A DTLS connection MUST be established before an SCTP association 149 can be set up. 151 o All associations MUST be single-homed. 153 o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or 154 IPv6 Address parameters. The INIT chunk MUST NOT contain the 155 Supported Address Types parameter. 157 o The implementation MUST NOT rely on processing ICMP or ICMPv6 158 packets. This applies in particular to path MTU discovery when 159 performed by SCTP. 161 5.2. Padding Extension 163 The padding extension defined in [RFC4820] MUST be supported and used 164 for probe packets when performing path MTU discovery as specified in 165 [RFC4821]. 167 5.3. Dynamic Address Reconfiguration Extension 169 If the dynamic address reconfiguration extension defined in [RFC5061] 170 is used, only wildcard addresses MUST be used in ASCONF chunks. 172 5.4. SCTP Authentication Extension 174 The SCTP authentication extension defined in [RFC4895] can be used 175 with DTLS encapsulation, but does not provide any additional benefit. 177 5.5. Partial Reliability Extension 179 Partial reliability as defined in [RFC3758] can be used in 180 combination with DTLS encapsulation. It is also possible to use 181 additional PR-SCTP policies. 183 5.6. Stream Reset Extension 185 The SCTP stream reset extension defined in [RFC6525] can be used with 186 DTLS encapsulation. It is used to reset streams and add streams 187 during the lifetime of the SCTP association. 189 5.7. Interleaving of Large User Messages 191 SCTP as defined in [RFC4960] does not support the interleaving of 192 large user messages that need to be fragmented and reassembled by the 193 SCTP layer. The protocol extension defined in 194 [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation can can be used 195 with DTLS encapsulation. 197 6. IANA Considerations 199 This document requires no actions from IANA. 201 7. Security Considerations 203 Security considerations for DTLS are specified in [RFC6347] and for 204 SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP 205 and DTLS introduces no new security considerations. 207 8. Acknowledgments 209 The authors wish to thank Gorry Fairhurst for his invaluable 210 comments. 212 9. References 214 9.1. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 230 Security Version 1.2", RFC 6347, January 2012. 232 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 233 Layer Security (TLS) and Datagram Transport Layer Security 234 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 236 9.2. Informative References 238 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 239 Conrad, "Stream Control Transmission Protocol (SCTP) 240 Partial Reliability Extension", RFC 3758, May 2004. 242 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 243 "Authenticated Chunks for the Stream Control Transmission 244 Protocol (SCTP)", RFC 4895, August 2007. 246 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 247 Kozuka, "Stream Control Transmission Protocol (SCTP) 248 Dynamic Address Reconfiguration", RFC 5061, September 249 2007. 251 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 252 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 253 6525, February 2012. 255 [I-D.ietf-rtcweb-overview] 256 Alvestrand, H., "Overview: Real Time Protocols for Brower- 257 based Applications", draft-ietf-rtcweb-overview-08 (work 258 in progress), September 2013. 260 [I-D.ietf-rtcweb-data-channel] 261 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data 262 Channels", draft-ietf-rtcweb-data-channel-06 (work in 263 progress), October 2013. 265 [I-D.ietf-tsvwg-sctp-ndata] 266 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A 267 New Data Chunk for Stream Control Transmission Protocol", 268 draft-ietf-tsvwg-sctp-ndata-00 (work in progress), 269 February 2014. 271 Authors' Addresses 273 Michael Tuexen 274 Muenster University of Applied Sciences 275 Stegerwaldstrasse 39 276 48565 Steinfurt 277 DE 279 Email: tuexen@fh-muenster.de 280 Randall R. Stewart 281 Adara Networks 282 Chapin, SC 29036 283 US 285 Email: randall@lakerest.net 287 Randell Jesup 288 WorldGate Communications 289 3800 Horizon Blvd, Suite #103 290 Trevose, PA 19053-4947 291 US 293 Phone: +1-215-354-5166 294 Email: randell_ietf@jesup.org 296 Salvatore Loreto 297 Ericsson 298 Hirsalantie 11 299 Jorvas 02420 300 FI 302 Email: Salvatore.Loreto@ericsson.com