In message <20150805201942.ga29...@laperouse.bortzmeyer.org>, Stephane Bortzmey er writes: > 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):
Looks reasonable with one change below. > 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 s/would send/sent/ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
