DNS hardening, was Re: Dan Kaminsky

Sat Aug 8 02:41:05 UTC 2009

On Thu, 06 Aug 2009 06:51:24 +0000
Paul Vixie <vixie at isc.org> wrote:

> Christopher Morrow <morrowc.lists at 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