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

[Mukund Sivaraman <[e-mail]>]

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