idnits 2.17.1 draft-ietf-nsis-ntlp-sctp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 396. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 18, 2006) is 6515 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-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '1') ** Obsolete normative reference: RFC 2960 (ref. '2') (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '4') (Obsoleted by RFC 9293) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 Expires: December 20, 2006 University of Goettingen 5 J. Crowcroft 6 University of Cambridge 7 June 18, 2006 9 General Internet Signaling Transport (GIST) over SCTP 10 draft-ietf-nsis-ntlp-sctp-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 20, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 The General Internet Signaling Transport (GIST) protocol currently 44 uses TCP or TLS over TCP for connection mode operation. This 45 document describes the usage of GIST over the Stream Control 46 Transmission Protocol (SCTP). The use of SCTP can take the advantage 47 of features provided by SCTP, namely streaming-based transport, 48 support of multiple streams to avoid head of line blocking, and the 49 support of multi-homing to provide network level fault tolerance. 50 Additionally, the support for some extensions of SCTP is also 51 discussed, namely its Partial Reliability Extension and the usage of 52 TLS over SCTP. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 58 3. GIST Over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Message Association Setup . . . . . . . . . . . . . . . . 4 60 3.2. Stack-Configuration-Data information for SCTP . . . . . . 4 61 3.3. Effect on GIST State Maintenance . . . . . . . . . . . . . 5 62 3.4. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 5 63 3.5. API between GIST and NSLP . . . . . . . . . . . . . . . . 5 64 3.5.1. SendMessage . . . . . . . . . . . . . . . . . . . . . 6 65 3.5.2. NetworkNotification . . . . . . . . . . . . . . . . . 6 66 3.6. TLS over SCTP Support . . . . . . . . . . . . . . . . . . 6 67 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 76 Intellectual Property and Copyright Statements . . . . . . . . . . 10 78 1. Introduction 80 This document describes the usage of the General Internet Signaling 81 Transport (GIST) protocol [1] over the Stream Control Transmission 82 Protocol (SCTP) [2]. 84 GIST, in its initial specification for connection mode operation, 85 runs on top of a byte-stream oriented transport protocol providing a 86 reliable, in-sequence delivery, i.e., using the Transmission Control 87 Protocol (TCP) [4] for signaling message transport. However, some 88 NSLP context information has a definite lifetime, therefore, the GIST 89 transport protocol must accommodate flexible retransmission, so stale 90 NSLP messages that are held up by congestion can be dropped. 91 Together with the head-of-line blocking issue and other issues with 92 TCP, these considerations argue that implementations of GIST should 93 support the Stream Control Transport Protocol (SCTP)[2] as an 94 optional transport protocol for GIST, especially if deployment over 95 the public Internet is contemplated. Like TCP, SCTP supports 96 reliability, congestion control, fragmentation. Unlike TCP, SCTP 97 provides a number of functions that are desirable for signaling 98 transport, such as multiple streams and multiple IP addresses for 99 path failure recovery. In addition, its Partial Reliability 100 extension (PR-SCTP) [5] supports partial retransmission based on a 101 programmable retransmission timer. 103 This document shows how GIST should be used with SCTP to provide 104 these additional features to deliver the GIST C-mode messages (which 105 can in turn carry NSIS Signaling Layer Protocol (NSLP) [6] messages 106 as payload). More specifically: 107 how to use the multiple streams feature of SCTP. 108 how to handle the message oriented nature of SCTP. 109 how to take the advantage of multi-homing support of SCTP. 111 Additionally, this document also discusses how to support two 112 extensions of SCTP, namely PR-SCTP [5] and TLS over SCTP [7]. 114 The method described in this document does not require any changes of 115 GIST or SCTP. It is only required that SCTP implementations support 116 the optional feature of fragmentation of SCTP user messages. 118 2. Terminology and Abbreviations 120 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL", in this document are to be interpreted as described in 123 BCP 14, RFC 2119 [3]. Other terminologies and abbreviations used in 124 this document are taken from related specifications (e.g., [1] and 126 [2]) as follows: 127 o TLS - Transport Layer Security 128 o SCTP - Stream Control Transmission Protocol 129 o PR-SCTP - SCTP Partial Reliability Extension 130 o MRM - Message Routing Method 131 o MRI - Message Routing Information 132 o MRS - Message Routing State 133 o MA - A GIST Messaging Association is a single connection between 134 two explicitly identified GIST adjacent peers on the data path. A 135 messaging association may use a specific transport protocol and 136 known ports. If security protection is required, it may use a 137 specific network layer security association, or use a transport 138 layer security association internally. A messaging association is 139 bidirectional; signaling messages can be sent over it in either 140 direction, and can refer to flows of either direction. 141 o SCTP Association - A protocol relationship between SCTP endpoints, 142 composed of the two SCTP endpoints and protocol state information. 143 An association can be uniquely identified by the transport 144 addresses used by the endpoints in the association. Two SCTP 145 endpoints MUST NOT have more than one SCTP association between 146 them at any given time. 147 o Stream - A sequence of user messages that are to be delivered to 148 the upper-layer protocol in order with respect to other messages 149 within the same stream. 151 3. GIST Over SCTP 153 3.1. Message Association Setup 155 The basic GIST protocol specification defines two possible protocols 156 to be used in message associations, namely Forwards-TCP and TLS. 157 This document adds Forwards-SCTP as another possible protocol. In 158 Forwards-SCTP, analog to Forwards-TCP, connections between peers are 159 opened in the forwards direction, from the querying node, towards the 160 responder. SCTP connections may carry NSLP messages with the 161 transfer attribute 'reliable'. 163 A new MA-Protocol-ID type, "Forwards-SCTP", is defined in this 164 document for using SCTP as GIST transport protocol. 166 3.2. Stack-Configuration-Data information for SCTP 168 In order to run GIST over SCTP, the Stack-Proposal and Stack- 169 Configuration-Data objects need to recognize the Forwards-SCTP MA- 170 Protocol-ID type, and interpret it for the transport protocol 171 negotiation during the GIST MA setup handshake (e.g., whether SCTP 172 runs alone or together with TLS). 174 In turn, the "MA-protocol-options" field for Forwards-SCTP needs to 175 be defined for the Stack-Configuration-Data object defined by GIST. 176 This "MA-protocol-options" contains proposed values for the initial 177 and maximum retransmission timeout (RTO) as well as a port number in 178 the case of Response messages. The proposed values for RTO are only 179 suggestions to the peer and may be overridden by local policy. In 180 fact, in order to avoid denial of service attacks, the minimum RTO 181 value is not included in the proposal and in addition implementations 182 should only accept reasonable RTO proposals. 184 The MA-protocol-options formats are: 185 o in a Query: 4 byte RTO initial value and 4 byte RTO maximum value 186 o in a Response: 4 byte RTO initial value, 4 byte RTO maximum value 187 and 2 byte port number at which the connection will be accepted. 189 3.3. Effect on GIST State Maintenance 191 A GIST MA is established over an SCTP association, which comprises 192 one or more SCTP streams. Each of such streams can be used for one 193 or multiple sessions (i.e., one or more MRSs). After completing a 194 GIST MA setup, which implicitly establishes a bi-directional SCTP 195 stream, C-mode messages can be sent over the SCTP association in 196 either direction. Due to multi-streaming support of SCTP, it is easy 197 to maintain sequencing of messages that affect the same resource 198 (e.g., the same NSLP session), rather than maintaining all messages 199 along the same transport connection/association in a correlated 200 fashion as TCP (which imposes strict (re)ordering and reliability per 201 transport level). 203 3.4. PR-SCTP Support 205 A variant of SCTP, PR-SCTP [5] provides a "timed reliability" 206 service. It allows the user to specify, on a per message basis, the 207 rules governing how persistent the transport service should be in 208 attempting to send the message to the receiver. Because of the chunk 209 bundling function of SCTP, reliable and partial reliable messages can 210 be multiplexed over a single PR-SCTP association. Therefore, a GIST 211 over SCTP implementation SHOULD attempt to establish a PR-SCTP 212 association instead of a standard SCTP association, if available, to 213 support more flexible transport features for potential needs of 214 different NSLPs. 216 3.5. API between GIST and NSLP 218 GIST specification defines an abstract API between GIST and NSLPs. 219 While this document does not change the API itself, the semantics of 220 some parameters have slightly different interpretation in the context 221 of SCTP. This section only lists those primitives and parameters, 222 that need special consideration when used in the context of SCTP. 223 The relevant primitives are repeatet from [1] to improve readability, 224 but [1] remains authoritative. 226 3.5.1. SendMessage 228 The SendMessage primitive is used by the NSLP to initiate sending of 229 messages. 231 SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle, 232 NSLP-Id, Session-ID, MRI, 233 SSI-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC ) 235 The following parameter has changed semantics: 237 Timeout: According to [1] this parameter represents the "length of 238 time GIST should attempt to send this message before indicating an 239 error". When used with SCTP, this parameter is also used as the 240 timeout for the "timed reliability" service of PR-SCTP. 242 3.5.2. NetworkNotification 244 The NetworkNotification primitive is passed from GIST to an NSLP. It 245 indicates that a network event of possible interest to the NSLP 246 occurred. 248 NetworkNotification ( MRI, Network-Notification-Type ) 250 If SCTP detects a failure of the primary path, GIST should indicate 251 this event to the NSLP by calling the NetworkNotification primitive 252 with Network-Notification-Type "Routing Status Change". This 253 notification should be done even if SCTP was able to remain an open 254 connection to the next peer due to its multi-homing capabilities. 256 3.6. TLS over SCTP Support 258 GIST using TLS over SCTP is analog to GIST using TLS over TCP. Thus, 259 TLS over SCTP is triggered by a protocol stack consisting of the 260 Forwards-SCTP MA-protocol-ID and the TLS MA-protocol-ID ([1], Section 261 5.7.3). The GIST specification defines the versions of TLS that can 262 be used, as well as the authentication model. All these aspects are 263 not changed by this document and remain valid for TLS over SCTP. 264 Regarding GIST implementations, no special treatment is required in 265 the case of TLS over SCTP in contrast to the existing TLS over TCP 266 case. However, the SCTP and TLS implementations need to provide a 267 TLS over SCTP service as descriped in [7]. One should note that an 268 SCTP association with TLS support takes advantages of SCTP, such as 269 multi-streaming and multi-homing. 271 4. Bit-Level Formats 273 4.1. MA-Protocol-Options 275 This section provides the bit-level format for the MA-protocol- 276 options field that is used for SCTP protocol in the Stack- 277 Configuration-Data object of GIST (see Section 3.2). 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Initial RTO value | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Maximum RTO value | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 : SCTP port number | Reserved : 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Initial RTO value = Initial RTO value (SCTP configuration) in msec 290 Maximum RTO value = Maximum RTO value (SCTP configuration) in msec 291 SCTP port number = Port number at which the responder will accept 292 SCTP connections 294 The SCTP port number is only supplied if sent by the responder. 296 5. Security Considerations 298 The security considerations of both [1] and [2] apply. Further 299 security analysis is needed to consider any additional security 300 vulnerabilities, and will be included in an updated draft. 302 6. IANA Considerations 304 A new MA-Protocol-ID (Forwards-SCTP) needs to be assigned, with a 305 recommended value of 3. 307 7. Acknowledgments 309 The authors would like to thank John Loughney, Robert Hancock and Jan 310 Demter for their helpful suggestions. 312 8. References 314 8.1. Normative References 316 [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet 317 Signaling Transport", draft-ietf-nsis-ntlp-09 (work in 318 progress), February 2006. 320 [2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 321 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, 322 "Stream Control Transmission Protocol", RFC 2960, October 2000. 324 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 325 Levels", BCP 14, RFC 2119, March 1997. 327 8.2. Informative References 329 [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 330 September 1981. 332 [5] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, 333 "Stream Control Transmission Protocol (SCTP) Partial Reliability 334 Extension", RFC 3758, May 2004. 336 [6] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 337 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, 338 June 2005. 340 [7] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer 341 Security over Stream Control Transmission Protocol", RFC 3436, 342 December 2002. 344 Authors' Addresses 346 Xiaoming Fu 347 University of Goettingen 348 Institute for Informatics 349 Lotzestr. 16-18 350 Goettingen 37083 351 Germany 353 Email: fu@cs.uni-goettingen.de 355 Christian Dickmann 356 University of Goettingen 357 Institute for Informatics 358 Lotzestr. 16-18 359 Goettingen 37083 360 Germany 362 Email: mail@christian-dickmann.de 364 Jon Crowcroft 365 University of Cambridge 366 Computer Laboratory 367 William Gates Building 368 15 JJ Thomson Avenue 369 Cambridge CB3 0FD 370 UK 372 Email: jon.crowcroft@cl.cam.ac.uk 374 Intellectual Property Statement 376 The IETF takes no position regarding the validity or scope of any 377 Intellectual Property Rights or other rights that might be claimed to 378 pertain to the implementation or use of the technology described in 379 this document or the extent to which any license under such rights 380 might or might not be available; nor does it represent that it has 381 made any independent effort to identify any such rights. Information 382 on the procedures with respect to rights in RFC documents can be 383 found in BCP 78 and BCP 79. 385 Copies of IPR disclosures made to the IETF Secretariat and any 386 assurances of licenses to be made available, or the result of an 387 attempt made to obtain a general license or permission for the use of 388 such proprietary rights by implementers or users of this 389 specification can be obtained from the IETF on-line IPR repository at 390 http://www.ietf.org/ipr. 392 The IETF invites any interested party to bring to its attention any 393 copyrights, patents or patent applications, or other proprietary 394 rights that may cover technology that may be required to implement 395 this standard. Please address the information to the IETF at 396 ietf-ipr@ietf.org. 398 Disclaimer of Validity 400 This document and the information contained herein are provided on an 401 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 402 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 403 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 404 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 405 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 406 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 408 Copyright Statement 410 Copyright (C) The Internet Society (2006). This document is subject 411 to the rights, licenses and restrictions contained in BCP 78, and 412 except as set forth therein, the authors retain all their rights. 414 Acknowledgment 416 Funding for the RFC Editor function is currently provided by the 417 Internet Society.