On Thu, 06 Aug 2009 06:51:24 +0000
Paul Vixie <vi...@isc.org> wrote:
> Christopher Morrow <morrowc.li...@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
