Subject: [DNSOP] Review of draft-ietf-dnsop-cookies-00

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 16 Dec 2014 20:55:12 +0530

Hi all

As a part of DNS fragments drafting (which requires protection against
UDP amplification attacks), I reviewed draft-ietf-dnsop-cookies-00. Its
use in fragments would be narrow and I mainly read the draft from that
point-of-view.

The draft describes different types of attacks and the COOKIE
mechanisms. While it seems sound, while reading it I felt it didn't
explain well HOW the mechanisms help in preventing the listed attacks,
or HOW the mechanisms should be deployed. This is partly a network
availablity and partly a network integrity related draft, so I think it
needs further descriptions and clarifications. It would be nice for
things that are left to policy have guidelines.

As far as network availability is concerned, compared to what is there
now, the effect of this draft is to deny service to some requests where
service is provided now.

(Another way to look at this would be that in a network without
 possibility of such attacks, this draft's real effect is to improve
 service where service would be disrupted now. Nevertheless, the draft
 is written to assist the server in dropping or refusing requests that
 don't satisfy some conditions, and so the earlier point is considered.)

The conditions for such denial must be described clearly, and perhaps,
not completely left to operators to decide.

TCP
---

It would be useful for "Weak authentication" to be defined in the
"Definitions" section. The draft seems to state that what TCP provides
after the three-way connection handshake is weak authentication, but
that COOKIE option also provides "weak authentication", so its complete
meaning should be stated somewhere.

>   The protection provided by DNS cookies bears some resemblance to that
>   provided by using TCP for DNS transactions. To bypass the weak
>   protection provided by using TCP requires an off-path attacker
>   guessing the 32-bit TCP sequence number in use. To bypass the weak
>   protection provided by DNS Cookies requires such an attacker to guess
>   a 64-bit pseudo-random quantity. Where DNS Cookies are not available
>   but TCP is, a fall back to using TCP is a reasonable strategy.

Many of the off-path attacks for UDP don't occur in TCP. There are some
attacks on TCP to inject segments by on-path eavesdroppers (and perhaps
a 1 in 1<<32 attack by a very lucky off-path attacker), but they won't
be discovered by this COOKIE feature even if the option exists. Towards
this, the description in the introduction seems somewhat badly
phrased. A DNS message over TCP is not limited to a single IP datagram,
and COOKIE does not sign data. Perhaps it is trying to compare TCP
(either with or without COOKIE) vs. UDP+COOKIE, but it should be
clarified. The word UDP doesn't occur even once in the draft, so it is
unclear what is intended.

TCP already performs "weak authentication" via the 3-way connection
establishment handshake, so apart from keeping the COOKIE option alive
and going, why should this option have any effect at all (i.e., deny
service) in DNS over TCP, when it cannot further help TCP?

[As a side note: to avoid SYN flood attacks, most TCPs used on the
public internet nowadays use cookies as a weak authentication in the
sequence number field (and recently using the timestamp TCP option too,
to preserve some more TCP options) during the initial handshake. This is
done to avoid maintaining state on the server side until the three-way
handshake is complete. This is not an on-going cookie that lasts during
the connection, and though it is similarly used to verify the client
without maintaining per-request state on the server, the similarity to
DNS cookies ends there.]

UDP
---

UDP is the fast case. A single datagram is sent as a query and a single
datagram is received as the reply. Ignoring processing time, if the
round-trip time between client and server is represented by the unit
RTT, the lookup takes 1 RTT.

Typically, UDP is tried first by clients, and if the answer does not
fit, TCP is tried. In the best case scenario, assuming the TC=1 reply is
delivered correctly, after 1 RTT spent on UDP, the client tries a 3-way
handshake ~ another 1 RTT, plus actually sending the data, and receiving
a reply, both flows in slow-start, which can take another 1-2 RTT at
best for the first 1-3 segments. So this takes at least 3 roundtrips for
the simplest DNS query that falls to TCP.

From my part of the world to the USA, a roundtrip averages about
280ms. This makes it nearly a second to resolve a single name from a
nameserver that truncates, in the best case and without recursion. (A
user visiting a new website in her browser would have to wait for
resolution to complete, and then the actual HTTP TCP connection to
establish, and the process is repeated as as more webservers are
contacted.)

Fallback to DNS over TCP is slower than UDP, and one of the contributors
is the initial attempt over UDP. If DNS UDP peformance degrades, there
isn't much in the way to directly try TCP for all its advantages,
especially as recent DNS RFCs seem to make TCP support mandatory.

In section 5.2.3, Bad or Absent Server Cookie:

>   In responding to such a request, the server has the following three
>   choices:
>
>   (1) Silently discard the request.

The server can refuse to process a request for myriad other reasons
including resource exhaustion, but this draft should not introduce
dropping requests as a possibility for "Bad or Absent Cookie". In this
case, the client cannot recover as it will not receive the server
cookie. It would be good if the draft recommends that the server SHOULD
make an effort to send a minimal response with the server cookie to
clients that support the COOKIE option.

Similarly in section 5.2.2, over TCP requests should never be dropped or
refused due to lack of COOKIE as a reason due to the reasons in the TCP
section above. [BTW, the last paragraph of that section also contradicts
this by saying that servers should use TC=1 in the case of (2) so that
future requests are served by TCP.]

Coming back to 5.2.3,

>   (2) Not process the request other than returning a minimal length
>       error response. Because of the correct length COOKIE OPT option
>       in the request, the client can be assume to understand the new
>       error codes assigned in this document. Both the Error Field in
>       the returned COOKIE OPT option and the extended RCODE are set to
>       BADCOOKIE.
>
>   (3) Processes the request normally and sends its usual response
>       including a COOKIE OPT option with an Error field of BADCOOKIE
>       and a zero RCODE (unless there was also a non-cookie error in
>       processing the request).

In a DNS implementation that supports the COOKIE option, in the case of
(2), at least 2 roundtrips are necessary to actually get an answer for
the query when the cookie is unknown when contacting a nameserver for
the first time, or when the cookies change.

In the case of (3), the risk of amplification attacks comes back.

The choice between (2) and (3) is moved to a policy decision, but there
are no guidelines for it.

Given the risk of EDNS payload size related drops from an uknown server
and extra roundtrips, what are the reasons why this option should be
used in preference to TCP (that is just 1 RTT longer to get an answer
from) and has several other advantages?

Some other comments
-------------------

1. In section 2, off-path attacks are considered. Apart from off-path
attackers (who have no access to traffic), and on-path attackers (who
can modify traffic), there is another class of attackers between these
two classes, which are eavesdroppers. Such attackers can listen in and
sometimes can inject traffic, but cannot filter or alter traffic. I
guess for the purposes of this draft, they can be considered as on-path.

2. In section 5.2,

>   In the case of multiple COOKIE OPT options in a request, only the
>   first (the one closest to the DNS header) is considered. All others
>   are ignored.

This seems to go against RFC 6891. RFC 6891 states this:

>   The order of appearance of option tuples is not defined.  If one
>   option modifies the behaviour of another or multiple options are
>   related to one another in some way, they have the same effect
>   regardless of ordering in the RDATA wire encoding.

A lower layer that processes OPT options may not end up preserving the
ordering of options. So I suggest changing the text to restrict the
number of COOKIES options to 1 and behave as if it's not found
otherwise.

3. In Section 5.2.3:

>   (2) Not process the request other than returning a minimal length
>       error response. Because of the correct length COOKIE OPT option
>       in the request, the client can be assume to understand the new
>       error codes assigned in this document. Both the Error Field in
>       the returned COOKIE OPT option and the extended RCODE are set to
>       BADCOOKIE.

Considering that the COOKIE option has an error code field, and it is
only sent to the peer that knows about the COOKIE option, is there a
reason why the extended RCODE is introduced? Wouldn't it suffice to
return RCODE=Refused with the error code field assigned?

4. Does the draft explain how DNS amplification is prevented? It
specifies COOKIEs, but there is a bit of connect-the-dots that can be
stated, i.e., what facilities fix what issues, and how.

It would be useful to present reasons next to all these behavioral
descriptions, i.e., say "The client must drop the response to address
XYZ threat described in the introduction."

5. The server cookie is unknown in Figure 1, but I recommend having a
matching amount of effort (32 bytes of 0s) sent in this request in the
server cookie field as in figure 2. This is a draft about countering
amplification, so let the client do as much work as it expects the
server to do. This will also reduce the number of figures to 1 in the
draft, simplifying it.

If you do this, I promise not to write a draft that adds a DNS option
that bloats the query message to be as large as the EDNS client buffer
size. ;)

