GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3257

Network Working Group L. Coene Request for Comments: 3257 Siemens Category: Informational April 2002

    Stream Control Transmission Protocol Applicability Statement

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

 This document describes the applicability of the Stream Control
 Transmission Protocol (SCTP).  It also contrasts SCTP with the two
 dominant transport protocols, User Datagram Protocol (UDP) &
 Transmission Control Protocol (TCP), and gives some guidelines for
 when best to use SCTP and when not best to use SCTP.

Table of contents

 1. Introduction ..................................................  2
 1.1 Terminology ..................................................  2
 2 Transport protocols ............................................  2
 2.1 TCP service model ............................................  2
 2.2 SCTP service model ...........................................  3
 2.3 UDP service model ............................................  4
 3 SCTP Multihoming issues ........................................  4
 4 SCTP Network Address Translators (NAT) issues [RFC2663] ........  5
 5 Security Considerations ........................................  6
 5.1 Security issues with TCP .....................................  6
 5.2 Security issues with SCTP ....................................  7
 5.3 Security issues with both TCP and SCTP .......................  8
 6 References and related work ....................................  9
 7 Acknowledgments ................................................ 10
 Appendix A: Major functions provided by SCTP ..................... 11
 Editor's Address ................................................. 12
 Full Copyright Statement ......................................... 13

Coene Informational [Page 1] RFC 3257 SCTP Applicability Statement April 2002

1 Introduction

 SCTP is a reliable transport protocol [RFC2960], which along with TCP
 [RFC793], RTP [RFC1889], and UDP [RFC768], provides transport-layer
 services for upper layer protocols and services.  UDP, RTP, TCP, and
 SCTP are currently the IETF standards-track transport-layer
 protocols.  Each protocol has a domain of applicability and services
 it provides, albeit with some overlaps.
 By clarifying the situations where the functionality of these
 protocols are applicable, this document can guide implementers and
 protocol designers in selecting which protocol to use.
 Special attention is given to services SCTP provides which would make
 a decision to use SCTP the right one.
 Major functions provided by SCTP can be found in Appendix A.

1.1 Terminology

 The following terms are commonly identified in this work:
 Association: SCTP connection between two endpoints.
 Transport address: A combination of IP address and SCTP port number.
 Upper layer: The user of the SCTP protocol, which may be an
 adaptation layer, a session layer protocol, or the user application
 directly.
 Multihoming: Assigning more than one IP network interface to a single
 endpoint.

2 Transport protocols

2.1 TCP service model

 TCP is a connection-oriented (a.k.a., session-oriented) transport
 protocol.  This means that it requires both the establishment of a
 connection prior to the exchange of application data and a connection
 tear-down to release system resources after the completion of data
 transfer.
 TCP is currently the most widely used connection-oriented transport
 protocol for the Internet.

Coene Informational [Page 2] RFC 3257 SCTP Applicability Statement April 2002

 TCP provides the upper layer with the following transport services:
  1. data reliability;
  1. data sequence preservation; and
  1. flow and congestion control.

2.2 SCTP service model

 SCTP is also connection-oriented and provides all the transport
 services that TCP provides.  Many Internet applications therefore
 should find that either TCP or SCTP will meet their transport
 requirements.  Note, for applications conscious about processing
 cost, there might be a difference in processing cost associated with
 running SCTP with only a single ordered stream and one address pair
 in comparison to running TCP.
 However, SCTP has some additional capabilities that TCP lacks and
 This can make SCTP a better choice for some applications and
 environments:
  1. multi-streams support:
 SCTP supports the delivery of multiple independent user message
 streams within a single SCTP association.  This capability, when
 properly used, can alleviate the so-called head-of-line-blocking
 problem caused by the strict sequence delivery constraint imposed to
 the user data by TCP.
 This can be particularly useful for applications that need to
 exchange multiple, logically separate message streams between two
 endpoints.
  1. multi-homing support:
 SCTP provides transparent support for communications between two
 endpoints of which one or both is multi-homed.
 SCTP provides monitoring of the reachability of the addresses on the
 remote endpoint and in the case of failure can transparently failover
 from the primary address to an alternate address, without upper layer
 intervention.

