SCTP Is Not a SPDY Alternative

‹prev | My Chain | next›

I got started with researching SCTP as a SPDY alternative. I was pleasantly surprised to find how easy it was to set up a test server running on SCTP and send packets to it—even over my home network.

As was correctly pointed out in the comments to yesterday's work, SCTP is not a legitimate threat to compete with SPDY because, although it runs on IP in the TCP/IP stack, it does not work with NAT. Since most of the world runs behind NAT at some level, SCTP proper is dead on arrival.

There is an IETF proposal to run SCTP over UDP, which would allow it to work with NAT. As far as I can tell there are no reference implementations for doing something like this.

I am left incredibly angry at having wasted two days worth of work. Let me be clear here. I have nothing but respect for the folks behind SCTP. It seems quite successful in the telephony field and was pretty cool to play with. My anger is aimed at people who themselves demonstrate vitriol at Google for implementing SPDY without trying SCTP.

SCTP is simply not a viable alternative.

That said, I would like to have one last look at SCTP from a security standpoint. This is mostly for my own edification as SPDY does not add anything at the transport or internet layer like SCTP does (SPDY is an application layer protocol, after all).

Rather than re-use the lk-sctp sample app from last night, I give the sample code in the excellent SCTP article over on IBM Developer Works site a whirl.

After installing lk-sctp-dev on my Ubuntu machine, I can compile the daytime sample app:

➜  sctp  make
gcc -Wall   -c -o sctpclnt.o sctpclnt.c
gcc -Wall -o sctpclnt sctpclnt.c -L/usr/local/lib -lsctp
gcc -Wall   -c -o sctpsrvr.o sctpsrvr.c
sctpsrvr.c: In function ‘main’:
sctpsrvr.c:56:44: warning: pointer targets in passing argument 3 of ‘accept’ differ in signedness
/usr/include/sys/socket.h:214:12: note: expected ‘socklen_t * __restrict__’ but argument is of type ‘int *’
gcc -Wall -o sctpsrvr sctpsrvr.c -L/usr/local/lib -lsctp
sctpsrvr.c: In function ‘main’:
sctpsrvr.c:56:44: warning: pointer targets in passing argument 3 of ‘accept’ differ in signedness
/usr/include/sys/socket.h:214:12: note: expected ‘socklen_t * __restrict__’ but argument is of type ‘int *’

Despite the warnings, it did compile successfully and I am left with two executables: sctpclnt and sctpsrvr.

In one terminal, I run the server:

➜  sctp  ./sctpsrvr
Awaiting a new connection

In another terminal I start up the client:

➜  sctp  ./sctpclnt
assoc id  = 13
state     = 4
instrms   = 5
outstrms  = 5
(Local) Sat Jul  9 23:34:35 2011


(Local) Sat Jul  9 23:34:35 2011

Nice. Again, this just works. The article over on Developer Works does a nice job of explaining the code itself and some of the socket programming behind it. For now, I am more interested in the security of the four way handshake:



Unlike TCP/IP, which allocates resources to a stream upon initial receipt of a SYN packet, SCTP streams do not allocated resources that cookie, set in the previous INIT_ACK packet, is echoed back. No SYN attacks here, thank you very much. Simple and elegant.

I like what I have seen of SCTP so far. Just not as a competitor to SPDY.

Day #70