Subject: [dnsext] WGLC comments on draft-ietf-dnsext-dns-tcp-requirements-02

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Feb 2010 15:35:40 -0300

Hi,

Here are my comments on the aforementioned I-D:

**** Technical ****

Section 1:
>    However, some implementors have taken the text quoted above to mean
>    that TCP support is an optional feature of the DNS protocol.

To some extent, that makes it "optional" if "there's a valid reason". It
would be mandatory only if it were a "MUST".

Section 5:

> Therefore if the server needs to unilaterally
>    close a dormant TCP connection it MUST be free to do so whenever
>    required.

While I understand where you're going, the phrasing sounds weird. I'd
phrase it like "Servers MAY unilaterally close a dormant TCP connection..."

Section 5:

>    To mitigate the risk of unintentional server overload DNS clients
>    MUST take care to minimize the number of concurrent TCP connections
>    made to any individual server.

Same here. I'd rephrase it to something like "To mitigate the risk of
unintentional server overload DNS clients SHOULD limit the number of
concurrent TCP connections made to any individual server".
Note that not only I rephrased the text, but I also s/MUST/SHOULD/

Anyway, I think you should make the same type of statement for
*servers*. I'd argue that that would be even more important that
requiring *clients* to limit the number of concurrent connections.

Section 5:

As suggested by others (I think), you should probably stress that the
TCP endpoint actively closing the connection is the one that remains in
the TIME-WAIT state. So I'd argue that DNS servers should wait for
clients to close their connections, and if they get tired of waiting for
them to do so, they should probably ABORT (i.e., RST) the corresponding
connections.

Section 7 (security Considerations):

The higher risk is real. Put it simple: the more machinery you add to
something, the higher the chances that "something may go wrong". And TCP
in particular is complex.

Also, the more critical infrastructure (such as the DNS) depends on TCP,
the higher the chances that TCP will be attacked.

In the same section, you note:
>    Whilst there is a theoretically higher risk of such attacks against
>    TCP-enabled servers, techniques for the mitigation of DoS attacks at
>    the network level have improved substantially since DNS was first
>    designed.

You're talking about "DoS attacks at the network-level", and I may
agree. But you should be discussing *TCP* (*transport* layer), on which
there has not been that much progress (for instance, we publish the CPNI
TCP paper in 2009). Vectors such as "Sockstress" etc should give a hint
that things are not as good as they should be.

At the risk of sounding our own horn (although this was already proposed
by others), I'd suggest to reference CPNI's "Security Assessment of the
Transmission Control Protocol (TCP)", and also include its URL:
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf

**** Nits ****

Section 3:

>    In the absence of EDNS0 (see below) the normal behaviour of any DNS
>    server needing to send a UDP response that exceeds that 512 byte
>    limit is for the server to truncate the response so that it fits

I'd say "needing to send a DNS response that would exceed the UDP
512-byte limit" or the like. (i.e. there's no request/response udp-wise).

(lack of section number):
You should probably add an "Acknowledgements" section. It seems that
quite a few people has discussed this document on the mailing list. This
 would not only ack their contributions, but would also help the reader
to answer himself the question "who else reviewed this document?"

Thanks!

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