CISCO SUBNET

CORE NETWORKING AND

SECURITY
By Scott Hogg

About |

Scott Hogg is the CTO for Global Technology

Resources, Inc. (GTRI). Scott provides
network engineering, security consulting,
and training services to his clients.

What About Stream Control Transmission Protocol

(SCTP)?
What is SCTP and why are we not using it?
Network World | Apr 30, 2012 6:54 PM PT

Many in the networking industry may not be aware that SCTP exists and the benefits that it provides
end-to-end Internet communications. We use TCP over IP for most unicast communications and the
Internet is delivered over HTTP these days. SCTP is like TCP, but di erent. It is important to be aware
of SCTP, how it can be used and also understand why SCTP has not gained broader acceptance and
integration into more systems.
We are all familiar with the Internet Protocol (IP) and its 4-layer protocol suite that comprises of the
link layer, the internet layer, the transport layer, and the application layer. The internetworking layer
can use either IPv4 or IPv6 and can be used on top of numerous link layer technologies such as
Ethernet, PPP, SONET, Frame Relay, Fibre Channel, L2TP, FDDI, ARCNET, carrier pigeons, and even
social networks.
One of the first things everyone learns in a data communications class is the 7-layer OSI model and
the di erences between connection -oriented and connectionless protocols. Next, you learn about
the 4-layer IP stack and di erences between the transport-layer protocols Transmission Control
Protocol (TCP) and User Datagram Protocol (UDP). You then become familiar with UDP's
connectionless methods of carrying streams of data quickly and simply. You also start to know about
TCP's connection-oriented approach, its sliding window method to congestion control,
SYN/ACK/FIN/RST flags, and reliable stream delivery. However, few IT people are familiar with SCTP.
What is SCTP?

Stream Control Transmission Protocol (SCTP) is a transport-layer protocol that can be used on top
of IP networks for end-to-end communications. SCTP is an IETF standard developed by the
Transport Area Working Group (tsvwg). SCTP has been standardized by the IETF in a series of RFCs
that define the protocol, its applicability to other protocols, and its management. SCTP was
originally defined in RFC 2960 in October 2000, but was then updated with RFC 4960 in September
2007.
SCTP is similar to TCP in many ways. They are both unicast connection-oriented protocols that
provide reliable transport, in-sequence packet delivery and rate-adaptive congestion control. TCP
has an additive 16-bit checksum (RFC 1071) and SCTP has a 32-bit CRC (RFC 4960).
SCTP does provide some functions not found in TCP. SCTP is message-oriented whereas TCP is
stream-oriented. SCTP can handle multiple simultaneous streams and multiplexed streams where
TCP can handle only a single stream of data per connection. SCTP's stream-aware connection
control is one of its most notable features. SCTP also provides for multihoming in that the end
points can use multiple IP addresses for the connection. The SCTP connection endpoints can use IP
addresses from di erent ISPs for network-level fault tolerance. If, during the connection, one of
those ISPs were to fail, the connection would just use the IP address from the operational ISP for the
connections. Therefore, multihoming is supported without requiring the sites to have their own AS
number and run BGP.
SCTP may be more resistant to Man-In-The-Middle (MITM) and Denial of Service (DoS) attacks. SCTP
uses a cookie mechanism in the initial connection procedure (INIT ACK). SCTP doesn't allow for halfopen connections so it is more resilient to flooding, masquerade attacks.
SCTP also has many features that are similar to UDP. Both support unreliable transport and out-oforder packet delivery. SCTP does have a 12-byte header compared to UDP's 8-byte header, but that is
negligible when comparing performance between the protocols.
SCTP is able to do some things that UDP can't achieve. SCTP is able to deal with Path MTU Discovery
(PMTUD) and fragmentation. SCTP has connection detection and SCTP can detect dropped and
duplicated packets. Therefore, not every application is well suited to either TCP or UDP and SCTP
can provide the best of both TCP and UDP capabilities.
Happy Eyeballs and SCTP
Last year there was a great article in The IP Journal titled "Improving User Experience with IPv6 and
SCTP", by Dan Wing and Andrew Yourtchenko, Cisco Systems. This article described the concept of
happy eyeballs and how it can be applied to negotiating IPv4 or IPv6 connections and preferring IPv6
connections if possible. If IPv6 connectivity failed then applications should quickly fall back to using
IPv4. This article also described how applications should negotiate connections using either TCP of
SCTP and prefer SCTP when possible.
Happy Eyeballs techniques were integrated into Google Chrome, Mozilla Firefox, (not Microso
Internet Explorer) and Mac OS X Lion. Happy Eyeballs has been at the center of last year's World IPv6
Day and this year's World IPv6 Launch preparations.

