What About Stream Control Transmission Protocol (SCTP)? (original) (raw)

Analysis

Apr 30, 201210 mins

Cisco SystemsEnterprise ApplicationsNetworking

What is SCTP and why are we not using it?

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 different. 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 differences between connection -oriented and connectionless protocols. Next, you learn about the 4-layer IP stack and differences 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 different 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 half-open 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-of-order 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 Microsoft 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 draft 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 off into a second draft. This draft 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 often.

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.

Microsoft 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 connection-oriented 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 often?

The primary reason is that SCTP came after 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 difficult this has been for IPv6 adoption. SCTP suffers 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.

Microsoft has also not integrated SCTP into their operating systems which has limited the use of SCTP. Microsoft is not planning on integrating SCTP into Microsoft 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. Microsoft 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 traffic 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 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

SUBSCRIBE TO OUR NEWSLETTER

From our editors straight to your inbox

Get started by entering your email address below.

scott_hogg

Scott Hogg is an Internet Protocol version 6 (IPv6) consultant and teacher. Scott is a CCIE #5133 (Emeritus) and CISSP #4610 with over 30 years of network and security experience. Scott is Chair Emeritus of the Rocky Mountain IPv6 Task Force (RMv6TF), a member of the Infoblox IPv6 Center of Excellence (COE), and co-author of the Cisco Press book on IPv6 Security. Scott is president of Hogg Networking.