Subject: Re: [dnsext] DNS transport

From: Tony Finch <[email-masked]>
Date: Mon, 14 Sep 2009 20:13:08 +0100

On Mon, 14 Sep 2009, George Barwood wrote:
>
> (1) One objection to TCP that the handshake increases latency.
>
> I think it might be possible to get round this by servers using long-life
> SYN-cookies, and clients retaining and re-using the SYN-cookie when
> a new connection is needed.

Sounds like TCP for Transactions (RFC 1644). See
http://tcp-impl.grc.nasa.gov/tcp-impl/list/archive/1292.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 14 Sep 2009 16:00:38 -0700

On 9/14/09 8:04 AM, George Barwood wrote:
> Some wild thoughts I have had recently.
>

Perhaps this is suggesting a scheme to establish a long-lived client 
credentials based upon objects received from servers as a method to 
mitigate reflected attack.  T/TCP, as another alternative, but it 
creates several security vulnerabilities.

> (2) Another objection is that the server will need large amounts of buffer
> space for un-acknowledged data, enabling denial-of-service attacks on
> this buffering.
>
> I think a possible solution to this is to implement a TCP Send primitive
> that takes an Object rather than an array of bytes.

SCTP provides message fragmentation where DNS messages would map to 
Chunks.  SCTP also permits out-of-order and unreliable delivery to avoid 
server's retention of unacknowledged data.  SCTP first exchanges cookie 
and verification tags to avoid blind spoofing and reflected attack. 
When associations are retained over a burst of transactions, SCTP would 
provide overall low latency exchanges that would not suffer from 
head-of-line blocking.

> The Object would have a method
>
> Read( buffer, offset, count )
>
> to allow the TCP layer to obtain bytes as required.

SCTP can also tunnel over UDP and adapt to existing firewall constraints.

> This should reduce the memory requirements considerably, since
> a very compact representation of the response should be possible,
> except for queries for non-existent domains, where up to 256 bytes
> are required to store the non-existent domain name. Possibly DO=1
> NXDOMAIN response packets could be amended to not return
> a copy of the question, when server memory is low.
 >
> This may upset resolvers which expect a copy of the question to be returned,
> however since NXDOMAIN conditions are not entirely normal, this might
> be ok.

SCTP's Verification Tag can safely replace missing questions and still 
avoid blind spoofing.  However, over UDP or TCP transports, DNS 
responses missing DNS questions might be re-attempted.

> (3) Should servers be able to terminate TCP connections that are not
> making timely progress.

TCP should not be expected to function when resources are low.

> (4) It's not clear if servers are allowed to truncate UDP responses
> unilaterally. That is can a server choose to truncate a UDP response
> at say 512 bytes, even though the client has requested EDNS @4096?
> I think this should be allowed, and in fact encouraged, since it
> limits amplification attacks. This suggests that clients should only
> bother with UDP for unsigned zones, with TCP being the standard
> transport for signed zones.

SCTP better handles multiple questions over a single association as a 
means to avoid setup latency.  SCTP also automates Auto-Close after the 
lapse of a programmable number of seconds.  It seems DNSSEC support 
could be constrained to just the SCTP transport.

-Doug

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 Sep 2009 12:22:24 +0100

> http://tcp-impl.grc.nasa.gov/tcp-impl/list/archive/1292.html

Er, sorry about the broken link. Looks like some time in the last seven
years it moved to http://roland.grc.nasa.gov/tcp-impl/list/archive/1292.html

Tony.

---

From: "George Barwood" <[email-masked]>
Date: Tue, 15 Sep 2009 14:32:07 +0100

----- Original Message ----- 
From: "Tony Finch" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 15, 2009 12:22 PM
Subject: Re: [dnsext] DNS transport

> years it moved to http://roland.grc.nasa.gov/tcp-impl/list/archive/1292.html

That document contains the following statement, which seems wrong:

"  There have been several suggestions on methods for creating ISSes 
   that might prevent guessing, or at least make it more difficult. 
   Most of these involve simply using a random number for the ISS, or 
   randomizing the periodic increment, in a way that would break TCP's 
   ability to recognize data from an old instance of a connection. 
   These methods can be discarded. "

My understanding is that the TCP TIME_WAIT state protects against
old packets ( with old sequence numbers ) being a problem.
That is, a source port cannot be safely re-used for a given TCP destination
until a suitable time has elapsed. This does not seem to be a severe restriction,
if it were, an extended source port option would appear to be a solution.