The Happy Eyeballs dra changed and now that it is a full RFC (RFC 6555 - Happy Eyeballs: Success
with Dual-Stack Hosts) it does not address the SCTP negotiation. The SCTP portion of Happy
Eyeballs was then split o into a second dra . This dra describes the technique of a client
attempting to connect a server using SCTP and TCP and preferring SCTP communications if
possible. If more hosts followed this behavior, it would be easier to get SCTP used more o en.
SCTP Implementations
One of the key challenges with SCTP is that it required changes in the transport stack on the node.
The applications may need to be modified to use SCTP instead of TCP or UDP and be modified to
handle multiple simultaneous streams. SCTP is of no consequence to the routers along the
transport path because those routers are simply forwarding the IP packets based on the destination
address. The client and server applications need to be modified to handle the SCTP channel used
for end-to-end data exchange.
Because there are fewer implementation of SCTP than TCP deployments, it is easier to create a list of
SCTP implementations. Imagine how long the list of TCP-enabled applications would be. Following
are some descriptions of some of the implementations of SCTP.
The University of Delaware Protocol Engineering Laboratory (PEL) has an implementation of SCTP
within Firefox 3.0.11 and an SCTP patch for Mozilla. This group has worked on Apache over SCTP
and tcpdump support for SCTP. This group is also working on adapting Chrome to use SCTP in its
Chrome-SPDY over SCTP.
Wireshark and WinPcap can decode SCTP packets.
Cisco IOS 12.4T has support for SCTP Release 4.
You can use the "show sctp statistics" command or the older "show ip sctp statistics" command to
see if your network has forwarded any SCTP packets. NetFlow can export flows using SCTP using the
" ip flow-export destination sctp" command. The IPFlow NetFlow collector supports receiving those
flows using SCTP. In addition IPFIX also uses SCTP.
Many operating systems such as Linux (LKSCTP), Solaris 10, BSD (RivuS) have SCTP integrated into
their base operating systems by default or can have additional packages added to enable SCTP.
Microso does not support SCTP natively in its operating systems, but there is a SctpDrv Windows
library for SCTP connections.
There is a SCTP userspace/userland library (sctplib) that can run on multiple operating systems
There is a Java implementation of SCTP called OpenJDK: SCTP - SCTP Implementation.
The applications that derive the most benefit from the use of SCTP are in the voice and video
communications area. These come from the Sigtran and SS7 and SIP groups.
There is a Netbricks Sigtran stack.
There are also some systems that use Signaling System 7 that leverage SCTP.

OpenSS7
SS8 Networks
Ulticom
You can see that there are some implementations of SCTP, but SCTP is far from implemented
natively into every operating system and application.
Datagram Congestion Control Protocol (DCCP)
Similar to SCTP, many also are not aware that there is a fourth transport layer protocol that can be
used with IP. Datagram Congestion Control Protocol (DCCP) is another transport-layer connectionoriented protocol on top of IP. DCCP is defined in RFC 4340 by the IETF dccp working group.
There is a good table on Wikipedia that compares these transport-layer protocols and shows which
features each of them have.
DCCP is a relative new-comer to the list of IP transport protocols. Because it is newer, it has not been
widely used either for many of the same reasons SCTP has not been widely adopted.
So Why Aren't We Using SCTP?
If SCTP provides all these benefits, then why aren't we using it more o en?
The primary reason is that SCTP came a er TCP had already established itself as the common
connection-oriented protocol on top of IP. TCP had already taken hold and it is too embedded now
to be dethroned. Also, SCTP has not been promoted enough and not enough developers are aware
of its benefits or how to use it properly.
There is the problem that to add SCTP requires upgrading IP stacks and applications. Any
application that is written today to use TCP will need to be modified to work with SCTP. Rewriting the
world's applications is not practical. There are few server applications that support SCTP so there
are few client applications support SCTP. We have seen how di icult this has been for IPv6 adoption.
SCTP su ers from the same logjam as IPv6. Operating systems, applications, and network
equipment all needed to be upgraded to support IPv6 to enable it to work. SCTP only requires
applications and operating system support, but that is still a daunting task. Furthermore, few
content providers have IPv6-enabled their content so few end-users are making IPv6 connections.
Microso has also not integrated SCTP into their operating systems which has limited the use of
SCTP. Microso is not planning on integrating SCTP into Microso dot-Net framework because of
lack of customer demand. The fallacy to this logic is that customers are not asking for it because they
don't know that they need it. Microso should be smarter than its users, take the high-road, and
integrate it into their products.
Today most people access the Internet over HTTP from behind a NAT. The fact is that many middle
boxes and firewalls do not allow or are not programmed to work with SCTP. They only know about
keeping track of TCP connection state information. Many Intrusion Prevention Systems (IPSs) do not
inspect SCTP packets for attacks. The Cisco ASA firewalls can permit SCTP tra ic if you do it by

specifying the IP protocol as 132. Otherwise, SCTP cannot be specified in an access-list. You can
configure SCTP policies on a Juniper SRX or ScreenOS firewalls. There are numerous other
Sign In | Register
commercial-grade firewalls that don't support SCTP.

There are many examples in the IT world where the best ideas have not always gained wide
adoption. There are many examples of how the superior product lost out to a product that was more
visual appealing and marketed better. The same is true for networking protocols. Even though SCTP
may be superior to TCP and UDP in many ways, it has lost out to TCP because it was first-to-market
and, for the most part, works just fine.
Scott

Scott Hogg CTO, GTRI

Must read: Cisco CEO Robbins: Wait til you see whats in our innovation
pipeline

View Comments

YOU MIGHT LIKE

From the Web

The Best Indian Business

News For You

Ads by Revcontent

Business News You Can Use

Bloomberg Quint

Bloomberg Quint

Copyright 1994 - 2016 Network World, Inc. All rights reserved.

Bangalore Girl Gets 4

Shades Fairer in 14 Days by
Using This 1 Weird Old
Fit
Mom Daily
Trick!