idnits 2.17.1 draft-ietf-nsis-ntlp-sctp-07.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 5528 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) == Outdated reference: A later version (-07) exists of draft-ietf-nsis-ext-01 == Outdated reference: A later version (-09) exists of draft-ietf-behave-sctpnat-01 Summary: 4 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: 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-07.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 . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7 73 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 7 74 5.1. Multi-homing support of SCTP . . . . . . . . . . . . . . . 7 75 5.2. Streaming support in SCTP . . . . . . . . . . . . . . . . 8 76 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8 77 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 8 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 This document describes the usage of the General Internet Signaling 89 Transport (GIST) protocol [1] over the Stream Control Transmission 90 Protocol (SCTP) [2]. 92 GIST, in its initial specification for connection mode operation, 93 runs on top of a byte-stream oriented transport protocol providing a 94 reliable, in-sequence delivery, i.e., using the Transmission Control 95 Protocol (TCP) [7] for signaling message transport. However, some 96 NSLP context information has a definite lifetime, therefore, the GIST 97 transport protocol could benefit from flexible retransmission, so 98 stale NSLP messages that are held up by congestion can be dropped. 99 Together with the head-of-line blocking issue and other issues with 100 TCP, these considerations argue that implementations of GIST should 101 support the Stream Control Transport Protocol (SCTP)[2] as an 102 optional transport protocol for GIST, especially if deployment over 103 the public Internet is contemplated. Like TCP, SCTP supports 104 reliability, congestion control and fragmentation. Unlike TCP, SCTP 105 provides a number of functions that are desirable for signaling 106 transport, such as multiple streams and multiple IP addresses for 107 path failure recovery. Furthermore, SCTP offers an advantage of 108 message-oriented transport instead of using the byte stream oriented 109 TCP where one has to provide its own framing mechanisms. In 110 addition, its Partial Reliability extension (PR-SCTP) [3] supports 111 partial retransmission based on a programmable retransmission timer. 112 Furthermore, Datagram Transport Layer Security (DTLS) [4] provides a 113 viable solution for securing datagram transport protocols, e.g., by 114 using DTLS over SCTP [5]. 116 This document defines the use of SCTP as a transport protocol and the 117 use of DTLS as a security mechanism for GIST Messaging Associations 118 and discusses the implications on GIST State Maintenance and API 119 between GIST and NSLPs. Furthermore, this document shows how GIST 120 SHOULD be used to provide the additional features offered by SCTP to 121 deliver the GIST C-mode messages (which can in turn carry NSIS 122 Signaling Layer Protocol (NSLP) [8] messages as payload). More 123 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 method described in this document does not require any changes of 129 GIST or SCTP. However, SCTP implementations MUST support the 130 optional feature of fragmentation of SCTP user messages. 132 Additionally, this document specifies the use of DTLS for securing 133 GIST over datagram transport protocols such as SCTP. 135 2. Terminology and Abbreviations 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [6]. Other 140 terminologies and abbreviations used in this document are taken from 141 related specifications (e.g., [1] and [2]) as follows: 142 o SCTP - Stream Control Transmission Protocol 143 o PR-SCTP - SCTP Partial Reliability Extension 144 o MRM - Message Routing Method 145 o MRI - Message Routing Information 146 o MRS - Message Routing State 147 o SCD - Stack Configuration Data 148 o MA - A GIST Messaging Association is a single connection between 149 two explicitly identified GIST adjacent peers on the data path. A 150 messaging association may use a specific transport protocol and 151 known ports. If security protection is required, it may use a 152 specific network layer security association, or use a transport 153 layer security association internally. A messaging association is 154 bidirectional; signaling messages can be sent over it in either 155 direction, and can refer to flows of either direction. 156 o SCTP Association - A protocol relationship between SCTP endpoints, 157 composed of the two SCTP endpoints and protocol state information. 158 An association can be uniquely identified by the transport 159 addresses used by the endpoints in the association. All transport 160 addresses used by an SCTP endpoint must use the same port number, 161 but can use multiple IP addresses. A transport address used by an 162 SCTP endpoint must not be used by another SCTP endpoint. In other 163 words, a transport address is unique to an SCTP endpoint. Two 164 SCTP endpoints MUST NOT have more than one SCTP association 165 between them at any given time [2]. 166 o Stream - A sequence of user messages that are to be delivered to 167 the upper-layer protocol in order with respect to other messages 168 within the same stream. 170 3. GIST Over SCTP 172 3.1. Message Association Setup 174 3.1.1. Overview 176 The basic GIST protocol specification defines two possible protocols 177 to be used in Messaging Associations, namely Forwards-TCP and TLS. 178 This document adds Forwards-SCTP as another possible protocol. In 179 Forwards-SCTP, analog to Forwards-TCP, connections between peers are 180 opened in the forwards direction, from the querying node, towards the 181 responder. 183 A new MA-Protocol-ID type, "Forwards-SCTP", is defined in this 184 document for using SCTP as GIST transport protocol. A formal 185 definition of Forwards-SCTP is given in the following section. 187 3.1.2. Protocol-Definition: Forwards-SCTP 189 This MA-Protocol-ID denotes a basic use of SCTP between peers. 190 Support for this protocol is OPTIONAL. If this protocol is offered, 191 MA-protocol-options data MUST also be carried in the SCD object. The 192 MA-protocol-options field formats are: 193 o in a Query: no information apart from the field header. 194 o in a Response: 2 byte port number at which the connection will be 195 accepted, followed by 2 pad bytes. 197 The connection is opened in the forwards direction, from the querying 198 node towards the responder. The querying node MAY use any source 199 address and source port. The destination for establishing the 200 message association MUST be derived from information in the Response: 201 the address from the interface- address from the Network-Layer- 202 Information object and the port from the SCD object as described 203 above. 205 Associations using Forwards-SCTP can carry messages with the transfer 206 attribute Reliable=True. If an error occurs on the SCTP connection 207 such as a reset, as can be detected for example by a socket exception 208 condition, GIST MUST report this to NSLPs as discussed in Section 209 4.1.2 of [1]. 211 3.2. Effect on GIST State Maintenance 213 This document defines the use of SCTP as a transport protocol for 214 GIST Messaging Associations. As SCTP provides additional 215 functionality over TCP, this section dicusses the implications of 216 using GIST over SCTP on GIST State Maintenance. 218 While SCTP defines uni-directional streams, for the purpose of this 219 document, the concept of a bi-direction stream is used. 220 Implementations MUST establish downstream and upstream (uni- 221 directional) SCTP streams always together and use the same stream 222 identifier in both directions. Thus, the two uni-directional streams 223 (in opposite directions) form a bi-directional stream. 225 Due to the multi-streaming support of SCTP, it is possible to use 226 different SCTP streams for different resources (e.g., different NSLP 227 sessions), rather than maintaining all messages along the same 228 transport connection/association in a correlated fashion as TCP 229 (which imposes strict (re)ordering and reliability per transport 230 level). However, there are limitations to the use of multi- 231 streaming. All GIST messages for a particular session MUST be sent 232 over the same SCTP stream to assure the NSLP assumption of in-order 233 delivery. Multiple sessions MAY share the same SCTP stream based on 234 local policy. 236 The GIST concept of Messaging Association re-use is not affected by 237 this document or the use of SCTP. All rules defined in the GIST 238 specification remain valid in the context of GIST over SCTP. 240 3.3. PR-SCTP Support 242 A variant of SCTP, PR-SCTP [3] provides a "timed reliability" 243 service, which would be particular useful for delivering GIST 244 Connection mode messages. It allows the user to specify, on a per 245 message basis, the rules governing how persistent the transport 246 service should be in attempting to send the message to the receiver. 247 Because of the chunk bundling function of SCTP, reliable and partial 248 reliable messages can be multiplexed over a single PR-SCTP 249 association. Therefore, a GIST over SCTP implementation SHOULD 250 attempt to establish a PR-SCTP association using "timed reliability" 251 service instead of a standard SCTP association, if available, to 252 support more flexible transport features for potential needs of 253 different NSLPs. 255 In a standard SCTP, instead, if a node has sent the first 256 transmission before the lifetime expires, then the message MUST be 257 sent as a normal reliable message. During episodes of congestion 258 this is particularly unfortunate, as retransmission wastes bandwidth 259 that could have been used for other (non-lifetime expired) messages. 260 The "timed reliability" service in PR-SCTP eliminates this issue and 261 is hence RECOMMENDED to be used for GIST over PR-SCTP. 263 3.4. API between GIST and NSLP 265 GIST specification defines an abstract API between GIST and NSLPs. 266 While this document does not change the API itself, the semantics of 267 some parameters have slightly different interpretation in the context 268 of SCTP. This section only lists those primitives and parameters, 269 that need special consideration when used in the context of SCTP. 270 The relevant primitives from [1] are as follows: 271 o The Timeout parameter in API "SendMessage": According to [1], this 272 parameter represents the "length of time GIST should attempt to 273 send this message before indicating an error." When used with PR- 274 SCTP, this parameter is used as the timeout for the "timed 275 reliability" service of PR-SCTP. 276 o "NetworkNotification": According to [1], this primitive "is passed 277 from GIST to a signalling application. It indicates that a 278 network event of possible interest to the signalling application 279 occurred." Here, if SCTP detects a failure of the primary path, 280 GIST SHOULD also indicate this event to the NSLP by calling this 281 primitive with Network-Notification-Type "Routing Status Change". 282 This notification should be done even if SCTP was able to remain 283 an open connection to the peer due to its multi-homing 284 capabilities. 286 4. Bit-Level Formats 288 4.1. MA-Protocol-Options 290 This section provides the bit-level format for the MA-protocol- 291 options field that is used for SCTP protocol in the Stack- 292 Configuration-Data object of GIST. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 : SCTP port number | Reserved : 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 SCTP port number = Port number at which the responder will accept 301 SCTP connections 303 The SCTP port number is only supplied if sent by the responder. 305 5. Application of GIST over SCTP 307 5.1. Multi-homing support of SCTP 309 In general, the multi-homing support of SCTP can be used to improve 310 fault-tolerance in case of a path- or link-failure. Thus, GIST over 311 SCTP would be able to deliver NSLP messages between peers even if the 312 primary path is not working anymore. However, for the Message 313 Routing Methods (MRMs) defined in the basic GIST specification such a 314 feature is only of limited use. The default MRM is path-coupled, 315 which means, that if the primary path is failing for the SCTP 316 association, it most likely is also for the IP traffic that is 317 signaled for. Thus, GIST would need to perform a refresh anyway to 318 cope with the route change. Nevertheless, the use of the multi- 319 homing support of SCTP provides GIST and the NSLP with another source 320 to detect route changes. Furthermore, for the time between detection 321 of the route change and recovering from it, the alternative path 322 offered by SCTP can be used by the NSLP to make the transition more 323 smoothly. Finally, future MRMs might have different properties and 324 therefore benefit from multi-homing more broadly. 326 5.2. Streaming support in SCTP 328 Streaming support in SCTP is advantageous for GIST. It allows better 329 parallel processing, in particular by avoiding head of line blocking 330 issue in TCP. Since a same GIST MA may be reused by multiple 331 sessions, using TCP as transport GIST signaling messages belonging to 332 different sessions may be blocked if another message is dropped. In 333 the case of SCTP, this can be avoided as different sessions having 334 different requirements can belong to different streams, thus a 335 message loss or reordering in a stream will only affect the delivery 336 of messages within that particular stream, and not any other streams. 338 6. NAT Traversal Issue 340 NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and 341 the GIST extensibility capabilities defined in [9]. This 342 specification does not define NAT traversal procedure for GIST over 343 SCTP, although an approach for SCTP NAT traversal is described in 344 [10]. 346 7. Use of DTLS with GIST 348 The MA-Protocol-ID for DTLS denotes a basic use of datagram transport 349 layer channel security, initially in conjunction with SCTP. It 350 provides authentication, integrity and optionally replay protection 351 for control packets. The use of DTLS for securing GIST over SCTP 352 allows GIST to take the advantage of features provided by SCTP and 353 its extensions. Note replay protection is not available for DTLS 354 over SCTP [5]. The usage of DTLS for GIST over SCTP is similar to 355 TLS for GIST as specified in [1], where a stack-proposal containing 356 both MA-Protocol-IDs for SCTP and DTLS during the GIST handshake 357 phase. 359 GIST message associations using DTLS may carry messages with transfer 360 attributes requesting confidentiality or integrity protection. The 361 specific DTLS version will be negotiated within the DTLS layer 362 itself, but implementations MUST NOT negotiate to protocol versions 363 prior to DTLS v1.0 and MUST use the highest protocol version 364 supported by both peers. GIST nodes supporting DTLS MUST be able to 365 negotiate the DTLS NULL and block cipher ciphers and SHOULD be able 366 to negotiate the new cipher suites. They MAY negotiate any mutually 367 acceptable ciphersuite that provides authentication, integrity, and 368 confidentiality. The same rules for negotiating TLS cipher suites as 369 specified in Section 5.7.3 of [1] apply. 371 No MA-protocol-options field is required for DTLS. The configuration 372 information for the transport protocol over which DTLS is running 373 (e.g. SCTP port number) is provided by the MA-protocol-options for 374 that protocol. 376 8. Security Considerations 378 The security considerations of [1], [2] and [4] apply. Following 379 [5], replay detection of DTLS over SCTP is not supported. 381 The usage of DTLS [4] for securing GIST over datagram transport 382 protocols MUST be implemented and SHOULD be used. An implementation 383 of GIST over SCTP with no PR-SCTP support MAY use TLS for its channel 384 security, when DTLS is not available between two GIST peers. 386 9. IANA Considerations 388 This specification extends [1] by introducing two additional MA- 389 Protocol-IDs: 391 +---------------------+------------------------------------------+ 392 | MA-Protocol-ID | Protocol | 393 +---------------------+------------------------------------------+ 394 | 3 | SCTP opened in the forwards direction | 395 | | | 396 | 4 | DTLS initiated in the forwards direction | 397 +---------------------+------------------------------------------+ 399 10. Acknowledgments 401 The authors would like to thank John Loughney, Robert Hancock, Andrew 402 McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan Demter, Lauri 403 Liuhto, Michael Tuexen, and Roland Bless for their helpful 404 suggestions. 406 11. References 408 11.1. Normative References 410 [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet 411 Signalling Transport", draft-ietf-nsis-ntlp-17 (work in 412 progress), October 2008. 414 [2] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, 415 September 2007. 417 [3] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 418 "Stream Control Transmission Protocol (SCTP) Partial 419 Reliability Extension", RFC 3758, May 2004. 421 [4] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 422 Security", RFC 4347, April 2006. 424 [5] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 425 Transport Layer Security for Stream Control Transmission 426 Protocol", draft-ietf-tsvwg-dtls-for-sctp-00 (work in 427 progress), October 2008. 429 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 430 Levels", BCP 14, RFC 2119, March 1997. 432 11.2. Informative References 434 [7] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 435 September 1981. 437 [8] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 438 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 439 June 2005. 441 [9] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and 442 Extending the NSIS Protocol Family", draft-ietf-nsis-ext-01 443 (work in progress), March 2009. 445 [10] Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control 446 Transmission Protocol (SCTP) Network Address Translation", 447 draft-ietf-behave-sctpnat-01 (work in progress), February 2009. 449 Authors' Addresses 451 Xiaoming Fu 452 University of Goettingen 453 Institute of Computer Science 454 Goldschmidtstr. 7 455 Goettingen 37077 456 Germany 458 Email: fu@cs.uni-goettingen.de 460 Christian Dickmann 461 University of Goettingen 462 Institute of Computer Science 463 Goldschmidtstr. 7 464 Goettingen 37077 465 Germany 467 Email: mail@christian-dickmann.de 469 Jon Crowcroft 470 University of Cambridge 471 Computer Laboratory 472 William Gates Building 473 15 JJ Thomson Avenue 474 Cambridge CB3 0FD 475 UK 477 Email: jon.crowcroft@cl.cam.ac.uk