idnits 2.17.1 draft-ietf-nsis-ntlp-sctp-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (February 20, 2010) is 5176 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-04 -- 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-21 == Outdated reference: A later version (-07) exists of draft-ietf-nsis-ext-05 == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-02 Summary: 3 errors (**), 0 flaws (~~), 5 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: August 24, 2010 J. Crowcroft 6 University of Cambridge 7 February 20, 2010 9 General Internet Signaling Transport (GIST) over SCTP and Datagram TLS 10 draft-ietf-nsis-ntlp-sctp-09.txt 12 Abstract 14 The General Internet Signaling Transport (GIST) protocol currently 15 uses TCP or TLS over TCP for connection mode operation. This 16 document describes the usage of GIST over the Stream Control 17 Transmission Protocol (SCTP) and Datagram Transport Layer Security 18 (DTLS). The use of SCTP can take advantage of features provided by 19 SCTP, namely streaming-based transport, support of multiple streams 20 to avoid head of line blocking, the support of multi-homing to 21 provide network level fault tolerance, as well as partial reliability 22 extension for partially reliable data transmission. This document 23 also specifies how to establish GIST security over datagram transport 24 protocols using an extension to DTLS. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 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 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on August 24, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 68 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Message Association Setup . . . . . . . . . . . . . . . . 4 70 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5 72 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 73 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6 74 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7 75 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7 77 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8 78 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 8 79 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 8 80 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8 81 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 8 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 87 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 This document describes the usage of the General Internet Signaling 93 Transport (GIST) protocol [1] over the Stream Control Transmission 94 Protocol (SCTP) [2]. 96 GIST, in its initial specification for connection mode operation, 97 runs on top of a byte-stream oriented transport protocol providing a 98 reliable, in-sequence delivery, i.e., using the Transmission Control 99 Protocol (TCP) [7] for signaling message transport. However, some 100 NSIS Signaling Layer Protocol (NSLP) [8] context information has a 101 definite lifetime, therefore, the GIST transport protocol could 102 benefit from flexible retransmission, so stale NSLP messages that are 103 held up by congestion can be dropped. Together with the head-of-line 104 blocking issue and other issues with TCP, these considerations argue 105 that implementations of GIST should support the Stream Control 106 Transport Protocol (SCTP)[2] as an optional transport protocol for 107 GIST, especially if deployment over the public Internet is 108 contemplated. Like TCP, SCTP supports reliability, congestion 109 control and fragmentation. Unlike TCP, SCTP provides a number of 110 functions that are desirable for signaling transport, such as 111 multiple streams and multiple IP addresses for path failure recovery. 112 Furthermore, SCTP offers an advantage of message-oriented transport 113 instead of using the byte stream oriented TCP where one has to 114 provide its own framing mechanisms. In addition, its Partial 115 Reliability extension (PR-SCTP) [3] supports partial retransmission 116 based on a programmable retransmission timer. Furthermore, Datagram 117 Transport Layer Security (DTLS) [4] provides a viable solution for 118 securing SCTP [5], which allows SCTP to use almost all its transport 119 features and its extensions. 121 This document defines the use of SCTP as a transport protocol and the 122 use of DTLS as a security mechanism for GIST Messaging Associations 123 and discusses the implications on GIST State Maintenance and API 124 between GIST and NSLPs. Furthermore, this document descibes how GIST 125 should be interfaced to SCTP and used by NSLPs in order to exploit 126 the additional capabilties offered by SCTP to deliver GIST C-mode 127 messages more effectively. More specifically: 128 o How to use the multiple streams feature of SCTP. 129 o How to use the PR-SCTP extension of SCTP. 130 o How to take advantage of the multi-homing support of SCTP. 132 The methods of using an unchanged SCTP with GIST described in this 133 document do not require any changes to the high level operation and 134 structure of GIST. Addition of new transport options requires 135 additional interface code and configuration support to allow 136 applications to exploit the additional transport when appropriate. 137 In addition, SCTP implementations MUST support the optional feature 138 of fragmentation of SCTP user messages. 140 Additionally, this document also specifies how to establish GIST 141 security using DTLS for use in combination with e.g., SCTP and UDP. 143 2. Terminology and Abbreviations 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [6]. Other 148 terminologies and abbreviations used in this document are taken from 149 related specifications (e.g., [1] and [2]) as follows: 150 o SCTP - Stream Control Transmission Protocol 151 o PR-SCTP - SCTP Partial Reliability Extension 152 o MRM - Message Routing Method 153 o MRI - Message Routing Information 154 o MRS - Message Routing State 155 o SCD - Stack Configuration Data 156 o MA - A GIST Messaging Association is a single connection between 157 two explicitly identified GIST adjacent peers on the data path. A 158 messaging association may use a specific transport protocol and 159 known ports. If security protection is required, it may use a 160 specific network layer security association, or use a transport 161 layer security association internally. A messaging association is 162 bidirectional; signaling messages can be sent over it in either 163 direction, and can refer to flows of either direction. 164 o SCTP Association - A protocol relationship between SCTP endpoints, 165 composed of the two SCTP endpoints and protocol state information. 166 An association can be uniquely identified by the set of transport 167 addresses used by the endpoints in the association. All transport 168 addresses used by an SCTP endpoint must use the same port number, 169 but can use multiple IP addresses. A transport address used by an 170 SCTP endpoint must not be used by another SCTP endpoint. In other 171 words, a transport address is unique to an SCTP endpoint. Two 172 SCTP endpoints MUST NOT have more than one SCTP association 173 between them at any given time [2]. 174 o Stream - A sequence of user messages that are to be delivered to 175 the upper-layer protocol in order with respect to other messages 176 within the same stream. 178 3. GIST Over SCTP 180 3.1. Message Association Setup 181 3.1.1. Overview 183 The basic GIST protocol specification defines two possible protocols 184 to be used in Messaging Associations, namely Forwards-TCP and TLS. 185 These information are main part of the Stack Configuration Data [1]. 186 This document adds Forwards-SCTP as another possible protocol option. 187 In Forwards-SCTP, analog to Forwards-TCP, connections between peers 188 are opened in the forwards direction, from the querying node, towards 189 the responder. 191 A new MA-Protocol-ID type, "Forwards-SCTP", is defined in this 192 document for using SCTP as GIST transport protocol. A formal 193 definition of Forwards-SCTP is given in the following section. 195 3.1.2. Protocol-Definition: Forwards-SCTP 197 This MA-Protocol-ID denotes a basic use of SCTP between peers. 198 Support for this protocol is OPTIONAL. If this protocol is offered, 199 MA-protocol-options data MUST also be carried in the SCD object. The 200 MA-protocol-options field formats are: 201 o in a Query: no information apart from the field header. 202 o in a Response: 2 byte port number at which the connection will be 203 accepted, followed by 2 pad bytes. 205 The connection is opened in the forwards direction, from the querying 206 node towards the responder. The querying node MAY use any source 207 address and source port. The destination for establishing the 208 message association MUST be derived from information in the Response: 209 the address from the interface- address from the Network-Layer- 210 Information object and the port from the SCD object as described 211 above. 213 Associations using Forwards-SCTP can carry messages with the transfer 214 attribute Reliable=True. If an error occurs on the SCTP connection 215 such as a reset, as can be reported by an SCTP socket API 216 notification[9], GIST MUST report this to NSLPs as discussed in 217 Section 4.1.2 of [1]. For the multi-homing scenario, when a 218 destination address of a GIST over SCTP peer encounters a change, the 219 SCTP API will notify GIST about the availability of different SCTP 220 endpoint addresses and possible change of the primary path. 222 3.2. Effect on GIST State Maintenance 224 This document defines the use of SCTP as a transport protocol for 225 GIST Messaging Associations. As SCTP provides additional 226 functionality over TCP, this section dicusses the implications of 227 using GIST over SCTP on GIST State Maintenance. 229 While SCTP defines uni-directional streams, for the purpose of this 230 document, the concept of a bi-directional stream is used. 231 Implementations MUST establish downstream and upstream (uni- 232 directional) SCTP streams always together and use the same stream 233 identifier in both directions. Thus, the two uni-directional streams 234 (in opposite directions) form a bi-directional stream. 236 Due to the multi-streaming support of SCTP, it is possible to use 237 different SCTP streams for different resources (e.g., different NSLP 238 sessions), rather than maintaining all messages along the same 239 transport connection/association in a correlated fashion as TCP 240 (which imposes strict (re)ordering and reliability per transport 241 level). However, there are limitations to the use of multi- 242 streaming. All GIST messages for a particular session MUST be sent 243 over the same SCTP stream to assure the NSLP assumption of in-order 244 delivery. Multiple sessions MAY share the same SCTP stream based on 245 local policy. 247 The GIST concept of Messaging Association re-use is not affected by 248 this document or the use of SCTP. All rules defined in the GIST 249 specification remain valid in the context of GIST over SCTP. 251 3.3. PR-SCTP Support 253 A variant of SCTP, PR-SCTP [3] provides a "timed reliability" 254 service, which would be particular useful for delivering GIST 255 Connection mode messages. It allows the user to specify, on a per 256 message basis, the rules governing how persistent the transport 257 service should be in attempting to send the message to the receiver. 258 Because of the chunk bundling function of SCTP, reliable and 259 partially reliable messages can be multiplexed over a single PR-SCTP 260 association. Therefore, a GIST over SCTP implementation SHOULD 261 attempt to establish a PR-SCTP association using "timed reliability" 262 service instead of a standard SCTP association, if available, to 263 support more flexible transport features for potential needs of 264 different NSLPs. 266 In a standard SCTP, instead, if a node has sent the first 267 transmission before the lifetime expires, then the message MUST be 268 sent as a normal reliable message. During episodes of congestion 269 this is particularly unfortunate, as retransmission wastes bandwidth 270 that could have been used for other (non-lifetime expired) messages. 271 The "timed reliability" service in PR-SCTP eliminates this issue and 272 is hence RECOMMENDED to be used for GIST over PR-SCTP. 274 3.4. API between GIST and NSLP 276 GIST specification defines an abstract API between GIST and NSLPs. 277 While this document does not change the API itself, the semantics of 278 some parameters have slightly different interpretation in the context 279 of SCTP. This section only lists those primitives and parameters, 280 that need special consideration when used in the context of SCTP. 281 The relevant primitives from [1] are as follows: 282 o The Timeout parameter in API "SendMessage": According to [1], this 283 parameter represents the "length of time GIST should attempt to 284 send this message before indicating an error." When used with PR- 285 SCTP, this parameter is used as the timeout for the "timed 286 reliability" service of PR-SCTP. 287 o "NetworkNotification": According to [1], this primitive "is passed 288 from GIST to a signalling application. It indicates that a 289 network event of possible interest to the signalling application 290 occurred." Here, if SCTP detects a failure of the primary path, 291 GIST SHOULD also indicate this event to the NSLP by calling this 292 primitive with Network-Notification-Type "Routing Status Change". 293 This notification should be done even if SCTP was able to remain 294 an open connection to the peer due to its multi-homing 295 capabilities. 297 4. Bit-Level Formats 299 4.1. MA-Protocol-Options 301 This section provides the bit-level format for the MA-protocol- 302 options field that is used for SCTP protocol in the Stack- 303 Configuration-Data object of GIST. 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 : SCTP port number | Reserved : 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 SCTP port number = Port number at which the responder will accept 312 SCTP connections 314 The SCTP port number is only supplied if sent by the responder. 316 5. Application of GIST over SCTP 318 5.1. Multi-homing support of SCTP 320 In general, the multi-homing support of SCTP can be used to improve 321 fault-tolerance in case of a path- or link-failure. Thus, GIST over 322 SCTP would be able to deliver NSLP messages between peers even if the 323 primary path is not working anymore. However, for the Message 324 Routing Methods (MRMs) defined in the basic GIST specification such a 325 feature is only of limited use. The default MRM is path-coupled, 326 which means, that if the primary path is failing for the SCTP 327 association, it most likely is also for the IP traffic that is 328 signaled for. Thus, GIST would need to perform a refresh anyway to 329 cope with the route change. Nevertheless, the use of the multi- 330 homing support of SCTP provides GIST and the NSLP with another source 331 to detect route changes. Furthermore, for the time between detection 332 of the route change and recovering from it, the alternative path 333 offered by SCTP can be used by the NSLP to make the transition more 334 smoothly. Finally, future MRMs might have different properties and 335 therefore benefit from multi-homing more broadly. 337 5.2. Streaming support in SCTP 339 Streaming support in SCTP is advantageous for GIST. It allows better 340 parallel processing, in particular by avoiding head of line blocking 341 issue in TCP. Since a same GIST MA may be reused by multiple 342 sessions, using TCP as transport for GIST signaling messages 343 belonging to different sessions may be blocked if another message is 344 dropped. In the case of SCTP, this can be avoided as different 345 sessions having different requirements can belong to different 346 streams, thus a message loss or reordering in a stream will only 347 affect the delivery of messages within that particular stream, and 348 not any other streams. 350 6. NAT Traversal Issue 352 NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and 353 the GIST extensibility capabilities defined in [10]. This 354 specification does not define NAT traversal procedure for GIST over 355 SCTP, although an approach for SCTP NAT traversal is described in 356 [11]. 358 7. Use of DTLS with GIST 360 The MA-Protocol-ID for DTLS denotes a basic use of datagram transport 361 layer channel security, initially in conjunction with SCTP. It 362 provides authentication, integrity and optionally replay protection 363 for control packets. The use of DTLS for securing GIST over SCTP 364 allows GIST to take the advantage of features provided by SCTP and 365 its extensions. Note replay protection is not available for DTLS 366 over SCTP [5]. The usage of DTLS for GIST over SCTP is similar to 367 TLS for GIST as specified in [1], where a stack-proposal containing 368 both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake 369 phase. 371 GIST message associations using DTLS may carry messages with transfer 372 attributes requesting confidentiality or integrity protection. The 373 specific DTLS version will be negotiated within the DTLS layer 374 itself, but implementations MUST NOT negotiate to protocol versions 375 prior to DTLS v1.0 and MUST use the highest protocol version 376 supported by both peers. GIST nodes supporting DTLS MUST be able to 377 negotiate the DTLS NULL and block cipher ciphers and SHOULD be able 378 to negotiate the new cipher suites. They MAY negotiate any mutually 379 acceptable ciphersuite that provides authentication, integrity, and 380 confidentiality. The same rules for negotiating TLS cipher suites as 381 specified in Section 5.7.3 of [1] apply. 383 No MA-protocol-options field is required for DTLS. The configuration 384 information for the transport protocol over which DTLS is running 385 (e.g. SCTP port number) is provided by the MA-protocol-options for 386 that protocol. 388 8. Security Considerations 390 The security considerations of [1], [2] and [4] apply. Following 391 [5], replay detection of DTLS over SCTP is not supported. 393 The usage of DTLS [4] for securing GIST over datagram transport 394 protocols MUST be implemented and SHOULD be used. An implementation 395 of GIST over SCTP with no PR-SCTP support MAY use TLS for its channel 396 security, when DTLS is not available between two GIST peers. 398 9. IANA Considerations 400 This specification extends [1] by introducing two additional MA- 401 Protocol-IDs: 403 +---------------------+------------------------------------------+ 404 | MA-Protocol-ID | Protocol | 405 +---------------------+------------------------------------------+ 406 | 3 | SCTP opened in the forwards direction | 407 | | | 408 | 4 | DTLS initiated in the forwards direction | 409 +---------------------+------------------------------------------+ 411 10. Acknowledgments 413 The authors would like to thank John Loughney, Robert Hancock, Andrew 414 McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, Lauri 415 Liuhto, Michael Tuexen, and Roland Bless for their helpful 416 suggestions. 418 11. References 420 11.1. Normative References 422 [1] Schulzrinne, H. and M. Stiemerling, "GIST: General Internet 423 Signalling Transport", draft-ietf-nsis-ntlp-20 (work in 424 progress), June 2009. 426 [2] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 427 September 2007. 429 [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 430 "Stream Control Transmission Protocol (SCTP) Partial 431 Reliability Extension", RFC 3758, May 2004. 433 [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 434 Security", RFC 4347, April 2006. 436 [5] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 437 Transport Layer Security for Stream Control Transmission 438 Protocol", draft-ietf-tsvwg-dtls-for-sctp-04 (work in 439 progress), February 2010. 441 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 442 Levels", BCP 14, RFC 2119, March 1997. 444 11.2. Informative References 446 [7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 447 September 1981. 449 [8] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 450 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 451 June 2005. 453 [9] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, 454 "Sockets API Extensions for Stream Control Transmission 455 Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-21 (work in 456 progress), February 2010. 458 [10] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and 459 Extending the NSIS Protocol Family", draft-ietf-nsis-ext-05 460 (work in progress), December 2009. 462 [11] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 463 Transmission Protocol (SCTP) Network Address Translation", 464 draft-ietf-behave-sctpnat-02 (work in progress), December 2009. 466 Authors' Addresses 468 Xiaoming Fu 469 University of Goettingen 470 Institute of Computer Science 471 Goldschmidtstr. 7 472 Goettingen 37077 473 Germany 475 Email: fu@cs.uni-goettingen.de 477 Christian Dickmann 478 University of Goettingen 479 Institute of Computer Science 480 Goldschmidtstr. 7 481 Goettingen 37077 482 Germany 484 Email: mail@christian-dickmann.de 485 Jon Crowcroft 486 University of Cambridge 487 Computer Laboratory 488 William Gates Building 489 15 JJ Thomson Avenue 490 Cambridge CB3 0FD 491 UK 493 Email: jon.crowcroft@cl.cam.ac.uk