On Thu, 06 Aug 2009 06:51:24 +0000 Paul Vixie <vixie@isc.org> wrote:
Christopher Morrow <morrowc.lists@gmail.com> writes:
how does SCTP ensure against spoofed or reflected attacks?
there is no server side protocol control block required in SCTP. someone sends you a "create association" request, you send back a "ok, here's your cookie" and you're done until/unless they come back and say "ok, here's my cookie, and here's my DNS request." so a spoofer doesn't get a cookie and a reflector doesn't burden a server any more than a ddos would do.
because of the extra round trips nec'y to create an SCTP "association" (for which you can think, lightweight TCP-like session-like), it's going to be nec'y to leave associations in place between iterative caches and authority servers, and in place between stubs and iterative caches. however, because the state is mostly on the client side, a server with associations open to millions of clients at the same time is actually no big deal.
Am I missing something? The SCTP cookie guards against the equivalent of SYN-flooding attacks. The problem with SCTP is normal operations. A UDP DNS query today takes a message and a reply, with no (kernel) state created on the server end. For SCTP, it takes two round trips to set up the connection -- which includes kernel state -- followed by the query and reply, and tear-down. I confess that I don't remember the SCTP state diagram; in TCP, the side that closes first can end up in FIN-WAIT2 state, which is stable. That is, suppose the server -- the loaded party -- tries to shed kernel state by closing its DNS socket first. If the client goes away or is otherwise uncooperative, the server will then end up in FIN-WAIT2, in which case kernel memory is consumed "forever" by conforming server TCPs. Does SCTP have that problem? --Steve Bellovin, http://www.cs.columbia.edu/~smb