rfc3257.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/2 页

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:

   - data reliability;

   - data sequence preservation; and

   - 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:

   - 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.

   - 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).

   - 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.

   - 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:

   - best-effort data delivery, and

   - 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