idnits 2.17.00 (12 Aug 2021) /tmp/idnits16708/draft-ietf-tsvwg-sctp-dtls-encaps-09.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 (January 24, 2015) is 2667 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 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: draft-ietf-rtcweb-overview has been published as RFC 8825 == Outdated reference: draft-ietf-rtcweb-data-channel has been published as RFC 8831 == Outdated reference: draft-ietf-tsvwg-sctp-prpolicies has been published as RFC 7496 == Outdated reference: draft-ietf-tsvwg-sctp-ndata has been published as RFC 8260 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: July 28, 2015 Netflix, Inc. 6 R. Jesup 7 WorldGate Communications 8 S. Loreto 9 Ericsson 10 January 24, 2015 12 DTLS Encapsulation of SCTP Packets 13 draft-ietf-tsvwg-sctp-dtls-encaps-09.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 unaware of 22 the protocols being used below DTLS; hence explicit IP addresses 23 cannot be used in the SCTP control chunks. As a consequence, the 24 SCTP associations carried over DTLS can only be 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 July 28, 2015. 43 Copyright Notice 45 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Encapsulation and Decapsulation Procedure . . . . . . . . . . 3 63 4. General Considerations . . . . . . . . . . . . . . . . . . . 3 64 5. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Appendix A. NOTE to the RFC-Editor . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 latest 80 version when this RFC was published, DTLS 1.2, is defined in 81 [RFC6347]. This encapsulation is used for example within the WebRTC 82 protocol suite (see [I-D.ietf-rtcweb-overview] for an overview) for 83 transporting non-SRTP data between browsers. The architecture of 84 this stack is described in [I-D.ietf-rtcweb-data-channel]. 86 [NOTE to RFC-Editor: 88 Please ensure that the authors double check the above statement 89 about DTLS 1.2 during AUTH48 and then remove this note before 90 publication. 92 ] 93 +----------+ 94 | SCTP | 95 +----------+ 96 | DTLS | 97 +----------+ 98 | ICE/UDP | 99 +----------+ 101 Figure 1: Basic stack diagram 103 This encapsulation of SCTP over DTLS over UDP or ICE/UDP (see 104 [RFC5245]) can provide a NAT traversal solution in addition to 105 confidentiality, source authentication, and integrity protected 106 transfers. Please note that using ICE does not necessarily imply 107 that a different packet format is used on the wire. 109 Please note that the procedures defined in [RFC6951] for dealing with 110 the UDP port numbers do not apply here. When using the encapsulation 111 defined in this document, SCTP is unaware about the protocols used 112 below DTLS. 114 2. Conventions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 3. Encapsulation and Decapsulation Procedure 122 When an SCTP packet is provided to the DTLS layer, the complete SCTP 123 packet, consisting of the SCTP common header and a number of SCTP 124 chunks, is handled as the payload of the application layer protocol 125 of DTLS. When the DTLS layer has processed a DTLS record containing 126 a message of the application layer protocol, the payload is passed to 127 the SCTP layer. The SCTP layer expects an SCTP common header 128 followed by a number of SCTP chunks. 130 4. General Considerations 132 An implementation of SCTP over DTLS MUST implement and use a path 133 maximum transmission unit (MTU) discovery method that functions 134 without ICMP to provide SCTP/DTLS with an MTU estimate. An 135 implementation of "Packetization Layer Path MTU Discovery" [RFC4821] 136 either in SCTP or DTLS is RECOMMENDED. 138 The path MTU discovery is performed by SCTP when SCTP over DTLS is 139 used for data channels (see Section 5 of 140 [I-D.ietf-rtcweb-data-channel]). 142 5. DTLS Considerations 144 The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD 145 support the most recently published version of DTLS, which was DTLS 146 1.2 [RFC6347] when this RFC was published. In the absence of a 147 revision to this document, the latter requirement applies to all 148 future versions of DTLS when they are published as RFCs. This 149 document will only be revised if a revision to DTLS or SCTP makes a 150 revision to the encapsulation necessary. 152 [NOTE to RFC-Editor: 154 Please ensure that the authors double check the above statement 155 about DTLS 1.2 during AUTH48 and then remove this note before 156 publication. 158 ] 160 SCTP performs segmentation and reassembly based on the path MTU. 161 Therefore the DTLS layer MUST NOT use any compression algorithm. 163 The DTLS MUST support sending messages larger than the current path 164 MTU. This might result in sending IP level fragmented messages. 166 If path MTU discovery is performed by the DTLS layer, the method 167 described in [RFC4821] MUST be used. For probe packets, the 168 extension defined in [RFC6520] MUST be used. 170 If path MTU discovery is performed by the SCTP layer and IPv4 is used 171 as the network layer protocol, the DTLS implementation SHOULD allow 172 the DTLS user to enforce that the corresponding IPv4 packet is sent 173 with the Don't Fragment (DF) bit set. If controlling the DF bit is 174 not possible, for example due to implementation restrictions, a safe 175 value for the path MTU has to be used by the SCTP stack. It is 176 RECOMMENDED that the safe value does not exceed 1200 bytes. Please 177 note that [RFC1122] only requires end hosts to be able to reassemble 178 fragmented IP packets up to 576 bytes in length. 180 The DTLS implementation SHOULD allow the DTLS user to set the 181 Differentiated services code point (DSCP) used for IP packets being 182 sent (see [RFC2474]). This requires the DTLS implementation to pass 183 the value through and the lower layer to allow setting this value. 184 If the lower layer does not support setting the DSCP, then the DTLS 185 user will end up with the default value used by protocol stack. 186 Please note that only a single DSCP value can be used for all packets 187 belonging to the same SCTP association. 189 Using explicit congestion notifications (ECN) in SCTP requires the 190 DTLS layer to pass the ECN bits through and its lower layer to expose 191 access to them for sent and received packets (see [RFC3168]). The 192 implementation of DTLS and its lower layer have to provide this 193 support. If this is not possible, for example due to implementation 194 restrictions, ECN can't be used by SCTP. 196 6. SCTP Considerations 198 This section describes the usage of the base protocol and the 199 applicability of various SCTP extensions. 201 6.1. Base Protocol 203 This document uses SCTP [RFC4960] with the following restrictions, 204 which are required to reflect that the lower layer is DTLS instead of 205 IPv4 and IPv6 and that SCTP does not deal with the IP addresses or 206 the transport protocol used below DTLS: 208 o A DTLS connection MUST be established before an SCTP association 209 can be set up. 211 o Multiple SCTP associations MAY be multiplexed over a single DTLS 212 connection. The SCTP port numbers are used for multiplexing and 213 demultiplexing the SCTP associations carried over a single DTLS 214 connection. 216 o All SCTP associations are single-homed, because DTLS does not 217 expose any address management to its upper layer. Therefore it is 218 RECOMMENDED to set the SCTP parameter path.max.retrans to 219 association.max.retrans. 221 o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or 222 IPv6 Address parameters. The INIT chunk MUST NOT contain the 223 Supported Address Types parameter. 225 o The implementation MUST NOT rely on processing ICMP or ICMPv6 226 packets, since the SCTP layer most likely is unable to access the 227 SCTP common header in the plain text of the packet, which 228 triggered the sending of the ICMP or ICMPv6 packet. This applies 229 in particular to path MTU discovery when performed by SCTP. 231 o If the SCTP layer is notified about a path change by its lower 232 layers, SCTP SHOULD retest the Path MTU and reset the congestion 233 state to the initial state. The window-based congestion control 234 method specified in [RFC4960], resets the congestion window and 235 slow start threshold to their initial values. 237 6.2. Padding Extension 239 When the SCTP layer performs path MTU discovery as specified in 240 [RFC4821], the padding extension defined in [RFC4820] MUST be 241 supported and used for probe packets (HEARTBEAT chunks bundled with 242 PADDING chunks [RFC4820]). 244 6.3. Dynamic Address Reconfiguration Extension 246 If the dynamic address reconfiguration extension defined in [RFC5061] 247 is used, ASCONF chunks MUST use wildcard addresses only. 249 6.4. SCTP Authentication Extension 251 The SCTP authentication extension defined in [RFC4895] can be used 252 with DTLS encapsulation, but does not provide any additional benefit. 254 6.5. Partial Reliability Extension 256 Partial reliability as defined in [RFC3758] can be used in 257 combination with DTLS encapsulation. It is also possible to use 258 additional PR-SCTP policies, for example the ones defined in 259 [I-D.ietf-tsvwg-sctp-prpolicies]. 261 6.6. Stream Reset Extension 263 The SCTP stream reset extension defined in [RFC6525] can be used with 264 DTLS encapsulation. It is used to reset SCTP streams and add SCTP 265 streams during the lifetime of the SCTP association. 267 6.7. Interleaving of Large User Messages 269 SCTP as defined in [RFC4960] does not support the interleaving of 270 large user messages that need to be fragmented and reassembled by the 271 SCTP layer. The protocol extension defined in 272 [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and can be used 273 with DTLS encapsulation. 275 7. IANA Considerations 277 This document requires no actions from IANA. 279 8. Security Considerations 281 Security considerations for DTLS are specified in [RFC4347] and for 282 SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP 283 and DTLS introduces no new security considerations. 285 SCTP should not process the IP addresses used for the underlying 286 communication since DTLS provides no guarantees about them. 288 It should be noted that the inability to process ICMP or ICMPv6 289 messages does not add any security issue. When SCTP is carried over 290 a connection-less lower layer like IPv4, IPv6, or UDP, processing of 291 these messages is required to protect other nodes not supporting 292 SCTP. Since DTLS provides a connection-oriented lower layer, this 293 kind of protection is not necessary. 295 9. Acknowledgments 297 The authors wish to thank David Black, Benoit Claise, Spencer 298 Dawkins, Francis Dupont, Gorry Fairhurst, Stephen Farrell, Christer 299 Holmberg, Barry Leiba, Eric Rescorla, Tom Taylor, Joe Touch and 300 Magnus Westerlund for their invaluable comments. 302 10. References 304 10.1. Normative References 306 [RFC1122] Braden, R., "Requirements for Internet Hosts - 307 Communication Layers", STD 3, RFC 1122, October 1989. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 313 Security", RFC 4347, April 2006. 315 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 316 Parameter for the Stream Control Transmission Protocol 317 (SCTP)", RFC 4820, March 2007. 319 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 320 Discovery", RFC 4821, March 2007. 322 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 323 4960, September 2007. 325 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 326 Security Version 1.2", RFC 6347, January 2012. 328 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 329 Layer Security (TLS) and Datagram Transport Layer Security 330 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 332 10.2. Informative References 334 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 335 1981. 337 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 338 (IPv6) Specification", RFC 2460, December 1998. 340 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 341 "Definition of the Differentiated Services Field (DS 342 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 343 1998. 345 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 346 of Explicit Congestion Notification (ECN) to IP", RFC 347 3168, September 2001. 349 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 350 Conrad, "Stream Control Transmission Protocol (SCTP) 351 Partial Reliability Extension", RFC 3758, May 2004. 353 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 354 "Authenticated Chunks for the Stream Control Transmission 355 Protocol (SCTP)", RFC 4895, August 2007. 357 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 358 Kozuka, "Stream Control Transmission Protocol (SCTP) 359 Dynamic Address Reconfiguration", RFC 5061, September 360 2007. 362 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 363 (ICE): A Protocol for Network Address Translator (NAT) 364 Traversal for Offer/Answer Protocols", RFC 5245, April 365 2010. 367 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 368 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 369 6525, February 2012. 371 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 372 Control Transmission Protocol (SCTP) Packets for End-Host 373 to End-Host Communication", RFC 6951, May 2013. 375 [I-D.ietf-rtcweb-overview] 376 Alvestrand, H., "Overview: Real Time Protocols for 377 Browser-based Applications", draft-ietf-rtcweb-overview-13 378 (work in progress), November 2014. 380 [I-D.ietf-rtcweb-data-channel] 381 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 382 Channels", draft-ietf-rtcweb-data-channel-13 (work in 383 progress), January 2015. 385 [I-D.ietf-tsvwg-sctp-prpolicies] 386 Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, 387 "Additional Policies for the Partial Reliability Extension 388 of the Stream Control Transmission Protocol", draft-ietf- 389 tsvwg-sctp-prpolicies-06 (work in progress), December 390 2014. 392 [I-D.ietf-tsvwg-sctp-ndata] 393 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 394 "Stream Schedulers and a New Data Chunk for the Stream 395 Control Transmission Protocol", draft-ietf-tsvwg-sctp- 396 ndata-02 (work in progress), January 2015. 398 Appendix A. NOTE to the RFC-Editor 400 Although the references to [I-D.ietf-tsvwg-sctp-prpolicies] and 401 [I-D.ietf-tsvwg-sctp-ndata] are informative, put this document in 402 REF-HOLD until these two references have been approved and update 403 these references to the corresponding RFCs. 405 Authors' Addresses 407 Michael Tuexen 408 Muenster University of Applied Sciences 409 Stegerwaldstrasse 39 410 48565 Steinfurt 411 DE 413 Email: tuexen@fh-muenster.de 415 Randall R. Stewart 416 Netflix, Inc. 417 Chapin, SC 29036 418 US 420 Email: randall@lakerest.net 421 Randell Jesup 422 WorldGate Communications 423 3800 Horizon Blvd, Suite #103 424 Trevose, PA 19053-4947 425 US 427 Phone: +1-215-354-5166 428 Email: randell_ietf@jesup.org 430 Salvatore Loreto 431 Ericsson 432 Hirsalantie 11 433 Jorvas 02420 434 FI 436 Email: Salvatore.Loreto@ericsson.com