As per Relevance of the word transport, we have this rfc below:
Network Working Group L.
Request for Comments: 3257
Category: Informational April 2002
Stream Control Transmission Protocol Applicability
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document describes the applicability of the Stream
Transmission Protocol (SCTP). It also contrasts SCTP with the
dominant transport protocols, User Datagram Protocol (UDP) &
Transmission Control Protocol (TCP), and gives some guidelines
when best to use SCTP and when not best to use SCTP
Table of
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
SCTP is a reliable transport protocol [RFC2960], which along with
[RFC793], RTP [RFC1889], and UDP [RFC768], provides transport-
services for upper layer protocols and services. UDP, RTP, TCP,
SCTP are currently the IETF standards-track transport-
protocols. Each protocol has a domain of applicability and
it provides, albeit with some overlaps
By clarifying the situations where the functionality of
protocols are applicable, this document can guide implementers
protocol designers in selecting which protocol to use
Special attention is given to services SCTP provides which would
a decision to use SCTP the right one
Major functions provided by SCTP can be found in Appendix A
1.1
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
adaptation layer, a session layer protocol, or the user
directly
Multihoming: Assigning more than one IP network interface to a
endpoint
2 Transport
2.1 TCP service
TCP is a connection-oriented (a.k.a., session-oriented)
protocol. This means that it requires both the establishment of
connection prior to the exchange of application data and a
tear-down to release system resources after the completion of
transfer
TCP is currently the most widely used connection-oriented
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;
- flow and congestion control
2.2 SCTP service
SCTP is also connection-oriented and provides all the
services that TCP provides. Many Internet applications
should find that either TCP or SCTP will meet their
requirements. Note, for applications conscious about
cost, there might be a difference in processing cost associated
running SCTP with only a single ordered stream and one address
in comparison to running TCP
However, SCTP has some additional capabilities that TCP lacks
This can make SCTP a better choice for some applications
environments
- multi-streams support
SCTP supports the delivery of multiple independent user
streams within a single SCTP association. This capability,
properly used, can alleviate the so-called head-of-line-
problem caused by the strict sequence delivery constraint imposed
the user data by TCP
This can be particularly useful for applications that need
exchange multiple, logically separate message streams between
endpoints
- multi-homing support
SCTP provides transparent support for communications between
endpoints of which one or both is multi-homed
SCTP provides monitoring of the reachability of the addresses on
remote endpoint and in the case of failure can transparently
from the primary address to an alternate address, without upper
intervention
Coene Informational [Page 3]
RFC 3257 SCTP Applicability Statement April 2002
This capability can be used to build redundant paths between two
endpoints and can be particularly useful for applications that
transport-level fault tolerance
Achieving path redundancy between two SCTP endpoints
requires that the two endpoints being equipped with
interfaces assigned with multiple addresses and that routing
configured appropriately (see Section 3).
- preservation of message boundaries
SCTP preserves application messages boundaries. This is useful
the application data is not a continuous byte stream but comes
logical chunks that the receiver handles separately
In contrast, TCP offers a reliable data stream that has no
of what an application may consider logical chunks of the data
- unordered reliable message delivery
SCTP supports the transportation of user messages that have
application-specified order, yet need guaranteed reliable delivery
Applications that need to send un-ordered reliable messages or
using their own message sequencing and ordering mechanisms may
this SCTP capability useful
2.3 UDP Service
UDP is connectionless. This means that applications that use UDP
not need to perform connection establishment or tear-down
As transport services to its upper layer, UDP provides only
- best-effort data delivery,
- preservation of message boundaries
Applications that do not require a reliable transfer of more than
packet's worth of data will find UDP adequate. Some transaction
based applications fall into this category
3 SCTP Multihoming
SCTP provides transport-layer support for multihoming.
has the potential of providing additional robustness against
failures. In some applications, this may be extremely important,
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
communication between two endpoints of which one or both is
with multiple IP addresses on possibly multiple network interfaces
It does NOT deal with communication ends that contain
endpoints (i.e., clustered endpoints) that can switch over to
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
interface for each endpoint. The number of paths used is the
of network interfaces used by any of the endpoints. When an
selects its source address, careful consideration must be taken.
the same source address is always used, then it is possible that
endpoint will be subject to the same single point of failure.
the endpoint chooses a source address, it should always select
source address of the packet to correspond to the IP address of
Network interface where the packet will be emitted subject to
binding address constraint. The binding address constraint is,
simply, that the endpoint must never choose a source address that
not part of the association i.e., the peer endpoint must
any source address used as being part of the association
The availability of the association will benefit greatly from
multiple addresses bound to the association endpoint when
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
available network addresses), the endpoint(s) behind the NAT
consider one of the following options
(1) When single homed sessions are to be used, no transport
should be sent in the INIT or INIT ACK chunk(Refer to section 3.3
RFC2960 for chunk definitions). This will force the endpoint
receives this initiation message to use the source address in the
header as the only destination address for this association.
method can be used for a NAT, but any multi-homing configuration
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
For multihoming the NAT must have a public IP address for
represented internal IP address. The host can preconfigure an
address that the NAT can substitute, or, the NAT can have
Application Layer Gateway (ALG) which will intelligently
the IP addresses in the INIT and INIT ACK chunks. See Figure 2.
If Network Address Port Translation is used with a multihomed
endpoint, then any port translation must be applied on a per
association basis such that an SCTP endpoint continues to receive
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
(2) Another alternative is to use the hostname feature and DNS
resolve the addresses. The hostname is included in the INIT of
association or in the INIT ACK. The hostname must be resolved by
before the association is completely set up. There are
issues regarding NAT and DNS, refer to RFC2694 for details
5 Security
In this section, some relevant security issues found in
deployment of the connection-oriented transport protocols will
discussed
5.1 Security issues with
Some TCP implementations have been known to be vulnerable to
denial of service attacks, i.e., attacks that had been executed by
attacker that could not see most of the traffic to or from the
host
Coene Informational [Page 6]
RFC 3257 SCTP Applicability Statement April 2002
The attacker would send a large number of connection
requests (TCP-SYN packets) to the attacked target, possibly
faked IP source addresses. The attacked host would reply by
SYN-ACK packets and entering SYN-received state, thereby
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
limit) and the host under attack would have to start turning down
connection establishment requests
TCP implementations with SYN-cookies algorithm [SYN-COOK] reduce
risk of such blind denial of service attacks. TCP
can switch to using this algorithm in times when their SYN-queues
filled up while still fully conforming to the TCP
[RFC793]. However, use of options such as a window scale [RFC1323],
is not possible, then. With the SYN-cookie mechanism, a TCB is
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.
guessing valid sequence numbers, an attacker would be able to forge
connection. However, with a secure hashsum algorithm, for some
the current SYN-cookie implementations the likelihood of
this attack is on the order of magnitude of 1 in 2^24, i.e.,
attacker would have to send 2^24 packets before obtaining one
connection when SYN-cookies are used
5.2 Security issues with
SCTP has been designed with the experiences made with TCP in mind
To make it hard for blind attackers (i.e., attackers that are
man-in-the-middle) to inject forged SCTP datagrams into
associations, each side of an SCTP association uses a 32 bit
called "Verification Tag" to ensure that a datagram really belongs
the existing association. So in addition to a combination of
and destination transport addresses that belong to an
association, a valid SCTP datagram must also have the correct tag
be accepted by the recipient
Unlike in TCP, usage of cookie in association establishment is
mandatory in SCTP. For the server, a new association is
established after three messages (containing INIT, INIT-ACK, COOKIE
ECHO chunks) have been exchanged. The cookie is a variable
parameter that contains all relevant data to initialize the TCB
the server side, plus a HMAC used to secure it. This HMAC (MD5
per [RFC1321] or SHA-1 [SHA1]) is computed over the cookie and
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
case a valid COOKIE-ECHO chunk is received by a client, and
computed HMAC for this new cookie matches that contained in
cookie
With SCTP the chances of an attacker being able to blindly forge
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
contained in the cookie, i.e., lower than 1 in 2^128 which for
practical purposes is negligible
It should be noted that SCTP only tries to increase the
of a network. SCTP does not contain any protocol mechanisms that
directly related to user message authentication, integrity
confidentiality functions. For such features, it depends on
IPsec protocols and architecture and/or on security features of
application protocols
Transport Layer security(TLS)[RFC2246] using SCTP must always
in-order streams
Currently the IPSEC working group is investigating the support
multi-homing by IPSEC protocols. At the present time to use IPSEC
one must use 2 * N * M security associations if one endpoint uses
addresses and the other M addresses
5.3 Security Issues with both TCP and
It is important to note that neither TCP nor SCTP protect itself
man-in-the-middle attacks where an established session might
hijacked (assuming the attacker can see the traffic from and
its own packets to either endpoints).
Also, to prevent blind connection/session setup forgery, both
implementations supporting SYN-cookies and SCTP implementations
on a server-known, secret key to protect the HMAC data. It must
ensured that this key is created subject to the
mentioned in [RFC1750].
Although SCTP has been designed carefully as to avoid some of
problems that have appeared with TCP, it has as of yet not
widely deployed. It is therefore possible that new security
will be identified that will have to be addressed in
revisions of [RFC2960].
Coene Informational [Page 8]
RFC 3257 SCTP Applicability Statement April 2002
6 References and related
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control
Protocol", RFC 2960, October 2000.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network
Translator (NAT) Terminology and Considerations",
2663, August 1999.
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A
Heffernan, "DNS extensions to Network Address
(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,
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",
2719, October 1999.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP
for High Performance", RFC 1323, May 1992.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "
Recommendations for Security", RFC 1750, December 1994.
[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard,"
Institute of Standards and Technology, U.S. Department
Commerce, April 1995.
[SYNCOOK] Dan J. Bernstein, SYN cookies, 1997, see
[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-
Applications", RFC 1889, January 1996.
7
This document was initially developed by a design team consisting
Lode Coene, John Loughney, Michel Tuexen, Randall R. Stewart
Qiaobing Xie, Matt Holdrege, Maria-Carmen Belinchon,
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
others for their invaluable comments
Coene Informational [Page 10]
RFC 3257 SCTP Applicability Statement April 2002
Appendix A: Major functions provided by
- Reliable Data
- Multiple streams to help avoid head-of-line
- Ordered and unordered data delivery on a per-stream
- Bundling and fragmentation of user
- TCP friendly Congestion and flow
- Support continuous monitoring of
- Graceful termination of
- Support of multi-homing for added
- Some protection against blind denial-of-service
- Some protection against blind masquerade
Coene Informational [Page 11]
RFC 3257 SCTP Applicability Statement April 2002
8 Editor's
Lode
Siemens
Atealaan 34
B-2200
Phone: +32-14-252081
EMail: lode.coene@siemens.atea.
Coene Informational [Page 12]
RFC 3257 SCTP Applicability Statement April 2002
9. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Coene Informational [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
