idnits 2.17.1 draft-tuexen-tsvwg-sctp-dtls-encaps-00.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 (March 4, 2012) is 4428 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-02 == Outdated reference: A later version (-10) exists of draft-ietf-ledbat-congestion-09 Summary: 2 errors (**), 0 flaws (~~), 3 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: September 5, 2012 Ericsson 6 R. Stewart 7 Adara Networks 8 M. Tuexen 9 Muenster Univ. of Appl. Sciences 10 March 4, 2012 12 DTLS Encapsulation of SCTP Packets for RTCWEB 13 draft-tuexen-tsvwg-sctp-dtls-encaps-00.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 memo document specifies how SCTP can be used on 20 top of the Datagram Transport Layer Security (DTLS) protocol. SCTP 21 over DTLS is used by the RTCWeb protocol suite for transporting non- 22 media data between browsers. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 5, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Encapsulation and Decapsulation Procedure . . . . . . . . . . . 3 61 4. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . . 4 62 5. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . . 4 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 1.1. Overview 75 The Stream Control Transmission Protocol (SCTP) as defined in 76 [RFC4960] is a transport protocol running on top of the network 77 protocols IPv4 or IPv6. This memo document specifies how SCTP can be 78 used on top of the Datagram Transport Layer Security (DTLS) protocol. 79 SCTP over DTLS is used by the RTCWeb protocol suite (see 80 [I-D.ietf-rtcweb-overview] for an overview) for transporting non- 81 media data between browsers. The architecture of this stack is 82 described in [I-D.jesup-rtcweb-data]. 84 1.2. Terminology 86 This document uses the following terms: 88 Association: An SCTP association. 90 Stream: A unidirectional stream of an SCTP association. It is 91 uniquely identified by a stream identifier. 93 1.3. Abbreviations 95 DTLS: Datagram Transport Layer Security. 97 MTU: Maximum Transmission Unit. 99 PPID: Payload Protocol Identifier. 101 SCTP: Stream Control Transmission Protocol. 103 TCP: Transmission Control Protocol. 105 TLS: Transport Layer Security. 107 2. Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Encapsulation and Decapsulation Procedure 115 When an SCTP packet is sent down to the DTLS layer, the complete SCTP 116 packet, consisting of the SCTP common header and a number of SCTP 117 chunks, MUST be handled as the payload of the application layer 118 protocol of DTLS. When the DTLS layer has processed a DTLS record 119 containing a message of the application layer protocol, the payload 120 MUST be given up to the SCTP layer. The SCTP layer expects an SCTP 121 common header followed by a number of SCTP chunks. 123 4. DTLS Considerations 125 The DTLS implementation MUST be based on [RFC6347]. 127 If path MTU discovery is performed by the DTLS layer, the method 128 described in [RFC4821] MUST be used. For probe packets, the 129 extension defined in [RFC6520] MUST be used. 131 If path MTU discovery is performed by the SCTP layer and IPv4 is used 132 as the network layer protocol, the DTLS implementation MUST allow the 133 DTLS user to enforce that the corresponding IPv4 packet is sent with 134 the DF bit set. 136 SCTP performs segmentation and reassembly based on the path MTU. 137 Therefore the DTLS layer MUST NOT use any compression algorithm. 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 The SCTP implementation MUST support the Supported Extensions 170 Parameter defined in [RFC5061] to signal the support of the SCTP 171 stream reset extension (see Section 5.6). The other functionality 172 described in [RFC5061] MUST NOT be used. 174 5.4. SCTP Authentication Extension 176 The SCTP authentication extension defined in [RFC4895] is not 177 required. 179 5.5. Partial Reliability Extension 181 The SCTP implementation MUST support the extension defined in 182 [RFC3758]. 184 The SCTP implementation SHOULD support the following PR-SCTP 185 policies: 187 o A user message is abandoned after a user specified lifetime. 189 o A user message is abandoned if the number of retransmissions 190 exceeds a user specified threshold. 192 5.6. Stream Reset Extension 194 The SCTP implementation MUST support the SCTP stream reset extension 195 defined in [RFC6525]. It is used to reset streams and add streams 196 during the lifetime of the SCTP association. 198 5.7. Large User Message Extension 200 SCTP as defined in [RFC4960] does not support the multiplexing of 201 large user messages that need to be fragmented and reassembled by the 202 SCTP layer. To overcome this limitation, the SCTP implementation 203 SHOULD support an extension, which has to be defined. 205 5.8. Congestion Control 207 In addition to the TCP-like congestion control specified in 208 [RFC4960], other congestion control algorithms MAY be provided. For 209 example, it might be helpful to use a congestion control which does 210 not increase the queueing delay substantially (see 211 [I-D.ietf-ledbat-congestion] for an example). 213 6. IANA Considerations 215 This document requires no actions from IANA. 217 7. Security Considerations 219 TBD. 221 8. Acknowledgments 223 The authors wish to thank XXX for their invaluable comments. 225 9. References 227 9.1. Normative References 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, March 1997. 232 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 233 Conrad, "Stream Control Transmission Protocol (SCTP) 234 Partial Reliability Extension", RFC 3758, May 2004. 236 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 237 Parameter for the Stream Control Transmission Protocol 238 (SCTP)", RFC 4820, March 2007. 240 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 241 Discovery", RFC 4821, March 2007. 243 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 244 "Authenticated Chunks for the Stream Control Transmission 245 Protocol (SCTP)", RFC 4895, August 2007. 247 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 248 RFC 4960, September 2007. 250 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 251 Kozuka, "Stream Control Transmission Protocol (SCTP) 252 Dynamic Address Reconfiguration", RFC 5061, 253 September 2007. 255 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 256 Security Version 1.2", RFC 6347, January 2012. 258 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 259 Layer Security (TLS) and Datagram Transport Layer Security 260 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 262 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 263 Transmission Protocol (SCTP) Stream Reconfiguration", 264 RFC 6525, February 2012. 266 9.2. Informative References 268 [I-D.ietf-rtcweb-overview] 269 Alvestrand, H., "Overview: Real Time Protocols for Brower- 270 based Applications", draft-ietf-rtcweb-overview-02 (work 271 in progress), September 2011. 273 [I-D.jesup-rtcweb-data] 274 Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Datagram 275 Connection", draft-jesup-rtcweb-data-01 (work in 276 progress), October 2011. 278 [I-D.ietf-ledbat-congestion] 279 Hazel, G., Iyengar, J., Kuehlewind, M., and S. Shalunov, 280 "Low Extra Delay Background Transport (LEDBAT)", 281 draft-ietf-ledbat-congestion-09 (work in progress), 282 October 2011. 284 Authors' Addresses 286 Randell Jesup 287 WorldGate Communications 288 3800 Horizon Blvd, Suite #103 289 Trevose, PA 19053-4947 290 US 292 Phone: +1-215-354-5166 293 Email: randell_ietf@jesup.org 294 Salvatore Loreto 295 Ericsson 296 Hirsalantie 11 297 Jorvas 02420 298 FI 300 Email: Salvatore.Loreto@ericsson.com 302 Randall R. Stewart 303 Adara Networks 304 Chapin, SC 29036 305 US 307 Email: randall@lakerest.net 309 Michael Tuexen 310 Muenster University of Applied Sciences 311 Stegerwaldstrasse 39 312 48565 Steinfurt 313 DE 315 Email: tuexen@fh-muenster.de