Coene Informational [Page 3] RFC 3257 SCTP Applicability Statement April 2002

 This capability can be used to build redundant paths between two SCTP
 endpoints and can be particularly useful for applications that seek
 transport-level fault tolerance.
 Achieving path redundancy between two SCTP endpoints normally
 requires that the two endpoints being equipped with multiple
 interfaces assigned with multiple addresses and that routing is
 configured appropriately (see Section 3).
  1. preservation of message boundaries:
 SCTP preserves application messages boundaries.  This is useful when
 the application data is not a continuous byte stream but comes in
 logical chunks that the receiver handles separately.
 In contrast, TCP offers a reliable data stream that has no indication
 of what an application may consider logical chunks of the data.
  1. unordered reliable message delivery:
 SCTP supports the transportation of user messages that have no
 application-specified order, yet need guaranteed reliable delivery.
 Applications that need to send un-ordered reliable messages or prefer
 using their own message sequencing and ordering mechanisms may find
 this SCTP capability useful.

2.3 UDP Service model

 UDP is connectionless.  This means that applications that use UDP do
 not need to perform connection establishment or tear-down.
 As transport services to its upper layer, UDP provides only:
  1. best-effort data delivery, and
  1. preservation of message boundaries.
 Applications that do not require a reliable transfer of more than a
 packet's worth of data will find UDP adequate.  Some transaction-
 based applications fall into this category.

3 SCTP Multihoming Issues

 SCTP provides transport-layer support for multihoming.  Multihoming
 has the potential of providing additional robustness against network
 failures.  In some applications, this may be extremely important, for
 example, in signaling transport of PSTN signaling messages [RFC2719].

Coene Informational [Page 4] RFC 3257 SCTP Applicability Statement April 2002

 It should be noted that SCTP multihoming support only deals with
 communication between two endpoints of which one or both is assigned
 with multiple IP addresses on possibly multiple network interfaces.
 It does NOT deal with communication ends that contain multiple
 endpoints (i.e., clustered endpoints) that can switch over to an
 alternate endpoint in case of failure of the original endpoint.
 Generally, for truly fault resilient communication between two end-
 points, the multihoming feature needs more than one IP network
 interface for each endpoint.  The number of paths used is the minimum
 of network interfaces used by any of the endpoints.  When an endpoint
 selects its source address, careful consideration must be taken.  If
 the same source address is always used, then it is possible that the
 endpoint will be subject to the same single point of failure.  When
 the endpoint chooses a source address, it should always select the
 source address of the packet to correspond to the IP address of the
 Network interface where the packet will be emitted subject to the
 binding address constraint.  The binding address constraint is, put
 simply, that the endpoint must never choose a source address that is
 not part of the association i.e., the peer endpoint must recognize
 any source address used as being part of the association.
 The availability of the association will benefit greatly from having
 multiple addresses bound to the association endpoint when the
 endpoint is on a multi-homed host.

4 SCTP Network Address Translators (NAT) issues [RFC2663]

 When two endpoints are to setup an SCTP association and one (or both)
 of them is behind a NAT (i.e., it does not have any publicly
 available network addresses), the endpoint(s) behind the NAT should
 consider one of the following options:
 (1) When single homed sessions are to be used, no transport addresses
 should be sent in the INIT or INIT ACK chunk(Refer to section 3.3 of
 RFC2960 for chunk definitions).  This will force the endpoint that
 receives this initiation message to use the source address in the IP
 header as the only destination address for this association.  This
 method can be used for a NAT, but any multi-homing configuration at
 the endpoint that is behind the NAT will not be visible to its peer,
 and thus not be taken advantage of.  See figure 1.

Coene Informational [Page 5] RFC 3257 SCTP Applicability Statement April 2002

    +-------+  +---------+      *~~~~~~~~~~*           +------+
    |Host A |  |   NAT   |     *   Cloud    *          |Host B|
    | 10.2  +--|10.1|2.1 |----|--------------|---------+ 1.2  |
    |       |  |    |    |     *            *          |      |
    +-------+  +---------+      *~~~~~~~~~~*           +------+
             Fig 1: SCTP through NAT without multihoming
 For multihoming the NAT must have a public IP address for each
 represented internal IP address.  The host can preconfigure an IP
 address that the NAT can substitute, or, the NAT can have internal
 Application Layer Gateway (ALG) which will intelligently translate
 the IP addresses in the INIT and INIT ACK chunks.  See Figure 2.
 If Network Address Port Translation is used with a multihomed SCTP
 endpoint, then any port translation must be applied on a per-
 association basis such that an SCTP endpoint continues to receive the
 same port number for all messages within a given association.
    +-------+   +----------+      *~~~~~~~~~~*           +------+
    |Host A |   |    NAT   |     *   Cloud    *          |Host B|
    | 10.2  +---+ 10.1|5.2 +-----+ 1.1<+->3.1--+---------+ 1.2  |
    | 11.2  +---+ 11.1|6.2 |     |     +->4.2--+---------+ 2.2  |
    |       |   |          |      *           *          |      |
    +-------+   +----------+       *~~~~~~~~~*           +------+
              Fig 2: SCTP through NAT with multihoming
 (2) Another alternative is to use the hostname feature and DNS to
 resolve the addresses.  The hostname is included in the INIT of the
 association or in the INIT ACK.  The hostname must be resolved by DNS
 before the association is completely set up.  There are special
 issues regarding NAT and DNS, refer to RFC2694 for details.

