Subject: [dnsext] Inherent stickyness: WGLC draft-ietf-dnsext-dns-tcp-requirements

From: William Allen Simpson <[email-masked]>
Date: Mon, 22 Feb 2010 16:18:53 -0500

I'm starting a new thread, because I feel like this is being overlooked.

DNS over UDP is flexible.  If the first try doesn't work quickly enough,
we just try another server.  Everybody is required to have at least two
servers per domain.

DNS over TCP is sticky.  If we found the server with UDP, we *have* to
assume that it accepts TCP.  If it doesn't respond, we wait at least 3
minutes (according to RFC 1123) before giving up and trying another.
That's much too long for practical purposes.

So, here my proposed revision of Brian's list of actions -- a resource
starved TCP server should:

(a) Support SYN cookies.  This will kick in as congestion occurs.  Many
     stacks have support these daya, so this is not a stretch.

(b) Reap idle TCBs gracefully (FIN), starting with those with smallest
     RTT's observed.  Local traffic can recover most quickly.

(c) Delete unacked SYN TCBs, oldest first.  Old SYNs currently require
     at least 360 seconds; the least pain will be felt by local traffic.

(d) Ungraceful reaping -- no RST, toss the TCB, *longest* RTT first.
     Any outstanding traffic will generate RST as it arrives.  This also
     favors local traffic.

(e) Stop serving UDP, to kick resolvers over to another server.  This is
     really a last resort -- the attackers have won....

(f) Reject SYNs (requires using RST).

Note that this makes DNS TCP as sticky as possible, keeping existing
connections, servicing SYNs as much as possible.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2010 19:43:01 -0300

William,

> That's much too long for practical purposes.

Agreed. But that should be discused in a separate document. This
document is just meant to clarify support for TCP.

>     at least 360 seconds; the least pain will be felt by local traffic.

Unacked SYN/ACKs, you mean?

>     Any outstanding traffic will generate RST as it arrives.  This also

The only issue here is that this reaction you propose is not described
(I think) in the abstract TCP API of RFC 793. While aborting TCB's with
an RSTs is described as an ABORT call.

>     really a last resort -- the attackers have won....

This is way too risky, and I wouldn't apply it unless there's *lots* of
analysis.

> (f) Reject SYNs (requires using RST).

Same here.

> connections, servicing SYNs as much as possible.

Meta-comment: at the point you're facing resource exhaustion, I'd argue
that's it's probably not the best choice to "keep existing connections".
I'd fail on the side of servicing more clients (over different
connections that are then closed), rather keeping the same conenctions open.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: William Allen Simpson <[email-masked]>
Date: Tue, 23 Feb 2010 11:27:11 -0500

> document is just meant to clarify support for TCP.
As this is the document that clarifies support, it MUST indicate how
UDP falls over to TCP, and how TCP survives.

> connections that are then closed), rather keeping the same conenctions open.
Connections take energy and time to establish and close.  Always err on the
side of keeping existing connections stable over servicing new connections.
That is, be conservative in what you do....

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 23 Feb 2010 08:48:32 -0800

> That is, be conservative in what you do....

And connections take state to maintain...

The most likely problem with TCP on any server is state of "idle" connections, as the state for a new connection is no more than an idle connection once established, and (with SYN-cookies) is zero until it is established.

The real "resource" consumed in a new connection over an established connection is one extra RTT of latency and, if doing a big transfer, the RTTs involved in the slowstart ramp-up.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2010 14:12:19 -0300

> UDP falls over to TCP, and how TCP survives.

I don't think this need to be done in the same document. Yes, it should
be done. But not necessarily in the same document.

> That is, be conservative in what you do....

That sort of assumes that the established ones are legitimate -- which
needn't be the case. With such a policy, a Naphta attack (see the CPNI
doc) could kill your nameserver.

Thanks,