idnits 2.17.1 draft-ietf-tsvwg-sctp-dtls-encaps-07.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 10, 2014) is 3425 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 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-13 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-12 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-sctp-prpolicies-05 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-01 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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: June 13, 2015 Netflix, Inc. 6 R. Jesup 7 WorldGate Communications 8 S. Loreto 9 Ericsson 10 December 10, 2014 12 DTLS Encapsulation of SCTP Packets 13 draft-ietf-tsvwg-sctp-dtls-encaps-07.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. Using the 21 encapsulation method described in this document, SCTP is agnostic 22 about the protocols being used below DTLS, explicit IP addresses can 23 not be used in the SCTP control chunks. As a consequence, the SCTP 24 associations are single homed. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 13, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 3. Encapsulation and Decapsulation Procedure . . . . . . . . . . 3 63 4. General Considerations . . . . . . . . . . . . . . . . . . . 3 64 5. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 3 65 6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 Appendix A. NOTE to the RFC-Editor . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 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 [RFC0791] or IPv6 [RFC2460]. This document specifies 78 how SCTP is used on top of the Datagram Transport Layer Security 79 (DTLS) protocol. DTLS 1.0 is defined in [RFC4347] and the present 80 latest version, DTLS 1.2, is defined in [RFC6347]. This 81 encapsulation is used for example within the WebRTC protocol suite 82 (see [I-D.ietf-rtcweb-overview] for an overview) for transporting 83 non-SRTP data between browsers. The architecture of this stack is 84 described in [I-D.ietf-rtcweb-data-channel]. 86 Please note that the procedures defined in [RFC6951] for dealing with 87 the UDP port numbers do not apply here. When using the encapsulation 88 defined in this document, SCTP is agnostic about the protocols used 89 below DTLS. 91 2. Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Encapsulation and Decapsulation Procedure 99 When an SCTP packet is provided to the DTLS layer, the complete SCTP 100 packet, consisting of the SCTP common header and a number of SCTP 101 chunks, is handled as the payload of the application layer protocol 102 of DTLS. When the DTLS layer has processed a DTLS record containing 103 a message of the application layer protocol, the payload is passed to 104 the SCTP layer. The SCTP layer expects an SCTP common header 105 followed by a number of SCTP chunks. 107 4. General Considerations 109 An implementation of SCTP over DTLS MUST implement and use a path 110 maximum transmission unit (MTU) discovery method that functions 111 without ICMP to provide SCTP/DTLS with an MTU estimate. An 112 implementation of "Packetization Layer Path MTU Discovery" [RFC4821] 113 either in SCTP or DTLS is RECOMMENDED. 115 5. DTLS Considerations 117 The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD 118 support the most recently published version of DTLS, which is DTLS 119 1.2 [RFC6347] as of December 2014. In the absence of a revision to 120 this document, the latter requirement applies to all future versions 121 of DTLS when they are published as RFCs. This document will only be 122 revised if a revision to DTLS or SCTP makes a revision to the 123 encapsulation necessary. 125 SCTP performs segmentation and reassembly based on the path MTU. 126 Therefore the DTLS layer MUST NOT use any compression algorithm. 128 The DTLS MUST support sending messages larger than the current path 129 MTU. This might result in sending IP level fragmented messages. 131 If path MTU discovery is performed by the DTLS layer, the method 132 described in [RFC4821] MUST be used. For probe packets, the 133 extension defined in [RFC6520] MUST be used. 135 If path MTU discovery is performed by the SCTP layer and IPv4 is used 136 as the network layer protocol, the DTLS implementation SHOULD allow 137 the DTLS user to enforce that the corresponding IPv4 packet is sent 138 with the Don't Fragment (DF) bit set. If controlling the DF bit is 139 not possible, for example due to implementation restrictions, a safe 140 value for the path MTU has to be used by the SCTP stack. It is 141 RECOMMENDED that the safe value does not exceed 1200 bytes. Please 142 note that [RFC1122] only requires end hosts to be able to reassemble 143 fragmented IP packets up to 576 bytes in length. 145 The DTLS implementation SHOULD allow the DTLS user to set the 146 Differentiated services code point (DSCP) used for IP packets being 147 sent (see [RFC2474]). This requires the DTLS implementation to pass 148 the value through and the lower layer to allow setting this value. 149 If the lower layer does not support setting the DSCP, then the DTLS 150 user will end up with the default value used by protocol stack. 151 Please note that only a single DSCP value can be used for all packets 152 belonging to the same SCTP association. 154 Using explicit congestion notifications (ECN) in SCTP requires the 155 DTLS layer to pass the ECN bits through and its lower layer to expose 156 access to them for sent and received packets (see [RFC3168]). The 157 implementation of DTLS and its lower layer should provide this 158 support. If this is not possible, for example due to implementation 159 restrictions, ECN can't be used by SCTP. 161 6. SCTP Considerations 163 This section describes the usage of the base protocol and the 164 applicability of various SCTP extensions. 166 6.1. Base Protocol 168 This document uses SCTP [RFC4960] with the following restrictions, 169 which are required to reflect that the lower layer is DTLS instead of 170 IPv4 and IPv6 and that SCTP does not deal with the IP addresses or 171 the transport protocol used below DTLS: 173 o A DTLS connection MUST be established before an SCTP association 174 can be set up. 176 o Multiple SCTP associations MAY be multiplexed over a single DTLS 177 connection. The SCTP port numbers are used for multiplexing and 178 demultiplexing the SCTP associations carried over a single DTLS 179 connection. 181 o All SCTP associations are single-homed, because DTLS does not 182 expose any address management to its upper layer. Therefore it is 183 RECOMMENDED to set the SCTP parameter path.max.retrans to 184 association.max.retrans. 186 o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or 187 IPv6 Address parameters. The INIT chunk MUST NOT contain the 188 Supported Address Types parameter. 190 o The implementation MUST NOT rely on processing ICMP or ICMPv6 191 packets. This applies in particular to path MTU discovery when 192 performed by SCTP. 194 o If the SCTP is notified about a path change by its lower layers, 195 SCTP SHOULD retest the Path MTU and reset the congestion state to 196 the initial state. In case of a window based congestion control 197 like the one specified in [RFC4960], this means setting the 198 congestion window and slow start threshold to its initial values. 200 6.2. Padding Extension 202 The padding extension defined in [RFC4820] MUST be supported and used 203 for probe packets when performing path MTU discovery as specified in 204 [RFC4821] by the SCTP layer. 206 6.3. Dynamic Address Reconfiguration Extension 208 If the dynamic address reconfiguration extension defined in [RFC5061] 209 is used, only wildcard addresses MUST be used in ASCONF chunks. 211 6.4. SCTP Authentication Extension 213 The SCTP authentication extension defined in [RFC4895] can be used 214 with DTLS encapsulation, but does not provide any additional benefit. 216 6.5. Partial Reliability Extension 218 Partial reliability as defined in [RFC3758] can be used in 219 combination with DTLS encapsulation. It is also possible to use 220 additional PR-SCTP policies, for example the ones defined in 221 [I-D.ietf-tsvwg-sctp-prpolicies]. 223 6.6. Stream Reset Extension 225 The SCTP stream reset extension defined in [RFC6525] can be used with 226 DTLS encapsulation. It is used to reset SCTP streams and add SCTP 227 streams during the lifetime of the SCTP association. 229 6.7. Interleaving of Large User Messages 231 SCTP as defined in [RFC4960] does not support the interleaving of 232 large user messages that need to be fragmented and reassembled by the 233 SCTP layer. The protocol extension defined in 234 [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and can be used 235 with DTLS encapsulation. 237 7. IANA Considerations 239 This document requires no actions from IANA. 241 8. Security Considerations 243 Security considerations for DTLS are specified in [RFC4347] and for 244 SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP 245 and DTLS introduces no new security considerations. 247 SCTP should not process the IP addresses used for the underlying 248 communication since DTLS provides no guarantees about them. 250 It should be noted that the inability to process ICMP or ICMPv6 251 messages does not add any security issue. The processing of these 252 messages for SCTP carried over a connection-less lower layer like IP, 253 IPv6 or UDP is required to protect nodes not supporting SCTP. Since 254 DTLS provides a connection-oriented lower layer, this kind of 255 protection is not necessary. 257 9. Acknowledgments 259 The authors wish to thank David Black, Spencer Dawkins, Gorry 260 Fairhurst, Christer Holmberg, Eric Rescorla, Joe Touch and Magnus 261 Westerlund for their invaluable comments. 263 10. References 265 10.1. Normative References 267 [RFC1122] Braden, R., "Requirements for Internet Hosts - 268 Communication Layers", STD 3, RFC 1122, October 1989. 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, March 1997. 273 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 274 Security", RFC 4347, April 2006. 276 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 277 Parameter for the Stream Control Transmission Protocol 278 (SCTP)", RFC 4820, March 2007. 280 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 281 Discovery", RFC 4821, March 2007. 283 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 284 4960, September 2007. 286 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 287 Security Version 1.2", RFC 6347, January 2012. 289 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 290 Layer Security (TLS) and Datagram Transport Layer Security 291 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 293 10.2. Informative References 295 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 296 1981. 298 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 299 (IPv6) Specification", RFC 2460, December 1998. 301 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 302 "Definition of the Differentiated Services Field (DS 303 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 304 1998. 306 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 307 of Explicit Congestion Notification (ECN) to IP", RFC 308 3168, September 2001. 310 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 311 Conrad, "Stream Control Transmission Protocol (SCTP) 312 Partial Reliability Extension", RFC 3758, May 2004. 314 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 315 "Authenticated Chunks for the Stream Control Transmission 316 Protocol (SCTP)", RFC 4895, August 2007. 318 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 319 Kozuka, "Stream Control Transmission Protocol (SCTP) 320 Dynamic Address Reconfiguration", RFC 5061, September 321 2007. 323 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 324 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 325 6525, February 2012. 327 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 328 Control Transmission Protocol (SCTP) Packets for End-Host 329 to End-Host Communication", RFC 6951, May 2013. 331 [I-D.ietf-rtcweb-overview] 332 Alvestrand, H., "Overview: Real Time Protocols for 333 Browser-based Applications", draft-ietf-rtcweb-overview-13 334 (work in progress), November 2014. 336 [I-D.ietf-rtcweb-data-channel] 337 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 338 Channels", draft-ietf-rtcweb-data-channel-12 (work in 339 progress), September 2014. 341 [I-D.ietf-tsvwg-sctp-prpolicies] 342 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 343 "Additional Policies for the Partial Reliability Extension 344 of the Stream Control Transmission Protocol", draft-ietf- 345 tsvwg-sctp-prpolicies-05 (work in progress), November 346 2014. 348 [I-D.ietf-tsvwg-sctp-ndata] 349 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 350 "Stream Schedulers and a New Data Chunk for the Stream 351 Control Transmission Protocol", draft-ietf-tsvwg-sctp- 352 ndata-01 (work in progress), July 2014. 354 Appendix A. NOTE to the RFC-Editor 356 Although the references to [I-D.ietf-tsvwg-sctp-prpolicies] and 357 [I-D.ietf-tsvwg-sctp-ndata] are informative, put this document in 358 REF-HOLD until these two references have been approved and update 359 these references to the corresponding RFCs. 361 Authors' Addresses 363 Michael Tuexen 364 Muenster University of Applied Sciences 365 Stegerwaldstrasse 39 366 48565 Steinfurt 367 DE 369 Email: tuexen@fh-muenster.de 371 Randall R. Stewart 372 Netflix, Inc. 373 Chapin, SC 29036 374 US 376 Email: randall@lakerest.net 377 Randell Jesup 378 WorldGate Communications 379 3800 Horizon Blvd, Suite #103 380 Trevose, PA 19053-4947 381 US 383 Phone: +1-215-354-5166 384 Email: randell_ietf@jesup.org 386 Salvatore Loreto 387 Ericsson 388 Hirsalantie 11 389 Jorvas 02420 390 FI 392 Email: Salvatore.Loreto@ericsson.com