7 Network Working Group L. Coene
8 Request for Comments: 3257 Siemens
9 Category: Informational April 2002
12 Stream Control Transmission Protocol Applicability Statement
16 This memo provides information for the Internet community. It does
17 not specify an Internet standard of any kind. Distribution of this
22 Copyright (C) The Internet Society (2002). All Rights Reserved.
26 This document describes the applicability of the Stream Control
27 Transmission Protocol (SCTP). It also contrasts SCTP with the two
28 dominant transport protocols, User Datagram Protocol (UDP) &
29 Transmission Control Protocol (TCP), and gives some guidelines for
30 when best to use SCTP and when not best to use SCTP.
34 1. Introduction .................................................. 2
35 1.1 Terminology .................................................. 2
36 2 Transport protocols ............................................ 2
37 2.1 TCP service model ............................................ 2
38 2.2 SCTP service model ........................................... 3
39 2.3 UDP service model ............................................ 4
40 3 SCTP Multihoming issues ........................................ 4
41 4 SCTP Network Address Translators (NAT) issues [RFC2663] ........ 5
42 5 Security Considerations ........................................ 6
43 5.1 Security issues with TCP ..................................... 6
44 5.2 Security issues with SCTP .................................... 7
45 5.3 Security issues with both TCP and SCTP ....................... 8
46 6 References and related work .................................... 9
47 7 Acknowledgments ................................................ 10
48 Appendix A: Major functions provided by SCTP ..................... 11
49 Editor's Address ................................................. 12
50 Full Copyright Statement ......................................... 13
58 Coene Informational [Page 1]
60 RFC 3257 SCTP Applicability Statement April 2002
65 SCTP is a reliable transport protocol [RFC2960], which along with TCP
66 [RFC793], RTP [RFC1889], and UDP [RFC768], provides transport-layer
67 services for upper layer protocols and services. UDP, RTP, TCP, and
68 SCTP are currently the IETF standards-track transport-layer
69 protocols. Each protocol has a domain of applicability and services
70 it provides, albeit with some overlaps.
72 By clarifying the situations where the functionality of these
73 protocols are applicable, this document can guide implementers and
74 protocol designers in selecting which protocol to use.
76 Special attention is given to services SCTP provides which would make
77 a decision to use SCTP the right one.
79 Major functions provided by SCTP can be found in Appendix A.
83 The following terms are commonly identified in this work:
85 Association: SCTP connection between two endpoints.
87 Transport address: A combination of IP address and SCTP port number.
89 Upper layer: The user of the SCTP protocol, which may be an
90 adaptation layer, a session layer protocol, or the user application
93 Multihoming: Assigning more than one IP network interface to a single
100 TCP is a connection-oriented (a.k.a., session-oriented) transport
101 protocol. This means that it requires both the establishment of a
102 connection prior to the exchange of application data and a connection
103 tear-down to release system resources after the completion of data
106 TCP is currently the most widely used connection-oriented transport
107 protocol for the Internet.
114 Coene Informational [Page 2]
116 RFC 3257 SCTP Applicability Statement April 2002
119 TCP provides the upper layer with the following transport services:
123 - data sequence preservation; and
125 - flow and congestion control.
127 2.2 SCTP service model
129 SCTP is also connection-oriented and provides all the transport
130 services that TCP provides. Many Internet applications therefore
131 should find that either TCP or SCTP will meet their transport
132 requirements. Note, for applications conscious about processing
133 cost, there might be a difference in processing cost associated with
134 running SCTP with only a single ordered stream and one address pair
135 in comparison to running TCP.
137 However, SCTP has some additional capabilities that TCP lacks and
138 This can make SCTP a better choice for some applications and
141 - multi-streams support:
143 SCTP supports the delivery of multiple independent user message
144 streams within a single SCTP association. This capability, when
145 properly used, can alleviate the so-called head-of-line-blocking
146 problem caused by the strict sequence delivery constraint imposed to
147 the user data by TCP.
149 This can be particularly useful for applications that need to
150 exchange multiple, logically separate message streams between two
153 - multi-homing support:
155 SCTP provides transparent support for communications between two
156 endpoints of which one or both is multi-homed.
158 SCTP provides monitoring of the reachability of the addresses on the
159 remote endpoint and in the case of failure can transparently failover
160 from the primary address to an alternate address, without upper layer
170 Coene Informational [Page 3]
172 RFC 3257 SCTP Applicability Statement April 2002
175 This capability can be used to build redundant paths between two SCTP
176 endpoints and can be particularly useful for applications that seek
177 transport-level fault tolerance.
179 Achieving path redundancy between two SCTP endpoints normally
180 requires that the two endpoints being equipped with multiple
181 interfaces assigned with multiple addresses and that routing is
182 configured appropriately (see Section 3).
184 - preservation of message boundaries:
186 SCTP preserves application messages boundaries. This is useful when
187 the application data is not a continuous byte stream but comes in
188 logical chunks that the receiver handles separately.
190 In contrast, TCP offers a reliable data stream that has no indication
191 of what an application may consider logical chunks of the data.
193 - unordered reliable message delivery:
195 SCTP supports the transportation of user messages that have no
196 application-specified order, yet need guaranteed reliable delivery.
198 Applications that need to send un-ordered reliable messages or prefer
199 using their own message sequencing and ordering mechanisms may find
200 this SCTP capability useful.
202 2.3 UDP Service model
204 UDP is connectionless. This means that applications that use UDP do
205 not need to perform connection establishment or tear-down.
207 As transport services to its upper layer, UDP provides only:
209 - best-effort data delivery, and
211 - preservation of message boundaries.
213 Applications that do not require a reliable transfer of more than a
214 packet's worth of data will find UDP adequate. Some transaction-
215 based applications fall into this category.
217 3 SCTP Multihoming Issues
219 SCTP provides transport-layer support for multihoming. Multihoming
220 has the potential of providing additional robustness against network
221 failures. In some applications, this may be extremely important, for
222 example, in signaling transport of PSTN signaling messages [RFC2719].
226 Coene Informational [Page 4]
228 RFC 3257 SCTP Applicability Statement April 2002
231 It should be noted that SCTP multihoming support only deals with
232 communication between two endpoints of which one or both is assigned
233 with multiple IP addresses on possibly multiple network interfaces.
234 It does NOT deal with communication ends that contain multiple
235 endpoints (i.e., clustered endpoints) that can switch over to an
236 alternate endpoint in case of failure of the original endpoint.
238 Generally, for truly fault resilient communication between two end-
239 points, the multihoming feature needs more than one IP network
240 interface for each endpoint. The number of paths used is the minimum
241 of network interfaces used by any of the endpoints. When an endpoint
242 selects its source address, careful consideration must be taken. If
243 the same source address is always used, then it is possible that the
244 endpoint will be subject to the same single point of failure. When
245 the endpoint chooses a source address, it should always select the
246 source address of the packet to correspond to the IP address of the
247 Network interface where the packet will be emitted subject to the
248 binding address constraint. The binding address constraint is, put
249 simply, that the endpoint must never choose a source address that is
250 not part of the association i.e., the peer endpoint must recognize
251 any source address used as being part of the association.
253 The availability of the association will benefit greatly from having
254 multiple addresses bound to the association endpoint when the
255 endpoint is on a multi-homed host.
257 4 SCTP Network Address Translators (NAT) issues [RFC2663]
259 When two endpoints are to setup an SCTP association and one (or both)
260 of them is behind a NAT (i.e., it does not have any publicly
261 available network addresses), the endpoint(s) behind the NAT should
262 consider one of the following options:
264 (1) When single homed sessions are to be used, no transport addresses
265 should be sent in the INIT or INIT ACK chunk(Refer to section 3.3 of
266 RFC2960 for chunk definitions). This will force the endpoint that
267 receives this initiation message to use the source address in the IP
268 header as the only destination address for this association. This
269 method can be used for a NAT, but any multi-homing configuration at
270 the endpoint that is behind the NAT will not be visible to its peer,
271 and thus not be taken advantage of. See figure 1.
282 Coene Informational [Page 5]
284 RFC 3257 SCTP Applicability Statement April 2002
287 +-------+ +---------+ *~~~~~~~~~~* +------+
288 |Host A | | NAT | * Cloud * |Host B|
289 | 10.2 +--|10.1|2.1 |----|--------------|---------+ 1.2 |
291 +-------+ +---------+ *~~~~~~~~~~* +------+
293 Fig 1: SCTP through NAT without multihoming
295 For multihoming the NAT must have a public IP address for each
296 represented internal IP address. The host can preconfigure an IP
297 address that the NAT can substitute, or, the NAT can have internal
298 Application Layer Gateway (ALG) which will intelligently translate
299 the IP addresses in the INIT and INIT ACK chunks. See Figure 2.
301 If Network Address Port Translation is used with a multihomed SCTP
302 endpoint, then any port translation must be applied on a per-
303 association basis such that an SCTP endpoint continues to receive the
304 same port number for all messages within a given association.
306 +-------+ +----------+ *~~~~~~~~~~* +------+
307 |Host A | | NAT | * Cloud * |Host B|
308 | 10.2 +---+ 10.1|5.2 +-----+ 1.1<+->3.1--+---------+ 1.2 |
309 | 11.2 +---+ 11.1|6.2 | | +->4.2--+---------+ 2.2 |
311 +-------+ +----------+ *~~~~~~~~~* +------+
313 Fig 2: SCTP through NAT with multihoming
315 (2) Another alternative is to use the hostname feature and DNS to
316 resolve the addresses. The hostname is included in the INIT of the
317 association or in the INIT ACK. The hostname must be resolved by DNS
318 before the association is completely set up. There are special
319 issues regarding NAT and DNS, refer to RFC2694 for details.
321 5 Security Considerations
323 In this section, some relevant security issues found in the
324 deployment of the connection-oriented transport protocols will be
327 5.1 Security issues with TCP
329 Some TCP implementations have been known to be vulnerable to blind
330 denial of service attacks, i.e., attacks that had been executed by an
331 attacker that could not see most of the traffic to or from the target
338 Coene Informational [Page 6]
340 RFC 3257 SCTP Applicability Statement April 2002
343 The attacker would send a large number of connection establishment
344 requests (TCP-SYN packets) to the attacked target, possibly from
345 faked IP source addresses. The attacked host would reply by sending
346 SYN-ACK packets and entering SYN-received state, thereby allocating
347 space for a TCB. At some point the SYN-queue would fill up, (i.e.,
348 the number of connections waiting to be established would rise to a
349 limit) and the host under attack would have to start turning down new
350 connection establishment requests.
352 TCP implementations with SYN-cookies algorithm [SYN-COOK] reduce the
353 risk of such blind denial of service attacks. TCP implementations
354 can switch to using this algorithm in times when their SYN-queues are
355 filled up while still fully conforming to the TCP specification
356 [RFC793]. However, use of options such as a window scale [RFC1323],
357 is not possible, then. With the SYN-cookie mechanism, a TCB is only
358 created when the client sends back a valid ACK packet to the server,
359 and the 3-way handshake has thus been successfully completed.
361 Blind connection forgery is another potential threat to TCP. By
362 guessing valid sequence numbers, an attacker would be able to forge a
363 connection. However, with a secure hashsum algorithm, for some of
364 the current SYN-cookie implementations the likelihood of achieving
365 this attack is on the order of magnitude of 1 in 2^24, i.e., the
366 attacker would have to send 2^24 packets before obtaining one forged
367 connection when SYN-cookies are used.
369 5.2 Security issues with SCTP
371 SCTP has been designed with the experiences made with TCP in mind.
372 To make it hard for blind attackers (i.e., attackers that are not
373 man-in-the-middle) to inject forged SCTP datagrams into existing
374 associations, each side of an SCTP association uses a 32 bit value
375 called "Verification Tag" to ensure that a datagram really belongs to
376 the existing association. So in addition to a combination of source
377 and destination transport addresses that belong to an established
378 association, a valid SCTP datagram must also have the correct tag to
379 be accepted by the recipient.
381 Unlike in TCP, usage of cookie in association establishment is made
382 mandatory in SCTP. For the server, a new association is fully
383 established after three messages (containing INIT, INIT-ACK, COOKIE-
384 ECHO chunks) have been exchanged. The cookie is a variable length
385 parameter that contains all relevant data to initialize the TCB on
386 the server side, plus a HMAC used to secure it. This HMAC (MD5 as
387 per [RFC1321] or SHA-1 [SHA1]) is computed over the cookie and a
388 secret, server-owned key.
394 Coene Informational [Page 7]
396 RFC 3257 SCTP Applicability Statement April 2002
399 As specifically prescribed for SCTP implementations [RFC2960],
400 additional resources for new associations may only be reserved in
401 case a valid COOKIE-ECHO chunk is received by a client, and the
402 computed HMAC for this new cookie matches that contained in the
405 With SCTP the chances of an attacker being able to blindly forge a
406 connection are even lower than in the case of TCP using SYN-cookies,
407 since the attacker would have to guess a correct value for the HMAC
408 contained in the cookie, i.e., lower than 1 in 2^128 which for all
409 practical purposes is negligible.
411 It should be noted that SCTP only tries to increase the availability
412 of a network. SCTP does not contain any protocol mechanisms that are
413 directly related to user message authentication, integrity and
414 confidentiality functions. For such features, it depends on the
415 IPsec protocols and architecture and/or on security features of the
416 application protocols.
418 Transport Layer security(TLS)[RFC2246] using SCTP must always use
421 Currently the IPSEC working group is investigating the support of
422 multi-homing by IPSEC protocols. At the present time to use IPSEC,
423 one must use 2 * N * M security associations if one endpoint uses N
424 addresses and the other M addresses.
426 5.3 Security Issues with both TCP and SCTP
428 It is important to note that neither TCP nor SCTP protect itself from
429 man-in-the-middle attacks where an established session might be
430 hijacked (assuming the attacker can see the traffic from and inject
431 its own packets to either endpoints).
433 Also, to prevent blind connection/session setup forgery, both TCP
434 implementations supporting SYN-cookies and SCTP implementations rely
435 on a server-known, secret key to protect the HMAC data. It must be
436 ensured that this key is created subject to the recommendations
437 mentioned in [RFC1750].
439 Although SCTP has been designed carefully as to avoid some of the
440 problems that have appeared with TCP, it has as of yet not been
441 widely deployed. It is therefore possible that new security issues
442 will be identified that will have to be addressed in further
443 revisions of [RFC2960].
450 Coene Informational [Page 8]
452 RFC 3257 SCTP Applicability Statement April 2002
455 6 References and related work
457 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
458 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
459 Zhang, L. and V. Paxson, "Stream Control Transmission
460 Protocol", RFC 2960, October 2000.
462 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
463 Internet Protocol", RFC 2401, November 1998.
465 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
466 Translator (NAT) Terminology and Considerations", RFC
469 [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
470 Heffernan, "DNS extensions to Network Address Translators
471 (DNS_ALG)", RFC 2694, September 1999.
473 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
476 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
479 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
480 L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp,
481 "Architectural Framework for Signaling Transport", RFC
484 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
487 [RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
488 for High Performance", RFC 1323, May 1992.
490 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
491 Recommendations for Security", RFC 1750, December 1994.
493 [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National
494 Institute of Standards and Technology, U.S. Department of
495 Commerce, April 1995.
497 [SYNCOOK] Dan J. Bernstein, SYN cookies, 1997, see also
498 <http://cr.yp.to/syncookies.html>
500 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
501 RFC 2246, January 1999.
506 Coene Informational [Page 9]
508 RFC 3257 SCTP Applicability Statement April 2002
511 [RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V.
512 Jacobson, "RTP: A Transport Protocol for Real-Time
513 Applications", RFC 1889, January 1996.
517 This document was initially developed by a design team consisting of
518 Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart,
519 Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas
520 Jungmaier, Gery Verwimp and Lyndon Ong.
522 The authors wish to thank Renee Revis, I. Rytina, H.J. Schwarzbauer,
523 J.P. Martin-Flatin, T. Taylor, G. Sidebottom, K. Morneault, T.
524 George, M. Stillman, N. Makinae, S. Bradner, A. Mankin, G. Camarillo,
525 H. Schulzrinne, R. Kantola, J. Rosenberg, R.J. Atkinson, and many
526 others for their invaluable comments.
562 Coene Informational [Page 10]
564 RFC 3257 SCTP Applicability Statement April 2002
567 Appendix A: Major functions provided by SCTP
569 - Reliable Data Transfer
571 - Multiple streams to help avoid head-of-line blocking
573 - Ordered and unordered data delivery on a per-stream basis
575 - Bundling and fragmentation of user data
577 - TCP friendly Congestion and flow control
579 - Support continuous monitoring of reachability
581 - Graceful termination of association
583 - Support of multi-homing for added reliability
585 - Some protection against blind denial-of-service attacks
587 - Some protection against blind masquerade attacks
618 Coene Informational [Page 11]
620 RFC 3257 SCTP Applicability Statement April 2002
632 EMail: lode.coene@siemens.atea.be
674 Coene Informational [Page 12]
676 RFC 3257 SCTP Applicability Statement April 2002
679 9. Full Copyright Statement
681 Copyright (C) The Internet Society (2002). All Rights Reserved.
683 This document and translations of it may be copied and furnished to
684 others, and derivative works that comment on or otherwise explain it
685 or assist in its implementation may be prepared, copied, published
686 and distributed, in whole or in part, without restriction of any
687 kind, provided that the above copyright notice and this paragraph are
688 included on all such copies and derivative works. However, this
689 document itself may not be modified in any way, such as by removing
690 the copyright notice or references to the Internet Society or other
691 Internet organizations, except as needed for the purpose of
692 developing Internet standards in which case the procedures for
693 copyrights defined in the Internet Standards process must be
694 followed, or as required to translate it into languages other than
697 The limited permissions granted above are perpetual and will not be
698 revoked by the Internet Society or its successors or assigns.
700 This document and the information contained herein is provided on an
701 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
702 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
703 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
704 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
705 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
709 Funding for the RFC Editor function is currently provided by the
730 Coene Informational [Page 13]