idnits 2.17.1 draft-dreibholz-tsvwg-sctp-nextgen-ideas-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 09, 2016) is 3028 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (ref. '8') (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 6096 (ref. '12') (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 7053 (ref. '16') (Obsoleted by RFC 9260) == Outdated reference: A later version (-27) exists of draft-tuexen-tsvwg-sctp-multipath-09 == Outdated reference: A later version (-37) exists of draft-hohendorf-secure-sctp-18 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 Simula Research Laboratory 4 Intended status: Informational January 09, 2016 5 Expires: July 12, 2016 7 Ideas for a Next Generation of the Stream Control Transmission Protocol 8 (SCTP) 9 draft-dreibholz-tsvwg-sctp-nextgen-ideas-03.txt 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 http://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 July 12, 2016. 35 Copyright Notice 37 Copyright (c) 2016 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 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2 54 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.3. Stream Control Transmission Protocol . . . . . . . . . . 2 56 1.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. What to Change in the Next Generation of SCTP? . . . . . . . 3 58 2.1. Security Considerations . . . . . . . . . . . . . . . . . 3 59 2.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 4 60 3. Experimental Implementations . . . . . . . . . . . . . . . . 4 61 4. Testbed Platform . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 65 6.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 1.1. Abbreviations 72 o SCTP: Stream Control Transmission Protocol 74 1.2. Conventions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [1]. 80 1.3. Stream Control Transmission Protocol 82 The Stream Control Transmission Protocol (SCTP) has been defined as 83 RFCs in [2], [3], [4], [5], [6], [7], [8], [9], [11], [12], [13], 84 [14], [15], [16]. There is also a detailed introduction provided by 85 [23] as well as lots of further information material on [20]. SCTP 86 is therefore not introduced in more detail here. 88 1.4. Scope 90 The scope of this document is to collect some ideas of what to 91 update/change for a next generation of the SCTP protocol. It is a 92 result of lessons learned from more than one decade of SCTP 93 deployment (see also [23]) as well as ongoing discussions on applying 94 SCTP for WebRTC Data Channels (as introduced in more detail in [19]). 96 2. What to Change in the Next Generation of SCTP? 98 o Make useful extensions part of the next generation core protocol 99 itself (that is, make their implementation a MUST): 101 * Partial Reliablility ([5]) 103 * Chunk Authentication ([7]) 105 * Partial Reliablility ([9]) 107 * Stream Reconfiguration ([14]) 109 * SACK Immediately ([16]) 111 o Consider additional features as part of the next generation core 112 protocol: 114 * Non-Renegable Selective Acknowledgments (NR-SACK) ([25]) 116 * Concurrent Multi-Path Transfer for SCTP (CMT-SCTP) ([17]) 118 o Chunk Authentication provides integrity but not confidentiality. 119 There could be a feature for encryption as well, for example like 120 [18]. Having encryption directly included inside the core 121 transport protocol may make it easier to use (less error-prone 122 work for application developers). 124 o SCTP assigns a fixed TSN per DATA chunk. The TSN cannot be 125 changed any more. That is, it is not possible for a middlebox to 126 split chunks into smaller pieces (for example, for hardware 127 offloading). For further discussion: may it be useful to consider 128 a different behavior? 130 o Definition of path: For SCTP, a path is defined by a remote 131 destination address. [21], [22] shows that CMT-SCTP performance 132 also depends on the local endpoint's outgoing links. Considering 133 each pair of local outgoing and remote incoming address as 134 different path may lead to improved performance in many Internet 135 scenarios. 137 2.1. Security Considerations 139 Security considerations for SCTP can be found in [10]. 141 2.2. IANA Considerations 143 This document introduces no additional considerations for IANA. 145 3. Experimental Implementations 147 An Open Source simulation model for SCTP is available for OMNeT++ 148 within the INET Framework. See [24] for the Git repository. For 149 documentation on the model, see [26] and [23]. This model can be 150 used to evaluate future ideas for SCTP. 152 4. Testbed Platform 154 NorNet is a large-scale and realistic Internet testbed platform with 155 support for multi-homing. A description of and introduction to 156 NorNet is provided in [27], [28], [29], [30]. Further information 157 can be found on the project website [31] at https://www.nntb.no. 159 5. Acknowledgments 161 The author would like to thank Martin Becke for discussions and 162 support. 164 6. References 166 6.1. Normative References 168 [1] Bradner, S., "Key words for use in RFCs to Indicate 169 Requirement Levels", BCP 14, RFC 2119, March 1997. 171 [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., 172 Loughney, J., and M. Stillman, "Requirements for Reliable 173 Server Pooling", RFC 3237, January 2002. 175 [3] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 176 Layer Security over Stream Control Transmission Protocol", 177 RFC 3436, December 2002. 179 [4] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 180 Stewart, "On the Use of Stream Control Transmission 181 Protocol (SCTP) with IPsec", RFC 3554, July 2003. 183 [5] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 184 Conrad, "Stream Control Transmission Protocol (SCTP) 185 Partial Reliability Extension", RFC 3758, May 2004. 187 [6] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and 188 Parameter for the Stream Control Transmission Protocol 189 (SCTP)", RFC 4820, March 2007. 191 [7] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 192 "Authenticated Chunks for the Stream Control Transmission 193 Protocol (SCTP)", RFC 4895, August 2007. 195 [8] Stewart, R., "Stream Control Transmission Protocol", RFC 196 4960, September 2007. 198 [9] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 199 Kozuka, "Stream Control Transmission Protocol (SCTP) 200 Dynamic Address Reconfiguration", RFC 5061, September 201 2007. 203 [10] Stillman, M., Gopal, R., Guttman, E., Sengodan, S., and M. 204 Holdrege, "Threats Introduced by Reliable Server Pooling 205 (RSerPool) and Requirements for Security in Response to 206 Threats", RFC 5355, September 2008. 208 [11] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 209 Transport Layer Security (DTLS) for Stream Control 210 Transmission Protocol (SCTP)", RFC 6083, January 2011. 212 [12] Tuexen, M. and R. Stewart, "Stream Control Transmission 213 Protocol (SCTP) Chunk Flags Registration", RFC 6096, 214 January 2011. 216 [13] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. 217 Yasevich, "Sockets API Extensions for the Stream Control 218 Transmission Protocol (SCTP)", RFC 6458, December 2011. 220 [14] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 221 Transmission Protocol (SCTP) Stream Reconfiguration", RFC 222 6525, February 2012. 224 [15] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream 225 Control Transmission Protocol (SCTP) Packets for End-Host 226 to End-Host Communication", RFC 6951, May 2013. 228 [16] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK- 229 IMMEDIATELY Extension for the Stream Control Transmission 230 Protocol", RFC 7053, November 2013. 232 [17] Amer, P., Becke, M., Dreibholz, T., Ekiz, N., Jana, J., 233 Natarajan, P., Stewart, R., and M. Tuexen, "Load Sharing 234 for the Stream Control Transmission Protocol (SCTP)", 235 draft-tuexen-tsvwg-sctp-multipath-09 (work in progress), 236 October 2014. 238 [18] Hohendorf, C., Unurkhaan, E., and T. Dreibholz, "Secure 239 SCTP", draft-hohendorf-secure-sctp-18 (work in progress), 240 July 2014. 242 [19] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 243 Channels", draft-ietf-rtcweb-data-channel-13 (work in 244 progress), January 2015. 246 6.2. Informative References 248 [20] Dreibholz, T., "Thomas Dreibholz's SCTP Page", Online: 249 http://www.iem.uni-due.de/~dreibh/sctp/, 2016, 250 . 252 [21] Becke, M., Adhari, H., Rathgeb, E., Fa, F., Yang, X., and 253 X. Zhou, "Comparison of Multipath TCP and CMT-SCTP based 254 on Intercontinental Measurements", Proceedings of the IEEE 255 Global Communications Conference (GLOBECOM), December 256 2013, . 259 [22] Adhari, H., "Practical Experiences with an Inter- 260 Continental Testbed for Multi-Path Transport", Proceedings 261 of the 1st International NorNet Users Workshop (NNUW-1), 262 September 2013, 263 . 266 [23] Dreibholz, T., "Evaluation and Optimisation of Multi-Path 267 Transport using the Stream Control Transmission Protocol", 268 Habilitation Treatise, March 2012, 269 . 273 [24] Varga, A., "INET Framework for OMNeT++", 2014, 274 . 276 [25] Natarajan, P., Ekiz, N., Yilmaz, E., Amer, P., and J. 277 Iyengar, "Non-Renegable Selective Acknowledgments (NR- 278 SACKs) for SCTP", Proceedings of the 16th IEEE 279 International Conference on Network Protocols (ICNP) Pages 280 187-196, ISBN 978-1-4244-2506-8, DOI 10.1109/ 281 ICNP.2008.4697037, October 2008, 282 . 285 [26] Ruengeler, I., "SCTP - Evaluating, Improving and Extending 286 the Protocol for Broader Deployment", December 2009, 287 . 291 [27] Gran, E., Dreibholz, T., and A. Kvalbein, "NorNet Core - A 292 Multi-Homed Research Testbed", Computer Networks, Special 293 Issue on Future Internet Testbeds Volume 61, Pages 75-87, 294 ISSN 1389-1286, DOI 10.1016/j.bjp.2013.12.035, March 2014, 295 . 298 [28] Dreibholz, T. and E. Gran, "Design and Implementation of 299 the NorNet Core Research Testbed for Multi-Homed Systems", 300 Proceedings of the 3nd International Workshop on Protocols 301 and Applications with Multi-Homing Support (PAMS) Pages 302 1094-1100, ISBN 978-0-7695-4952-1, DOI 10.1109/ 303 WAINA.2013.71, March 2013, 304 . 308 [29] Dreibholz, T., "The NorNet Core Testbed - Introduction and 309 Status", Proceedings of the 1st International NorNet Users 310 Workshop (NNUW-1), September 2013, 311 . 314 [30] Dreibholz, T., "The NorNet Core Testbed - An Experiment 315 Tutorial", Proceedings of the 1st International NorNet 316 Users Workshop (NNUW-1), September 2013, 317 . 320 [31] Dreibholz, T., "NorNet -- A Real-World, Large-Scale Multi- 321 Homing Testbed", Online: https://www.nntb.no/, 2016, 322 . 324 Author's Address 326 Thomas Dreibholz 327 Simula Research Laboratory, Network Systems Group 328 Martin Linges vei 17 329 1364 Fornebu, Akershus 330 Norway 332 Phone: +47-6782-8200 333 Fax: +47-6782-8201 334 Email: dreibh@simula.no 335 URI: http://www.iem.uni-due.de/~dreibh/