Subject: [dnsext] Re: DNS hardening, was Re: Dan Kaminsky

From: Paul Vixie <[email-masked]>
Date: Thu, 06 Aug 2009 15:26:14 +0000

doug otis, paul vixie, and florian weimer splashed some SCTP over on nanog@
in the last 24 hours.  here's the interesting part, as i measure such things:

> Subject: Re: DNS hardening, was Re: Dan Kaminsky
> From: Florian Weimer <[email-masked]>
> Date: Thu, 06 Aug 2009 07:22:14 +0000
> 
> * Paul Vixie:
> 
> > there is no server side protocol control block required in SCTP.
> 
> SCTP needs per-peer state for congestion control and retransmission.
> 
> > 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.
> 
> This is a red herring.  The TCP state issues are deeper and haven't
> got much to do with source address validation.  The issues are mostly
> caused by how the BSD sockets API is designed.  SCTP uses the same API
> model, and suffers from similar problems.
> 
> > 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.
> 
> This doesn't seem possible with current SCTP because the heartbeat
> rate quickly adds up and overloads servers further upstream.  It also
> does not work on UNIX-like system where processes are short-lived and
> get a fresh stub resolver each time they are restarted.
> 
> -- 
> Florian Weimer                <[email-masked]>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstraße 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99

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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 08 Aug 2009 15:46:40 +0000

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" <[email-masked]>
> To: Paul Vixie <[email-masked]>
> Cc: [email-masked]
> 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 <[email-masked]> wrote:
> 
> > Christopher Morrow <[email-masked]> writes:
> > 
> > > how does SCTP ensure against spoofed or reflected attacks?
> > 
> > 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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 08 Aug 2009 15:45:26 +0000

there's one more after this, from steve bellovin, will be fwd'd in a moment.

> Newsgroups: gmane.org.operators.nanog
> Date: Thu, 06 Aug 2009 07:07:32 +0000
> Cc: [email-masked]
> To: Douglas Otis <[email-masked]>
> Archived-At: <http://permalink.gmane.org/gmane.org.operators.nanog/66869>
> 
> * Douglas Otis:
> 
> > Establishing SCTP as a preferred DNS transport offers a safe harbor
> > for major ISPs.
> 
> SCTP is not a suitable transport for DNS, for several reasons:
> 
> Existing SCTP stacks are not particularly robust (far less than TCP).
> The number of bugs still found in them is rather large.
> 
> Only very few stacks (if any) implement operation without kernel
> buffers.  The remaining ones are subject to the same state exhaustion
> attacks as TCP stacks are.
> 
> At least some parts of SCTP and the SCTP API were designed for a
> cooperative environment.
> 
> The SCTP API specification is very ambiguous, which is quite strange
> for such a young protocol.  For instance, it is not clear if a single
> socket is used to communicate with multiple peers, head-of-line
> blocking can occur.
> 
> The protocol has insufficient signalling to ensure that
> implementations turn off features which are harmful on a global scale.
> For instance, persistant authoritative <-> resolver connections only
> work if you switch off heartbeat, but the protocol cannot do this, and
> it is likely that many peers won't do it.
> 
> SCTP proposers generally counter these observations by referring to
> extensions and protocols which are not yet standardized, not
> implemented, or both, constantly moving the goalposts.
> 
> --

---

From: Doug Otis <[email-masked]>
Date: Sun, 09 Aug 2009 14:38:19 -0700

On 8/8/09 8:46 AM, Paul Vixie wrote:

>> query and reply, and tear-down.

There is info within initial exchanges (beyond that exchanged with TCP) 
that allows SCTP to be robust.  TCP transitions from Listen to SYN_RCVD 
send SYN ACK, ACK recv, Established. From SYN_RVCD, it might also send 
FIN, transition with recv ACK, and stick on FIN-WAIT2 for recv FIN.

>> I confess that I don't remember the

SCTP state diagram:
http://www.csm.ornl.gov/~dunigan/netperf/SCTPstate.png

TCP state diagram:
http://www.csm.ornl.gov/~dunigan/netperf/TCPstate.gif

SCTP goes from Closed, recv Cookie ECHO, Send Cookie ACK to Established. 
   Shutdown sent with Timer.  SCTP can transitions from any to state to 
Closed with Abort for any reason.  Minor state adjustments are handled 
by the Out-of-the-Blue (OOTB) routines.

RFC4460 provides SCTP errata and issue review.

As part of a long term strategy, the concept of allowing (somewhat) 
persistent SCTP DNS associations versus single transactions per TCP 
connection is to retain the low latency obtained with UDP, in that the 
next query might be bundled in a separate stream or issued within some 
period of time later.  Deciding when an association is to be shutdown 
should weigh the overhead of retaining associations and heartbeats, 
against establishing new associations.

SCTP DNS handled in this fashion should help eliminate spoofing between 
ISP recursive resolvers, and provide reliable transactions with 
authoritative name servers without extra ordinary provisioning.  SCTP 
HTTP should also help make web sites more impervious to DDoS attacks and 
various types of exploits.  Using SCTP with DNS should also ensure 
teething issues are quickly overcome.

Flood protections often put in place for TCP may block without verifying 
the source's involvement.  This means TCP can be globally flooded, or 
have sources selectively inhibited due to address spoofing.  In 
addition, as a result of DNSSEC response sizes, UDP responses may also 
imperil the networks reaching the addresses being spoofed.  SCTP 
eliminates these threats while demanding the least amount of additional 
resources.

SCTP multi-home feature work best within an IPv6 environment, however 
SCTP's use with DNS should also help ensure it works well with IPv4 as well.

-Doug

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Aug 2009 00:27:47 +0000

> Date: Sun, 09 Aug 2009 14:38:19 -0700
> From: Doug Otis <[email-masked]>
> 

actually steve bellovin wrote that not me.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 10 Aug 2009 09:03:59 -0700

On 8/9/09 5:27 PM, Paul Vixie wrote:
>> From: Doug Otis<[email-masked]>
>>

My apologies.  I should have started by saying Steve and not delete the 
line-

-Doug