
Better networking with SCTP - vinutheraj
http://www.ibm.com/developerworks/linux/library/l-sctp/?ca=dgr-lnxw07SCTP
======
tptacek
SCTP does two things that I think are hugely important.

First, it provides a datagram/record transport that is TCP-friendly. The most
important thing TCP does isn't reliability; it's the insanely complicated
interpretive dance it performs with other TCPs to keep them from melting the
network. Right now, your only scalable transport option is TCP, which means
you're boned if you want real-time.

Second, it provides reliable out-of-order delivery, which is exactly the happy
medium that I assert without evidence 99% of UDP apps actually need.
Reliability good. Enforced ordered delivery bad; means updates lag behind
stale data.

The big issue with SCTP is that firewalls will block it.

~~~
dkersten
I recently learned about SCTP because I had to write a SIGTRAN interface for
work.

SCTP is interesting to me because it offers choice:

\- Do I want reliable or unreliable?

\- Do I want ordered or unordered?

\- Do I want multiple streams per connection?

\- Do I want multi homing?

And a few other benefits:

\- Resistant to SYN attacks

\- Proper shutdown procedure/no half open connections

IMHO, it IS the superior protocol. Obviously since its not widespread, it
won't work too well for some things yet.

~~~
tptacek
Meh. SYN floods are pretty much a solved problem. Try to take something behind
an F5 offline, for the simplest example.

I agree that, on paper, it's a more useful protocol. Remember though that TCP
is about the congestion control algorithm. The rest of what TCP does is
trivial.

~~~
dkersten
You're right, of course. They each have their uses. I still think SCTP has
more potential though, but I'm not able to back that up, so whatever :-P

~~~
tptacek
Not trying to shoot you down FWIW, just trying to dispel the myth of the TCP
SYN flood. You'd be surprised how many otherwise very savvy clients ask us
about them.

~~~
dkersten
I'm actually not terribly familiar with how they work, so no worries! I'm
happy to be corrected.

------
agnokapathetic
Not questioning the OP's intentions, but a remote vulnerability in most SCTP
stacks was published last week: <http://pastebin.com/m6863ef05> CVE-2009-0065

~~~
tptacek
This is a vulnerability in one SCTP stack. Linux's. I'm not sure there's a
single mainstream protocol that hasn't had a vulnerability.

~~~
agnokapathetic
Its not every day you see remote code execution exploit of a _Transport_ layer
protocol, and what OS do you think people are going to be toying around with
SCTP... Linux. This is serious.

edit: needed to review the OSI model.

~~~
tptacek
WTF do I care if the protocol you broke was transport layer or application
layer? Code execution is code execution. What a strange argument.

~~~
mmelin
Simply because a vulnerability in the transport layer results in every service
relying on that protocol to be vulnerable? Are you saying that a remote code
execution vulnerability in TCP would not be worse than one in for instance
FTP?

(I am aware of your credentials so I'm trying to figure out what I'm missing,
not trying to be snippy)

~~~
tptacek
Ok. Fair point. TCP would be worse than FTP, because you could hit it from
ports 21, 22, 80, and 443.

FTP would be far worse than SCTP, because you're much more likely to be using
it.

I'll admit, my mind jumped immediately to "vulnerability in the kernel! much
worse than vulnerability in a web server!", which is exactly the wrong way to
think about the problem --- once you've conceded code execution to an
attacker, you've conceded the box.

Maybe that wasn't his argument. Thanks for calling me out on that.

Either way, the Linux advisory he cited should have absolutely no impact on
your consideration of SCTP.

------
scythe
"Since then, it has found its way into all major operating systems, including
GNU/Linux, BSD, and Solaris. It's also available for the Microsoft® Windows®
operating systems as a third-party commercial package."

I don't think that you can really exclude Windows from the category "major
operating systems". It might not be your favorite operating system (it
certainly isn't mine), but give the devil his due.

------
ajb
What would be really cool would be a sctp option for vnc. When you're working
on a poor connection, it's really annoying when vnc becomes blocked waiting
for some rectangle to be retransmitted, when it could perfectly well keep
going updating the other rectangles.

------
planckscnst
Would it be ideal for HTTP to be delivered over SCTP instead of TCP? If so,
how the heck can the internet migrate over to SCTP?

~~~
olefoo
If nothing else, it's possible to tunnel tcp over sctp. But you could write a
webserver that delivered HTTP messages over sctp directly. In fact that would
make a good research project for someone. And it would likely be useful, if
only for the sheer amount of stuff that uses HTTP as a transport. The thing is
that as an asynchronous protocol HTTP doesn't get that much benefit from being
delivered over sctp whereas protocols that depend on continuous session state
like ssh or XMPP or VOIP streams would potentially gain much more.

~~~
noss
I think it could be useful for a reverse proxy when talking with the backends.
SCTP would be contained to your LAN traffic so adoption on the open internet &
firewalls is a non-issue, and you get some benefits from avoiding head of line
blocking. Possibly. Discuss below! :)

