idnits 2.17.1 draft-ietf-tsvwg-sctp-dtls-encaps-06.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 (November 11, 2014) is 3453 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-12 == Outdated reference: A later version (-13) exists of draft-ietf-rtcweb-data-channel-12 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-01 Summary: 3 errors (**), 0 flaws (~~), 5 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: May 15, 2015 Netflix, Inc. 6 R. Jesup 7 WorldGate Communications 8 S. Loreto 9 Ericsson 10 November 11, 2014 12 DTLS Encapsulation of SCTP Packets 13 draft-ietf-tsvwg-sctp-dtls-encaps-06.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 May 15, 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Overview 74 The Stream Control Transmission Protocol (SCTP) as defined in 75 [RFC4960] is a transport protocol running on top of the network 76 protocols IPv4 [RFC0791] or IPv6 [RFC2460]. This document specifies 77 how SCTP is used on top of the Datagram Transport Layer Security 78 (DTLS) protocol defined in [RFC4347]. This encapsulation is used for 79 example within the WebRTC protocol suite (see 80 [I-D.ietf-rtcweb-overview] for an overview) for transporting non-SRTP 81 data between browsers. The architecture of this stack is described 82 in [I-D.ietf-rtcweb-data-channel]. 84 Please note that the procedures defined in [RFC6951] for dealing with 85 the UDP port numbers do not apply here. When using the encapsulation 86 defined in this document, SCTP is agnostic about the protocols used 87 below DTLS. 89 2. Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 3. Encapsulation and Decapsulation Procedure 97 When an SCTP packet is provided to the DTLS layer, the complete SCTP 98 packet, consisting of the SCTP common header and a number of SCTP 99 chunks, MUST be handled as the payload of the application layer 100 protocol of DTLS. When the DTLS layer has processed a DTLS record 101 containing a message of the application layer protocol, the payload 102 MUST be given up to the SCTP layer. The SCTP layer expects an SCTP 103 common header followed by a number of SCTP chunks. 105 4. General Considerations 107 An implementation of SCTP over DTLS MUST implement and use a path 108 maximum transmission unit (MTU) discovery method that functions 109 without ICMP to provide SCTP/DTLS with an MTU estimate. An 110 implementation of "Packetization Layer Path MTU Discovery" [RFC4821] 111 either in SCTP or DTLS is RECOMMENDED. 113 5. DTLS Considerations 115 The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD 116 support the most recently published version of DTLS, which is DTLS 117 1.2 [RFC6347] as of November 2014. In the absence of a revision to 118 this document, the latter requirement applies to all future versions 119 of DTLS when they are published as RFCs. This document will only be 120 revised if a revision to DTLS or SCTP makes a revision to the 121 encapsulation necessary. 123 SCTP performs segmentation and reassembly based on the path MTU. 124 Therefore the DTLS layer MUST NOT use any compression algorithm. 126 The DTLS MUST support sending messages larger than the current path 127 MTU. This might result in sending IP level fragmented messages. 129 If path MTU discovery is performed by the DTLS layer, the method 130 described in [RFC4821] MUST be used. For probe packets, the 131 extension defined in [RFC6520] MUST be used. 133 If path MTU discovery is performed by the SCTP layer and IPv4 is used 134 as the network layer protocol, the DTLS implementation SHOULD allow 135 the DTLS user to enforce that the corresponding IPv4 packet is sent 136 with the Don't Fragment (DF) bit set. If controlling the DF bit is 137 not possible, for example due to implementation restrictions, a safe 138 value for the path MTU has to be used by the SCTP stack. It is 139 RECOMMENDED that the save value does not exceed 1200 bytes. Please 140 note that [RFC1122] only requires end hosts to be able to reassemble 141 fragmented IP packets of reassembled size of 576 bytes. 143 The DTLS implementation SHOULD allow the DTLS user to set the 144 Differentiated services code point (DSCP) used for IP packets being 145 sent (see [RFC2474]). This requires the DTLS implementation to pass 146 the value through and the lower layer to allow setting this value. 147 If the lower layer does not support setting the DSCP, then the DTLS 148 user will end up with the default value used by protocol stack. 149 Please note that only a single DSCP value can be used for all packets 150 belonging to the same SCTP association. 152 Using explicit congestion notifications (ECN) in SCTP requires the 153 DTLS layer to pass the ECN bits through and its lower layer to expose 154 access to them for sent and received packets (see [RFC3168]). The 155 implementation of DTLS and its lower layer should provide this 156 support. If this is not possible, for example due to implementation 157 restrictions, ECN can't be used by SCTP. 159 6. SCTP Considerations 161 This section describes the usage of the base protocol and the 162 applicability of various SCTP extensions. 164 6.1. Base Protocol 166 This document uses SCTP [RFC4960] with the following restrictions, 167 which are required to reflect that the lower layer is DTLS instead of 168 IPv4 and IPv6 and that SCTP does not deal with the IP addresses or 169 the transport protocol used below DTLS: 171 o A DTLS connection MUST be established before an SCTP association 172 can be set up. 174 o Multiple SCTP associations MAY be multiplexed over a single DTLS 175 connection. The SCTP port numbers are used for multiplexing and 176 demultiplexing the SCTP associations carried over a single DTLS 177 connection. 179 o All SCTP associations are single-homed, because DTLS does not 180 expose any address management to its upper layer. Therefore it is 181 RECOMMENDED to set the SCTP parameter path.max.retrans to 182 association.max.retrans. 184 o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or 185 IPv6 Address parameters. The INIT chunk MUST NOT contain the 186 Supported Address Types parameter. 188 o The implementation MUST NOT rely on processing ICMP or ICMPv6 189 packets. This applies in particular to path MTU discovery when 190 performed by SCTP. 192 o If the SCTP is notified about a path change by its lower layers, 193 SCTP SHOULD retest the Path MTU and reset the congestion state to 194 the initial state. In case of a window based congestion control 195 like the one specified in [RFC4960], this means setting the 196 congestion window and slow start threshold to its initial values. 198 6.2. Padding Extension 200 The padding extension defined in [RFC4820] MUST be supported and used 201 for probe packets when performing path MTU discovery as specified in 202 [RFC4821] by the SCTP layer. 204 6.3. Dynamic Address Reconfiguration Extension 206 If the dynamic address reconfiguration extension defined in [RFC5061] 207 is used, only wildcard addresses MUST be used in ASCONF chunks. 209 6.4. SCTP Authentication Extension 211 The SCTP authentication extension defined in [RFC4895] can be used 212 with DTLS encapsulation, but does not provide any additional benefit. 214 6.5. Partial Reliability Extension 216 Partial reliability as defined in [RFC3758] can be used in 217 combination with DTLS encapsulation. It is also possible to use 218 additional PR-SCTP policies. 220 6.6. Stream Reset Extension 222 The SCTP stream reset extension defined in [RFC6525] can be used with 223 DTLS encapsulation. It is used to reset SCTP streams and add SCTP 224 streams during the lifetime of the SCTP association. 226 6.7. Interleaving of Large User Messages 228 SCTP as defined in [RFC4960] does not support the interleaving of 229 large user messages that need to be fragmented and reassembled by the 230 SCTP layer. The protocol extension defined in 231 [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and can be used 232 with DTLS encapsulation. 234 7. IANA Considerations 236 This document requires no actions from IANA. 238 8. Security Considerations 240 Security considerations for DTLS are specified in [RFC4347] and for 241 SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP 242 and DTLS introduces no new security considerations. 244 SCTP should not process the IP addresses used for the underlying 245 communication since DTLS provides no guarantees about them. 247 It should be noted that the inability to process ICMP or ICMPv6 248 messages does not add any security issue. The processing of these 249 messages for SCTP carried over a connection-less lower layer like IP, 250 IPv6 or UDP is required to protect nodes not supporting SCTP. Since 251 DTLS provides a connection-oriented lower layer, this kind of 252 protection is not necessary. 254 9. Acknowledgments 256 The authors wish to thank David Black, Gorry Fairhurst, Christer 257 Holmberg, Eric Rescorla, Joe Touch and Magnus Westerlund for their 258 invaluable comments. 260 10. References 262 10.1. Normative References 264 [RFC1122] Braden, R., "Requirements for Internet Hosts - 265 Communication Layers", STD 3, RFC 1122, October 1989. 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 271 Security", RFC 4347, April 2006. 273 [RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 274 Parameter for the Stream Control Transmission Protocol 275 (SCTP)", RFC 4820, March 2007. 277 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 278 Discovery", RFC 4821, March 2007. 280 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 281 4960, September 2007. 283 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 284 Security Version 1.2", RFC 6347, January 2012. 286 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 287 Layer Security (TLS) and Datagram Transport Layer Security 288 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 290 10.2. Informative References 292 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 293 1981. 295 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 296 (IPv6) Specification", RFC 2460, December 1998. 298 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 299 "Definition of the Differentiated Services Field (DS 300 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 301 1998. 303 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 304 of Explicit Congestion Notification (ECN) to IP", RFC 305 3168, September 2001. 307 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 308 Conrad, "Stream Control Transmission Protocol (SCTP) 309 Partial Reliability Extension", RFC 3758, May 2004. 311 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 312 "Authenticated Chunks for the Stream Control Transmission 313 Protocol (SCTP)", RFC 4895, August 2007. 315 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 316 Kozuka, "Stream Control Transmission Protocol (SCTP) 317 Dynamic Address Reconfiguration", RFC 5061, September 318 2007. 320 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 321 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 322 6525, February 2012. 324 [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 325 Control Transmission Protocol (SCTP) Packets for End-Host 326 to End-Host Communication", RFC 6951, May 2013. 328 [I-D.ietf-rtcweb-overview] 329 Alvestrand, H., "Overview: Real Time Protocols for 330 Browser-based Applications", draft-ietf-rtcweb-overview-12 331 (work in progress), October 2014. 333 [I-D.ietf-rtcweb-data-channel] 334 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 335 Channels", draft-ietf-rtcweb-data-channel-12 (work in 336 progress), September 2014. 338 [I-D.ietf-tsvwg-sctp-ndata] 339 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 340 "Stream Schedulers and a New Data Chunk for the Stream 341 Control Transmission Protocol", draft-ietf-tsvwg-sctp- 342 ndata-01 (work in progress), July 2014. 344 Authors' Addresses 346 Michael Tuexen 347 Muenster University of Applied Sciences 348 Stegerwaldstrasse 39 349 48565 Steinfurt 350 DE 352 Email: tuexen@fh-muenster.de 354 Randall R. Stewart 355 Netflix, Inc. 356 Chapin, SC 29036 357 US 359 Email: randall@lakerest.net 361 Randell Jesup 362 WorldGate Communications 363 3800 Horizon Blvd, Suite #103 364 Trevose, PA 19053-4947 365 US 367 Phone: +1-215-354-5166 368 Email: randell_ietf@jesup.org 370 Salvatore Loreto 371 Ericsson 372 Hirsalantie 11 373 Jorvas 02420 374 FI 376 Email: Salvatore.Loreto@ericsson.com