Jump to content

Stream Control Transmission Protocol: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
→‎Implementations: the source does not seem to be related to ssh implementation, and ssh source doesn't seem to know about implementation either
GreenC bot (talk | contribs)
Bots
2,144,822 edits
Rescued 1 archive link. Wayback Medic 2.5 per WP:URLREQ#Network World
 
(42 intermediate revisions by 32 users not shown)
Line 1: Line 1:
{{Short description|Computer network protocol}}
{{Short description|Computer network protocol}}
{{Infobox networking protocol
| title = Stream Control Transmission Protocol
| logo =
| logo alt =
| image =
| image alt =
| caption =
| is stack = yes
| abbreviation = SCTP
| purpose =
| developer =
| date = 2000
| based on =
| influenced =
| osilayer = [[Transport layer]] (4)
| rfcs = {{IETF RFC|9260}}
| hardware =
}}
{{IPstack}}
{{IPstack}}


The '''Stream Control Transmission Protocol''' ('''SCTP''') is a [[computer networking]] [[communications protocol]] which operates at the [[transport layer]] and serves a role similar to the popular protocols [[Transmission Control Protocol|TCP]] and [[User Datagram Protocol|UDP]]. It is standardized by [[IETF]] in {{IETF RFC|4960}}.
The '''Stream Control Transmission Protocol''' ('''SCTP''') is a [[computer networking]] [[communications protocol]] in the [[transport layer]] of the [[Internet protocol suite]]. Originally intended for [[Signaling System 7]] (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the [[User Datagram Protocol]] (UDP), while ensuring reliable, in-sequence transport of messages with [[TCP congestion control|congestion control]] like the [[Transmission Control Protocol]] (TCP). Unlike UDP and TCP, the protocol supports [[multihoming]] and redundant paths to increase resilience and reliability.


SCTP is standardized by the [[Internet Engineering Task Force]] (IETF) in {{IETF RFC|9260}}. The SCTP reference implementation was released as part of [[FreeBSD]] version 7, and has since been widely ported to other platforms.
SCTP provides some of the features of both UDP and TCP: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with [[TCP congestion control|congestion control]] like TCP. It differs from those protocols by providing multi-homing and redundant paths to increase resilience and reliability.

In the absence of native SCTP support in operating systems, it is possible to [[Tunneling protocol|tunnel]] SCTP over UDP,<ref>{{cite IETF |title=UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication |rfc=6951 | first = Michael | last = Tuexen | first2 = Randall R. | last2 = Stewart |date=May 2013 |publisher=[[Internet Engineering Task Force|IETF]]}}</ref> as well as to map TCP API calls to SCTP calls so existing applications can use SCTP without modification.<ref>
{{cite web
| url = http://www.cis.udel.edu/~amer/PEL/poc/pdf/EuroBSDCon2007-bickhart-SCTP-Shim-layer.pdf
| title = Transparent TCP-to-SCTP Translation Shim Layer
| first = Ryan | last = Bickhart |author2= Paul D. Amer
|author3= Randall R. Stewart
| year = 2007 | accessdate = 2008-09-13
}}
</ref>
The reference implementation was released as part of [[FreeBSD]] version 7. It has since been widely ported.


==Formal oversight==
==Formal oversight==
The [[IETF]] Signaling Transport ([[SIGTRAN]]) working group defined the protocol (number 132<ref>{{cite web |url= https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml |title= Protocol Numbers |website= iana.org |publisher= [[Internet Assigned Numbers Authority|IANA]] |accessdate= 2014-09-09}}</ref>) in the year 2000,<ref>{{cite IETF |title=Stream Control Transmission Protocol |rfc=2960 |date=October 2000|publisher=[[Internet Engineering Task Force|IETF]]}}</ref> and the IETF Transport Area (TSVWG) working group maintains it. {{IETF RFC|4960}} defines the protocol. {{IETF RFC|3286}} provides an introduction.
The [[IETF]] Signaling Transport ([[SIGTRAN]]) working group defined the protocol (number 132<ref>{{cite web |url= https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml |title= Protocol Numbers |website= iana.org |publisher= [[Internet Assigned Numbers Authority|IANA]] |access-date= 2014-09-09}}</ref>) in October 2000,<ref>{{cite IETF |title=Stream Control Transmission Protocol |rfc=2960 |date=October 2000|publisher=[[Internet Engineering Task Force|IETF]]}}</ref> and the IETF Transport Area (TSVWG) working group maintains it. {{IETF RFC|9260}} defines the protocol. {{IETF RFC|3286}} provides an introduction.


==Message-based multi-streaming==
==Message-based multi-streaming==
SCTP applications submit their data to be transmitted in messages (groups of bytes) to the SCTP transport layer. SCTP places messages and control information into separate ''chunks'' (data chunks and control chunks), each identified by a ''chunk header''. The protocol can fragment a message into a number of data chunks, but each data chunk contains data from only one user message. SCTP bundles the chunks into SCTP packets. The SCTP packet, which is submitted to the [[Internet Protocol]], consists of a packet header, SCTP control chunks (when necessary), followed by SCTP data chunks (when available).
SCTP applications submit data for transmission in messages (groups of bytes) to the SCTP transport layer. SCTP places messages and control information into separate ''chunks'' (data chunks and control chunks), each identified by a ''chunk header''. The protocol can fragment a message into multiple data chunks, but each data chunk contains data from only one user message. SCTP bundles the chunks into SCTP packets. The SCTP packet, which is submitted to the [[Internet Protocol]], consists of a packet header, SCTP control chunks (when necessary), followed by SCTP data chunks (when available).


One can characterize SCTP as message-oriented, meaning it transports a sequence of messages (each being a group of bytes), rather than transporting an unbroken stream of bytes as does TCP. As in UDP, in SCTP a sender sends a message in one operation, and that exact message is passed to the receiving application process in one operation. In contrast, TCP is a stream-oriented protocol, transporting [[byte stream|streams of bytes]] reliably and in order. However TCP does not allow the receiver to know how many times the sender application called on the TCP transport passing it groups of bytes to be sent out. At the sender, TCP simply appends more bytes to a queue of bytes waiting to go out over the network, rather than having to keep a queue of individual separate outbound messages which must be preserved as such.
SCTP may be characterized as message-oriented, meaning it transports a sequence of messages (each being a group of bytes), rather than transporting an unbroken stream of bytes as in TCP. As in UDP, in SCTP a sender sends a message in one operation, and that exact message is passed to the receiving application process in one operation. In contrast, TCP is a stream-oriented protocol, transporting [[byte stream|streams of bytes]] reliably and in order. However TCP does not allow the receiver to know how many times the sender application called on the TCP transport passing it groups of bytes to be sent out. At the sender, TCP simply appends more bytes to a queue of bytes waiting to go out over the network, rather than having to keep a queue of individual separate outbound messages which must be preserved as such.


The term ''multi-streaming'' refers to the capability of SCTP to transmit several independent streams of chunks in parallel, for example transmitting [[web page]] images together with the web page text. In essence, it involves bundling several connections into a single SCTP association, operating on messages (or chunks) rather than bytes.
The term ''multi-streaming'' refers to the capability of SCTP to transmit several independent streams of chunks in parallel, for example transmitting [[web page]] images simultaneously with the web page text. In essence, it involves bundling several connections into a single SCTP association, operating on messages (or chunks) rather than bytes.


TCP preserves byte order in the stream by including a byte sequence number with each [[TCP segment|segment]]. SCTP, on the other hand, assigns a sequence number or a message-id<ref group=note>The [[SCTP packet structure#DATA chunk|DATA chunk]] uses a sequence number for ordered messages, the [[SCTP packet structure#I-DATA chunk|I-DATA chunk]], which solves some problems with the original DATA chunk, uses a message-id for all messages</ref> to each ''message'' sent in a stream. This allows independent ordering of messages in different streams. However, message ordering is optional in SCTP; a receiving application may choose to process messages in the order of receipt instead of in the order of sending.
TCP preserves byte order in the stream by including a byte sequence number with each [[TCP segment|segment]]. SCTP, on the other hand, assigns a sequence number or a message-id<ref group=note>The [[SCTP packet structure#DATA chunk|DATA chunk]] uses a sequence number for ordered messages, the [[SCTP packet structure#I-DATA chunk|I-DATA chunk]], which solves some problems with the original DATA chunk, uses a message-id for all messages</ref> to each ''message'' sent in a stream. This allows independent ordering of messages in different streams. However, message ordering is optional in SCTP; a receiving application may choose to process messages in the order of receipt instead of in the order of sending.
Line 31: Line 38:
==Features==
==Features==
Features of SCTP include:
Features of SCTP include:
* Reliable transmission of both ordered and unordered data streams.
* Reliable transmission of both ordered and unordered data streams
* [[Multihoming]] support in which one or both endpoints of a connection can consist of more than one IP address, enabling transparent fail-over between redundant network paths.
* Multihoming support in which one or both endpoints of a connection can consist of more than one IP address, enabling transparent fail-over between redundant network paths
* Delivery of chunks within independent streams eliminates unnecessary [[head-of-line blocking]], as opposed to TCP byte-stream delivery.
* Delivery of chunks within independent streams eliminates unnecessary [[head-of-line blocking]], as opposed to TCP byte-stream delivery.
* Explicit partial reliability.
* Explicit partial reliability
* Path selection and monitoring to select a primary data transmission path and test the connectivity of the transmission path.
* Path selection and monitoring to select a primary data transmission path and test the connectivity of the transmission path
* Validation and acknowledgment mechanisms protect against flooding attacks and provide notification of duplicated or missing data chunks.
* Validation and acknowledgment mechanisms protect against [[SYN flood|flooding attacks]] and provide notification of duplicated or missing data chunks.
* Improved error detection suitable for [[jumbo frames|Ethernet jumbo frames]].
* Improved error detection suitable for [[jumbo frames|Ethernet jumbo frames]]


The designers of SCTP originally intended it for the transport of telephony ([[Signaling System 7]]) over Internet Protocol, with the goal of duplicating some of the reliability attributes of the SS7 signaling network in IP. This IETF effort is known as [[SIGTRAN]]. In the meantime, other uses have been proposed, for example, the [[Diameter (protocol)|Diameter]] protocol<ref>{{cite IETF |title=Diameter Base Protocol |rfc=3588 |sectionname=Transport |section=2.1 |publisher=[[Internet Engineering Task Force|IETF]] |accessdate=2012-05-18 }}</ref> and [[Reliable Server Pooling]] (RSerPool).<ref>{{cite IETF |title=An Overview of Reliable Server Pooling Protocols |rfc=5351 |sectionname=Example Scenario Using RSerPool Session Services |section=4.2 |page=10|publisher=[[Internet Engineering Task Force|IETF]]}}</ref>
The designers of SCTP originally intended it for the transport of telephony (i.e. Signaling System 7) over Internet Protocol, with the goal of duplicating some of the reliability attributes of the SS7 signaling network in IP. This IETF effort is known as [[SIGTRAN]]. In the meantime, other uses have been proposed, for example, the [[Diameter (protocol)|Diameter]] protocol<ref>{{cite IETF |title=Diameter Base Protocol |rfc=3588 |sectionname=Transport |section=2.1 |publisher=[[Internet Engineering Task Force|IETF]] |access-date=2012-05-18 }}</ref> and [[Reliable Server Pooling]] (RSerPool).<ref>{{cite IETF |title=An Overview of Reliable Server Pooling Protocols |rfc=5351 |sectionname=Example Scenario Using RSerPool Session Services |section=4.2 |page=10|publisher=[[Internet Engineering Task Force|IETF]]}}</ref>


==Motivations and adoption==
==Motivation and adoption==
TCP has provided the primary means to transfer data reliably across the Internet. However, TCP has imposed limitations on several applications. From {{IETF RFC|4960}}:
TCP has provided the primary means to transfer data reliably across the Internet. However, TCP has imposed limitations on several applications. From {{IETF RFC|4960}}:
* TCP provides both reliable data transfer and strict order-of-transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking property of TCP causes unnecessary delay.
* TCP provides both reliable data transfer and strict order-of-transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking property of TCP causes unnecessary delay.
* For applications exchanging distinct records or messages, the stream-oriented nature of TCP requires the addition of explicit markers or other encoding to delineate the individual records.
* For applications exchanging distinct records or messages, the stream-oriented nature of TCP requires the addition of explicit markers or other encoding to delineate the individual records.
* In order to avoid sending many small IP packets where one single larger packet would have sufficed, the TCP implementation may delay transmitting data while waiting for possibly more data being queued by the application ([[Nagle's algorithm]]). If and when such a small delay is undesirable, the application must explicitly request undelayed transmission on a case-by-case basis using the [http://seclists.org/webappsec/2005/q3/0351.html push facility] (i.e. by setting the PSH flag in the TCP packet header). SCTP on the other hand allows undelayed transmission to be configured as a default for an association, eliminating any undesired delays, but at the cost of higher transfer overhead.<ref>[https://tools.ietf.org/html/rfc4960#section-1.5.5 RFC 4960, section 1.5.5]</ref>
* In order to avoid sending many small IP packets where one single larger packet would have sufficed, the TCP implementation may delay transmitting data while waiting for possibly more data being queued by the application ([[Nagle's algorithm]]). If and when such a small delay is undesirable, the application must explicitly request undelayed transmission on a case-by-case basis using the [http://seclists.org/webappsec/2005/q3/0351.html push facility] (i.e. by setting the PSH flag in the TCP packet header). SCTP on the other hand allows undelayed transmission to be configured as a default for an association, eliminating any undesired delays, but at the cost of higher transfer overhead.<ref>[https://tools.ietf.org/html/rfc9260#section-1.5.5 RFC 9260, section 1.5.5]</ref>
* The limited scope{{vague|date=December 2017}} of TCP sockets complicates the task of providing highly-available data transfer capability using [[multihoming|multi-homed]] hosts.
* The limited scope{{vague|date=December 2017}} of TCP sockets complicates the task of providing highly-available data transfer capability using multihomed hosts.
* TCP is relatively vulnerable to denial-of-service attacks, such as [[SYN attack]]s.
* TCP is relatively vulnerable to denial-of-service attacks, such as [[SYN attack]]s.


Adoption has been slowed by lack of awareness, lack of implementations (particularly in Microsoft Windows), lack of application support and lack of network support.<ref>{{Cite news|url=http://www.networkworld.com/article/2222277/cisco-subnet/what-about-stream-control-transmission-protocol--sctp--.html|title=What About Stream Control Transmission Protocol (SCTP)?|last=Hogg|first=Scott|newspaper=Network World|access-date=2017-10-04}}</ref>
Adoption has been slowed by lack of awareness, lack of implementations (particularly in Microsoft Windows), lack of application support and lack of network support.<ref>{{Cite news|url=http://www.networkworld.com/article/2222277/cisco-subnet/what-about-stream-control-transmission-protocol--sctp--.html|archive-url=https://web.archive.org/web/20140830095541/http://www.networkworld.com/article/2222277/cisco-subnet/what-about-stream-control-transmission-protocol--sctp--.html|url-status=dead|archive-date=August 30, 2014|title=What About Stream Control Transmission Protocol (SCTP)?|last=Hogg|first=Scott|newspaper=Network World|access-date=2017-10-04}}</ref>

SCTP has seen adoption in the [[mobile telephony]] space as the transport protocol for several [[System_Architecture_Evolution#EPC protocol stack|core network interfaces]].<ref>{{cite book |last1=Olsson |first1=Magnus |last2=Mulligan |first2=Catherine |last3=Sultana |first3=Shabnam |last4=Rommer |first4=Stefan |last5=Frid |first5=Lars |title=EPC and 4G packet networks: driving the mobile broadband revolution |date=2013 |publisher=Elsevier/AP, Academic Press is an imprint of Elsevier |location=Amsterdam Boston |isbn=978-0-12-394595-2 |page=491 |edition=2nd}}</ref>

== Multihoming ==
{{multiple image
|direction = vertical
|width = 500
|image1 = SCTP-Multihoming.png
|caption1 = SCTP multihoming
|image2 = SCTP-LocalMultihoming-RemoteSinglehoming.png
|caption2 = Asymmetric multihoming: local multihoming to remote single homing
|image3 = SCTP-LocalSinglehoming-RemoteMultihoming.png
|caption3 = Asymmetric multihoming: local single homing to remote multihoming
}}


== Multi homing ==
SCTP provides redundant paths to increase reliability.
SCTP provides redundant paths to increase reliability.
[[File:SCTP-Multihoming.png|thumb|500px|SCTP Multihoming]]


Each SCTP end point needs to check reachability of the primary and redundant addresses of the remote end point using a [[Heartbeat (computing)|heartbeat]].
Each SCTP end point needs to check reachability of the primary and redundant addresses of the remote end point using a [[Heartbeat (computing)|heartbeat]]. Each SCTP end point needs to acknowledge the heartbeats it receives from the remote end point.
Each SCTP end point needs to acknowledge the heartbeats it receives from the remote end point.


When SCTP sends a message to a remote address, the source interface will only be decided by the routing table of the host (and not by SCTP).
When SCTP sends a message to a remote address, the source interface will only be decided by the routing table of the host (and not by SCTP).


In asymmetric multihoming, one of the two endpoints does not support multihoming.
=== Asymmetric multi homing ===
In asymmetric multi homing, one of the two end points does not support multi homing.

==== Local multi homing - Remote single homing ====
In Local multi homing and Remote single homing, if the remote primary address is not reachable, the SCTP association fails even if an alternate path is possible.
[[File:SCTP-LocalMultihoming-RemoteSinglehoming.png|thumb|500px|Asymmetric Multi homing : Local Multi homing - Remote Single homing]]


In local multihoming and remote single homing, if the remote primary address is not reachable, the SCTP association fails even if an alternate path is possible.
==== Local single homing - Remote multi homing ====
[[File:SCTP-LocalSinglehoming-RemoteMultihoming.png|thumb|500px|Asymmetric multi homing : Local Single homing - Remote multi homing]]


==Packet structure==
==Packet structure==
{{main|SCTP packet structure}}
{{Main|SCTP packet structure}}


An SCTP packet consists of two basic sections:
{| style="float:right; width:40%;"
# The ''common header'', which occupies the first 12 bytes and is highlighted in blue.
|-
# The ''data chunks'', which occupy the remaining portion of the packet. The first chunk is highlighted in green, and the last of ''N'' chunks (Chunk N) is highlighted in red.
|

{| class="wikitable" style="margin:0 auto; text-align:center; white-space:nowrap; white-space:nowrap;"
{| class="wikitable" style="text-align:center; white-space:nowrap; white-space:nowrap;"
|-
|-
! Bits
! Bits
! colspan="8" style="width:24%;"| 0–7
! colspan="8" width="25%" | 0–7
! colspan="8" style="width:24%;"| 8–15
! colspan="8" width="25%" | 8–15
! colspan="8" style="width:24%;"| 16–23
! colspan="8" width="25%" | 16–23
! colspan="8" style="width:24%;"| 24–31
! colspan="8" width="25%" | 24–31
|- style="background:#ddf;"
|- style="background:#ddf;"
!+0
!+0
Line 106: Line 119:
|- style="background:#fdd;"
|- style="background:#fdd;"
!…
!…
|style="text-align: center" colspan="8"|Chunk N type
|style="text-align: center" colspan="8"|Chunk ''N'' type
|style="text-align: center" colspan="8"|Chunk N flags
|style="text-align: center" colspan="8"|Chunk ''N'' flags
|colspan="16" style="text-align: center"|Chunk N length
|colspan="16" style="text-align: center"|Chunk ''N'' length
|- style="background:#fdd;"
|- style="background:#fdd;"
!…
!…
|colspan="32" style="text-align: center"|Chunk N data
|colspan="32" style="text-align: center"|Chunk ''N'' data
|}
|}
|}

An SCTP packet consists of two basic sections:
# The ''common header'', which occupies the first 12 bytes and is highlighted in blue, and
# The ''data chunks'', which occupy the remaining portion of the packet. The first chunk is highlighted in green, and the last of ''N'' chunks (Chunk N) is highlighted in red.


Each chunk starts with a one byte type identifier, with 15 chunk types defined by {{IETF RFC|4960}}, and at least 5 more defined by additional RFCs.<ref group=note>See [[SCTP packet structure]] for more details</ref> Eight flag bits, a two byte length field and the data compose the remainder of the chunk. If the chunk does not form a multiple of 4 bytes (i.e., the length is not a multiple of 4) then it is padded with zeros which are not included in the chunk length. The two byte length field limits each chunk to a 65,535 byte length (including the type, flags and length fields).
Each chunk starts with a one-byte type identifier, with 15 chunk types defined by {{IETF RFC|9260}}, and at least 5 more defined by additional RFCs.<ref group=note>See [[SCTP packet structure]] for more details.</ref> Eight flag bits, a two-byte length field, and the data compose the remainder of the chunk. If the chunk does not form a multiple of 4&nbsp;bytes (i.e., the length is not a multiple of 4), then it is padded with zeros, which are not included in the chunk length. The two-byte length field limits each chunk to a 65,535-byte length (including the type, flags and length fields).


==Security==
==Security==
Although encryption was not part of the original SCTP design, SCTP was designed with features for improved security, such as 4-way [[Handshaking|handshake]] (compared to [[Three-way handshake#Connection establishment|TCP 3-way handshake]]) to protect against [[SYN flood]]ing attacks, and large "cookies" for association verification and authenticity.
Although encryption was not part of the original SCTP design, SCTP was designed with features for improved security, such as 4-way [[Handshake (computing)|handshake]] (compared to [[Three-way handshake#Connection establishment|TCP 3-way handshake]]) to protect against [[SYN flood]]ing attacks, and large "cookies" for association verification and authenticity.


Reliability was also a key part of the security design of SCTP. [[Multihoming]] enables an association to stay open even when some routes and interfaces are down. This is of particular importance for [[SIGTRAN]] as it carries [[Signaling System 7|SS7]] over an IP network using SCTP, and requires strong resilience during link outages to maintain telecommunication service even when enduring network anomalies.
Reliability was also a key part of the security design of SCTP. Multihoming enables an association to stay open even when some routes and interfaces are down. This is of particular importance for [[SIGTRAN]] as it carries [[Signaling System 7|SS7]] over an IP network using SCTP, and requires strong resilience during link outages to maintain telecommunication service even when enduring network anomalies.


SCTP is sometimes a good [[OS fingerprinting|fingerprinting]] candidate. Some operating systems ship with SCTP support enabled, and, as it is not as well known as TCP or UDP, it is sometimes overlooked in firewall and intrusion detection configurations, thus often permitting probing traffic.
SCTP is sometimes a good [[TCP/IP stack fingerprinting|fingerprinting]] candidate. Some operating systems ship with SCTP support enabled, and, as it is not as well known as TCP or UDP, it is sometimes overlooked in firewall and intrusion detection configurations, thus often permitting probing traffic.


==Implementations==
==Implementations==
Line 133: Line 141:
|url = https://github.com/sctplab/sctp-refimpl
|url = https://github.com/sctplab/sctp-refimpl
|title = Reference Implementation for SCTP - RFC4960
|title = Reference Implementation for SCTP - RFC4960
|website = [[GitHub]]
|accessdate = 2013-10-14
|access-date = 2013-10-14
|quote = This is the reference implementation for SCTP. It is portable and runs on FreeBSD/MAC-OS/Windows and in User Space (including linux).
|quote = This is the reference implementation for SCTP. It is portable and runs on FreeBSD/MAC-OS/Windows and in User Space (including linux).
}}
}}
Line 141: Line 150:


* [[AIX operating system|AIX]] Version 5 and newer
* [[AIX operating system|AIX]] Version 5 and newer
* Generic [[BSD]] with external patch at [[KAME project]]
* [[NetBSD]]<ref name="NetBSD/sctp.h">{{cite web
* [[NetBSD]]<ref name="NetBSD/sctp.h">{{cite web
| url = http://bxr.su/n/sys/netinet/sctp.h
| url = http://bxr.su/n/sys/netinet/sctp.h
| title = sys/netinet/sctp.h
| title = sys/netinet/sctp.h
| publisher = [[NetBSD]] | website = BSD Cross Reference
| publisher = [[NetBSD]] | website = BSD Cross Reference
| date = 2017-06-27 | accessdate=2019-01-21
| date = 2017-06-27 | access-date=2019-01-21
}}</ref> since 8.0<ref name="NetBSD/sctp.4">{{cite web
}}</ref> since 8.0<ref name="NetBSD/sctp.4">{{cite web
| url = http://bxr.su/n/share/man/man4/sctp.4
| url = http://bxr.su/n/share/man/man4/sctp.4
| title = man4/sctp.4
| title = man4/sctp.4
| publisher = [[NetBSD]] | website = BSD Cross Reference
| publisher = [[NetBSD]] | website = BSD Cross Reference
| date = 2018-07-31 | accessdate=2019-01-21
| date = 2018-07-31 | access-date=2019-01-21
}}</ref>
}}</ref>
* [[Cisco IOS]] 12
* [[Cisco IOS]] 12 and above
* [[DragonFly BSD]] since version 1.4, however support is being deprecated in version 4.2 <ref name=DragonFlyBSD>{{cite web
* [[DragonFly BSD]] since version 1.4, however support is being deprecated in version 4.2 <ref name=DragonFlyBSD>{{cite web
| url = http://lists.dragonflybsd.org/pipermail/commits/2015-January/417496.html
| url = http://lists.dragonflybsd.org/pipermail/commits/2015-January/417496.html
| title = DragonFly Removes SCTP|website=Lists.dragonflybsd.org|accessdate=2016-04-28
| title = DragonFly Removes SCTP|website=Lists.dragonflybsd.org|access-date=2016-04-28
}}</ref>
}}</ref>
* [[FreeBSD]], version 7 and above, contains the reference SCTP implementation<ref name="freebsd7">{{cite web
* [[FreeBSD]], version 7 and above, contains the reference SCTP implementation<ref name="freebsd7">{{cite web
| url = //www.freebsd.org/features.html
| url = http://www.freebsd.org/features.html
| title = About FreeBSD's Technological Advances
| title = About FreeBSD's Technological Advances
| publisher = The FreeBSD Project | date = 2008-03-09 | accessdate = 2008-09-13
| publisher = The FreeBSD Project | date = 2008-03-09 | access-date = 2008-09-13
| quote = SCTP: FreeBSD 7.0 is the reference implementation for the new IETF Stream Control Transmission Protocol (SCTP) protocol, intended to support VoIP, telecommunications, and other applications with strong reliability and variable quality transmission through features such as multi-path delivery, fail-over, and multi-streaming.
| quote = SCTP: FreeBSD 7.0 is the reference implementation for the new IETF Stream Control Transmission Protocol (SCTP) protocol, intended to support VoIP, telecommunications, and other applications with strong reliability and variable quality transmission through features such as multi-path delivery, fail-over, and multi-streaming.
}}</ref>
}}</ref>
* [[HP-UX]], 11i v2 and above<ref>{{cite web
* [[HP-UX]], 11i v2 and above<ref>{{cite web
|url = http://h20293.www2.hp.com/portal/swdepot/displayInstallInfo.do?productNumber=SCTP
|url = http://h20293.www2.hp.com/portal/swdepot/displayInstallInfo.do?productNumber=SCTP
|archive-url = https://archive.is/20130103223740/http://h20293.www2.hp.com/portal/swdepot/displayInstallInfo.do?productNumber=SCTP
|archive-url = https://archive.today/20130103223740/http://h20293.www2.hp.com/portal/swdepot/displayInstallInfo.do?productNumber=SCTP
|url-status = dead
|url-status = dead
|archive-date = 2013-01-03
|archive-date = 2013-01-03
Line 172: Line 180:
|publisher = Hewlett-Packard Development Company
|publisher = Hewlett-Packard Development Company
}}</ref>
}}</ref>
* [[illumos]]
* [[Linux]] kernel-based 2.4 and newer
* [[Linux]] kernel 2.4 and above
* [[QNX]] Neutrino Realtime OS,<ref>{{cite web
* [[QNX]] Neutrino Realtime OS,<ref>{{cite web |title=TCP/IP Networking |url=http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/sys_arch/tcpip.html#SCTP |access-date=2008-09-13 |work=QNX Developer Support |publisher=QNX Software Systems}}{{cite web |title=What's New in this Reference |url=http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_lib_ref/whats_new.html |access-date=2012-12-18 |work=QNX Library Reference |publisher=QNX Software Systems}}</ref> 6.3.0 to 6.3.2, deprecated since 6.4.0<ref>{{cite web |title=QNX Software Development Platform 6.4.0 |url=http://www.qnx.com/developers/docs/660/index.jsp?topic=%2Fcom.qnx.doc.neutrino.utilities%2Ftopic%2Fwhats_new_64.html}}</ref>
| url = http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/sys_arch/tcpip.html#SCTP
* [[Tru64]] with the Compaq SCTP add-on package
| title = TCP/IP Networking | work = QNX Developer Support
| publisher = QNX Software Systems | accessdate = 2008-09-13
}}{{cite web
| url = http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_lib_ref/whats_new.html
| title = What's New in this Reference | work = QNX Library Reference
| publisher = QNX Software Systems | accessdate = 2012-12-18
}}</ref> 6.3.0 to 6.3.2, deprecated since 6.4.0<ref>{{cite web
|url=http://www.qnx.com/developers/docs/660/index.jsp?topic=%2Fcom.qnx.doc.neutrino.utilities%2Ftopic%2Fwhats_new_64.html
|title = QNX Software Development Platform 6.4.0}}</ref>
* Sun [[Solaris (operating system)|Solaris]] 10 and above<ref>{{cite web
* Sun [[Solaris (operating system)|Solaris]] 10 and above<ref>{{cite web
| url = http://www.sun.com/software/solaris/ds/network_performance.jsp#1
| url = http://www.sun.com/software/solaris/ds/network_performance.jsp#1
| title = Solaris 10 Operating System Networking — Extreme Network Performance
| title = Solaris 10 Operating System Networking — Extreme Network Performance
| publisher = [[Sun Microsystems]] | accessdate = 2008-09-13
| publisher = [[Sun Microsystems]] | access-date = 2008-09-13
}}</ref>
}}</ref>
* [[VxWorks]] versions 6.2.x to 6.4.x, and 6.7 and newer
* [[VxWorks]] versions 6.2.x to 6.4.x, and 6.7 and newer
* [[illumos]]


Third-party drivers:
Third-party drivers:
* [[Microsoft Windows]]:
* [[Microsoft Windows]]:
** The SctpDrv kernel driver is a port of the BSD SCTP stack to Windows<ref>{{cite web |url=http://www.bluestop.org/SctpDrv |archive-url=https://web.archive.org/web/20110108073234/http://www.bluestop.org/SctpDrv/ |url-status=dead |archive-date=2011-01-08 |title=SctpDrv: an SCTP driver for Microsoft Windows |accessdate=2011-02-04 }}</ref>
** The SctpDrv kernel driver is a port of the BSD SCTP stack to Windows (Abandoned after 2012)<ref>{{cite web |url=http://www.bluestop.org/SctpDrv |archive-url=https://web.archive.org/web/20171008083650/http://www.bluestop.org:80/SctpDrv/ |url-status=dead |archive-date=2017-10-08 |title=SctpDrv: an SCTP driver for Microsoft Windows |access-date=2022-01-04 }}</ref>
* [[MacOS]]:
* [[MacOS]]:
** SCTP Network Kernel Extension for Mac OS X<ref>{{cite web|url=https://github.com/sctplab/SCTP_NKE_ElCapitan |title=SCTP Network Kernel Extension for Mac OS X }}</ref>
** SCTP Network Kernel Extension for Mac OS X<ref>{{cite web|url=https://github.com/sctplab/SCTP_NKE_ElCapitan |title=SCTP Network Kernel Extension for Mac OS X |website=[[GitHub]] |date=23 September 2021 }}</ref>


[[User space|Userspace]] library:
[[User space|Userspace]] library:
* Portable SCTP userland stack<ref>https://github.com/sctplab/usrsctp</ref>
* Portable SCTP userland stack<ref>{{cite web |url=https://github.com/sctplab/usrsctp |title=sctplab/usrsctp |website=Github |access-date=21 September 2021 }}</ref>
* The SCTP library<ref>{{cite web|url=http://www.sctp.de/sctp-download.html |title=SCTP Download Page |date=2006-05-29 |accessdate=2011-02-04}}</ref>
* The SCTP library<ref>{{cite web|url=http://www.sctp.de/sctp-download.html |title=SCTP Download Page |date=2006-05-29 |access-date=2011-02-04}}</ref>
** [[Windows XP]] port<ref>{{cite web|url=http://www.sctp.be/sctplib/index.htm |title=Windows SCTP library installer |accessdate=2011-02-04}}</ref>
** [[Windows XP]] port<ref>{{cite web|url=http://www.sctp.be/sctplib/index.htm |title=Windows SCTP library installer |access-date=2011-02-04}}</ref>
* [[Java version history#Java SE 7|Oracle Java SE 7]]
* [[Erlang (programming language)|Erlang/OTP]]
* [[Erlang (programming language)|Erlang/OTP]]


The following applications implement SCTP:
The following applications implement SCTP:
* SSH - [[Secure Shell]].<ref>{{cite book|last=Seggelmann|first=R.|author2=Tuxen, M. |author3=Rathgeb, E.P. |title=SSH over SCTP — Optimizing a multi-channel protocol by adapting it to SCTP|journal=Communication Systems, Networks & Digital Signal Processing (CSNDSP), 2012 8th International Symposium on|date=18–20 July 2012|pages=1–6|doi=10.1109/CSNDSP.2012.6292659|isbn=978-1-4577-1473-3}}</ref>{{verify source|ssh}}
* [[WebRTC]]
* [[WebRTC]]
* [[NetFlow]]


==RFC history==
===Tunneling over UDP===
In the absence of native SCTP support in operating systems, it is possible to [[Tunneling protocol|tunnel]] SCTP over UDP,<ref>{{cite IETF |title=UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication |rfc=6951 | first = Michael | last = Tuexen | first2 = Randall R. | last2 = Stewart |date=May 2013 |publisher=[[Internet Engineering Task Force|IETF]]}}</ref> as well as to map TCP API calls to SCTP calls so existing applications can use SCTP without modification.<ref>
{{cite web
| url = http://www.cis.udel.edu/~amer/PEL/poc/pdf/EuroBSDCon2007-bickhart-SCTP-Shim-layer.pdf
| title = Transparent TCP-to-SCTP Translation Shim Layer
| first = Ryan | last = Bickhart |author2= Paul D. Amer
|author3= Randall R. Stewart
| year = 2007 | access-date = 2008-09-13
}}
</ref>

==RFCs==
* {{IETF RFC|9260}} Stream Control Transmission Protocol
* {{IETF RFC|8540}} Stream Control Transmission Protocol: Errata and Issues in RFC 4960 (obsoleted by RFC 9260)
* {{IETF RFC|7829}} SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
* {{IETF RFC|7829}} SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
* {{IETF RFC|7765}} TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
* {{IETF RFC|7765}} TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
* {{IETF RFC|7496}} Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension
* {{IETF RFC|7496}} Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension
* {{IETF RFC|7053}} SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (updates RFC 4960)
* {{IETF RFC|7053}} SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (obsoleted by RFC 9260)
* {{IETF RFC|6951}} UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
* {{IETF RFC|6951}} UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
* {{IETF RFC|6525}} Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
* {{IETF RFC|6525}} Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
* {{IETF RFC|6458}} Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)
* {{IETF RFC|6458}} Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)
* {{IETF RFC|6096}} Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (updates RFC 4960)
* {{IETF RFC|6096}} Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (obsoleted by RFC 9260)
* {{IETF RFC|5062}} Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures
* {{IETF RFC|5062}} Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures
* {{IETF RFC|5061}} Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
* {{IETF RFC|5061}} Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
* {{IETF RFC|5043}} Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
* {{IETF RFC|5043}} Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
* {{IETF RFC|4960}} Stream Control Transmission Protocol
* {{IETF RFC|4960}} Stream Control Transmission Protocol (obsoleted by RFC 9260)
* {{IETF RFC|4895}} Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
* {{IETF RFC|4895}} Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
* {{IETF RFC|4820}} Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)
* {{IETF RFC|4820}} Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)
* {{IETF RFC|4460}} Stream Control Transmission Protocol (SCTP) Specification Errata and Issues
* {{IETF RFC|4460}} Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (obsoleted by RFC 9260)
* {{IETF RFC|3873}} Stream Control Transmission Protocol (SCTP) [[Management Information Base]] (MIB)
* {{IETF RFC|3873}} Stream Control Transmission Protocol (SCTP) [[Management Information Base]] (MIB)
* {{IETF RFC|3758}} Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
* {{IETF RFC|3758}} Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
Line 234: Line 247:


==See also==
==See also==
* {{section link|Transport Layer|Comparison of transport layer protocols}}
* {{section link|Transport layer|Comparison of transport layer protocols}}
* [[Session Initiation Protocol]] (SIP) – which may initiate multiple streams over SCTP, TCP or UDP
* [[Session Initiation Protocol]] (SIP) – which may initiate multiple streams over SCTP, TCP, or UDP
* [[Multipath TCP]] – which allows a TCP connection to use multiple paths to maximize resource usage and increase redundancy
* [[Multipath TCP]] – which allows a TCP connection to use multiple paths to maximize resource usage and increase redundancy
* [[Happy Eyeballs]] – originally designed for efficient selection of IPv4 or IPv6 for a connection;<ref>{{Cite web|url=https://tools.ietf.org/html/rfc6555|title=Happy Eyeballs: Success with Dual-Stack Hosts|author=D. Wing|author2=A. Yourtchenko|date=April 2012|website=tools.ietf.org|publisher=[[IETF]]}}</ref> could also be adapted for selecting from different transport protocols, e.g.: TCP and SCTP<ref>{{Cite web|url=https://tools.ietf.org/html/draft-grinnemo-taps-he|title=Happy Eyeballs for Transport Selection|last=Khademi|first=Naeem|last2=Brunstrom|first2=Anna|date=July 21, 2016|website=tools.ietf.org|publisher=[[IETF]]|access-date=2017-01-09|last3=Hurtig|first3=Per|last4=Grinnemo|first4=Karl-Johan}}</ref>
* [[Happy Eyeballs]] – originally designed for efficient selection of IPv4 or IPv6 for a connection;<ref>{{Cite journal|url=https://tools.ietf.org/html/rfc6555|title=Happy Eyeballs: Success with Dual-Stack Hosts|author=D. Wing|author2=A. Yourtchenko|date=April 2012|website=tools.ietf.org|publisher=[[IETF]]}}</ref> could also be adapted to select from different transport protocols such as TCP and SCTP<ref>{{Cite web|url=https://tools.ietf.org/html/draft-grinnemo-taps-he|title=Happy Eyeballs for Transport Selection|last1=Khademi|first1=Naeem|last2=Brunstrom|first2=Anna|date=July 21, 2016|website=tools.ietf.org|publisher=[[IETF]]|access-date=2017-01-09|last3=Hurtig|first3=Per|last4=Grinnemo|first4=Karl-Johan}}</ref>


==Notes==
==Notes==
Line 247: Line 260:
==External links==
==External links==
* [https://web.archive.org/web/20131025214054/http://www.sigtran.ss7box.com/ sigtran (archived)]
* [https://web.archive.org/web/20131025214054/http://www.sigtran.ss7box.com/ sigtran (archived)]
* {{cite web | url = https://datatracker.ietf.org/wg/sigtran/about/ | title = Signaling Transport (sigtran) Working Group }}
* [https://web.archive.org/web/20050515080345/http://www.ietf.org/html.charters/sigtran-charter.html Ietf.org]
* {{cite web | url = https://datatracker.ietf.org/wg/tsvwg/about/ | title = Transport Area Working Group (tsvwg) }}
* [https://web.archive.org/web/20090201161053/http://www.ietf.org/html.charters/tsvwg-charter.html Ietf.org]
* [https://web.archive.org/web/20060206201712/http://www.openss7.org/ Openss7.org]
* {{cite web | title = OpenSS7 Project | url = http://www.openss7.org }}
* [http://www.lksctp.org SCTP workgroup for Linux]
* [http://www.lksctp.org SCTP workgroup for Linux]
* [http://www.sctp.de/ Michael Tüxen's SCTP Page]
* {{cite web | url = http://www.sctp.de/ | title = Michael Tüxen's SCTP Page }}
* [http://www.sctp.be/ Lode Coene's SCTP Page]
* {{cite web | url = http://www.sctp.be/ | title = Lode Coene's SCTP Page }}
* [https://www.uni-due.de/~be0001/sctp/ Thomas Dreibholz's SCTP Project Page]
* {{cite web | url = https://www.uni-due.de/~be0001/sctp/ | title = Thomas Dreibholz's SCTP Project Page }}

{{Authority control}}


[[Category:Computer-related introductions in 2000]]
[[Category:Streaming]]
[[Category:Streaming]]
[[Category:Internet Standards]]
[[Category:Internet Standards]]

Latest revision as of 20:03, 26 April 2024

Stream Control Transmission Protocol
Protocol stack
AbbreviationSCTP
Introduction2000
OSI layerTransport layer (4)
RFC(s)RFC 9260
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.

SCTP is standardized by the Internet Engineering Task Force (IETF) in RFC 9260. The SCTP reference implementation was released as part of FreeBSD version 7, and has since been widely ported to other platforms.

Formal oversight[edit]

The IETF Signaling Transport (SIGTRAN) working group defined the protocol (number 132[1]) in October 2000,[2] and the IETF Transport Area (TSVWG) working group maintains it. RFC 9260 defines the protocol. RFC 3286 provides an introduction.

Message-based multi-streaming[edit]

SCTP applications submit data for transmission in messages (groups of bytes) to the SCTP transport layer. SCTP places messages and control information into separate chunks (data chunks and control chunks), each identified by a chunk header. The protocol can fragment a message into multiple data chunks, but each data chunk contains data from only one user message. SCTP bundles the chunks into SCTP packets. The SCTP packet, which is submitted to the Internet Protocol, consists of a packet header, SCTP control chunks (when necessary), followed by SCTP data chunks (when available).

SCTP may be characterized as message-oriented, meaning it transports a sequence of messages (each being a group of bytes), rather than transporting an unbroken stream of bytes as in TCP. As in UDP, in SCTP a sender sends a message in one operation, and that exact message is passed to the receiving application process in one operation. In contrast, TCP is a stream-oriented protocol, transporting streams of bytes reliably and in order. However TCP does not allow the receiver to know how many times the sender application called on the TCP transport passing it groups of bytes to be sent out. At the sender, TCP simply appends more bytes to a queue of bytes waiting to go out over the network, rather than having to keep a queue of individual separate outbound messages which must be preserved as such.

The term multi-streaming refers to the capability of SCTP to transmit several independent streams of chunks in parallel, for example transmitting web page images simultaneously with the web page text. In essence, it involves bundling several connections into a single SCTP association, operating on messages (or chunks) rather than bytes.

TCP preserves byte order in the stream by including a byte sequence number with each segment. SCTP, on the other hand, assigns a sequence number or a message-id[note 1] to each message sent in a stream. This allows independent ordering of messages in different streams. However, message ordering is optional in SCTP; a receiving application may choose to process messages in the order of receipt instead of in the order of sending.

Features[edit]

Features of SCTP include:

  • Reliable transmission of both ordered and unordered data streams
  • Multihoming support in which one or both endpoints of a connection can consist of more than one IP address, enabling transparent fail-over between redundant network paths
  • Delivery of chunks within independent streams eliminates unnecessary head-of-line blocking, as opposed to TCP byte-stream delivery.
  • Explicit partial reliability
  • Path selection and monitoring to select a primary data transmission path and test the connectivity of the transmission path
  • Validation and acknowledgment mechanisms protect against flooding attacks and provide notification of duplicated or missing data chunks.
  • Improved error detection suitable for Ethernet jumbo frames

The designers of SCTP originally intended it for the transport of telephony (i.e. Signaling System 7) over Internet Protocol, with the goal of duplicating some of the reliability attributes of the SS7 signaling network in IP. This IETF effort is known as SIGTRAN. In the meantime, other uses have been proposed, for example, the Diameter protocol[3] and Reliable Server Pooling (RSerPool).[4]

Motivation and adoption[edit]

TCP has provided the primary means to transfer data reliably across the Internet. However, TCP has imposed limitations on several applications. From RFC 4960:

  • TCP provides both reliable data transfer and strict order-of-transmission delivery of data. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases, the head-of-line blocking property of TCP causes unnecessary delay.
  • For applications exchanging distinct records or messages, the stream-oriented nature of TCP requires the addition of explicit markers or other encoding to delineate the individual records.
  • In order to avoid sending many small IP packets where one single larger packet would have sufficed, the TCP implementation may delay transmitting data while waiting for possibly more data being queued by the application (Nagle's algorithm). If and when such a small delay is undesirable, the application must explicitly request undelayed transmission on a case-by-case basis using the push facility (i.e. by setting the PSH flag in the TCP packet header). SCTP on the other hand allows undelayed transmission to be configured as a default for an association, eliminating any undesired delays, but at the cost of higher transfer overhead.[5]
  • The limited scope[vague] of TCP sockets complicates the task of providing highly-available data transfer capability using multihomed hosts.
  • TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks.

Adoption has been slowed by lack of awareness, lack of implementations (particularly in Microsoft Windows), lack of application support and lack of network support.[6]

SCTP has seen adoption in the mobile telephony space as the transport protocol for several core network interfaces.[7]

Multihoming[edit]

SCTP multihoming
Asymmetric multihoming: local multihoming to remote single homing
Asymmetric multihoming: local single homing to remote multihoming

SCTP provides redundant paths to increase reliability.

Each SCTP end point needs to check reachability of the primary and redundant addresses of the remote end point using a heartbeat. Each SCTP end point needs to acknowledge the heartbeats it receives from the remote end point.

When SCTP sends a message to a remote address, the source interface will only be decided by the routing table of the host (and not by SCTP).

In asymmetric multihoming, one of the two endpoints does not support multihoming.

In local multihoming and remote single homing, if the remote primary address is not reachable, the SCTP association fails even if an alternate path is possible.

Packet structure[edit]

Main article: SCTP packet structure

An SCTP packet consists of two basic sections:

  1. The common header, which occupies the first 12 bytes and is highlighted in blue.
  2. The data chunks, which occupy the remaining portion of the packet. The first chunk is highlighted in green, and the last of N chunks (Chunk N) is highlighted in red.
Bits 0–7 8–15 16–23 24–31
+0 Source port Destination port
32 Verification tag
64 Checksum
96 Chunk 1 type Chunk 1 flags Chunk 1 length
128 Chunk 1 data
… …
… Chunk N type Chunk N flags Chunk N length
… Chunk N data

Each chunk starts with a one-byte type identifier, with 15 chunk types defined by RFC 9260, and at least 5 more defined by additional RFCs.[note 2] Eight flag bits, a two-byte length field, and the data compose the remainder of the chunk. If the chunk does not form a multiple of 4 bytes (i.e., the length is not a multiple of 4), then it is padded with zeros, which are not included in the chunk length. The two-byte length field limits each chunk to a 65,535-byte length (including the type, flags and length fields).

Security[edit]

Although encryption was not part of the original SCTP design, SCTP was designed with features for improved security, such as 4-way handshake (compared to TCP 3-way handshake) to protect against SYN flooding attacks, and large "cookies" for association verification and authenticity.

Reliability was also a key part of the security design of SCTP. Multihoming enables an association to stay open even when some routes and interfaces are down. This is of particular importance for SIGTRAN as it carries SS7 over an IP network using SCTP, and requires strong resilience during link outages to maintain telecommunication service even when enduring network anomalies.

SCTP is sometimes a good fingerprinting candidate. Some operating systems ship with SCTP support enabled, and, as it is not as well known as TCP or UDP, it is sometimes overlooked in firewall and intrusion detection configurations, thus often permitting probing traffic.

Implementations[edit]

The SCTP reference implementation runs on FreeBSD, Mac OS X, Microsoft Windows, and Linux.[8]

The following operating systems implement SCTP:

Third-party drivers:

  • Microsoft Windows:
    • The SctpDrv kernel driver is a port of the BSD SCTP stack to Windows (Abandoned after 2012)[17]
  • MacOS:
    • SCTP Network Kernel Extension for Mac OS X[18]

Userspace library:

The following applications implement SCTP:

Tunneling over UDP[edit]

In the absence of native SCTP support in operating systems, it is possible to tunnel SCTP over UDP,[22] as well as to map TCP API calls to SCTP calls so existing applications can use SCTP without modification.[23]

RFCs[edit]

  • RFC 9260 Stream Control Transmission Protocol
  • RFC 8540 Stream Control Transmission Protocol: Errata and Issues in RFC 4960 (obsoleted by RFC 9260)
  • RFC 7829 SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
  • RFC 7765 TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
  • RFC 7496 Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension
  • RFC 7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (obsoleted by RFC 9260)
  • RFC 6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
  • RFC 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
  • RFC 6458 Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)
  • RFC 6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (obsoleted by RFC 9260)
  • RFC 5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures
  • RFC 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
  • RFC 5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
  • RFC 4960 Stream Control Transmission Protocol (obsoleted by RFC 9260)
  • RFC 4895 Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
  • RFC 4820 Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)
  • RFC 4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (obsoleted by RFC 9260)
  • RFC 3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)
  • RFC 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
  • RFC 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
  • RFC 3436 Transport Layer Security over Stream Control Transmission Protocol
  • RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change (obsoleted by RFC 4960)
  • RFC 3286 An Introduction to the Stream Control Transmission Protocol
  • RFC 3257 Stream Control Transmission Protocol Applicability Statement
  • RFC 2960 Stream Control Transmission Protocol (updated by RFC 3309 and obsoleted by RFC 4960)

See also[edit]

Notes[edit]

  1. ^ The DATA chunk uses a sequence number for ordered messages, the I-DATA chunk, which solves some problems with the original DATA chunk, uses a message-id for all messages
  2. ^ See SCTP packet structure for more details.

References[edit]

  1. ^ "Protocol Numbers". iana.org. IANA. Retrieved 2014-09-09.
  2. ^ Stream Control Transmission Protocol. IETF. October 2000. doi:10.17487/RFC2960. RFC 2960.
  3. ^ "Transport". Diameter Base Protocol. IETF. sec. 2.1. doi:10.17487/RFC3588. RFC 3588. Retrieved 2012-05-18.
  4. ^ "Example Scenario Using RSerPool Session Services". An Overview of Reliable Server Pooling Protocols. IETF. p. 10. sec. 4.2. doi:10.17487/RFC5351. RFC 5351.
  5. ^ RFC 9260, section 1.5.5
  6. ^ Hogg, Scott. "What About Stream Control Transmission Protocol (SCTP)?". Network World. Archived from the original on August 30, 2014. Retrieved 2017-10-04.
  7. ^ Olsson, Magnus; Mulligan, Catherine; Sultana, Shabnam; Rommer, Stefan; Frid, Lars (2013). EPC and 4G packet networks: driving the mobile broadband revolution (2nd ed.). Amsterdam Boston: Elsevier/AP, Academic Press is an imprint of Elsevier. p. 491. ISBN 978-0-12-394595-2.
  8. ^ "Reference Implementation for SCTP - RFC4960". GitHub. Retrieved 2013-10-14. This is the reference implementation for SCTP. It is portable and runs on FreeBSD/MAC-OS/Windows and in User Space (including linux).
  9. ^ "sys/netinet/sctp.h". BSD Cross Reference. NetBSD. 2017-06-27. Retrieved 2019-01-21.
  10. ^ "man4/sctp.4". BSD Cross Reference. NetBSD. 2018-07-31. Retrieved 2019-01-21.
  11. ^ "DragonFly Removes SCTP". Lists.dragonflybsd.org. Retrieved 2016-04-28.
  12. ^ "About FreeBSD's Technological Advances". The FreeBSD Project. 2008-03-09. Retrieved 2008-09-13. SCTP: FreeBSD 7.0 is the reference implementation for the new IETF Stream Control Transmission Protocol (SCTP) protocol, intended to support VoIP, telecommunications, and other applications with strong reliability and variable quality transmission through features such as multi-path delivery, fail-over, and multi-streaming.
  13. ^ "Stream Control Transmission Protocol (SCTP)". Hewlett-Packard Development Company. Archived from the original on 2013-01-03.
  14. ^ "TCP/IP Networking". QNX Developer Support. QNX Software Systems. Retrieved 2008-09-13."What's New in this Reference". QNX Library Reference. QNX Software Systems. Retrieved 2012-12-18.
  15. ^ "QNX Software Development Platform 6.4.0".
  16. ^ "Solaris 10 Operating System Networking — Extreme Network Performance". Sun Microsystems. Retrieved 2008-09-13.
  17. ^ "SctpDrv: an SCTP driver for Microsoft Windows". Archived from the original on 2017-10-08. Retrieved 2022-01-04.
  18. ^ "SCTP Network Kernel Extension for Mac OS X". GitHub. 23 September 2021.
  19. ^ "sctplab/usrsctp". Github. Retrieved 21 September 2021.
  20. ^ "SCTP Download Page". 2006-05-29. Retrieved 2011-02-04.
  21. ^ "Windows SCTP library installer". Retrieved 2011-02-04.
  22. ^ Tuexen, Michael; Stewart, Randall R. (May 2013). UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication. IETF. doi:10.17487/RFC6951. RFC 6951.
  23. ^ Bickhart, Ryan; Paul D. Amer; Randall R. Stewart (2007). "Transparent TCP-to-SCTP Translation Shim Layer" (PDF). Retrieved 2008-09-13.
  24. ^ D. Wing; A. Yourtchenko (April 2012). "Happy Eyeballs: Success with Dual-Stack Hosts". tools.ietf.org. IETF.
  25. ^ Khademi, Naeem; Brunstrom, Anna; Hurtig, Per; Grinnemo, Karl-Johan (July 21, 2016). "Happy Eyeballs for Transport Selection". tools.ietf.org. IETF. Retrieved 2017-01-09.

External links[edit]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Stream_Control_Transmission_Protocol&oldid=1220930540"