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