idnits 2.17.1 draft-ietf-sigtran-sctp-applicability-07.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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 59 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 -- 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 (October 2001) is 8227 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) -- Missing reference section? 'RFC2960' on line 400 looks like a reference -- Missing reference section? 'RFC793' on line 421 looks like a reference -- Missing reference section? 'RFC1889' on line 448 looks like a reference -- Missing reference section? 'RFC768' on line 416 looks like a reference -- Missing reference section? 'RFC2719' on line 424 looks like a reference -- Missing reference section? 'RFC2663' on line 408 looks like a reference -- Missing reference section? 'SYN-COOK' on line 310 looks like a reference -- Missing reference section? 'RFC1323' on line 431 looks like a reference -- Missing reference section? 'RFC1321' on line 428 looks like a reference -- Missing reference section? 'SHA1' on line 438 looks like a reference -- Missing reference section? 'RFC2246' on line 445 looks like a reference -- Missing reference section? 'RFC1750' on line 435 looks like a reference -- Missing reference section? 'RFC2401' on line 405 looks like a reference -- Missing reference section? 'RFC2694' on line 412 looks like a reference -- Missing reference section? 'SYNCOOK' on line 442 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. Coene(Editor) 2 Internet Engineering Task Force Siemens 3 Issued: October 2001 4 Expires: April 2002 6 Stream Control Transmission Protocol Applicability Statement 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet- Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Abstract 30 This document describes the applicability of the Stream Control 31 Transmission Protocol (SCTP)[RFC2960]. It also contrasts SCTP with 32 the two dominant transport protocols, UDP & TCP, and gives some 33 guidelines for when best to use SCTP and when not best to use SCTP. 35 Draft Informational October 2001 37 Table of contents 39 Stream Control Transmission Protocol Applicability statement 40 ................................................................ ii 41 Chapter 1: Introduction ........................................ 2 42 Chapter 1.1: Terminology ....................................... 3 43 Chapter 1.2: Contributors ...................................... 3 44 Chapter 2: Transport protocols ................................. 3 45 Chapter 2.1: TCP service model ................................. 3 46 Chapter 2.2: SCTP service model ................................ 4 47 Chapter 2.3: UDP service model ................................. 5 48 Chapter 3: SCTP Multihoming issues ............................. 5 49 Chapter 4: SCTP with Network Address Translators (NAT) 50 [RFC2663] ...................................................... 6 51 Chapter 5: Security considerations ............................. 7 52 Chapter 5.1: Security issues with TCP .......................... 7 53 Chapter 5.2: Security issues with SCTP ......................... 8 54 Chapter 5.3: Security issues with both TCP and SCTP ............ 9 55 Chapter 6: References and related work ......................... 9 56 Chapter 7: Acknowledgments ..................................... 10 57 Chapter 8: Author's address .................................... 11 58 Appendix A: Major functions provided by SCTP ................... 13 60 1 Introduction 62 SCTP is a reliable transport protocol [RFC2960], which along with 63 TCP [RFC793], RTP [RFC1889] and UDP [RFC768], provides 64 transport-layer services for upper layer protocols and services. 65 UDP, RTP, TCP and SCTP are currently the IETF standards-track 66 transport-layer protocols. Each protocol has a domain of 67 applicability and services it provides, albeit with some overlaps. 69 By clarifying the situations where the functionality of these 70 protocols are applicable, this document can guide implementers and 71 protocol designers in selecting which protocol to use. 73 Special attention is given to services SCTP provides which would 74 make a decision to use SCTP the right one. 76 Major functions provided by SCTP can be found in Appendix A. 78 Draft Informational October 2001 80 1.1 Terminology 82 The following terms are commonly identified in this work: 84 Association: SCTP connection between two endpoints. 86 Transport address: A combination of IP address and SCTP port number. 88 Upper layer: The user of the SCTP protocol, which may be an 89 adaptation layer, a session layer protocol, or the user application 90 directly. 92 Multihoming: Assigning more than one IP network interface to a 93 single endpoint. 95 1.2 Contributors 97 The following people contributed to the document: L. Coene(Editor), 98 M. Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie, 99 M. Holdrege, M.C. Belinchon, A. Jungmaier, and L. Ong. 101 2 Transport protocols 103 2.1 TCP service model 105 TCP is a connection-oriented (a.k.a. session-oriented) transport 106 protocol. This means that it requires both the establishment of a 107 connection prior to exchange of application data and a connection 108 tear-down to release system resource after the completion of data 109 transfer. 111 TCP is currently the most widely used connection-oriented transport 112 protocol for the Internet. 114 TCP provides the upper layer with the following transport services: 116 - data reliability; 118 - data sequence preservation; and 120 - flow and congestion control. 122 Draft Informational October 2001 124 2.2 SCTP service model 126 SCTP is also connection-oriented and provides all the transport 127 services that TCP provides. Many Internet applications therefore 128 should find that either TCP or SCTP will meet their transport 129 requirements. Note, for applications conscious about processing 130 cost, there might be a difference in processing cost associated with 131 running SCTP with only a single ordered stream and one address pair 132 in comparison to running TCP. 134 However, SCTP has some additional capabilities that TCP lacks and 135 This can make SCTP a better choice for some applications and 136 environments: 138 - multi-streams support: 140 SCTP supports the delivery of multiple independent user message 141 streams within a single SCTP association. This capability, when 142 properly used, can alleviate the so-called head-of-line-blocking 143 problem caused by the strict sequence delivery constraint imposed to 144 the user data by TCP. 146 This can be particularly useful for applications that need to 147 exchange multiple, logically separate message streams between two 148 endpoints. 150 - multi-homing support: 152 SCTP provides transparent support for communications between two 153 endpoints of which one or both is multi-homed. 155 SCTP provides monitoring of the reachability of the addresses on the 156 remote endpoint and in the case of failure can transparently 157 failover from the primary address to an alternate address, without 158 upper layer intervention. 160 This capability can be used to build redundant paths between two 161 SCTP endpoints and can be particularly useful for applications that 162 seek transport-level fault tolerance. 164 Achieving path redundancy between two SCTP endpoints normally 165 requires that the two endpoints being equipped with multiple 166 interfaces assigned with multiple addresses and that routing is 167 configured appropriately (see Section 3). 169 - preservation of message boundaries: 171 SCTP preserves application messages boundaries. This is useful when 172 the application data is not a continuous byte stream but comes in 174 Draft Informational October 2001 176 logical chunks that the receiver handles separately. 178 In contrast, TCP offers a reliable data stream that has no 179 indication of what an application may consider logical chunks of the 180 data. 182 - unordered reliable message delivery: 184 SCTP supports the transportation of user messages that have no 185 application-specified order, yet need guaranteed reliable delivery. 187 Applications that need to send un-ordered reliable messages or 188 prefer to using their own message sequencing and ordering mechanisms 189 may find this SCTP capability useful. 191 2.3 UDP Service model 193 UDP is connectionless. This means that applications that use UDP do 194 not need to perform connection establishment or tear-down. 196 As transport services to its upper layer, UDP provides only: 198 - best-effort data delivery, and 200 - preservation of message boundaries. 202 Applications that do not require a reliable transfer of more than a 203 packet's worth of data will find UDP adequate. Some 204 transaction-based applications fall into this category. 206 3 Multihoming Issues 208 SCTP provides transport-layer support for multihoming. Multihoming 209 has the potential of providing additional robustness against network 210 failures. In some applications, this may be extremely important, for 211 example in signaling transport of PSTN signaling messages [RFC2719]. 213 It should be noted that SCTP multihoming support only deals with 214 communication between two endpoints of which one or both is assigned 215 with multiple IP addresses on possibly multiple network interfaces. 216 It does NOT deal with communication ends that contain multiple 217 endpoints (i.e., clustered endpoints) that can switch over to an 218 alternate endpoint in case of failure of the original endpoint. 220 Generally, for truly fault resilient communication between two 222 Draft Informational October 2001 224 end-points, the multihoming feature needs more than one IP network 225 interface for each endpoint. The number of paths used is the minimum 226 of network interfaces used by any of the endpoints. When an endpoint 227 selects its source address, careful consideration must be taken. If 228 the same source address is always used, then it is possible that the 229 endpoint will be subject to the same single point of failure. If 230 possible the endpoint should always select the source address of the 231 packet to correspond to the IP address of the Network interface 232 where the packet will be emitted. 234 4 Network Address Translators (NAT) Networks issues [RFC2663] 236 When two endpoints are to setup an SCTP association and one (or 237 both) of them is behind a NAT (i.e., it does not have any publicly 238 available network addresses), the endpoint(s) behind the NAT should 239 consider one of the following options: 241 (1) When single homed sessions are to be used, no transport 242 addresses should be sent in the INIT or INIT ACK chunk(Refer to 243 section 3.3 of RFC2960 for chunk definitions). This will force the 244 endpoint that receives this initiation message to use the source 245 address in the IP header as the only destination address for this 246 association. This method can be used for a NAT, but any 247 multi-homing configuration at the endpoint that is behind the NAT 248 will not be visible to its peer, and thus not be taken advantage 249 of. See figure 1. 251 +-------+ +---------+ *~~~~~~~~~~* +------+ 252 |Host A | | NAT | * Cloud * |Host B| 253 | 10.2 +--|10.1|2.1 |----|--------------|---------+ 1.2 | 254 | | | | | * * | | 255 +-------+ +---------+ *~~~~~~~~~~* +------+ 257 Fig 1: SCTP through NAT without multihoming 259 For multihoming the NAT must have a public IP address for each 260 represented internal IP address. The host can preconfigure IP 261 address that the NAT can substitute. Or the NAT can have internal 262 Application Layer Gateway (ALG) which will intelligently translate 263 the IP addresses in the INIT and INIT ACK chunks. See Figure 2. 265 If Network Address Port Translation is used with a multihomed SCTP 266 endpoint, then any port translation must be applied on a 267 per-association basis such that an SCTP endpoint continues to 268 receive the same port number for all messages within a given 269 association. 271 Draft Informational October 2001 273 +-------+ +----------+ *~~~~~~~~~~* +------+ 274 |Host A | | NAT | * Cloud * |Host B| 275 | 10.2 +---+ 10.1|5.2 +-----+ 1.1<+->3.1--+---------+ 1.2 | 276 | 11.2 +---+ 11.1|6.2 | | +->4.2--+---------+ 2.2 | 277 | | | | * * | | 278 +-------+ +----------+ *~~~~~~~~~* +------+ 280 Fig 2: SCTP through NAT with multihoming 282 (2) Another alternative is to use the hostname feature and DNS to 283 resolve the addresses. The hostname is included in the INIT of the 284 association or in the INIT ACK. The hostname must be resolved by DNS 285 before the association is completely set up. There are special 286 issues regarding NAT and DNS, refer to RFC2694 for details. 288 5 Security considerations 290 In this section, some relevant security issues found in the 291 deployment of the connection-oriented transport protocols will be 292 discussed. 294 5.1 Security issues with TCP 296 Some TCP implementations have been known to be vulnerable to blind 297 denial of service attacks, i.e. attacks that had been executed by an 298 attacker that could not see most of the traffic to or from the 299 target host. 301 The attacker would send a large number of connection establishment 302 requests (TCP-SYN packets) to the attacked target, possibly from 303 faked IP source addresses. The attacked host would reply by sending 304 SYN-ACK packets and entering SYN-received state, thereby allocating 305 space for a TCB. At some point the SYN-queue would fill up, 306 (i.e. the number of connections waiting to be established would 307 rise to a limit) and the host under attack would have to start 308 turning down new connection establishment requests. 310 TCP implementations with SYN-cookies algorithm [SYN-COOK] reduce the 311 risk of such blind denial of service attacks. TCP implementations 312 can switch to using this algorithm in times when their SYN-queues 313 are filled up while still fully conforming to the TCP specification 314 [RFC793]. However, use of options such as window scale [RFC1323], 315 is not possible, then. With the SYN-cookie mechanism, a TCB is only 316 created when the client sends back a valid ACK packet to the server, 317 and the 3-way handshake has thus been successfully completed. 319 Draft Informational October 2001 321 Blind connection forgery is another potential threat to TCP. By 322 guessing valid sequence numbers, an attacker would be able to forge 323 a connection. However, with a secure hashsum algorithm, for some of 324 the current SYN-cookie implementations the likelihood of achieving 325 this attack is on the order of magnitude of 1 in 2^24, i.e. the 326 attacker would have to send 2^24 packets before obtaining one forged 327 connection when SYN-cookies are used. 329 5.2 Security issues with SCTP 331 SCTP has been designed with the experiences made with TCP in 332 mind. To make it hard for blind attackers (i.e. attackers that are 333 not man-in-the-middle) to inject forged SCTP datagrams into existing 334 associations, each side of an SCTP association uses a 32 bit value 335 called "Verification Tag" to ensure that a datagram really belongs 336 to the existing association. So in addition to a combination of 337 source and destination transport addresses that belong to an 338 established association, a valid SCTP datagram must also have the 339 correct tag to be accepted by the recipient. 341 Unlike in TCP, usage of cookie in association establishment is made 342 mandatory in SCTP. For the server, a new association is fully 343 established after three messages (containing INIT, INIT-ACK, 344 COOKIE-ECHO chunks) have been exchanged. The cookie is a variable 345 length parameter that contains all relevant data to initialize the 346 TCB on the server side, plus a HMAC used to secure it. This HMAC 347 (MD5 as per [RFC1321] or SHA-1 [SHA1]) is computed over the cookie 348 and a secret, server-owned key. 350 As specifically prescribed for SCTP implementations [RFC2960], 351 additional resources for new associations may only be reserved in 352 case a valid COOKIE-ECHO chunk is received by a client, and the 353 computed HMAC for this new cookie matches that contained in the 354 cookie. 356 With SCTP the chances of an attacker being able to blindly forge a 357 connection are even lower than in the case of TCP using SYN-cookies, 358 since the attacker would have to guess a correct value for the HMAC 359 contained in the cookie, i.e. lower than 1 in 2^128 which for all 360 practical purposes is negligible. 362 It should be noted that SCTP only tries to increase the availability 363 of a network. SCTP does not contain any protocol mechanisms which 364 are directly related to user message authentication, integrity and 365 confidentiality functions. For such features, it depends on the 366 IPsec protocols and architecture and/or on security features of the 367 application protocols. 369 Transport Layer security(TLS)[RFC2246] using SCTP must always use 370 in-order streams. 372 Draft Informational October 2001 374 Currently the IPSEC working group is investigating the support of 375 mul- tihoming by IPSEC protocols. At the present time to use IPSEC, 376 one must use 2 * N * M security associations if one endpoint uses N 377 addresses and the other M addresses. 379 5.3 Security Issues with both TCP and SCTP 381 It is important to note that neither TCP nor SCTP protect itself 382 from man-in-the-middle attacks where an established session might be 383 hijacked (assuming the attacker can see the traffic from and inject 384 its own packets to either endpoints). 386 Also, for preventing blind connection/session setup forgery, both 387 TCP implementations supporting SYN-cookies and SCTP implementations 388 rely on a server-known, secret key to protect the HMAC data. It must 389 be ensured that this key is created subject to the recommendations 390 mentioned in [RFC1750]. 392 Although SCTP has been designed carefully as to avoid some of the 393 problems that have appeared with TCP, it has as of yet not been 394 widely deployed. It is therefore possible that new security issues 395 will be identified that will have to be addressed in further 396 revisions of [RFC2960]. 398 5 References and related work 400 [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 401 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, L. 402 and Paxson, V."Stream Control Transmission Protocol", RFC2960, 403 October 2000. 405 [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for the 406 Internet Protocol", RFC 2401, November 1998. 408 [RFC2663] Srisuresh, P. and Holdrege, M., "IP Network Address 409 Translator (NAT) Terminology and Considerations", RFC2663, August 410 1999 412 [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and Heffernan, 413 A., "DNS extensions to Network Address Translators (DNS_ALG)", 414 RFC2694, September 1999 416 [RFC768] Postel, J. (ed.), "User Datagram Protocol", STD 6, RFC 768, 417 August 1980. 419 Draft Informational October 2001 421 [RFC793] Postel, J. (ed.), "Transmission Control Protocol", STD 7, 422 RFC 793, September 1981. 424 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, 425 L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Architectural 426 Framework for Signaling Transport", RFC 2719, October 1999. 428 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 429 MIT Laboratory for Computer Science, April 1992. 431 [RFC1323] Jacobson, V., Braden, R, and D. Borman, "TCP Extensions 432 for High Performance", RFC 1323, LBL, USC/Information Sciences 433 Institute, Cray Research, May 1992. 435 [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 436 Recommendations for Security", RFC 1750, December 1994. 438 [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National 439 Institute of Standards and Technology, U.S. Department of Commerce, 440 April 1995. 442 [SYNCOOK] Dan J. Bernstein, SYN cookies, 1997, see also 443 445 [RFC2246] Dierks, T. and Allen, C.,"The TLS Protocol Version 1.0", 446 RFC 2246, January 1999. 448 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, 449 V., "RTP: A Transport Protocol for Real-Time Applications", RFC 450 1889, January 1996. 452 6 Acknowledgments 454 The authors wish to thank Renee Revis, I. Rytina, H.J. Schwarzbauer, 455 J.P. Martin-Flatin, T. Taylor, G. Sidebottom, K. Morneault, 456 T. George, M. Stillman, N. Makinae, S. Bradner, A. Mankin, 457 G. Camarillo, H. Schulzrinne, R. Kantola, J. Rosenberg and many 458 others for their invaluable comments. 460 Draft Informational October 2001 462 7 Author's Address 464 The following authors have contributed to this document. 466 Lode Coene Phone: +32-14-252081 467 Siemens Atea EMail:lode.coene@siemens.atea.be 468 Atealaan 34 469 B-2200 Herentals 470 Belgium 472 John Loughney Phone: +358-9-43761 473 Nokia Research Center EMail: john.loughney@nokia.com 474 Itamerenkatu 11-13 475 FIN-00180 Helsinki 476 Finland 478 Michel Tuexen Phone: +49-89-722-47210 479 Siemens AG EMail: Michael.Tuexen@icn.siemens.de 480 Hofmannstr. 51 481 81359 Munich 482 Germany 484 Randall R. Stewart Phone: +1-815-477-2127 485 24 Burning Bush Trail. EMail: rrs@cisco.com 486 Crystal Lake, IL 60012 487 USA 489 Qiaobing Xie Phone: +1-847-632-3028 490 Motorola, Inc. EMail: qxie1@email.mot.com 491 1501 W. Shure Drive 492 Arlington Heights, IL 60004 493 USA 495 Matt Holdrege Phone: - 496 ipVerse Email: matt@ipverse.com 497 223 Ximeno Avenue 498 Long Beach, CA 90803-1616 499 USA 501 Maria-Carmen Belinchon Phone: +34-91-339-3535 502 Ericsson Espana S. A. EMail: Maria.C.Belinchon@ericsson.com 503 Network Communication Services 504 Retama 7, 5th floor 505 Madrid, 28045 506 Spain 508 Andreas Jungmaier Phone: +49 201 1837636 509 University of Essen Email: ajung@exp-math.uni-essen.de 510 Networking Technology Group at the IEM 511 Ellernstrasse 29 512 D-45326 Essen 513 Germany 515 Draft Informational October 2001 517 Gery Verwimp Phone: +32-14-253424 518 Siemens Atea EMail: gery.verwimp@siemens.atea.be 519 Atealaan 34 520 B-2200 Herentals 521 Belgium 523 Lyndon Ong Phone: - 524 EMail: lyong@ciena.com 525 USA 527 Expires: April 30, 2002 529 Full Copyright Statement 531 Copyright (C) The Internet Society (2001). All Rights Reserved. 533 This document and translations of it may be copied and furnished to 534 others, and derivative works that comment on or otherwise explain 535 it or assist in its implementation may be prepared, copied, published 536 and distributed, in whole or in part, without restriction of any 537 kind, provided that the above copyright notice and this paragraph 538 are included on all such copies and derivative works. However, this 539 document itself may not be modified in any way, such as by 540 removing the copyright notice or references to the Internet Society or 541 other Internet organizations, except as needed for the purpose of 542 developing Internet standards in which case the procedures for 543 copyrights defined in the Internet Standards process must be 544 followed, or as required to translate it into languages other than 545 English. 547 The limited permissions granted above are perpetual and will not 548 Be revoked by the Internet Society or its successors or assigns. 550 This document and the information contained herein is provided on 551 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 552 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 553 INCLUDING 554 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 555 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 556 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 558 Appendix A: Major functions provided by SCTP 560 Draft Informational October 2001 562 - Reliable Data Transfer 564 - Multiple streams to help avoid head-of-line blocking 566 - Ordered and unordered data delivery on a per-stream basis 568 - Bundling and fragmentation of user data 570 - TCP friendly Congestion and flow control 572 - Support continuous monitoring of reachability 574 - Graceful termination of association 576 - Support of multi-homing for added reliability 578 - Some protection against blind denial-of-service attacks 580 - Some protection against blind masquerade attacks