OpenSS7
SS7 for the
Common Man
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.
Last modified: Fri, 21 Nov 2008 00:06:33 GMT
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-ietf-sigtran-sctp-applicability-07
Quick Links

Download

SCTP

SIGTRAN

SS7

Hardware

STREAMS

Asterisk

Related

Package

Manual

FAQ

SIGTRAN

SCTP

UA

TUA

SUA

ISUA

M3UA

M2UA

M2PA

IUA

TALI

SS7 over IP

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

draft-ietf-sigtran-sctp-applicability-07

Description: Request For Comments

You can download source copies of the file as follows:

draft-ietf-sigtran-sctp-applicability-07.txt in text format.

Listed below is the contents of file draft-ietf-sigtran-sctp-applicability-07.txt.


INTERNET-DRAFT                                         L. Coene(Editor)
Internet Engineering Task Force                                 Siemens
Issued:  October 2001                               
Expires: April 2002

      Stream Control Transmission Protocol Applicability Statement
         <draft-ietf-sigtran-sctp-applicability-07.txt>

Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026. Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its areas,
    and its working groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet- Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html

Abstract

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

Coene, at al.                                                   [Page 1]

Draft                     Informational                     October 2001

                           Table of contents

   Stream Control Transmission Protocol Applicability statement
   ................................................................   ii
   Chapter 1: Introduction ........................................    2
   Chapter 1.1: Terminology .......................................    3
   Chapter 1.2: Contributors ......................................    3
   Chapter 2: Transport protocols .................................    3
   Chapter 2.1: TCP service model .................................    3
   Chapter 2.2: SCTP service model ................................    4
   Chapter 2.3: UDP service model .................................    5
   Chapter 3: SCTP Multihoming issues .............................    5
   Chapter 4: SCTP with Network Address Translators (NAT)
   [RFC2663] ......................................................    6
   Chapter 5: Security considerations .............................    7
   Chapter 5.1: Security issues with TCP ..........................    7
   Chapter 5.2: Security issues with SCTP .........................    8
   Chapter 5.3: Security issues with both TCP and SCTP ............    9
   Chapter 6: References and related work .........................    9
   Chapter 7: Acknowledgments .....................................   10
   Chapter 8: Author's address ....................................   11
   Appendix A: Major functions provided by SCTP ...................   13

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.

Coene, at al.                                                   [Page 2]

Draft                     Informational                     October 2001

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.

1.2 Contributors

    The following people contributed to the document: L. Coene(Editor),
    M.  Tuexen, G. Verwimp, J. Loughney, R.R. Stewart, Qiaobing Xie,
    M. Holdrege, M.C. Belinchon, A. Jungmaier, and L. Ong.

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 exchange of application data and a connection
    tear-down to release system resource after the completion of data
    transfer.

    TCP is currently the most widely used connection-oriented transport
    protocol for the Internet.

    TCP provides the upper layer with the following transport services:

    - data reliability;

    - data sequence preservation; and

    - flow and congestion control.

Coene, at al.                                                   [Page 3]

Draft                     Informational                     October 2001

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.

    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

Coene, at al.                                                   [Page 4]

Draft                     Informational                     October 2001

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

    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

Coene, at al.                                                   [Page 5]

Draft                     Informational                     October 2001

    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. If
    possible the endpoint 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.

4 Network Address Translators (NAT) Networks 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.

       +-------+  +---------+      *~~~~~~~~~~*           +------+
       |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 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.

Coene, at al.                                                   [Page 6]

Draft                     Informational                     October 2001

       +-------+   +----------+      *~~~~~~~~~~*           +------+
       |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.

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

Coene, at al.                                                   [Page 7]

Draft                     Informational                     October 2001

    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.

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

Coene, at al.                                                   [Page 8]

Draft                     Informational                     October 2001

    Currently the IPSEC working group is investigating the support of
    mul- tihoming 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, for preventing 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].

