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

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 16 Feb 2015 22:24:31 +0100

I've read draft-ietf-dnsop-cookies-00.txt and I think it is a good
idea, it would improve seriously the security <icann>and
stability</icann> of the DNS, for a very small cost, so it should be
pursued.

My main concern with the current draft is in section 5.2. I simply do
not understand why the two cases:

* the client sends an OPT RR but no COOKIE option,
* the client sends a malformed COOKIE option,

are treated together. They are completely different, the first case is
the normal behaviour of today's resolvers, the second case is a
programming error (or mangling in transit) and it deserves a FORMERR
(not a REFUSED).

I therefore suggest to rewrite the paragraph starting with "When DNS
Cookies are implemented and enabled" as:

When DNS Cookies are implemented and enabled, there are five
possibilities: (1) there is no OPT RR at all in the request; (2) the
COOKIE OPT option in absent from the request 3) one Client Cookie is
present in the request but does not have a legal length; (4) there is
a valid length cookie option in the request with no Server Cookie or
an incorrect Server Cookie; or (5) there is a cookie option in the
request with a correct Server Cookie. The five possibilities are
discussed in the subsections below.

And then:

5.2.1 [NO CHANGE]

5.2.2 No Cookie option
A request with an OPT RR but no COOKIE OPT option is from a
   client that does not implement DNS cookies.  A server on which DNS cookies are enabled has the
   following three choices in responding to such a request:

   (1) Silently discard the request.

   (2) Not process the request other than returning a minimal length
       error response. Because of the absence of a 
       COOKIE OPT option in the request, it cannot be assumed that the
       client would understand any new RCODE values. An RCODE of
       Refused
       is returned and the Error Field of the returned COOKIE OPT option
       is set to NOCOOKIE.

   (3) Process the request normally and provide a normal response except
       that a COOKIE OPT option with a non-zero Error Field is included
       as in point 2 above. The RCODE in the DNS Header is zero unless
       some non-cookie error occurs in processing the request.

   Since all current resolvers are in this case (they do not send
   cookies), choosing (1) today is NOT RECOMMENDED. Server policy determines how often the server selects each of the
   above response choices; however, if the request was received over
   TCP, the server may wish to take the weak authentication provided by
   the use of TCP into account, increasing the probability of choice
   3.  
   For both response choices 2 and 3, the server
   should consider setting TC=1 in the response so that future requests
   from the client are more likely to be received with the weak
   authentication that can be provided by TCP.

5.2.3 Invalid cookie option
A request with an OPT RR and with a COOKIE
   that is not a valid length (10 or 18 through 42) means some form of
   abuse or a broken client
   implementation.  A server on which DNS cookies are enabled has the
   following three choices in responding to such a request:

   (1) Silently discard the request.

   (2) Not process the request other than returning a minimal length
       error response. Because of the absence of a validly formatted
       COOKIE OPT option in the request, it cannot be assumed that the
       client would understand any new RCODE values. An RCODE of FormErr
       is returned and the Error Field of the returned COOKIE OPT option
       is set to MFCOOKIE.

   (3) Process the request normally and provide a normal response except
       that a COOKIE OPT option with a non-zero Error Field is included
       as in point 2 above. The RCODE in the DNS Header is zero unless
       some non-cookie error occurs in processing the request.

   Server policy determines how often the server selects each of the
   above response choices; however, if the request was received over
   TCP, the server may wish to take the weak authentication provided by
   the use of TCP into account, increasing the probability of choice 3
   and decreasing the probability of choice 1 perhaps to the extent of
   never choosing 1.  For both response choices 2 and 3, the server
   should consider setting TC=1 in the response so that future requests
   from the client are more likely to be received with the weak
   authentication that can be provided by TCP.

5.2.3 Renumbered 5.2.4, otherwise unchanged

5.2.4 Renumbered 5.2.5, otherwise unchanged

Editorial: 

