idnits 2.17.1 draft-dreibholz-tsvwg-sctp-nextgen-ideas-15.txt: -(300): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(323): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(333): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. 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 (21 March 2022) is 761 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (ref. '7') (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (ref. '11') (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 7053 (ref. '15') (Obsoleted by RFC 9260) == Outdated reference: A later version (-27) exists of draft-tuexen-tsvwg-sctp-multipath-23 == Outdated reference: A later version (-37) exists of draft-hohendorf-secure-sctp-32 Summary: 3 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 T. Dreibholz 3 Internet-Draft SimulaMet 4 Intended status: Informational 21 March 2022 5 Expires: 22 September 2022 7 Ideas for a Next Generation of the Stream Control Transmission Protocol 8 (SCTP) 9 draft-dreibholz-tsvwg-sctp-nextgen-ideas-15 11 Abstract 13 This document collects some ideas for a next generation of the Stream 14 Control Transmission Protocol (SCTP) for further discussion. It is a 15 result of lessons learned from more than one decade of SCTP 16 deployment. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 22 September 2022. 35 Copyright Notice 37 Copyright (c) 2022 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Revised BSD License text as 46 described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Revised BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2 53 1.2. Stream Control Transmission Protocol . . . . . . . . . . 2 54 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. What to Change in the Next Generation of SCTP? . . . . . . . 2 56 2.1. Security Considerations . . . . . . . . . . . . . . . . . 3 57 2.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 3 58 3. Experimental Implementations . . . . . . . . . . . . . . . . 3 59 4. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 6.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 1.1. Abbreviations 70 * SCTP: Stream Control Transmission Protocol 72 1.2. Stream Control Transmission Protocol 74 The Stream Control Transmission Protocol (SCTP) has been defined as 75 RFCs in [1], [2], [3], [4], [5], [6], [7], [8], [10], [11], [12], 76 [13], [14], [15]. There is also a detailed introduction provided by 77 [22] as well as lots of further information material on [19]. SCTP 78 is therefore not introduced in more detail here. 80 1.3. Scope 82 The scope of this document is to collect some ideas of what to 83 update/change for a next generation of the SCTP protocol. It is a 84 result of lessons learned from more than one decade of SCTP 85 deployment (see also [22]) as well as ongoing discussions on applying 86 SCTP for WebRTC Data Channels (as introduced in more detail in [18]). 88 2. What to Change in the Next Generation of SCTP? 90 * Make useful extensions part of the next generation core protocol 91 itself (that is, make their implementation a MUST): 93 - Partial Reliablility ([4]) 95 - Chunk Authentication ([6]) 96 - Partial Reliablility ([8]) 98 - Stream Reconfiguration ([13]) 100 - SACK Immediately ([15]) 102 * Consider additional features as part of the next generation core 103 protocol: 105 - Non-Renegable Selective Acknowledgments (NR-SACK) ([24]) 107 - Concurrent Multi-Path Transfer for SCTP (CMT-SCTP) ([16]) 109 * Chunk Authentication provides integrity but not confidentiality. 110 There could be a feature for encryption as well, for example like 111 [17]. Having encryption directly included inside the core 112 transport protocol may make it easier to use (less error-prone 113 work for application developers). 115 * SCTP assigns a fixed TSN per DATA chunk. The TSN cannot be 116 changed any more. That is, it is not possible for a middlebox to 117 split chunks into smaller pieces (for example, for hardware 118 offloading). For further discussion: may it be useful to consider 119 a different behavior? 121 * Definition of path: For SCTP, a path is defined by a remote 122 destination address. [20], [21] shows that CMT-SCTP performance 123 also depends on the local endpoint's outgoing links. Considering 124 each pair of local outgoing and remote incoming address as 125 different path may lead to improved performance in many Internet 126 scenarios. 128 2.1. Security Considerations 130 Security considerations for SCTP can be found in [9]. 132 2.2. IANA Considerations 134 This document introduces no additional considerations for IANA. 136 3. Experimental Implementations 138 An Open Source simulation model for SCTP is available for OMNeT++ 139 within the INET Framework. See [23] for the Git repository. For 140 documentation on the model, see [25] and [22]. This model can be 141 used to evaluate future ideas for SCTP. 143 4. Testbed Platform 145 NorNet is a large-scale and realistic Internet testbed platform with 146 support for multi-homing. A description of and introduction to 147 NorNet is provided in [26], [27], [28], [29]. Further information 148 can be found on the project website [30] at https://www.nntb.no 149 (https://www.nntb.no). 151 5. Acknowledgments 153 The author would like to thank Martin Becke for discussions and 154 support. 156 6. References 158 6.1. Normative References 160 [1] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., 161 Loughney, J., and M. Stillman, "Requirements for Reliable 162 Server Pooling", RFC 3237, DOI 10.17487/RFC3237, January 163 2002, . 165 [2] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 166 Layer Security over Stream Control Transmission Protocol", 167 RFC 3436, DOI 10.17487/RFC3436, December 2002, 168 . 170 [3] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 171 Stewart, "On the Use of Stream Control Transmission 172 Protocol (SCTP) with IPsec", RFC 3554, 173 DOI 10.17487/RFC3554, July 2003, 174 . 176 [4] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 177 Conrad, "Stream Control Transmission Protocol (SCTP) 178 Partial Reliability Extension", RFC 3758, 179 DOI 10.17487/RFC3758, May 2004, 180 . 182 [5] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 183 Parameter for the Stream Control Transmission Protocol 184 (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007, 185 . 187 [6] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 188 "Authenticated Chunks for the Stream Control Transmission 189 Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 190 2007, . 192 [7] Stewart, R., Ed., "Stream Control Transmission Protocol", 193 RFC 4960, DOI 10.17487/RFC4960, September 2007, 194 . 196 [8] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 197 Kozuka, "Stream Control Transmission Protocol (SCTP) 198 Dynamic Address Reconfiguration", RFC 5061, 199 DOI 10.17487/RFC5061, September 2007, 200 . 202 [9] Stillman, M., Ed., Gopal, R., Guttman, E., Sengodan, S., 203 and M. Holdrege, "Threats Introduced by Reliable Server 204 Pooling (RSerPool) and Requirements for Security in 205 Response to Threats", RFC 5355, DOI 10.17487/RFC5355, 206 September 2008, . 208 [10] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 209 Transport Layer Security (DTLS) for Stream Control 210 Transmission Protocol (SCTP)", RFC 6083, 211 DOI 10.17487/RFC6083, January 2011, 212 . 214 [11] Tuexen, M. and R. Stewart, "Stream Control Transmission 215 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 216 DOI 10.17487/RFC6096, January 2011, 217 . 219 [12] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 220 Yasevich, "Sockets API Extensions for the Stream Control 221 Transmission Protocol (SCTP)", RFC 6458, 222 DOI 10.17487/RFC6458, December 2011, 223 . 225 [13] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 226 Transmission Protocol (SCTP) Stream Reconfiguration", 227 RFC 6525, DOI 10.17487/RFC6525, February 2012, 228 . 230 [14] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 231 Control Transmission Protocol (SCTP) Packets for End-Host 232 to End-Host Communication", RFC 6951, 233 DOI 10.17487/RFC6951, May 2013, 234 . 236 [15] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 237 IMMEDIATELY Extension for the Stream Control Transmission 238 Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, 239 . 241 [16] Amer, P. D., Becke, M., Dreibholz, T., Ekiz, N., Iyengar, 242 J., Natarajan, P., Stewart, R. R., and M. Tuexen, "Load 243 Sharing for the Stream Control Transmission Protocol 244 (SCTP)", Work in Progress, Internet-Draft, draft-tuexen- 245 tsvwg-sctp-multipath-23, 9 February 2022, 246 . 249 [17] Hohendorf, C., Unurkhaan, E., and T. Dreibholz, "Secure 250 SCTP", Work in Progress, Internet-Draft, draft-hohendorf- 251 secure-sctp-32, 6 September 2021, 252 . 255 [18] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 256 Channels", Work in Progress, Internet-Draft, draft-ietf- 257 rtcweb-data-channel-13, 4 January 2015, 258 . 261 6.2. Informative References 263 [19] Dreibholz, T., "Thomas Dreibholz's SCTP Page", 2022, 264 . 266 [20] Becke, M., Adhari, H., Rathgeb, E. P., Fu, F., Yang, X., 267 and X. Zhou, "Comparison of Multipath TCP and CMT-SCTP 268 based on Intercontinental Measurements", Proceedings of 269 the IEEE Global Communications Conference (GLOBECOM), 10 270 December 2013, . 274 [21] Adhari, H., "Practical Experiences with an Inter- 275 Continental Testbed for Multi-Path 276 Transport", Proceedings of the 1st International NorNet 277 Users Workshop (NNUW-1), 18 September 2013, . 281 [22] Dreibholz, T., "Evaluation and Optimisation of Multi-Path 282 Transport using the Stream Control Transmission 283 Protocol", Habilitation Treatise, 13 March 2012, 284 . 288 [23] Varga, A., "INET Framework for OMNeT++", 2014, 289 . 291 [24] Natarajan, P., Ekiz, N., Yilmaz, E., Amer, P. D., and 292 J. R. Iyengar, "Non-Renegable Selective Acknowledgments 293 (NR-SACKs) for SCTP", Proceedings of the 16th IEEE 294 International Conference on Network Protocols (ICNP) Pages 295 187-196, ISBN 978-1-4244-2506-8, 296 DOI 10.1109/ICNP.2008.4697037, October 2008, 297 . 300 [25] Rüngeler, I., "SCTP – Evaluating, Improving and Extending 301 the Protocol for Broader Deployment", December 2009, 302 . 306 [26] Gran, E. G., Dreibholz, T., and A. Kvalbein, "NorNet Core 307 – A Multi-Homed Research Testbed", Computer Networks, 308 Special Issue on Future Internet Testbeds Volume 61, Pages 309 75-87, ISSN 1389-1286, DOI 10.1016/j.bjp.2013.12.035, 14 310 March 2014, 311 . 313 [27] Dreibholz, T. and E. G. Gran, "Design and Implementation 314 of the NorNet Core Research Testbed for Multi-Homed 315 Systems", Proceedings of the 3nd International Workshop on 316 Protocols and Applications with Multi-Homing 317 Support (PAMS) Pages 1094-1100, ISBN 978-0-7695-4952-1, 318 DOI 10.1109/WAINA.2013.71, 27 March 2013, 319 . 323 [28] Dreibholz, T., "The NorNet Core Testbed – Introduction and 324 Status", Proceedings of the 1st International NorNet 325 Users Workshop (NNUW-1), 18 September 2013, 326 . 328 [29] Dreibholz, T., "The NorNet Core Testbed – An Experiment 329 Tutorial", Proceedings of the 1st International NorNet 330 Users Workshop (NNUW-1), 19 September 2013, 331 . 333 [30] Dreibholz, T., "NorNet – A Real-World, Large-Scale Multi- 334 Homing Testbed", 2022, . 336 Author's Address 338 Thomas Dreibholz 339 Simula Metropolitan Centre for Digital Engineering 340 Pilestredet 52 341 0167 Oslo 342 Norway 343 Email: dreibh@simula.no 344 URI: https://www.simula.no/people/dreibh