< draft-ietf-sigtran-sctp-applicability-07.txt		draft-ietf-sigtran-sctp-applicability-08.txt >
	INTERNET-DRAFT L. Coene(Editor)		A new Request for Comments is now available in online RFC libraries.
	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.
	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.
	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.
	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
	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
	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.
	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.
	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.
	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.
	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.
	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
	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		RFC 3257
	Draft Informational October 2001		Title: Stream Control Transmission Protocol Applicability
			Statement
			Author(s): L. Coene
			Status: Informational
			Date: April 2002
			Mailbox: lode.coene@siemens.atea.be
			Pages: 13
			Characters: 24198
			Updates/Obsoletes/SeeAlso: None
	- Reliable Data Transfer		I-D Tag: draft-ietf-sigtran-sctp-applicability-08.txt
	- Multiple streams to help avoid head-of-line blocking		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3257.txt
	- Ordered and unordered data delivery on a per-stream basis		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.
	- Bundling and fragmentation of user data		This document is a product of the Signaling Transport Working Group of
			the IETF.
	- TCP friendly Congestion and flow control		This memo provides information for the Internet community. It does
			not specify an Internet standard of any kind. Distribution of this
			memo is unlimited.
	- Support continuous monitoring of reachability		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	- Graceful termination of association		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	- Support of multi-homing for added reliability		To: rfc-info@RFC-EDITOR.ORG
			Subject: getting rfcs
	- Some protection against blind denial-of-service attacks		help: ways_to_get_rfcs
	- Some protection against blind masquerade attacks		Requests for special distribution should be addressed to either the
			author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 13 change blocks.
	567 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/