nanog mailing list archives

Re: DNS hardening, was Re: Dan Kaminsky


From: "Steven M. Bellovin" <smb () cs columbia edu>
Date: Fri, 7 Aug 2009 22:41:05 -0400

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


Current thread: