I offered to review this document during the WG meeting in Prague...
> Mitigation
> of such attacks on authoritative-only servers is possible using an
> approach known as Response Rate-Limiting [RRL], an approach designed
> to minimise the frequency at which legitimate responses are discarded
> by truncating responses that appear to be motivated by an attacker,
> forcing legitimate clients to re-query using TCP transport.
proposed rewrite:
Response Rate Limiting [RRL] is designed to help mitigate such attacks
against authoritative-only servers. One feature of RRL is to let some
amount of responses "slip" through the rate limiter. These are returned
with the TC (truncation) bit set, which causes legitimate clients to re-query
using TCP transport.
> Fragmentation is known to be problematic
> in general, and has also been implicated in increasing the risk of
> cache poisoning attacks.
Citation for above:
[fragmentation-considered-poisonous]
Herzberg, A. and H. Shulman, "Fragmentation Considered
Poisonous", May 2012, <http://arxiv.org/abs/1205.4011>.
>
> The use of TCP transport does not suffer from the risks of
> fragmentation nor reflection attacks.
I'm not sure there is general agreement on such an absolute statement. Perhaps
TCP is "less susceptible" to fragmentation and reflection?
>
> (It should perhaps be noted that the overhead for a DNS transaction
> over UDP truncated due to RRL is 3x RTT, higher than the overhead
> imposed on the same transaction initiated over TCP.)
>
> With increased deployment of DNSSEC and new RRtypes containing
> application specific cryptographic material, there is an increase in
> the prevalence of truncated responses received over UDP with fallback
> to TCP.
I'd suggest swapping the order of the two paragraphs above. I think large
DNSSEC responses is the normal case and perhaps a better reason to
care about (long lived) TCP than is the attack case. Both are "3x RTT"
(worst case) due to UDP truncation.
>
> The use of TCP transport requires considerably more state to be
Earlier it was said that UDP is stateless, so one could argue that TCP requires
infinitely more state. :-)
But I think the sentence should just say "...TCP transport requires state to be
retained..."
> well-used, and those that remain idle for long periods are closed
> promptly.
suggested rewrite:
... and idle connections are closed after an appropriate amount of time.
>
> This document proposes a signalling mechanism between DNS clients and
> servers that provides a means to better balance the use of UDP and
> TCP transport, reducing the impact of problems associated with UDP
I'm not sure its fair to say that this document reduces the impact of UDP
problems.
>
> The reduced overhead of this extension adds up significantly when
> combined with other edns extensions,
edns -> EDNS0
> [STARTTLS]. For example, the combination of these EDNS extensions
EDNS -> EDNS0 ?
> make it possible for hosts on high-latency mobile networks to
> natively perform DNSSEC validation and encrypt queries.
perhaps "...natively and efficiently perform..."?
>
> 3.1. Option Format
>
> The edns-tcp-keepalive option is encoded as follows:
>
> 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-------------------------------+-------------------------------+
> ! OPTION-CODE ! OPTION-LENGTH !
> +-------------------------------+-------------------------------+
> | TIMEOUT |
> +---------------------------------------------------------------+
>
> where:
>
> OPTION-CODE: the EDNS0 option code assigned to edns-tcp-keepalive,
> [TBD]
>
> OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2
> if it is present;
>
> TIMEOUT: an idle timeout value for the TCP connection, specified in
> units of 100 milliseconds, encoded in network byte order.
The diagram above indicates TIMEOUT is a 32-bit value, which would make
OPTION-LENGTH 4.
I suspect it was really intended as a 16-bit value (OPTION-LENGTH 2), which
means the max TIMEOUT is around 109 minutes?
>
> Clients MUST specify a OPTION-LENGTH of 0 and omit the TIMEOUT value.
an OPTION-LENGTH
> The
> DNS server SHOULD send a edns-tcp-keepalive option with a timeout of
> 0 if it deems its local resources are too low to service more TCP
> keepalive sessions.
Or if it wants clients to close currently open connections.
> imposed by the operating system. Servers that implement keepalive
suggest "...that implement edns-tcp-keepalive..."
>
> It is RECOMMENDED that DNS intermediaries which terminate TCP
> connections implement keepalive.
suggest "... implement edns-tcp-keepalive."
> Should a non-keepalive-aware
> intermediary sit between a client and server that both support
> keepalive a potential side effect will be an increased frequency of
> the proxy closing idle client connections.
suggest changing proxy to intermediary
> When a Nameserver
> detects abusive behaviour, it SHOULD immediately close the TCP
> connection and free all buffers used.
The "free all buffers used" sounds strange to my ear. I'd think it is
sufficient
to say that the TCP connections should be closed.
>
> [STARTTLS]
> Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
> and P. Hoffman, "TLS for DNS: Initiation and Performance
> Considerations", draft-ietf-dprive-start-tls-for-dns-02
> (work in progress), May 2015.
Since we're dropping the STARTTLS upgrade technique from that draft the
anchor text should probably be changed to something like "TLSforDNS".
DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