6. I have a comment on the design of the client cookie, but first, can
you explain the following:

>   However, NAT devices sometimes also map ports. This can cause
>   multiple DNS requests and responses from multiple internal hosts to
>   be mapped to a smaller number of external IP addresses, such as one
>   address.  Thus there could be many clients behind a NAT box that
>   appear to come from the same source IP address to a server outside
>   that NAT box.  If one of these were an attacker (think Zombie or
>   Botnet), that behind-NAT attacker could get the Server Cookie for
>   some server for the outgoing IP address by just making some random
>   request to that server. It could then include that Server Cookie in
>   the COOKIE OPT of requests to the server with the forged local IP
>   address of some other host and/or client behind the NAT box.
>   (Attacker possession of this Server Cookie will not help in forging
>   responses to cause cache poisoning as such responses are protected by
>   the required Client Cookie.)
>
>   To fix this potential defect, it is necessary to distinguish
>   different clients behind a NAT box from the point of view of the
>   server.

Cache poisoning cannot happen, so what is the potential defect? That the
other client behind NAT is attacked by traffic?

7. I wonder what would be ways to allow the first request from an IP
address to a server to pass without a valid server cookie in the request
(with one eventually added in the response), but disallow it from the
second request onwards? The simple stupid method, a bitfield of all the
1<<32 IPv4 addresses would occupy 512 MiB of memory...

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 16 Dec 2014 22:43:18 +0530

