idnits 2.17.1 draft-ietf-sigtran-sctp-applicability-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 341 has weird spacing: '...se only one o...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2960' on line 450 looks like a reference -- Missing reference section? 'RFC2663' on line 458 looks like a reference -- Missing reference section? 'RFC2401' on line 455 looks like a reference -- Missing reference section? 'RFC2694' on line 463 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. Coene 2 Internet Engineering Task Force M. Tuexen 3 Issued: April 2001 G. Verwimp 4 Expires: October 2001 Siemens 5 J. Loughney 6 Nokia 7 R.R. Stewart 8 Cisco 9 Qiaobing Xie 10 Motorola 11 M. Holdrege 12 ipVerse 13 M.C. Belinchon 14 Ericsson 15 A. Jungmayer 16 University of Essen 17 L. Ong 18 Ciena 20 Stream Control Transmission Protocol Applicability Statement 21 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF), its areas, 28 and its working groups. Note that other groups may also distribute 29 working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 38 Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Abstract 43 This document describes the applicability of the Stream Control 44 Transmission Protocol (SCTP)[RFC2960] for general usage in the 45 Internet. This document describes the key features of SCTP and how 46 they are used for general purpose data transport. 48 Table of Contents 50 Stream Control Transmission Protocol Applicability statement 51 ................................................................ ii 52 Chapter 1: Introduction ........................................ 2 53 Chapter 1.1: Terminology ....................................... 2 54 Chapter 1.2: Protocol Overview ................................. 3 55 Chapter 2: Applicability of SCTP ............................... 3 56 Chapter 2.1: Features provided by SCTP ......................... 3 57 Chapter 2.2: Applications that would benefit from using SCTP 58 ................................................................ 4 59 Chapter 2.3: Applications that may receive little benefit ...... 4 60 Chapter 3: Issues affecting deployment of SCTP ................. 5 61 Chapter 3.1 : SCTP multihoming and interaction with routing .... 5 62 Chapter 3.2 : Use of SCTP in Network Address Translators 63 (NAT) Networks ................................................. 9 64 Chapter 4: Security considerations ............................. 10 65 Chapter 5: References and related work ......................... 10 66 Chapter 6: Acknowledgments ..................................... 11 67 Chapter 7: Author's address .................................... 11 69 1 Introduction 71 1.1 Terminology 73 The following terms are commonly identified in related work: 75 Association: SCTP connection between two endpoints. 77 Transport address: A combination of IP address and SCTP port 78 number. 80 Upper layer: The user of the SCTP protocol, which may be an adap- 81 tation layer, a session layer protocol, or the user application 82 directly. 84 TLA: Top level aggregation, part of a aggregatable unicast address 86 Draft SCTP applicability statement April 2001 88 1.2 Protocol Overview 90 The Stream Control Transmission Protocol (SCTP) provides a reliable 91 transport between two endpoints. 93 The following functions are provided by SCTP: 95 - Reliable Data Transfer 97 - Multiple streams to help avoid head-of-line blocking 99 - Ordered and unordered data delivery on a per-stream basis 101 - Bundling and fragmentation of user data 103 - TCP friendly Congestion and flow control 105 - Support continuous monitoring of reachability 107 - Graceful termination of association 109 - Support of multi-homing for added reliability 111 - Some protection against blind denial-of-service attacks 113 - Some protection against blind masquerade attacks 115 2 Applicability of SCTP 117 When making a choice between reliable transport protocols, namely UDP, 118 TCP and SCTP, various factors will enter in to deciding which one to 119 choose. Certain applications will find an extreme advantage to using 120 SCTP, while others may find little advantage. 122 2.1 Features provided by SCTP 124 SCTP provides acknowledged, error-free, non-duplicated transfer of user 125 data, with framing to preserve user protocol data unit boundaries, and 126 transport-level data fragmentation to conform to discovered path MTU 127 size. It provides sequenced delivery within streams, with the option 128 for designating messages for order-of-arrival delivery instead. 130 SCTP also provides mechanisms for network-level fault tolerance through 132 Draft SCTP applicability statement April 2001 134 the use of multi-homing at either or both ends of an SCTP association. 135 SCTP automatically detects failure to reach a destination address and 136 compensates through the use of available alternate addresses. 138 2.2 Applications that would benefit from using SCTP. 140 Applications using SCTP should have sufficient traffic levels to justify 141 the overhead and benefit from SCTP association establishment and conges- 142 tion and flow control procedures. 144 Applications that require framing of reliable data streams can get that 145 feature from SCTP. 147 Applications which require ordered transport of messages, but transfer 148 multiple independent message sequences that are unrelated (sometimes 149 called transactions) will benefit from the partial ordering provided by 150 SCTP streams. 152 Applications that need to transfer messages that hold no particular 153 sequence or relationship to one another or can be correlated and 154 sequenced at the application level can benefit from the unordered 155 delivery service and transport-level fragmentation provided by SCTP. 157 Application which depend on fast retransmit of data will have a reduced 158 dependence on timeouts(thus easing the load on the Operating System). 160 Applications requiring network layer redundancy can use SCTP's multi- 161 homing feature to support this, provided that the host supports multiple 162 addresses and routing is configured appropriately (see Section 3). 164 Transport of PSTN signaling protocols such as Signaling System No. 7 165 over IP networks is an example application fitting these requirements. 167 2.3 Applications that may receive little benefit. 169 Applications requiring strict ordering of all data sent between communi- 170 cating endpoints would not benefit from the multi-stream capability pro- 171 vided by SCTP. In addition, applications oriented towards byte stream 172 transfer would not benefit from SCTP framing. 174 An example application that would derives no benefit from framing and 175 multi-stream capabilities of SCTP is file transfer. 177 Applications which do not require network-level redundancy or with 179 Draft SCTP applicability statement April 2001 181 physical limitations, e.g., only one network interface card is present, 182 would derive no benefit from SCTP's multi-homing feature. 184 Applications which generate small amounts of unrelated transactions 185 towards a destination do not gain a great benefit from using TCP 186 friendly congestion control and may experience a conservative 187 retransmission policy. 189 3 Issues affecting deployment of SCTP 191 3.1 SCTP multihoming and interaction with routing 193 For fault resilient communication between two SCTP endpoints, the mul- 194 tihoming feature needs more than one IP network interface for each end- 195 point. The number of paths used is the minimum of network interfaces 196 used by any of the endpoints. It is recommended to bind the association 197 to all the IP source addresses of the endpoint. Note that in IPv6, each 198 network interface will have more than one IP address. 200 Under the assumption that every IP address will have a different, 201 seperate paths towards the remote endpoint, (this is the responsibility 202 of the routing protocols or of manual configuration) , if the transport 203 to one of the IP address (= 1 particular path) fails then the traffic 204 can migrate to the other remaining IP address (= other paths) within the 205 SCTP association. 207 +------------+ *~~~~~~~~~* +------------+ 208 | Endpoint A | * Cloud * | Endpoint B | 209 | 1.2 +---------+ 1.1<--->3.1 +----------+ 3.2 | 210 | | | | | | 211 | 2.2 +---------+ 2.1<--->4.1 +----------+ 4.2 | 212 | | * * | | 213 +------------+ *~~~~~~~~~* +------------+ 215 Figure 3.1.1: Two hosts with redundant networks. 217 Consider figure 3.1.1, if the host routing tables look as follows the 218 endpoint will achieve maximum use of the multi-homing feature: 220 Endpoint A Endpoint B 221 Destination Gateway Destination Gateway 222 ------------------------ ------------------------- 223 3.0 1.1 1.0 3.1 224 4.0 2.1 2.0 4.1 226 Draft SCTP applicability statement April 2001 228 Now if you consider figure 3.1.1, if the host routing table looks as 229 follows, the association is subject to a single point of failure in that 230 if any interface breaks, the whole association will break(See figure 231 3.1.2). 233 Host A Host B 234 Destination Gateway Destination Gateway 235 ------------------------ ------------------------- 236 3.0 1.1 1.0 4.1 237 4.0 2.1 2.0 3.1 239 Example: link 4.2-4.1 fails 241 Primary path: link 1.2-1.1 - link 3.1-3.2 242 Second Path : Link 2.2-2.1 - link 4.1-4.2 244 Endpoint A 245 +-------+--------+------+ 246 |S= 1.2 | D= 3.2 | DATA | ------->----- Arrives at Endpoint B 247 +-------+--------+------+ 249 Endpoint B answers with SACK 250 +-------+--------+------+ 251 |S= 4.2 | D= 1.2 | SACK | Gets lost, because send out on the failed 252 +-------+--------+------+ 4.1-4.2 link 254 After X time, retransmit on the other path by endpoint A 256 Endpoint A 257 +-------+--------+------+ 258 |S= 2.2 | D= 4.2 | DATA | Is send out on link 2.2-2.1, but gets lost, 259 +-------+--------+------+ as msg has to pass via failed 4.1-4.2 link 261 The same scenario will play out for failures on the other links 263 Note : S = Source address 264 D = Destination address 266 Figure 3.1.2: Single point of failure case in redundant network 267 due to routing table in host B 269 When an endpoint selects its source address, careful consideration must 270 be taken. If the same source address is always used, then it is possible 271 that the endpoint will be subject to the same single point of failure 272 illustrated above. If possible the endpoint should always select the 273 source address of the packet to correspond to the IP address of the Net- 274 work interface where the packet will be emitted. 276 Draft SCTP applicability statement April 2001 278 +------------+ *~~~~~~~~~* +------------+ 279 | Endpoint A | * Cloud * | Endpoint B | 280 | 1.2 +---------+ 1.1<--+ | | | 281 | | | |->3.1|----------+ 3.2 | 282 | 2.2 +---------+ 2.1<--+ | | | 283 | | * * | | 284 +------------+ *~~~~~~~~~* +------------+ 286 Figure 3.1.3: Two hosts with asymmetric networks. 288 In Figure 3.1.3 consider the following host routing table: 290 Endpoint A Endpoint B 291 Destination Gateway Destination Gateway 292 ------------------------ ------------------------- 293 3.0 1.1 1.0 3.1 294 2.0 3.1 296 In this case the fault tolerance becomes limited by two seperate issues. 297 If the path between 3.1 and 3.2 breaks in both directions any associa- 298 tion will break between endpoint A and endpoint B. The second failure 299 will occur for the whole the association as well due to a breakage 300 between 1.2 and 1.1 in both directions, since no alternative route 301 exists to 3.2 and all traffic is being routed through one interface. 303 Now one of these issues can be remedied by the following modification 304 even when only one interface exists on endpoint B. 306 +------------+ *~~~~~~~~~~* +------------+ 307 | Endpoint A | * Cloud * | Endpoint B | 308 | 1.2 +---------+ 1.1<---+ | | | 309 | | | +->3.1+----------+ 3.2 & 4.2 | 310 | 2.2 +---------+ 2.1<---+ | | | 311 | | * * | | 312 +------------+ *~~~~~~~~~~* +------------+ 314 Figure 3.1.4: Two hosts with asymmetric networks, but symmetric 315 addresses. 317 In Figure 3.1.4 consider the following host routing table: 319 Endpoint A Endpoint B 320 Destination Gateway Destination Gateway 321 ------------------------ ------------------------- 322 3.0 1.1 1.0 3.1 323 4.0 2.1 2.0 3.1 325 Draft SCTP applicability statement April 2001 327 Now with the duplicate IP addresses assigned to the same interface and 328 the above routing tables, even if the interface between 1.1 and 1.2 329 breaks, an association will still survive this failure. 331 As a practical matter, it is recommended that IP addresses in a mul- 332 tihomed endpoint be assigned IP endpoints from different TLA's to ensure 333 against network failure. 335 In IP implementations the outgoing interface of multihomed hosts is 336 often determined by the destination IP address. The mapping is done by a 337 lookup in a routing table maintained by the operating system. Therefore 338 the outgoing interface is not determined by SCTP. Using such implemen- 339 tations, it should be noted that a multihomed host cannot make use of 340 the multiple local IP addresses if the peer is singlehomed. The mul- 341 tihomed host has only one path and will normally use only one of its 342 interfaces to send the SCTP datagrams to the peer. If this physical path 343 fails, the IP routing table in the multihome host has to be changed. 344 This problem is out of scope for SCTP. 346 SCTP will always send its traffic to a certain transport address (= des- 347 tination address + port number combination) for as long as the transmis- 348 sion is uninterrupted (= primary). The other transport addresses (secon- 349 dary paths) will act as a backup in case the primary path goes out of 350 service. The changeover between primary and backup will occur without 351 packet loss and is completely transparent to the application. The secon- 352 dary path can also be used for retransmissions(per section 6.4 of 353 [RFC2960]). 355 The port number is the same for all transport addresses of that specific 356 association. 358 Applications directly using SCTP may choose to control the multihoming 359 service themselves. The applications have then to supply the specific IP 360 address to SCTP for each outbound user message. This might be done for 361 reasons of load-sharing and load-balancing across the different paths. 362 This might not be advisable as the throughput of any of the paths is not 363 known in advance and constantly changes due to the actions of other 364 associations and transport protocols along that particular path, would 365 require very tight feedback of each of the paths to the loadsharing 366 functions of the user. 368 By sending a keep alive message on all the multiple paths that are not 369 used for active transmission of messages across the association, it is 370 possible for SCTP to detect whether one or more paths have failed. SCTP 371 will not use these failed paths when a changeover is required. 373 The transmission rate of sending keep alive message should be modifiable 374 and the possible loss of keep alive message could be used for the 376 Draft SCTP applicability statement April 2001 378 monitoring and measurements of the concerned paths. 380 3.2 Use of SCTP in Network Address Translators (NAT) Networks [RFC2663] 382 When a NAT is present between two endpoints, the endpoint that is behind 383 the NAT, i.e., one that does not have a publicly available network 384 address, shall take one of the following options: 386 (1) When single homed sessions are to be used, no transport addresses 387 should be sent in the INIT or INIT ACK chunk(Refer to section 3.3 388 of RFC2960 for chunk definitions). This will force the endpoint 389 that receives this initiation message to use the source address in 390 the IP header as the only destination address for this association. 391 This method can be used for a NAT, but any multi-homing configura- 392 tion at the endpoint that is behind the NAT will not be visible to 393 its peer, and thus not be taken advantage of. See figure 3.2.1. 395 +-------+ +---------+ *~~~~~~~~~~* +------+ 396 |Host A | | NAT | * Cloud * |Host B| 397 | 10.2 +--|10.1|2.1 |----|--------------|---------+ 1.2 | 398 | | | | | * * | | 399 +-------+ +---------+ *~~~~~~~~~~* +------+ 401 Fig 3.2.1: SCTP through NAT without multihoming 403 For multihoming the NAT must have a public IP address for each 404 represented internal IP address. The host can preconfigure IP 405 address that the NAT can substitute. Or the NAT can have internal 406 Application Layer Gateway (ALG) which will intelligently translate 407 the IP addresses in the INIT and INIT ACK chunks. See Figure 3.2.2. 409 If Network Address Port Translation is used with a multihomed SCTP 410 endpoint, then any port translation must be applied on a per- 411 association basis such that an SCTP endpoint continues to receive 412 the same port number for all messages within a given association. 414 +-------+ +----------+ *~~~~~~~~~~* +------+ 415 |Host A | | NAT | * Cloud * |Host B| 416 | 10.2 +---+ 10.1|5.2 +-----+ 1.1<+->3.1--+---------+ 1.2 | 417 | 11.2 +---+ 11.1|6.2 | | +->4.2--+---------+ 2.2 | 418 | | | | * * | | 419 +-------+ +----------+ *~~~~~~~~~* +------+ 421 Fig 3.2.2: SCTP through NAT with multihoming 423 Draft SCTP applicability statement April 2001 425 (2) Another alternative is to use the hostname feature and DNS to 426 resolve the addresses. The hostname is included in the INIT of the 427 association or in the INIT ACK. The hostname must be resolved by 428 DNS before the association is completely set up. There are special 429 issues regarding NAT and DNS, refer to RFC2694 for details. 431 4 Security considerations 433 SCTP only tries to increase the availability of a network. SCTP does not 434 contain any protocol mechanisms which are directly related to user mes- 435 sage authentication, integrity and confidentiality functions. For such 436 features, it depends on the IPSEC protocols and architecture and/or on 437 security features of its user protocols. 439 Mechanisms for reducing the risk of blind denial-of-service attacks and 440 masquerade attacks are built into SCTP protocol. See RFC2960, section 11 441 for detailed information. 443 Currently the IPSEC working group is investigating the support of mul- 444 tihoming by IPSEC protocols. At the present time to use IPSEC, one must 445 use 2 * N * M security associations if one endpoint uses N addresses and 446 the other M addresses. 448 5 References and related work 450 [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 451 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, L. 452 and Paxson, V."Stream Control Transmission Protocol", RFC2960, 453 October 2000. 455 [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for the 456 Internet Protocol", RFC 2401, November 1998. 458 [RFC2663] Srisuresh, P. and Holdrege, M., "IP Network Address Translator 459 (NAT) Terminology and Considerations", RFC2663, August 1999 461 Draft SCTP applicability statement April 2001 463 [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and Heffernan, A., 464 "DNS extensions to Network Address Translators (DNS_ALG)", RFC2694, 465 September 1999 467 6 Acknowledgments 469 The authors wish to thank Renee Revis, I. Rytina, H.J. Schwarzbauer, 470 J.P. Martin-Flatin, T. Taylor, G. Sidebottom, K. Morneault, T. George, 471 M. Stillman, N. Makinae, S. Bradner, A. Mankin, G. Camarillo, H. 472 Schulzrinne, R. Kantola, J. Rosenberg and many others for their invalu- 473 able comments. 475 7 Author's Address 477 Lode Coene Phone: +32-14-252081 478 Siemens Atea EMail: lode.coene@siemens.atea.be 479 Atealaan 34 480 B-2200 Herentals 481 Belgium 483 John Loughney Phone: +358-9-43761 484 Nokia Research Center EMail: john.loughney@nokia.com 485 Itamerenkatu 11-13 486 FIN-00180 Helsinki 487 Finland 489 Michel Tuexen Phone: +49-89-722-47210 490 Siemens AG EMail: Michael.Tuexen@icn.siemens.de 491 Hofmannstr. 51 492 81359 Munich 493 Germany 495 Randall R. Stewart Phone: +1-815-477-2127 496 24 Burning Bush Trail. EMail: rrs@cisco.com 497 Crystal Lake, IL 60012 498 USA 500 Qiaobing Xie Phone: +1-847-632-3028 501 Motorola, Inc. EMail: qxie1@email.mot.com 502 1501 W. Shure Drive 503 Arlington Heights, IL 60004 504 USA 506 Draft SCTP applicability statement April 2001 508 Matt Holdrege Phone: - 509 ipVerse Email: matt@ipverse.com 510 223 Ximeno Avenue 511 Long Beach, CA 90803-1616 512 USA 514 Maria-Carmen Belinchon Phone: +34-91-339-3535 515 Ericsson Espana S. A. EMail: Maria.C.Belinchon@ericsson.com 516 Network Communication Services 517 Retama 7, 5th floor 518 Madrid, 28045 519 Spain 521 Andreas Jungmayer Phone: +49-201-1837636 522 University of Essen EMail: ajung@exp-math.uni-essen.de 523 Institute for experimental Mathematics 524 Ellernstrasse 29 525 D-45326 Essen 526 Germany 528 Gery Verwimp Phone: +32-14-253424 529 Siemens Atea EMail: gery.verwimp@siemens.atea.be 530 Atealaan 34 531 B-2200 Herentals 532 Belgium 534 Lyndon Ong Phone: - 535 EMail: lyong@ciena.com 537 USA 539 Expires: October 31, 2001 541 Full Copyright Statement 543 Copyright (C) The Internet Society (2001). All Rights Reserved. 545 This document and translations of it may be copied and furnished to 546 others, and derivative works that comment on or otherwise explain 547 it or assist in its implementation may be prepared, copied, published 548 and distributed, in whole or in part, without restriction of any 549 kind, provided that the above copyright notice and this paragraph 551 Draft SCTP applicability statement April 2001 553 are included on all such copies and derivative works. However, this 554 document itself may not be modified in any way, such as by 555 removing the copyright notice or references to the Internet Society or 556 other Internet organizations, except as needed for the purpose of 557 developing Internet standards in which case the procedures for 558 copyrights defined in the Internet Standards process must be 559 followed, or as required to translate it into languages other than 560 English. 562 The limited permissions granted above are perpetual and will not 563 Be revoked by the Internet Society or its successors or assigns. 565 This document and the information contained herein is provided on 566 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 567 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 568 INCLUDING 569 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 570 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 571 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.