5 Security Considerations

 In this section, some relevant security issues found in the
 deployment of the connection-oriented transport protocols will be
 discussed.

5.1 Security issues with TCP

 Some TCP implementations have been known to be vulnerable to blind
 denial of service attacks, i.e., attacks that had been executed by an
 attacker that could not see most of the traffic to or from the target
 host.

Coene Informational [Page 6] RFC 3257 SCTP Applicability Statement April 2002

 The attacker would send a large number of connection establishment
 requests (TCP-SYN packets) to the attacked target, possibly from
 faked IP source addresses.  The attacked host would reply by sending
 SYN-ACK packets and entering SYN-received state, thereby allocating
 space for a TCB.  At some point the SYN-queue would fill up, (i.e.,
 the number of connections waiting to be established would rise to a
 limit) and the host under attack would have to start turning down new
 connection establishment requests.
 TCP implementations with SYN-cookies algorithm [SYN-COOK] reduce the
 risk of such blind denial of service attacks.  TCP implementations
 can switch to using this algorithm in times when their SYN-queues are
 filled up while still fully conforming to the TCP specification
 [RFC793].  However, use of options such as a window scale [RFC1323],
 is not possible, then.  With the SYN-cookie mechanism, a TCB is only
 created when the client sends back a valid ACK packet to the server,
 and the 3-way handshake has thus been successfully completed.
 Blind connection forgery is another potential threat to TCP.  By
 guessing valid sequence numbers, an attacker would be able to forge a
 connection.  However, with a secure hashsum algorithm, for some of
 the current SYN-cookie implementations the likelihood of achieving
 this attack is on the order of magnitude of 1 in 2^24, i.e., the
 attacker would have to send 2^24 packets before obtaining one forged
 connection when SYN-cookies are used.

5.2 Security issues with SCTP

 SCTP has been designed with the experiences made with TCP in mind.
 To make it hard for blind attackers (i.e., attackers that are not
 man-in-the-middle) to inject forged SCTP datagrams into existing
 associations, each side of an SCTP association uses a 32 bit value
 called "Verification Tag" to ensure that a datagram really belongs to
 the existing association.  So in addition to a combination of source
 and destination transport addresses that belong to an established
 association, a valid SCTP datagram must also have the correct tag to
 be accepted by the recipient.
 Unlike in TCP, usage of cookie in association establishment is made
 mandatory in SCTP.  For the server, a new association is fully
 established after three messages (containing INIT, INIT-ACK, COOKIE-
 ECHO chunks) have been exchanged.  The cookie is a variable length
 parameter that contains all relevant data to initialize the TCB on
 the server side, plus a HMAC used to secure it.  This HMAC (MD5 as
 per [RFC1321] or SHA-1 [SHA1]) is computed over the cookie and a
 secret, server-owned key.

Coene Informational [Page 7] RFC 3257 SCTP Applicability Statement April 2002

 As specifically prescribed for SCTP implementations [RFC2960],
 additional resources for new associations may only be reserved in
 case a valid COOKIE-ECHO chunk is received by a client, and the
 computed HMAC for this new cookie matches that contained in the
 cookie.
 With SCTP the chances of an attacker being able to blindly forge a
 connection are even lower than in the case of TCP using SYN-cookies,
 since the attacker would have to guess a correct value for the HMAC
 contained in the cookie, i.e., lower than 1 in 2^128 which for all
 practical purposes is negligible.
 It should be noted that SCTP only tries to increase the availability
 of a network.  SCTP does not contain any protocol mechanisms that are
 directly related to user message authentication, integrity and
 confidentiality functions.  For such features, it depends on the
 IPsec protocols and architecture and/or on security features of the
 application protocols.
 Transport Layer security(TLS)[RFC2246] using SCTP must always use
 in-order streams.
 Currently the IPSEC working group is investigating the support of
 multi-homing by IPSEC protocols.  At the present time to use IPSEC,
 one must use 2 * N * M security associations if one endpoint uses N
 addresses and the other M addresses.