> from) and has several other advantages?

Sorry, TCP also takes 2 RTT similar to UDP with DNS cookies. I had
included the initial UDP query by mistake, but this won't be involved if
TCP is directly tried.

		Mukund

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Dec 2014 09:20:12 -0800

> Mukund Sivaraman <mailto:[email-masked]>
> Tuesday, December 16, 2014 9:13 AM
>

3 round trips, 7 packets, for an isolated tcp/53 query.

s   ->
    <- s+a
a   ->
q   ->
    <- r+a
f+a ->
    <- f+a

obviously, the dickenson tcp change proposal bears on this, but today,
it's 3 rtt, 7 pkt, and that's assuming that the response fits in one
window. axfr is obviously much longer.

-- 
Paul Vixie

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 16 Dec 2014 23:17:34 +0530

Hi Paul

> 3 round trips, 7 packets, for an isolated tcp/53 query.

It's 2 round trips to get at the data, answer the question. FIN is
later.

		Mukund

---

From: P Vixie <[email-masked]>
Date: Tue, 16 Dec 2014 10:32:08 -0800

>It's 2 round trips to get at the data, answer the question. FIN is

The total transaction time includes all time during which state is held. That third round trip is in your departmental budget and will show up at scale or in benchmarks. So you have to count it.

Vixie
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 16 Dec 2014 14:44:40 -0500

Its time to stop obsessing over latency in DNS!

DNS doesn't exist in a vacuum, but then goes to at minimum, a TCP handshake, and who knows what else beyond it.  Amdahl's law matters.

How many headaches would go away if all DNS is over TCP?  And how much would it really make a difference in Latency?

> On Dec 16, 2014, at 12:20 PM, Paul Vixie <[email-masked]> wrote:
> 
> obviously, the dickenson tcp change proposal bears on this, but today, it's 3 rtt, 7 pkt, and that's assuming that the response fits in one window. axfr is obviously much longer.

And this is wrong:  The f+a RTT doesn't matter, thats AFTER the result has been received.  TCP is 2 RTT to actually get the result.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 16 Dec 2014 14:47:57 -0500

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 17 Dec 2014 06:21:17 +0530

