doc/rfc3257.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           L. Coene
   8 Request for Comments: 3257                                       Siemens
   9 Category: Informational                                       April 2002
  10
  11
  12       Stream Control Transmission Protocol Applicability Statement
  13
  14 Status of this Memo
  15
  16    This memo provides information for the Internet community.  It does
  17    not specify an Internet standard of any kind.  Distribution of this
  18    memo is unlimited.
  19
  20 Copyright Notice
  21
  22    Copyright (C) The Internet Society (2002).  All Rights Reserved.
  23
  24 Abstract
  25
  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.
  31
  32 Table of contents
  33
  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
  51
  52
  53
  54
  55
  56
  57
  58 Coene                        Informational                      [Page 1]
  59 \f
  60 RFC 3257              SCTP Applicability Statement            April 2002
  61
  62
  63 1 Introduction
  64
  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.
  71
  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.
  75
  76    Special attention is given to services SCTP provides which would make
  77    a decision to use SCTP the right one.
  78
  79    Major functions provided by SCTP can be found in Appendix A.
  80
  81 1.1 Terminology
  82
  83    The following terms are commonly identified in this work:
  84
  85    Association: SCTP connection between two endpoints.
  86
  87    Transport address: A combination of IP address and SCTP port number.
  88
  89    Upper layer: The user of the SCTP protocol, which may be an
  90    adaptation layer, a session layer protocol, or the user application
  91    directly.
  92
  93    Multihoming: Assigning more than one IP network interface to a single
  94    endpoint.
  95
  96 2 Transport protocols
  97
  98 2.1 TCP service model
  99
 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
 104    transfer.
 105
 106    TCP is currently the most widely used connection-oriented transport
 107    protocol for the Internet.
 108
 109
 110
 111
 112
 113
 114 Coene                        Informational                      [Page 2]
 115 \f
 116 RFC 3257              SCTP Applicability Statement            April 2002
 117
 118
 119    TCP provides the upper layer with the following transport services:
 120
 121    - data reliability;
 122
 123    - data sequence preservation; and
 124
 125    - flow and congestion control.
 126
 127 2.2 SCTP service model
 128
 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.
 136
 137    However, SCTP has some additional capabilities that TCP lacks and
 138    This can make SCTP a better choice for some applications and
 139    environments:
 140
 141    - multi-streams support:
 142
 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.
 148
 149    This can be particularly useful for applications that need to
 150    exchange multiple, logically separate message streams between two
 151    endpoints.
 152
 153    - multi-homing support:
 154
 155    SCTP provides transparent support for communications between two
 156    endpoints of which one or both is multi-homed.
 157
 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
 161    intervention.
 162
 163
 164
 165
 166
 167
 168
 169
 170 Coene                        Informational                      [Page 3]
 171 \f
 172 RFC 3257              SCTP Applicability Statement            April 2002
 173
 174
 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.
 178
 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).
 183
 184    - preservation of message boundaries:
 185
 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.
 189
 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.
 192
 193    - unordered reliable message delivery:
 194
 195    SCTP supports the transportation of user messages that have no
 196    application-specified order, yet need guaranteed reliable delivery.
 197
 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.
 201
 202 2.3 UDP Service model
 203
 204    UDP is connectionless.  This means that applications that use UDP do
 205    not need to perform connection establishment or tear-down.
 206
 207    As transport services to its upper layer, UDP provides only:
 208
 209    - best-effort data delivery, and
 210
 211    - preservation of message boundaries.
 212
 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.
 216
 217 3 SCTP Multihoming Issues
 218
 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].
 223
 224
 225
 226 Coene                        Informational                      [Page 4]
 227 \f
 228 RFC 3257              SCTP Applicability Statement            April 2002
 229
 230
 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.
 237
 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.
 252
 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.
 256
 257 4 SCTP Network Address Translators (NAT) issues [RFC2663]
 258
 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:
 263
 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.
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Coene                        Informational                      [Page 5]
 283 \f
 284 RFC 3257              SCTP Applicability Statement            April 2002
 285
 286
 287       +-------+  +---------+      *~~~~~~~~~~*           +------+
 288       |Host A |  |   NAT   |     *   Cloud    *          |Host B|
 289       | 10.2  +--|10.1|2.1 |----|--------------|---------+ 1.2  |
 290       |       |  |    |    |     *            *          |      |
 291       +-------+  +---------+      *~~~~~~~~~~*           +------+
 292
 293                Fig 1: SCTP through NAT without multihoming
 294
 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.
 300
 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.
 305
 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  |
 310       |       |   |          |      *           *          |      |
 311       +-------+   +----------+       *~~~~~~~~~*           +------+
 312
 313                 Fig 2: SCTP through NAT with multihoming
 314
 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.
 320
 321 5 Security Considerations
 322
 323    In this section, some relevant security issues found in the
 324    deployment of the connection-oriented transport protocols will be
 325    discussed.
 326
 327 5.1 Security issues with TCP
 328
 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
 332    host.
 333
 334
 335
 336
 337
 338 Coene                        Informational                      [Page 6]
 339 \f
 340 RFC 3257              SCTP Applicability Statement            April 2002
 341
 342
 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.
 351
 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.
 360
 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.
 368
 369 5.2 Security issues with SCTP
 370
 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.
 380
 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.
 389
 390
 391
 392
 393
 394 Coene                        Informational                      [Page 7]
 395 \f
 396 RFC 3257              SCTP Applicability Statement            April 2002
 397
 398
 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
 403    cookie.
 404
 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.
 410
 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.
 417
 418    Transport Layer security(TLS)[RFC2246] using SCTP must always use
 419    in-order streams.
 420
 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.
 425
 426 5.3 Security Issues with both TCP and SCTP
 427
 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).
 432
 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].
 438
 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].
 444
 445
 446
 447
 448
 449
 450 Coene                        Informational                      [Page 8]
 451 \f
 452 RFC 3257              SCTP Applicability Statement            April 2002
 453
 454
 455 6 References and related work
 456
 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.
 461
 462    [RFC2401]   Kent, S. and R. Atkinson, "Security Architecture for the
 463                Internet Protocol", RFC 2401, November 1998.
 464
 465    [RFC2663]   Srisuresh, P. and M. Holdrege, "IP Network Address
 466                Translator (NAT) Terminology and Considerations", RFC
 467                2663, August 1999.
 468
 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.
 472
 473    [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
 474                August 1980.
 475
 476    [RFC793]    Postel, J., "Transmission Control Protocol", STD 7, RFC
 477                793, September 1981.
 478
 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
 482                2719, October 1999.
 483
 484    [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
 485                April 1992.
 486
 487    [RFC1323]   Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
 488                for High Performance", RFC 1323, May 1992.
 489
 490    [RFC1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
 491                Recommendations for Security", RFC 1750, December 1994.
 492
 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.
 496
 497    [SYNCOOK]   Dan J. Bernstein, SYN cookies, 1997, see also
 498                <http://cr.yp.to/syncookies.html>
 499
 500    [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 501                RFC 2246, January 1999.
 502
 503
 504
 505
 506 Coene                        Informational                      [Page 9]
 507 \f
 508 RFC 3257              SCTP Applicability Statement            April 2002
 509
 510
 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.
 514
 515 7 Acknowledgments
 516
 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.
 521
 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.
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Coene                        Informational                     [Page 10]
 563 \f
 564 RFC 3257              SCTP Applicability Statement            April 2002
 565
 566
 567 Appendix A: Major functions provided by SCTP
 568
 569    - Reliable Data Transfer
 570
 571    - Multiple streams to help avoid head-of-line blocking
 572
 573    - Ordered and unordered data delivery on a per-stream basis
 574
 575    - Bundling and fragmentation of user data
 576
 577    - TCP friendly Congestion and flow control
 578
 579    - Support continuous monitoring of reachability
 580
 581    - Graceful termination of association
 582
 583    - Support of multi-homing for added reliability
 584
 585    - Some protection against blind denial-of-service attacks
 586
 587    - Some protection against blind masquerade attacks
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Coene                        Informational                     [Page 11]
 619 \f
 620 RFC 3257              SCTP Applicability Statement            April 2002
 621
 622
 623 8  Editor's Address
 624
 625    Lode Coene
 626    Siemens Atea
 627    Atealaan 34
 628    B-2200 Herentals
 629    Belgium
 630
 631    Phone: +32-14-252081
 632    EMail: lode.coene@siemens.atea.be
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Coene                        Informational                     [Page 12]
 675 \f
 676 RFC 3257              SCTP Applicability Statement            April 2002
 677
 678
 679 9.  Full Copyright Statement
 680
 681    Copyright (C) The Internet Society (2002).  All Rights Reserved.
 682
 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
 695    English.
 696
 697    The limited permissions granted above are perpetual and will not be
 698    revoked by the Internet Society or its successors or assigns.
 699
 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.
 706
 707 Acknowledgement
 708
 709    Funding for the RFC Editor function is currently provided by the
 710    Internet Society.
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Coene                        Informational                     [Page 13]
 731 \f