[dnsext] SCTP trials on NANOG, 3 of 3 (Re: DNS hardening)

[Paul Vixie <[e-mail]>]

i'm fwd'ing these here to be sure that protocol people and not just ops
people have a chance to see and hear what's being said and asked re: SCTP.

> Date: Fri, 7 Aug 2009 22:41:05 -0400
> From: "Steven M. Bellovin" <[e-mail]>
> To: Paul Vixie <[e-mail]>
> Cc: [e-mail]
> Subject: Re: DNS hardening, was Re: Dan Kaminsky
> Organization: Columbia University
> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.16.0; x86_64--netbsd)
> 
> On Thu, 06 Aug 2009 06:51:24 +0000
> Paul Vixie <[e-mail]> wrote:
> 
> > Christopher Morrow <[e-mail]> 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

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>