Hi Nicholas

On Tue, Dec 16, 2014 at 02:44:40PM -0500, Nicholas Weaver wrote:
> DNS doesn't exist in a vacuum, but then goes to at minimum, a TCP
> handshake, and who knows what else beyond it.  Amdahl's law matters.
> 
> How many headaches would go away if all DNS is over TCP?  And how much
> would it really make a difference in Latency?

Surely a lot of problems would go away. But I don't think we can say
that latency doesn't matter. Though it is 2 roundtrips instead of 1, the
wait effectively doubles, and may increase further by a ~constant factor
during recursion. This would be conspicuous on long networks.

As DNS resolution is at the head of the batch of items that is done when
a user uses a network service, it adds to the average turnaround time of
every item on the list.

TCP performance "feels" different depending on what it is used for. On
LFNs, slow-start can throttle up fast (being a doubling throttle), and
due to the receive window TCP can deliver a lot of data quickly
vs. DNS-like UDP that restricts flow to request/response pairs.

For DNS, where there isn't a lot of data to transmit (in normal
queries), TCP connection setup is a big part of overall time to service
a request and it may not amortize well.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 17 Dec 2014 06:41:46 +0530

Hi Paul

On Tue, Dec 16, 2014 at 10:32:08AM -0800, P Vixie wrote:
> The total transaction time includes all time during which state is
> held. That third round trip is in your departmental budget and will
> show up at scale or in benchmarks. So you have to count it.

Is this network traffic budget (3-4 extra frames), or CPU budget or
memory budget for the TCP contexts?

I'm not able to tell from the above, in what way you mean FIN teardowns
would affect query performance as they can be done in parallel, whereas
the roundtrips upto the point the data is received happen in lockstep.

		Mukund

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 22 Dec 2014 15:28:24 +0100

On Tue, Dec 16, 2014 at 02:44:40PM -0500,
 Nicholas Weaver <[email-masked]> wrote 
 a message of 34 lines which said:

> handshake, and who knows what else beyond it.

But other people are obsessed, too. The TCP guys published RFC
7413. And the TLD crowd designed session resumption, to reduce
latency.

---

From: "Guangqing Deng" <[email-masked]>
Date: Mon, 29 Dec 2014 14:52:14 +0800

Totally agree. At least there are almost no people complaining of the DNS resolution being too fast, but there do exist some ones who think the DNS resolution delay is not as short as they expected, especially those running applications depending on the DNS resolution.

Guangqing Deng
CNNIC 
 
From: Mukund Sivaraman
Date: 2014-12-17 09:21
To: Nicholas Weaver
CC: dnsop; Paul Vixie
Subject: Re: [DNSOP] Enough latency obsession Re: Review of draft-ietf-dnsop-cookies-00
Hi Nicholas

 

 
Mukund

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Sun, 28 Dec 2014 23:05:09 -0800

> Guangqing Deng <mailto:[email-masked]>
> Sunday, December 28, 2014 10:52 PM
> ... there do exist some ones who think the DNS resolution delay is not
> as short as they expected, especially those running applications
> depending on the DNS resolution.

early internet applications were written with the assumption of on-host
or on-lan RDNS, such that a cached answer would be almost immediate
(less than 1 millisecond). using google dns or opendns or any other
cloud-oriented ("anycast") RDNS has a higher time-cost than that.
servers in san francisco, san jose, palo alto, or fremont are ~5
milliseconds from me. opendns and google dns are ~8ms from me. my
on-campus (well, at my house) RDNS servers are ~400 microseconds (~0.4
milliseconds).

so, i agree. and i was half way down the path of considering how a light
weight caching DNS shim could be installed on a host or on a LAN that
would do RTT-based server selection to keep track of closer/farther
servers, and i realized, i was reinventing RDNS. one of my new great
regrets of things-not-done-while-at-ISC was to make BIND RDNS into a
binary package that could be installed on any windows or mac/os or
android or iOS device, with cloud/subscription based configuration (for
RPZ policy).

-- 
Paul Vixie