On Sat, Aug 01, 2015 at 10:06:48AM -0400, Donald Eastlake <d3e...@gmail.com> 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
