idnits 2.17.1 draft-ietf-nsis-ntlp-sctp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (March 8, 2009) is 5521 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) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-17 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') ** 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-00 -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '7') (Obsoleted by RFC 9293) Summary: 4 errors (**), 0 flaws (~~), 3 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: Standards Track University of Goettingen 5 Expires: September 9, 2009 J. Crowcroft 6 University of Cambridge 7 March 8, 2009 9 General Internet Signaling Transport (GIST) over SCTP and Datagram TLS 10 draft-ietf-nsis-ntlp-sctp-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 9, 2009. 35 Copyright Notice 37 Copyright (c) 2009 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 in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The General Internet Signaling Transport (GIST) protocol currently 49 uses TCP or TLS over TCP for connection mode operation. This 50 document describes the usage of GIST over the Stream Control 51 Transmission Protocol (SCTP) and Datagram Transport Layer Security 52 (DTLS). The use of SCTP can take advantage of features provided by 53 SCTP, namely streaming-based transport, support of multiple streams 54 to avoid head of line blocking, the support of multi-homing to 55 provide network level fault tolerance, as well as partial reliability 56 extension for partially reliable data transmission. This document 57 also specifies how to establish GIST security over datagram transport 58 protocols using an extension to DTLS. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 64 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Message Association Setup . . . . . . . . . . . . . . . . 4 66 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5 68 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 69 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6 70 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 6 71 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 6 73 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7 74 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7 75 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 7 76 6. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 8 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 This document describes the usage of the General Internet Signaling 88 Transport (GIST) protocol [1] over the Stream Control Transmission 89 Protocol (SCTP) [2]. 91 GIST, in its initial specification for connection mode operation, 92 runs on top of a byte-stream oriented transport protocol providing a 93 reliable, in-sequence delivery, i.e., using the Transmission Control 94 Protocol (TCP) [7] for signaling message transport. However, some 95 NSLP context information has a definite lifetime, therefore, the GIST 96 transport protocol could benefit from flexible retransmission, so 97 stale NSLP messages that are held up by congestion can be dropped. 98 Together with the head-of-line blocking issue and other issues with 99 TCP, these considerations argue that implementations of GIST should 100 support the Stream Control Transport Protocol (SCTP)[2] as an 101 optional transport protocol for GIST, especially if deployment over 102 the public Internet is contemplated. Like TCP, SCTP supports 103 reliability, congestion control and fragmentation. Unlike TCP, SCTP 104 provides a number of functions that are desirable for signaling 105 transport, such as multiple streams and multiple IP addresses for 106 path failure recovery. In addition, its Partial Reliability 107 extension (PR-SCTP) [3] supports partial retransmission based on a 108 programmable retransmission timer. Furthermore, Datagram Transport 109 Layer Security (DTLS) [4] provides a viable solution for securing 110 datagram transport protocols, e.g., by using DTLS over SCTP [5]. 112 This document defines the use of SCTP as a transport protocol and the 113 use of DTLS as a security mechanism for GIST Messaging Associations 114 and discusses the implications on GIST State Maintenance and API 115 between GIST and NSLPs. Furthermore, this document shows how GIST 116 SHOULD be used to provide the additional features offered by SCTP to 117 deliver the GIST C-mode messages (which can in turn carry NSIS 118 Signaling Layer Protocol (NSLP) [8] messages as payload). More 119 specifically: 120 o How to use the multiple streams feature of SCTP. 121 o How to use the PR-SCTP extention of SCTP. 122 o How to take advantage of the multi-homing support of SCTP. 124 The method described in this document does not require any changes of 125 GIST or SCTP. However, SCTP implementations MUST support the 126 optional feature of fragmentation of SCTP user messages. 128 2. Terminology and Abbreviations 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [6]. Other 133 terminologies and abbreviations used in this document are taken from 134 related specifications (e.g., [1] and [2]) as follows: 135 o SCTP - Stream Control Transmission Protocol 136 o PR-SCTP - SCTP Partial Reliability Extension 137 o MRM - Message Routing Method 138 o MRI - Message Routing Information 139 o MRS - Message Routing State 140 o SCD - Stack Configuration Data 141 o MA - A GIST Messaging Association is a single connection between 142 two explicitly identified GIST adjacent peers on the data path. A 143 messaging association may use a specific transport protocol and 144 known ports. If security protection is required, it may use a 145 specific network layer security association, or use a transport 146 layer security association internally. A messaging association is 147 bidirectional; signaling messages can be sent over it in either 148 direction, and can refer to flows of either direction. 149 o SCTP Association - A protocol relationship between SCTP endpoints, 150 composed of the two SCTP endpoints and protocol state information. 151 An association can be uniquely identified by the transport 152 addresses used by the endpoints in the association. Two SCTP 153 endpoints MUST NOT have more than one SCTP association between 154 them at any given time. 155 o Stream - A sequence of user messages that are to be delivered to 156 the upper-layer protocol in order with respect to other messages 157 within the same stream. 159 3. GIST Over SCTP 161 3.1. Message Association Setup 163 3.1.1. Overview 165 The basic GIST protocol specification defines two possible protocols 166 to be used in Messaging Associations, namely Forwards-TCP and TLS. 167 This document adds Forwards-SCTP as another possible protocol. In 168 Forwards-SCTP, analog to Forwards-TCP, connections between peers are 169 opened in the forwards direction, from the querying node, towards the 170 responder. 172 A new MA-Protocol-ID type, "Forwards-SCTP", is defined in this 173 document for using SCTP as GIST transport protocol. A formal 174 definition of Forwards-SCTP is given in the following section. 176 3.1.2. Protocol-Definition: Forwards-SCTP 178 This MA-Protocol-ID denotes a basic use of SCTP between peers. 179 Support for this protocol is OPTIONAL. If this protocol is offered, 180 MA-protocol-options data MUST also be carried in the SCD object. The 181 MA-protocol-options field formats are: 182 o in a Query: no information apart from the field header. 183 o in a Response: 2 byte port number at which the connection will be 184 accepted, followed by 2 pad bytes. 186 The connection is opened in the forwards direction, from the querying 187 node towards the responder. The querying node MAY use any source 188 address and source port. The destination information MUST be derived 189 from information in the Response: the address from the interface- 190 address from the Network-Layer-Information object and the port from 191 the SCD object as described above. 193 Associations using Forwards-SCTP can carry messages with the transfer 194 attribute Reliable=True. If an error occurs on the SCTP connection 195 such as a reset, as can be detected for example by a socket exception 196 condition, GIST MUST report this to NSLPs as discussed in Section 197 4.1.2 of [1]. 199 3.2. Effect on GIST State Maintenance 201 This document defines the use of SCTP as a transport protocol for 202 GIST Messaging Associations. As SCTP provides additional 203 functionality over TCP, this section dicusses the implications of 204 using GIST over SCTP on GIST State Maintenance. 206 While SCTP defines uni-directional streams, for the purpose of this 207 document, the concept of a bi-direction stream is used. 208 Implementations MUST establish downstream and upstream (uni- 209 directional) SCTP streams always together and use the same stream 210 identifier in both directions. Thus, the two uni-directional streams 211 (in opposite directions) form a bi-directional stream. 213 Due to the multi-streaming support of SCTP, it is possible to use 214 different SCTP streams for different resources (e.g., different NSLP 215 sessions), rather than maintaining all messages along the same 216 transport connection/association in a correlated fashion as TCP 217 (which imposes strict (re)ordering and reliability per transport 218 level). However, there are limitations to the use of multi- 219 streaming. All GIST messages for a particular session MUST be sent 220 over the same SCTP stream to assure the NSLP assumption of in-order 221 delivery. Multiple sessions MAY share the same SCTP stream based on 222 local policy. 224 The GIST concept of Messaging Association re-use is not affected by 225 this document or the use of SCTP. All rules defined in the GIST 226 specification remain valid in the context of GIST over SCTP. 228 3.3. PR-SCTP Support 230 A variant of SCTP, PR-SCTP [3] provides a "timed reliability" 231 service. It allows the user to specify, on a per message basis, the 232 rules governing how persistent the transport service should be in 233 attempting to send the message to the receiver. Because of the chunk 234 bundling function of SCTP, reliable and partial reliable messages can 235 be multiplexed over a single PR-SCTP association. Therefore, a GIST 236 over SCTP implementation SHOULD attempt to establish a PR-SCTP 237 association instead of a standard SCTP association, if available, to 238 support more flexible transport features for potential needs of 239 different NSLPs. 241 3.4. API between GIST and NSLP 243 GIST specification defines an abstract API between GIST and NSLPs. 244 While this document does not change the API itself, the semantics of 245 some parameters have slightly different interpretation in the context 246 of SCTP. This section only lists those primitives and parameters, 247 that need special consideration when used in the context of SCTP. 248 The relevant primitives from [1] are as follows: 249 o The Timeout parameter in API "SendMessage": According to [1], this 250 parameter represents the "length of time GIST should attempt to 251 send this message before indicating an error." When used with PR- 252 SCTP, this parameter is used as the timeout for the "timed 253 reliability" service of PR-SCTP. 254 o "NetworkNotification": According to [1], this primitive "is passed 255 from GIST to a signalling application. It indicates that a 256 network event of possible interest to the signalling application 257 occurred." Here, if SCTP detects a failure of the primary path, 258 GIST SHOULD also indicate this event to the NSLP by calling this 259 primitive with Network-Notification-Type "Routing Status Change". 260 This notification should be done even if SCTP was able to remain 261 an open connection to the peer due to its multi-homing 262 capabilities. 264 4. Bit-Level Formats 266 4.1. MA-Protocol-Options 268 This section provides the bit-level format for the MA-protocol- 269 options field that is used for SCTP protocol in the Stack- 270 Configuration-Data object of GIST. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 : SCTP port number | Reserved : 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 SCTP port number = Port number at which the responder will accept 279 SCTP connections 281 The SCTP port number is only supplied if sent by the responder. 283 5. Application of GIST over SCTP 285 5.1. Multi-homing support of SCTP 287 In general, the multi-homing support of SCTP can be used to improve 288 fault-tolerance in case of a path- or link-failure. Thus, GIST over 289 SCTP would be able to deliver NSLP messages between peers even if the 290 primary path is not working anymore. However, for the Message 291 Routing Methods (MRMs) defined in the basic GIST specification such a 292 feature is only of limited use. The default MRM is path-coupled, 293 which means, that if the primary path is failing for the SCTP 294 association, it most likely is also for the IP traffic that is 295 signaled for. Thus, GIST would need to perform a refresh anyway to 296 cope with the route change. Nevertheless, the use of the multi- 297 homing support of SCTP provides GIST and the NSLP with another source 298 to detect route changes. Furthermore, for the time between detection 299 of the route change and recovering from it, the alternative path 300 offered by SCTP can be used by the NSLP to make the transition more 301 smoothly. Finally, future MRMs might have different properties and 302 therefore benefit from multi-homing more broadly. 304 5.2. Streaming support in SCTP 306 Streaming support in SCTP is advantageous for GIST. It allows better 307 parallel processing, in particular by avoiding head of line blocking 308 issue in TCP. Since a same GIST MA may be reused by multiple 309 sessions, using TCP as transport GIST signaling messages belonging to 310 different sessions may be blocked if another message is dropped. In 311 the case of SCTP, this can be avoided as different sessions having 312 different requirements can belong to different streams, thus a 313 message loss or reordering in a stream will only affect the delivery 314 of messages within that particular stream, and not any other streams. 316 6. Use of DTLS with GIST 318 The MA-Protocol-ID for DTLS denotes a basic use of datagram transport 319 layer channel security, initially in conjunction with SCTP. It 320 provides authentication, integrity and optionally replay protection 321 for control packets. The use of DTLS for securing GIST over SCTP 322 allows GIST to take the advantage of features provided by SCTP and 323 its extensions. Note replay protection is not available for DTLS 324 over SCTP [5]. The usage of DTLS for GIST over SCTP is similar to 325 TLS for GIST as specified in [1], where a stack-proposal containing 326 both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake 327 phase. 329 GIST message associations using DTLS may carry messages with transfer 330 attributes requesting confidentiality or integrity protection. The 331 specific DTLS version will be negotiated within the DTLS layer 332 itself, but implementations MUST NOT negotiate to protocol versions 333 prior to DTLS v1.0 and MUST use the highest protocol version 334 supported by both peers. GIST nodes supporting DTLS MUST be able to 335 negotiate the DTLS NULL and block cipher ciphers and SHOULD be able 336 to negotiate the new cipher suites. They MAY negotiate any mutually 337 acceptable ciphersuite that provides authentication, integrity, and 338 confidentiality. The same rules for negotiating TLS cipher suites as 339 specified in Section 5.7.3 of [1] apply. 341 No MA-protocol-options field is required for DTLS. The configuration 342 information for the transport protocol over which DTLS is running 343 (e.g. SCTP port number) is provided by the MA-protocol-options for 344 that protocol. 346 7. Security Considerations 348 The security considerations of [1], [2] and [4] apply. Following 349 [5], replay detection of DTLS over SCTP is not supported. 351 The usage of DTLS [4] for securing GIST over datagram transport 352 protocols MUST be implemented and SHOULD be used. An implementation 353 of GIST over SCTP with no PR-SCTP support MAY use TLS for its channel 354 security, when DTLS is not available between two GIST peers. 356 8. IANA Considerations 358 This specification extends [1] by introducing two additional MA- 359 Protocol-IDs: 361 +---------------------+------------------------------------------+ 362 | MA-Protocol-ID | Protocol | 363 +---------------------+------------------------------------------+ 364 | 3 | SCTP opened in the forwards direction | 365 | | | 366 | 4 | DTLS initiated in the forwards direction | 367 +---------------------+------------------------------------------+ 369 9. Acknowledgments 371 The authors would like to thank John Loughney, Robert Hancock, Andrew 372 McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, Lauri 373 Liuhto, and Michael Tuexen for their helpful suggestions. 375 10. References 377 10.1. Normative References 379 [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet 380 Signalling Transport", draft-ietf-nsis-ntlp-17 (work in 381 progress), October 2008. 383 [2] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 384 September 2007. 386 [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 387 "Stream Control Transmission Protocol (SCTP) Partial Reliability 388 Extension", RFC 3758, May 2004. 390 [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 391 Security", RFC 4347, April 2006. 393 [5] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport 394 Layer Security for Stream Control Transmission Protocol", 395 draft-ietf-tsvwg-dtls-for-sctp-00 (work in progress), 396 October 2008. 398 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 399 Levels", BCP 14, RFC 2119, March 1997. 401 10.2. Informative References 403 [7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 404 September 1981. 406 [8] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 407 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 408 June 2005. 410 Authors' Addresses 412 Xiaoming Fu 413 University of Goettingen 414 Institute of Computer Science 415 Goldschmidtstr. 7 416 Goettingen 37077 417 Germany 419 Email: fu@cs.uni-goettingen.de 421 Christian Dickmann 422 University of Goettingen 423 Institute of Computer Science 424 Goldschmidtstr. 7 425 Goettingen 37077 426 Germany 428 Email: mail@christian-dickmann.de 430 Jon Crowcroft 431 University of Cambridge 432 Computer Laboratory 433 William Gates Building 434 15 JJ Thomson Avenue 435 Cambridge CB3 0FD 436 UK 438 Email: jon.crowcroft@cl.cam.ac.uk