The mechanism I envisage would be for the server to compute an initial
sequence number that is a (secure) hash of the client IP address and a 
fixed server secret, and for the server to allow the normal handshake 
to be by-passed on subsequent connections, provided the sequence
number is valid.

I expect some kind of option signalling may be desirable to allow the server
to signal support to the client. I haven't looked into the precise detail of how
that should work yet.

There might be problems with firewalls/middleboxes, in that case a normal
TCP handshake would be needed until such boxes could be updated.

George

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Sep 2009 17:05:57 +0000

> From: "George Barwood" <[email-masked]>
> Date: Tue, 15 Sep 2009 09:43:58 +0100
> 
> If in fact TCP is good enough (possibly with some re-engineering/an 
> extra TCP option),  there is no need to consider alternatives.

some of us are working on that approach, offline.  draft to come.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 15 Sep 2009 11:00:15 -0700

On 9/15/09 1:43 AM, George Barwood wrote:
> From: "Douglas Otis"<[email-masked]>
>
> [SCTP discussion snipped]
>
> Doug,
>
> It's clear that one can define alternative transports, as you know,
> I have also made a proposal here
>
> http://tools.ietf.org/html/draft-barwood-dnsext-dns-transport
>
> What I mainly wanted to examine in this thread was whether the
> objections to TCP can be overcome.
>

Use of SCTP would not change the DNS protocol from the perspective of 
message content, nor alter the transport protocol.

Instead, you propose changing DNS protocol message content AND the 
transport protocol.  Transport related changes should be discussed on an 
appropriate list, such as TSVWG.

-Doug

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 15 Sep 2009 11:36:51 -0700

On Sep 15, 2009, at 11:00 AM, Douglas Otis wrote:

> Use of SCTP would not change the DNS protocol from the perspective  
> of message content, nor alter the transport protocol.
>
> transport protocol.  Transport related changes should be discussed  
> on an appropriate list, such as TSVWG.

Actually, you don't need to change the transport protocol, you just  
need to change the user side API for the transport protocol.

As long as your authority is deterministic, you only need to save the  
query, not the reply, until you get the reply ACKed if you are doing a  
sure level TCP.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Sep 2009 19:29:59 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Tue, 15 Sep 2009 11:36:51 -0700
> ...

alas, until we have ubiquitous dnssec, authorities will not be deterministic.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 15 Sep 2009 12:51:33 -0700

> alas, until we have ubiquitous dnssec, authorities will not be  

Even with ubiquitous DNSSEC, you won't be "deterministic": you can  
easily return different subsets/different order for loadbalancing  
etc.  Those games should still work, no?

But you CAN be deterministic without being "deterministic": just make  
sure the process is deterministic based on a random seed and the TCP 4- 
tuple.

---

From: bert hubert <[email-masked]>
Date: Tue, 15 Sep 2009 23:37:33 +0200

On Tue, Sep 15, 2009 at 9:51 PM, Nicholas Weaver
<[email-masked]> wrote:
> Even with ubiquitous DNSSEC, you won't be "deterministic": you can easily
> return different subsets/different order for loadbalancing etc.  Those games
> should still work, no?

Not if you expect things to work reliably. While pondering
implementing DNSSEC, I've been thinking a lot about RRSIG lifetimes
(TTL & fuzz) versus the lifetimes of the covered RRSET. To say the
least, I worry if everyone will get this right.

    Bert

---

From: Florian Weimer <[email-masked]>
Date: Wed, 16 Sep 2009 08:40:22 +0000

> message content, nor alter the transport protocol.

You'd still have to add negotation for SCTP parameters which can't be
negotiated at the SCTP layer, wouldn't you?

-- 
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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Sep 2009 10:48:21 -0700

> negotiated at the SCTP layer, wouldn't you?

The SCTP transport handles negotiations related to options useful for 
DNS.  SCTP supports Unordered and Unreliable delivery negotiation. 
These modes allow DNS queries or their response not to be retained by 
servers.  Clients could retry lost messages over the same association.

Rather than attempting to kludge yet another API option and operational 
modes for TCP, these features are implemented, tested, and released with 
SCTP.  Abrupt timeouts abandoning TCP buffers and connections will 
likely defeat congestion avoidance and require additional state and 
delays to restore congestion avoidance.

SCTP handles low latency, multi-path, error detection, concurrency, 
framing, and importantly security far better than TCP can.  DNSSEC over 
SCTP offers a means to ensure safe and reliable operation, providing 
clear guidelines for introducing DNSSEC.  Safety first.

-Doug