* I had trouble understand section 6 so I suggest to add, after "There
is no problem with DNS transactions between clients and servers behind
a NAT box using local IP addresses", the terms ", because the server
uses only, to check the cookie, the source IP address it sees,
whatever the translations that happened before."

* Also in section 6, after "it is RECOMMENDED that the same server
secret be used by each DNS server in a set of anycast servers", I
suggest to specify ", and kept synchronised, by an external mean -
which is off-topic for this document".

Typos:

* In 5.3, RCODE is spelled RCDOE

* In 6, server is spelled sever

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Feb 2015 08:58:00 +1100

I sent this to Donald yesterday for inclusion in the next revision.
This describes the simpler option we mentioned in Honolulu.  Once
it is out we need the WG to work out which version of the option
to proceed with.

[Donald I left the "9." off "BIND 9.10" when I sent this to you.]

Mark

6. Simple DNS Cookie Option

   The Simple DNS Cookie Option is a alternative DNS COOKIE option
   format that is implemented in BIND 9.10 using a experimental option
   code.  It differs from the the COOKIE OPT Option (Section 4) in
   that it does not contain a error code and as a consequence there
   is mimimal error handling required.  Only one of COOKIE OPT or
   Simple DNS Cookie Option will be in the final document.  Both
   are present here for comparision.

   The Simple DNS Cookie Option is a OPT RR [RFC6891] option that
   can be included in the RDATA portion of an OPT RR in DNS requests
   and responses.  The option length varies depending on the
   circumstances in which it is being used.  There are two case as
   described below.  Both use the same OPTION-CODE; they are
   distinguished by there length.

   In a request sent by a client to a server when the client does
   not know the server cookie, its length is 8, consisting a 8 byte
   Client Cookie as shown in Figure 3.

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 = {TBD}     |       OPTION-LENGTH = 8       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-    Client Cookie (fixed size, 8 bytes)              -+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3. Simple COOKIE Option, Unknown Server Cookie

   In a request sent by a client when a server cookie is known and
   in all responses, the length is variable from 16 to 40 bytes,
   consisting of a 8 bytes Client Cookie followed by the variable
   8 to 32 bytes Server Cookie as shown in Figure 4.  The variability
   of the option length stems from the variable length Server Cookie.
   The Server Cookie is an integer number of bytes with a minimum
   size of 64 bits for security and a maximum size of 256 bits for
   implementation convenience.

                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 = {TBD}     |   OPTION-LENGTH >= 16, <= 40  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-+-    Client Cookie (fixed size, 8 bytes)              -+-+-+-+
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    /       Server Cookie  (variable size, 8 to 32 bytes)           /
    /                                                               /
    +-+-+-+-...

               Figure 4. Simple COOKIE Option, Known Server Cookie

6.1 Simple Client Cookie

	[This section is identical to section 4.1]

   The Client Cookie SHOULD be a pseudo-random function of the server IP
   address and a secret quantity known only to the client. This client
   secret SHOULD have at least 64 bits of entropy [RFC4086] and be
   changed periodically (see Section 5.4). The selection of the pseudo-
   random function is a matter private to the client as only the client
   needs to recognize its own DNS cookies.

   For further discussion of the Client Cookie field, see Section 5.1.
   For example methods of determining a Client Cookie, see Appendix A.

   A client MUST NOT use the same Client Cookie value for queries to all
   servers.

6.2 Simple Server Cookie

	[This section is identical to section 4.2]

   The Simple Server Cookie SHOULD consist of or include a 64-bit
   or larger pseudo-random function of the request source IP address,
   the request Simple Client Cookie, and a secret quantity known
   only to the server. (See Section 8 for a discussion of why the
   Simple Client Cookie is used as input to the Simple Server Cookie
   but the Simple Server Cookie is not used as an input to the
   Simple Client Cookie.) This server secret SHOULD have at least
   64 bits of entropy [RFC4086] and be changed periodically (see
   Section 5.4).  The selection of the pseudo-random function is a
   matter private to the server as only the server needs to recognize
   its own DNS cookies.

   For further discussion of the Simple Server Cookie field see Section 5.2.
   For example methods of determining a Server Cookie, see Appendix B.

   A server MUST NOT use the same Server Cookie value for responses to
   all clients.