5 References and related work

    [RFC2960] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , ,
    Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, L.
    and Paxson, V."Stream Control Transmission Protocol", RFC2960,
    October 2000.

    [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for the
    Internet Protocol", RFC 2401, November 1998.

    [RFC2663] Srisuresh, P. and Holdrege, M., "IP Network Address
    Translator (NAT) Terminology and Considerations", RFC2663, August
    1999

    [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and Heffernan,
    A., "DNS extensions to Network Address Translators (DNS_ALG)",
    RFC2694, September 1999

    [RFC768] Postel, J. (ed.), "User Datagram Protocol", STD 6, RFC 768,
    August 1980.

Coene, at al.                                                   [Page 9]

Draft                     Informational                     October 2001

    [RFC793] Postel, J. (ed.), "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,
    MIT Laboratory for Computer Science, April 1992.

    [RFC1323] Jacobson, V., Braden, R, and D. Borman, "TCP Extensions
    for High Performance", RFC 1323, LBL, USC/Information Sciences
    Institute, Cray Research, 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 Allen, C.,"The TLS Protocol Version 1.0",
    RFC 2246, January 1999.

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

6 Acknowledgments

    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 and many
    others for their invaluable comments.

Coene, at al.                                                  [Page 10]

Draft                     Informational                     October 2001

7  Author's Address

    The following authors have contributed to this document.

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

    John Loughney               Phone: +358-9-43761
    Nokia Research Center       EMail: john.loughney@nokia.com
    Itamerenkatu 11-13
    FIN-00180    Helsinki
    Finland

    Michel Tuexen               Phone: +49-89-722-47210
    Siemens AG                  EMail: Michael.Tuexen@icn.siemens.de
    Hofmannstr. 51
    81359 Munich
    Germany

    Randall R. Stewart          Phone: +1-815-477-2127
    24 Burning Bush Trail.      EMail: rrs@cisco.com
    Crystal Lake, IL 60012
    USA

    Qiaobing Xie                Phone: +1-847-632-3028
    Motorola, Inc.              EMail: qxie1@email.mot.com
    1501 W. Shure Drive
    Arlington Heights, IL 60004
    USA

    Matt Holdrege               Phone: -
    ipVerse                     Email: matt@ipverse.com
    223 Ximeno Avenue
    Long Beach, CA 90803-1616
    USA

    Maria-Carmen Belinchon      Phone: +34-91-339-3535
    Ericsson Espana S. A.       EMail: Maria.C.Belinchon@ericsson.com
    Network Communication Services
    Retama 7, 5th floor
    Madrid, 28045
    Spain

    Andreas Jungmaier           Phone:   +49 201 1837636
    University of Essen         Email: ajung@exp-math.uni-essen.de
    Networking Technology Group at the IEM
    Ellernstrasse 29
    D-45326 Essen
    Germany

Coene, at al.                                                  [Page 11]

Draft                     Informational                     October 2001

    Gery Verwimp                Phone: +32-14-253424
    Siemens Atea                EMail: gery.verwimp@siemens.atea.be
    Atealaan 34
    B-2200    Herentals
    Belgium

    Lyndon Ong                  Phone: -
                                EMail: lyong@ciena.com
    USA

Expires: April 30, 2002

Full Copyright Statement

Copyright (C) The Internet Society (2001).  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.

Appendix A: Major functions provided by SCTP

Coene, at al.                                                  [Page 12]

Draft                     Informational                     October 2001

     - Reliable Data Transfer

     - Multiple streams to help avoid head-of-line blocking

     - Ordered and unordered data delivery on a per-stream basis

     - Bundling and fragmentation of user data

     - TCP friendly Congestion and flow control

     - Support continuous monitoring of reachability

     - Graceful termination of association

     - Support of multi-homing for added reliability

     - Some protection against blind denial-of-service attacks

     - Some protection against blind masquerade attacks

Coene, at al.                                                  [Page 13]


OpenSS7
SS7 for the
Common Man
Home TopIndex FirstPrev Next LastMore Download Info FAQ Mail  Home -> Documentation -> SIGTRAN -> draft-ietf-sigtran-sctp-applicability-07
Last modified: Fri, 21 Nov 2008 00:06:33 GMT
© Copyright 1997-2007 OpenSS7 Corporation All Rights Reserved.