Subject: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-05.txt

From: [email-masked]
Date: Sat, 01 Aug 2015 06:52:04 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Domain Name System (DNS) Cookies
        Authors         : Donald E. Eastlake
                          Mark Andrews
	Filename        : draft-ietf-dnsop-cookies-05.txt
	Pages           : 30
	Date            : 2015-08-01

Abstract:
   DNS cookies are a lightweight DNS transaction security mechanism that
   provides limited protection to DNS servers and clients against a
   variety of increasingly common denial-of-service and amplification /
   forgery or cache poisoning attacks by off-path attackers. DNS Cookies
   are tolerant of NAT, NAT-PT, and anycast and can be incrementally
   deployed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-cookies/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-cookies-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-cookies-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 1 Aug 2015 10:06:48 -0400

This revisions incorporates the early allocation of 23 as the BADCOOKIE
RCODE and the changes agreed to on this mailing list.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 5 Aug 2015 22:19:42 +0200

On Sat, Aug 01, 2015 at 10:06:48AM -0400,
 Donald Eastlake <[email-masked]> wrote 
 a message of 151 lines which said:

> This revisions incorporates the early allocation of 23 as the
> BADCOOKIE RCODE and the changes agreed to on this mailing list.

Editorial: I still find section 5.2 "Responding to Request" very
confusing. It says "there are four possibilities" but the four
subsections don't match the list given. For instance, the draft says
"(2) there is no valid Client Cookie in the request because the COOKIE
OPT option is absent from the request, or one is present but is not a
legal length;" (thus mixing the normal behavior of a non-cookie client
and a software bug) but this possibility (2) then becomes two
subsections 5.2.1 and 5.2.2. And the possibility "(1) there is no OPT
RR at all in the request;" was merged with a part of (2) to be
subsection 5.2.1.

Note this is an old (and never fully addressed) problem
<https://mailarchive.ietf.org/arch/msg/dnsop/rQ0uUYOJqvhGFUQ9hbNFYCp8Nk8>

I suggest to rewrite it as (if there is a public version of the draft
source, I can send patches/pull requests instead):

5.2 Responding to Request

   The Server Cookie, when it occurs in a COOKIE OPT option in a
   request, is intended to weakly assure the server that the request
   came from a client that is both at the source IP address of the
   request and using the Client Cookie included in the option. This weak
   assurance is provided by the Server Cookie that server would send to
   that client in an earlier response appearing as the Server Cookie
   field in the request.

   At a server where DNS Cookies are not implemented and enabled,
   presence of a COOKIE OPT option is ignored and the server responds as
   if no COOKIE OPT option had been included in the request.

   When DNS Cookies are implemented and enabled, there are five
   possibilities: (1) there is no OPT RR at all in the request; or there
   is a OPT RR but the the COOKIE OPT option is absent from the
   request (2) a COOKIE OPT is present but is not a
   legal length or otherwise malformed; (3) there is a valid length
   cookie option in the
   request with no Server Cookie; (4) there is a Server Cookie but it   
   is invalid; or (5) there is a cookie option in the request with a
   correct Server Cookie.

   The five possibilities are discussed in the subsections below.

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

5.2.1 No Opt RR or No COOKIE OPT option

   If there is no OPT record or no COOKIE OPT option present in the
   request then the server responds to the request as if the server
   doesn't implement the COOKIE OPT.

5.2.2 Malformed COOKIE OPT option

   If the COOKIE OPT is too short to contain a Client Cookie then
   FORMERR is generated.  If the COOKIE OPT is longer than that required
   to hold a COOKIE OPT with just a Client Cookie (8) but is shorter
   that the minimum COOKIE OPT with both a Client and Server Cookie (16)
   then FORMERR is generated.  If the COOKIE OPT is longer than the
   maximum valid COOKIE OPT (40) then a FORMERR is generated.

   In summary, valid cookie lengths are 8 and 16 to 40 inclusive.

5.2.3 Only a Client Cookie

   Based on server policy, including rate limiting, the server chooses
   one of the following:

   (1) Silently discard the request.

   (2) Send a BADCOOKIE error response.

   (3) Process the request and provide a normal response. The RCODE is
       NOERROR unless some non-cookie error occurs in processing the
       request.

   If the server responds, choosing 2 or 3 above, it SHALL generate its
   own COOKIE OPT containing both the Client Cookie copied from the
   request and a Server Cookie it has generated and adds this COOKIE OPT
   to the response's OPT record. Servers MUST, at least occasionally,
   respond to such requests to inform the client of the correct Server
   Cookie. This is necessary so that such a client can bootstrap to the
   weakly secure state where requests and responses have recognized
   Server Cookies and Client Cookies.

   If the request was received over TCP, the server SHOULD take the weak
   authentication provided by the use of TCP into account and SHOULD
   choose 3. In this case, if the server is not willing to accept the
   weak security provided by TCP as a substitute for the weak security
   provided by DNS Cookies but instead chooses 2, there is some danger
   of an indefinite loop of retries (see Section 5.3).

5.2.4 A Client Cookie and an Invalid Server Cookie

   The server examines the Server Cookie to determine if it is a valid
   Server Cookie it has generated.  This examination will result in a
   determination of whether the Server Cookie is valid or not.  If the
   cookie is invalid, it can be because of a stale Server Cookie, or a
   client's IP address or Client Cookie changing without the DNS server
   being aware, or an anycast server cluster that is not consistently
   configured, or an attempt to spoof the client.

   The server SHALL process the request as if the invalid Server Cookie
   was not present as described in Section 5.2.3.

5.2.5 A Client Cookie and a Valid Server Cookie

   When this occurs the server can assume that the request is from a
   client that it has talked to before and defensive measures for
   spoofed UDP requests, if any, are no longer required.

   The server SHALL process the request and include a COOKIE OPT in the
   response by (a) copying the complete COOKIE OPT from the request or
   (b) generating a new COOKIE OPT containing both the Client Cookie
   copied from the request and a valid Server Cookie it has generated.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Aug 2015 11:36:33 +1000

In message <[email-masked]>, Stephane Bortzmey
> source, I can send patches/pull requests instead):

Looks reasonable with one change below.

>    assurance is provided by the Server Cookie that server would send to

s/would send/sent/

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]