7. Simple DNS Cookies Protocol Description

   This section discusses using Simple DNS Cookies in the DNS Protocol.

7.1 Originating Requests (Simple)

   A DNS client that implements DNS includes one DNS Cookie option in
   every DNS requests it sends unless DNS cookies are disabled.

   If the client has a cached server cookie for the server against
   its IP address it includes that in the option along with the
   client cookie (Figure 4) otherwise it just sends a option with
   a client cookie (Figure 3).

7.2 Responding to Request (Simple)

   The Server Cookie, when included in a COOKIE option in a request,
   is intended to weakly assure that server that the request has
   come from a client that it has responsed to in the past and is
   both at the same source address and is using the same Client
   Cookie in the option.

   At a server where Simple DNS Cookies are not implemented and enabled,
   presence of a COOKIE OPT option is ignored and the server responds as
   before.

   When DNS Cookies are implemented and enabled, there are four
   possibilities: (1) there is no OPT RR at all in the request; (2)
   there is no valid Client Cookie in the request because the COOKIE OPT
   option in absent from the request or one is present but not a legal
   length; (3) there is a valid length cookie option in the request with
   no Server Cookie or an incorrect Server Cookie; or (4) there is a
   cookie option in the request with a correct Server Cookie. The four
   possibilities are discussed in the subsections below.

   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.

7.2.1 No Opt RR or No COOKIE OPT option

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

7.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 mimimum COOKIE OPT with both 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 and 40 inclusive.

7.2.3 Only a CLIENT Cookie

   The server SHALL process the query as if the Client Cookie was not
   present.  In addition it shall generate its own COOKIE OPT containing
   both the client cookie copied from the request and a server cookie it
   has generated.  This will be added to the OPT record.

7.2.4 A Client Cookie and Server Cookie

   The server shall examine the Server Cookie to determine if it is a
   valid server cookie it has generated.  This examination will result
   in a deterimination of whether the server cookie is valid or not.

7.2.4.1 A Client Cookie and Invalid Server Cookie

   This can occur due to a stale server cookie being returned, a
   clients IP address changing without the DNS client being aware,
   a attempt to spoof the client is occuring.

   The server SHALL process the query as if the Client Cookie was
   not present.  In addition it SHALL generate its own COOKIE OPT
   containing both the client cookie copied from the request and a
   valid server cookie it has generated.  This will be added to the
   OPT record.

7.2.4.2 A Client Cookie and Valid Server Cookie

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

   The server SHALL process the query 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.

10. IANA Considerations

   IANA is requested to assign the following four code points:

      The OPT option value for COOKIE is <TBD> [10 suggested].

	[ The following are not required for Simple COOKIE OPT ]

      Three new DNS error codes in the range above 16 and below 3,840 as
      shown below:

       RCODE       Name       Description                 Reference
      --------  ---------  -----------------           ---------------
      TBD1[23]  NOCOOKIE   No client cookie.           [this document]
      TBD2[24]  MFCOOKIE   Malformed cookie.           [this document]
      TBD3[25]  BADCOOKIE  Bad/missing server cookie.  [this document]

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Feb 2015 17:11:01 +0100

On Tue, Feb 17, 2015 at 08:58:00AM +1100,
 Mark Andrews <[email-masked]> wrote 

> I sent this to Donald yesterday for inclusion in the next revision.

draft-ietf-dnsop-cookies-01 has exactly the same problem in its
section 5.2 (confusion between two very different cases, the client
sends an OPT RR but no COOKIE option, and the client sends a malformed
COOKIE option).