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

From: [email-masked]
Date: Sun, 22 Feb 2015 20:01:37 -0800

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-01.txt
	Pages           : 34
	Date            : 2015-02-22

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:
http://tools.ietf.org/html/draft-ietf-dnsop-cookies-01

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

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: Willem Toorop <[email-masked]>
Date: Mon, 23 Feb 2015 14:52:40 +0100

Thanks,

Are section 6 and 7 an alternative drop in replacement for section 4 and
5?  Because I feel there are some pieces missing in section 7 about
server policies and how that works out in responses, that can be found
in section 5.

Sections 7.2.3 (Only a CLIENT Cookie) and 7.2.4.1 (A Client Cookie and
Invalid Server Cookie) state that the server creates and sets a server
cookie for/in the response.  Then the sections mention: "The server
SHALL process the query as if the Client Cookie was not present."

That last statement depends on server policy, yes?  These server
policies are not explicitly mentioned in section 7, but there are some
suggestions in section 5.2.2 and 5.2.3: one could (1) silently discard
(but not always), (2) reply with error response or (3) process as normal.

Suppose a server policy (2) that returns error responses on absent or
wrong server cookie requests;  With the absence of the extra rcodes in
section 6 & 7, does that mean a REFUSED response including the server
cookie?

THE REFUSED response is only mentioned in 5.2.2, policy option (2).
Do I interpret the last paragraph of that section correct that there is
a suggestion to return REFUSED responses with the TC bit set, to
stimulate the initiation of TCP connection as an alternative weak
authentication?  Is this acceptable policy for sections 7.2.1 and 7.2.2
as well?

Is policy (1), silently discard, from section 5.2.2 and 5.2.3 also
considered a viable policy option in section 7?

Also, I think that the (obvious?) inclusion of a server cookie with
policies (2) and (3) could be mentioned more explicitly in section 5.2.3.

Regards,

-- Willem

Op 23-02-15 om 05:01 schreef [email-masked]:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 24 Feb 2015 11:00:31 +1100

> SHALL process the query as if the Client Cookie was not present."

The server will do whatever processing as if the cookie was not
there (e.g.  rate limit / set tc=1 / just generate the response)
because it does not have a valid server cookie and does not know
if this is a spoofed request or not.

> (but not always), (2) reply with error response or (3) process as normal.

Section 5 gives some policies but really deciding policy is outside
of the cookie option itself.  Having a valid server cookie is one
input into policy selection.  Named skips RRL processing if there
is a valid server cookie.

> section 6 & 7, does that mean a REFUSED response including the server

Exactly the same thing as sending REFUSED means today.

What is a client going to do with NOCOOKIE?
What is a client going to do with MFCOOKIE?
What is a client going to do with BADCOOKIE?

If the client doesn't understand cookies these are meaningless noise
in the reply.

MFCOOKIE is just a subset of FORMERR.  I don't see a recovery
strategy for MFCOOKIE other than to not send a cookie.  I also
don't see this ever being sent if there is any sort of QA done
before release.

BADCOOKIE the client could retry with the new cookie but if you end
up with a pair of servers with mis matched secrets / server algorithms
it won't do you much good.  Forcing to TCP will allow the transaction
to succeed.

This is why I went with a simpler option in BIND 9.10.  I don't see
NOCOOKIE ever being sent on the Internet as there is no control of
the clients.  MFCOOKIE is FORMERR.  BADCOOKIE has its own failure
modes.

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