idnits 2.17.1 draft-ietf-nsis-ntlp-sctp-11.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 28, 2010) is 5112 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (ref. '2') (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 4347 (ref. '4') (Obsoleted by RFC 6347) == Outdated reference: A later version (-06) exists of draft-ietf-tsvwg-dtls-for-sctp-05 -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '7') (Obsoleted by RFC 9293) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-22 == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Fu 3 Internet-Draft C. Dickmann 4 Intended status: Experimental University of Goettingen 5 Expires: October 30, 2010 J. Crowcroft 6 University of Cambridge 7 April 28, 2010 9 General Internet Signaling Transport (GIST) over Stream Control 10 Transmission Protocol (SCTP) and Datagram Transport Layer Security 11 (DTLS) 12 draft-ietf-nsis-ntlp-sctp-11.txt 14 Abstract 16 The General Internet Signaling Transport (GIST) protocol currently 17 uses TCP or Transport Layer Security (TLS) over TCP for connection 18 mode operation. This document describes the usage of GIST over the 19 Stream Control Transmission Protocol (SCTP) and Datagram Transport 20 Layer Security (DTLS). The use of SCTP can take advantage of 21 features provided by SCTP, namely streaming-based transport, support 22 of multiple streams to avoid head of line blocking, the support of 23 multi-homing to provide network level fault tolerance, as well as 24 partial reliability extension for partially reliable data 25 transmission. This document also specifies how to establish GIST 26 security over datagram transport protocols using an extension to 27 DTLS. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 30, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 65 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Message Association Setup . . . . . . . . . . . . . . . . 4 67 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 4 69 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 70 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 5 71 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 6 72 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 6 74 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7 75 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7 76 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 7 77 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8 78 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 8 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 84 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 This document describes the usage of the General Internet Signaling 90 Transport (GIST) protocol [1] and Datagram Transport Layer Security 91 (DTLS) over the Stream Control Transmission Protocol (SCTP) [2]. 93 GIST, in its initial specification for connection mode operation, 94 runs on top of a byte-stream oriented transport protocol providing a 95 reliable, in-sequence delivery, i.e., using the Transmission Control 96 Protocol (TCP) [7] for signaling message transport. However, some 97 Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [8] 98 context information has a definite lifetime, therefore, the GIST 99 transport protocol could benefit from flexible retransmission, so 100 stale NSLP messages that are held up by congestion can be dropped. 101 Together with the head-of-line blocking and multihoming issues with 102 TCP, these considerations argue that implementations of GIST should 103 support the Stream Control Transport Protocol (SCTP)[2] as an 104 optional transport protocol for GIST. Like TCP, SCTP supports 105 reliability, congestion control and fragmentation. Unlike TCP, SCTP 106 provides a number of functions that are desirable for signaling 107 transport, such as multiple streams and multiple IP addresses for 108 path failure recovery. Furthermore, SCTP offers an advantage of 109 message-oriented transport instead of using the byte stream oriented 110 TCP where one has to provide its own framing mechanisms. In 111 addition, its Partial Reliability extension (PR-SCTP) [3] supports 112 partial retransmission based on a programmable retransmission timer. 113 Furthermore, Datagram Transport Layer Security (DTLS) [4] provides a 114 viable solution for securing SCTP [5], which allows SCTP to use 115 almost all its transport features and its extensions. 117 This document defines the use of SCTP as a transport protocol and the 118 use of DTLS as a security mechanism for GIST Messaging Associations 119 and discusses the implications on GIST state maintenance and API 120 between GIST and NSLPs. Furthermore, this document describes how 121 GIST should be interfaced to SCTP and used by NSLPs in order to 122 exploit the additional capabilities offered by SCTP to deliver GIST 123 C-mode messages more effectively. More specifically: 124 o How to use the multiple streams feature of SCTP. 125 o How to use the PR-SCTP extension of SCTP. 126 o How to take advantage of the multi-homing support of SCTP. 128 The methods of using an unchanged SCTP with GIST described in this 129 document do not require any changes to the high level operation and 130 structure of GIST. Addition of new transport options requires 131 additional interface code and configuration support to allow 132 applications to exploit the additional transport when appropriate. 133 In addition, SCTP over GIST implementations MUST support the optional 134 feature of fragmentation of SCTP user messages. 136 Additionally, this document also specifies how to establish GIST 137 security using DTLS for use in combination with e.g., SCTP and UDP. 139 2. Terminology and Abbreviations 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [6]. Other 144 terminologies and abbreviations used in this document are taken from 145 related specifications (e.g., [1] and [2]). 147 3. GIST Over SCTP 149 This section defines a new MA-Protocol-ID type, "Forwards-SCTP", for 150 using SCTP as GIST transport protocol. 152 3.1. Message Association Setup 154 3.1.1. Overview 156 The basic GIST protocol specification defines two possible protocols 157 to be used in Messaging Associations, namely Forwards-TCP and TLS. 158 This information are main part of the Stack Configuration Data (SCD) 159 [1]. This document adds Forwards-SCTP and DTLS as another two 160 possible protocol options. In Forwards-SCTP, analog to Forwards-TCP, 161 connections between peers are opened in the forwards direction, from 162 the querying node, towards the responder. 164 3.1.2. Protocol-Definition: Forwards-SCTP 166 This MA-Protocol-ID "Forwards-SCTP" denotes a basic use of SCTP 167 between peers. Support for this protocol is OPTIONAL. If this 168 protocol is offered, MA-protocol-options data MUST also be carried in 169 the SCD object. The MA-protocol-options field formats are: 170 o in a Query: no information apart from the field header. 171 o in a Response: 2 byte port number at which the connection will be 172 accepted, followed by 2 pad bytes. 174 The connection is opened in the forwards direction, from the querying 175 node towards the responder. The querying node MAY use any source 176 address and source port. The destination for establishing the 177 message association MUST be derived from information in the Response: 178 the address from the interface- address from the Network-Layer- 179 Information object and the port from the SCD object as described 180 above. 182 Associations using Forwards-SCTP can carry messages with the transfer 183 attribute Reliable=True. If an error occurs on the SCTP connection 184 such as a reset, as can be reported by an SCTP socket API 185 notification[9], GIST MUST report this to NSLPs as discussed in 186 Section 4.1.2 of [1]. For the multi-homing scenario, when a 187 destination address of a GIST over SCTP peer encounters a change, the 188 SCTP API will notify GIST about the availability of different SCTP 189 endpoint addresses and possible change of the primary path. 191 3.2. Effect on GIST State Maintenance 193 As SCTP provides additional functionality over TCP, this section 194 discusses the implications of using GIST over SCTP on GIST State 195 Maintenance. 197 While SCTP defines uni-directional streams, for the purpose of this 198 document, the concept of a bi-directional stream is used. 199 Implementations MUST establish downstream and upstream (uni- 200 directional) SCTP streams always together and use the same stream 201 identifier in both directions. Thus, the two uni-directional streams 202 (in opposite directions) form a bi-directional stream. 204 Due to the multi-streaming support of SCTP, it is possible to use 205 different SCTP streams for different resources (e.g., different NSLP 206 sessions), rather than maintaining all messages along the same 207 transport connection/association in a correlated fashion as TCP 208 (which imposes strict (re)ordering and reliability per transport 209 level). However, there are limitations to the use of multi- 210 streaming. All GIST messages for a particular session MUST be sent 211 over the same SCTP stream to assure the NSLP assumption of in-order 212 delivery. Multiple sessions MAY share the same SCTP stream based on 213 local policy. 215 The GIST concept of Messaging Association re-use is not affected by 216 this document or the use of SCTP. All rules defined in the GIST 217 specification remain valid in the context of GIST over SCTP. 219 3.3. PR-SCTP Support 221 A variant of SCTP, PR-SCTP [3] provides a "timed reliability" 222 service, which would be particular useful for delivering GIST 223 Connection mode messages. It allows the user to specify, on a per 224 message basis, the rules governing how persistent the transport 225 service should be in attempting to send the message to the receiver. 226 Because of the chunk bundling function of SCTP, reliable and 227 partially reliable messages can be multiplexed over a single PR-SCTP 228 association. Therefore, a GIST over SCTP implementation SHOULD 229 attempt to establish a PR-SCTP association using "timed reliability" 230 service instead of a standard SCTP association, if available, to 231 support more flexible transport features for potential needs of 232 different NSLPs. 234 In a standard SCTP, instead, if a node has sent the first 235 transmission before the lifetime expires, then the message MUST be 236 sent as a normal reliable message. During episodes of congestion 237 this is particularly unfortunate, as retransmission wastes bandwidth 238 that could have been used for other (non-lifetime expired) messages. 239 The "timed reliability" service in PR-SCTP eliminates this issue and 240 is hence RECOMMENDED to be used for GIST over PR-SCTP. 242 3.4. API between GIST and NSLP 244 GIST specification defines an abstract API between GIST and NSLPs. 245 While this document does not change the API itself, the semantics of 246 some parameters have slightly different interpretation in the context 247 of SCTP. This section only lists those primitives and parameters, 248 that need special consideration when used in the context of SCTP. 249 The relevant primitives from [1] are as follows: 250 o The Timeout parameter in API "SendMessage": According to [1], this 251 parameter represents the "length of time GIST should attempt to 252 send this message before indicating an error." When used with PR- 253 SCTP, this parameter is used as the timeout for the "timed 254 reliability" service of PR-SCTP. 255 o "NetworkNotification": According to [1], this primitive "is passed 256 from GIST to a signalling application. It indicates that a 257 network event of possible interest to the signalling application 258 occurred." Here, if SCTP detects a failure of the primary path, 259 GIST SHOULD also indicate this event to the NSLP by calling this 260 primitive with Network-Notification-Type "Routing Status Change". 261 This notification should be done even if SCTP was able to retain 262 an open connection to the peer due to its multi-homing 263 capabilities. 265 4. Bit-Level Formats 267 4.1. MA-Protocol-Options 269 This section provides the bit-level format for the MA-protocol- 270 options field that is used for SCTP protocol in the Stack- 271 Configuration-Data object of GIST. 273 0 1 2 3 274 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 : SCTP port number | Reserved : 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 SCTP port number = Port number at which the responder will accept 280 SCTP connections 282 The SCTP port number is only supplied if sent by the responder. 284 5. Application of GIST over SCTP 286 5.1. Multi-homing support of SCTP 288 In general, the multi-homing support of SCTP can be used to improve 289 fault-tolerance in case of a path- or link-failure. Thus, GIST over 290 SCTP would be able to deliver NSLP messages between peers even if the 291 primary path is not working anymore. However, for the Message 292 Routing Methods (MRMs) defined in the basic GIST specification such a 293 feature is only of limited use. The default MRM is path-coupled, 294 which means, that if the primary path is failing for the SCTP 295 association, it most likely is also for the IP traffic that is 296 signaled for. Thus, GIST would need to perform a refresh to the NSIS 297 nodes to the alternative path anyway to cope with the route change. 298 When the two endpoints of a multi-homed SCTP association (but none of 299 the intermediate nodes between them) support NSIS, GIST over SCTP 300 provides a robust means for GIST to deliver NSLP messages even when 301 the primary path fails but at least one alternative path between 302 these (NSIS-enabled) endpoints of the multihomed path is available. 303 Additionally, the use of the multi-homing support of SCTP provides 304 GIST and the NSLP with another source to detect route changes. 305 Furthermore, for the time between detection of the route change and 306 recovering from it, the alternative path offered by SCTP can be used 307 by the NSLP to make the transition more smoothly. Finally, future 308 MRMs might have different properties and therefore benefit from 309 multi-homing more broadly. 311 5.2. Streaming support in SCTP 313 Streaming support in SCTP is advantageous for GIST. It allows better 314 parallel processing, in particular by avoiding head of line blocking 315 issue in TCP. Since a same GIST MA may be reused by multiple 316 sessions, using TCP as transport for GIST signaling messages 317 belonging to different sessions may be blocked if another message is 318 dropped. In the case of SCTP, this can be avoided as different 319 sessions having different requirements can belong to different 320 streams, thus a message loss or reordering in a stream will only 321 affect the delivery of messages within that particular stream, and 322 not any other streams. 324 6. NAT Traversal Issue 326 NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and 327 the GIST extensibility capabilities defined in [10]. This 328 specification does not define NAT traversal procedure for GIST over 329 SCTP, although an approach for SCTP NAT traversal is described in 330 [11]. 332 7. Use of DTLS with GIST 334 This section specifies a new "MA-Protocol-ID" for the use of DTLS in 335 GIST, which denotes a basic use of datagram transport layer channel 336 security, initially in conjunction with SCTP over GIST. It provides 337 authentication, integrity and optionally replay protection for 338 control packets. The use of DTLS for securing GIST over SCTP allows 339 GIST to take the advantage of features provided by SCTP and its 340 extensions. Note replay protection is not available for DTLS over 341 SCTP [5]. The usage of DTLS for GIST over SCTP is similar to TLS for 342 GIST as specified in [1], where a stack-proposal containing both MA- 343 Protocol-IDs for SCTP and DTLS during the GIST handshake phase. 345 GIST message associations using DTLS may carry messages with transfer 346 attributes requesting confidentiality or integrity protection. The 347 specific DTLS version will be negotiated within the DTLS layer 348 itself, but implementations MUST NOT negotiate to protocol versions 349 prior to DTLS v1.0 and MUST use the highest protocol version 350 supported by both peers. GIST nodes supporting DTLS MUST be able to 351 negotiate the DTLS NULL and block ciphers and SHOULD be able to 352 negotiate the new cipher suites. They MAY negotiate any mutually 353 acceptable ciphersuite that provides authentication, integrity, and 354 confidentiality. The same rules for negotiating TLS cipher suites as 355 specified in Section 5.7.3 of [1] apply. 357 No MA-protocol-options field is required for DTLS. The configuration 358 information for the transport protocol over which DTLS is running 359 (e.g. SCTP port number) is provided by the MA-protocol-options for 360 that protocol. 362 8. Security Considerations 364 The security considerations of [1], [2] and [4] apply. Following 365 [5], replay detection of DTLS over SCTP is not supported. 367 The usage of DTLS [4] for securing GIST over datagram transport 368 protocols MUST be implemented and SHOULD be used. An implementation 369 of GIST over SCTP with no PR-SCTP support MAY use TLS for its channel 370 security, when DTLS is not available between two GIST peers. 372 9. IANA Considerations 374 This specification requests the following codepoints (MA-Protocol- 375 IDs) be assigned in a registry created by [1]: 377 +---------------------+------------------------------------------+ 378 | MA-Protocol-ID | Protocol | 379 +---------------------+------------------------------------------+ 380 | 3 | SCTP opened in the forwards direction | 381 | | | 382 | 4 | DTLS initiated in the forwards direction | 383 +---------------------+------------------------------------------+ 385 Note that MA-Protocol-ID 4 is never used alone but always coupled 386 with a transport protocol in the stack proposal. 388 10. Acknowledgments 390 The authors would like to thank John Loughney, Jukka Manner, Magnus 391 Westerlund, Robert Hancock, Andrew McDonald, Martin Stiemerling, 392 Fang-Chun Kuo, Jan Demter, Lauri Liuhto, Michael Tuexen, and Roland 393 Bless for their helpful suggestions. 395 11. References 397 11.1. Normative References 399 [1] Schulzrinne, H. and M. Stiemerling, "GIST: General Internet 400 Signalling Transport", draft-ietf-nsis-ntlp-20 (work in 401 progress), June 2009. 403 [2] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 404 September 2007. 406 [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 407 "Stream Control Transmission Protocol (SCTP) Partial 408 Reliability Extension", RFC 3758, May 2004. 410 [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 411 Security", RFC 4347, April 2006. 413 [5] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 414 Transport Layer Security (DTLS) for Stream Control Transmission 415 Protocol (SCTP)", draft-ietf-tsvwg-dtls-for-sctp-05 (work in 416 progress), March 2010. 418 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 419 Levels", BCP 14, RFC 2119, March 1997. 421 11.2. Informative References 423 [7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 424 September 1981. 426 [8] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 427 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 428 June 2005. 430 [9] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, 431 "Sockets API Extensions for Stream Control Transmission 432 Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-22 (work in 433 progress), March 2010. 435 [10] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and 436 Extending the NSIS Protocol Family", draft-ietf-nsis-ext-07 437 (work in progress), April 2010. 439 [11] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 440 Transmission Protocol (SCTP) Network Address Translation", 441 draft-ietf-behave-sctpnat-02 (work in progress), December 2009. 443 Authors' Addresses 445 Xiaoming Fu 446 University of Goettingen 447 Institute of Computer Science 448 Goldschmidtstr. 7 449 Goettingen 37077 450 Germany 452 Email: fu@cs.uni-goettingen.de 454 Christian Dickmann 455 University of Goettingen 456 Institute of Computer Science 457 Goldschmidtstr. 7 458 Goettingen 37077 459 Germany 461 Email: mail@christian-dickmann.de 463 Jon Crowcroft 464 University of Cambridge 465 Computer Laboratory 466 William Gates Building 467 15 JJ Thomson Avenue 468 Cambridge CB3 0FD 469 UK 471 Email: jon.crowcroft@cl.cam.ac.uk