5.3 Security Issues with both TCP and SCTP

 It is important to note that neither TCP nor SCTP protect itself from
 man-in-the-middle attacks where an established session might be
 hijacked (assuming the attacker can see the traffic from and inject
 its own packets to either endpoints).
 Also, to prevent blind connection/session setup forgery, both TCP
 implementations supporting SYN-cookies and SCTP implementations rely
 on a server-known, secret key to protect the HMAC data.  It must be
 ensured that this key is created subject to the recommendations
 mentioned in [RFC1750].
 Although SCTP has been designed carefully as to avoid some of the
 problems that have appeared with TCP, it has as of yet not been
 widely deployed.  It is therefore possible that new security issues
 will be identified that will have to be addressed in further
 revisions of [RFC2960].

Coene Informational [Page 8] RFC 3257 SCTP Applicability Statement April 2002

6 References and related work

 [RFC2960]   Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
             Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
             Zhang, L. and V. Paxson, "Stream Control Transmission
             Protocol", RFC 2960, October 2000.
 [RFC2401]   Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.
 [RFC2663]   Srisuresh, P. and M. Holdrege, "IP Network Address
             Translator (NAT) Terminology and Considerations", RFC
             2663, August 1999.
 [RFC2694]   Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
             Heffernan, "DNS extensions to Network Address Translators
             (DNS_ALG)", RFC 2694, September 1999.
 [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
             August 1980.
 [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
             793, September 1981.
 [RFC2719]   Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene,
             L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp,
             "Architectural Framework for Signaling Transport", RFC
             2719, October 1999.
 [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
             April 1992.
 [RFC1323]   Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
             for High Performance", RFC 1323, May 1992.
 [RFC1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
             Recommendations for Security", RFC 1750, December 1994.
 [SHA1]      NIST FIPS PUB 180-1, "Secure Hash Standard," National
             Institute of Standards and Technology, U.S. Department of
             Commerce, April 1995.
 [SYNCOOK]   Dan J. Bernstein, SYN cookies, 1997, see also
             <http://cr.yp.to/syncookies.html>
 [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
             RFC 2246, January 1999.

Coene Informational [Page 9] RFC 3257 SCTP Applicability Statement April 2002

 [RFC1889]   Schulzrinne, H., Casner, S., Frederick, R. and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", RFC 1889, January 1996.

7 Acknowledgments

 This document was initially developed by a design team consisting of
 Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart,
 Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon, Andreas
 Jungmaier, Gery Verwimp and Lyndon Ong.
 The authors wish to thank Renee Revis, I. Rytina, H.J. Schwarzbauer,
 J.P. Martin-Flatin, T. Taylor, G. Sidebottom, K. Morneault, T.
 George, M. Stillman, N. Makinae, S. Bradner, A. Mankin, G. Camarillo,
 H. Schulzrinne, R. Kantola, J. Rosenberg, R.J. Atkinson, and many
 others for their invaluable comments.

Coene Informational [Page 10] RFC 3257 SCTP Applicability Statement April 2002

Appendix A: Major functions provided by SCTP

  1. Reliable Data Transfer
  1. Multiple streams to help avoid head-of-line blocking
  1. Ordered and unordered data delivery on a per-stream basis
  1. Bundling and fragmentation of user data
  1. TCP friendly Congestion and flow control
  1. Support continuous monitoring of reachability
  1. Graceful termination of association
  1. Support of multi-homing for added reliability
  1. Some protection against blind denial-of-service attacks
  1. Some protection against blind masquerade attacks

Coene Informational [Page 11] RFC 3257 SCTP Applicability Statement April 2002

8 Editor's Address

 Lode Coene
 Siemens Atea
 Atealaan 34
 B-2200 Herentals
 Belgium
 Phone: +32-14-252081
 EMail: lode.coene@siemens.atea.be

Coene Informational [Page 12] RFC 3257 SCTP Applicability Statement April 2002

9. Full Copyright Statement

 Copyright (C) The Internet Society (2002).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Coene Informational [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3257.txt · Last modified: 2002/04/10 16:09 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki