Better Networking with SCTP 233
5-0 writes to tell us that IBM DeveloperWorks has an interesting look at the key features of SCTP in the Linux 2.6 kernel and the ability to deliver multi-streaming. "SCTP is a reliable, general-purpose transport layer protocol for use on IP networks. While the protocol was originally designed for telephony signaling, SCTP provided an added bonus -- it solved some of the limitations of TCP while borrowing beneficial features of UDP. SCTP provides features for high availability, increased reliability, and improved security for socket initiation."
Goodbye TCP? (Score:3, Insightful)
Really?
Re:Goodbye TCP? (Score:4, Insightful)
Re:INIT floods (Score:5, Insightful)
Flooding using the flooder's true address will still work, but it is trivial to block. Sure, having 100000 zombies flood a single destination will put quite a burden and will force the floodee to maintain a huge list of banned addresses, but, a single hash table on the router will alleviate anything except for bandwidth wasted.
This is same as a full TCP connect() flood.
There is a TCP hack named "syn cookies", but this doesn't work very well as TCP wasn't designed to be resistant to SYN floods.
Re:How long... (Score:5, Insightful)
And no overzealous firewalls on the way.
Re:INIT floods (Score:5, Insightful)
SCTP protects against this type of attack through a four-way handshake and the introduction of a cookie. In SCTP, a client initiates a connection with an INIT packet. The server responds with an INIT-ACK, which includes the cookie (a unique context identifying this proposed connection). The client then responds with a COOKIE-ECHO, which contains the cookie sent by the server. At this point, the server allocates the resource for the connection and acknowledges this by sending a COOKIE-ACK to the client.
Funny how things suddenly makes sense when you read the entire paragraph.
Re:Cool thing (Score:2, Insightful)
What for? Could you give a specific example of an application where such a protocol would be needed? (That is where using TCP or UDP would require a severe overhead in the application layer.)
If you have always wanted such a protocol, you certainly must have had a specific use in mind.
read the RFC (Score:4, Insightful)
I will grant SCTP does some neet stuff, the best is that it allows independent non-mutually-blocking streams over one connection. It also has state cookies, yum.
SCTP tries to be all things to all people in one protocol. It reads as though they just decided the whole layered protocol thing was overrated and shoved every new feature into this one layer.
Re:SCTP vs TCP benchmarks (Score:2, Insightful)
I think the point is to use what you have more effeciently, if real "bandwidth" is measured as the transfer rate of actual payload from point A to point B, then using it more effeciently (less overhead) does actually increase "bandwidth", not magic but it does allow me to go "faster" than I can without utilizing those more effecient technique(s).
Re:4-way handshake (Score:3, Insightful)
Re:Overzealous security admins (Score:2, Insightful)
What sucks is when some pompous asshat says "no, I can't provide you with a mechanism to accept incoming connections" or "no, you can't open an outgoing ssh connection".
I feel your pain, however I've found that it makes sense use a simple formula when evaluating an end user request to allow XYZ traffic to traverse a firewall(s) on my organizations network, 1. Is there a business need for it or is it just a user saying "oh this would be nice to have" 2. Is there a more secure and/or functional way to accomplish what the user needs to do? 3. Am I going to open up my network to significant security risks if I do this? do those risks outweigh the business need?
Characterizing any admin that says to you "no you can't traverse the company firewalls with XYZ traffic because doing so represents a significant security risk to the company network" as a "pompous asshat" is a bit unfair don't you think? perhaps you should attempt to look at it from the "pompous asshats" point of view and ponder what your response would be if the positions were reversed, if your answer is "well I'd let any traffic that any user asks for to traverse my firewalls" then there's a very good reason you're not the one making the determination what crosses company firewalls.
No, but if you were an ISP... (Score:3, Insightful)
However if you were an ISP, tasked assumedly with providing connectivity to your customers, and did something similar, then yes, you would be, in my opinion. And there are a fair number of really crummy ISPs who, for one specious reason or another, block various ports and protocols.
And perhaps most unfortunately of all, it's quite common for these ISPs to have regional broadband monopolies, so that a customer doesn't really have the option of just dropping them and switching to a provider that doesn't suck so badly.
kitchen sink (Score:3, Insightful)
For example, manually opening multiple connections through different interfaces and then having the SCTP implementation figure out which one to send through is nonsense; if the system has multiple routes to the Internet, then that can be taken care of at the IP level.
Similarly, preservation of write boundaries is a useless gimmick that is rarely needed, and when it is needed, can be easily implemented in user code.
The four-way handshake during setup is possibly useful, but you can trivially get the same with TCP in a backwards compatible fashion if you configure your kernel to protect against SYN spoofing.
Altogether, I'm not quite sure what problem SCTP is supposed to solve. SCTP has made its way into some other standards, so it will probably be unavoidable, but it's not a well-designed protocol in my opinion.
Re:Does this matter with TCP/IP offload and iWarp? (Score:3, Insightful)
-Ack