Subject: Re: draft-eastlake-dnsext-cookies-00.txt

From: Kenji Rikitake <[email-masked]>
Date: Mon, 26 Jun 2006 16:04:30 +0900

In the message <[email-masked]>
dated Sun, Jun 25, 2006 at 11:08:05PM -0400,
Eastlake III Donald-LDE008 <[email-masked]> writes:
> http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-00.txt

> 4.1 Resolver Cookies

[...]

>    A resolver MUST NOT use the same Resolver Cookie value for queries to
>    all servers.

> 4.2 Resolver Cookies

[...]

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

The above "all requests" should "all resolvers" if the Section 4.1
says "all servers".

> 5.3 Implementation Requirements

>    DNS resolvers and servers MUST implement DNS cookies.

>    DNS resolvers SHOULD operate in and be shipped so as to default to
>    the Enabled or Enforced mode for all servers.

>    DNS servers SHOULD operate in and be shipped so as to default to the
>    Enabled or Enforced mode for all resolvers they are willing to
>    service.

While I agree with the idea that the cookie should be enforced as
possible, I also think making it a MUST as the first paragraph in the
Section 5.3 could not be feasible, regarding the number of current
non-cookie (or just Disabled in Section 5.2) DNS programs.  Any
perspective on the deployment issues?

Some questions come into my mind:

* How long (in time, e.g., seconds) or how many DNS packets is a server
or a resolver allowed to retain the same cookie to the other end (making
a pair of server-resolver relationship)?  I guess it depends on the
traffic which the server/resolver handles, though I think some minimum
values of cookie-rollover timing should be suggested.

* SHOULD/MUST a server/resolver change the cookie for each program on
the other end?

Regards,
// Kenji Rikitake

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: John Kristoff <[email-masked]>
Date: Fri, 30 Jun 2006 15:16:12 -0500

On Sun, 25 Jun 2006 23:08:28 -0400
"Eastlake III Donald-LDE008" <[email-masked]> wrote:

> So I had this idea for DNS cookies to help ameliorate traffic
> amplification, cache poisoning, etc. attacks. Anyway, I've written up
> my idea and the first draft is available as
> I'd be interested in people's comments.

This is a topic I'm interested in so I wanted to provide some feedback.
Hopefully it is helpful.

I did some experimentation with putting RRs in the additional section
of requests and found that most servers seem to silently ignore them.
However, I did find one case, where servers that fingerprint (fpdns)
as a Microsoft Windows DNS 2000 implementation will first send back a
FORMERR.  Though some servers stop there, I've seen others that then
follow up immediately with an answer if the query was otherwise valid.

In the case of adding a cookie to the additional section in a response,
what if there is no room for the cookie, particularly if the policy for
them is set to "enforced"?  Does it take precedence over other records?

My understanding of this draft is that this attempts to offset the
DoS reflection/amplification attack by trying to avoid having servers
respond to illegimate requests.  For the resolver, it attempts to
help avoid cache poisoning by essentially requiring an attacker to
forge another, hopefully not easily knowable, set of bits.  From the
perspective of minimizing the DoS attacks, the server has no incentive,
and in fact probably has a disincentive to set the policy to enabled,
rather than disabled or enforced.  The resolvers have some incentive
to set their policy to enabled.  Unless I'm missing something, there
is this policy disconnect that will prohibit deployment without the
impossible "flag day".

The whole notion of having to have the resolvers and servers "learn"
the cookies based on past queries and answers in the first place seems
problematic.  There seems to be a race condition here that an attacker
would be able to exploit, either by having the other side learn it's
illegimate cookie first or when a valid cookie expires.

In the case of a forwarding server, what should happen?  Will a cookie
be forwarded along with the request or should it be stripped, or even
stripped and replaced with a new cookie, while doing validation on
the cookie it received and vice versa with the original querier (if
it has support for any of this functionality at all).

I found a handful of small grammatical problems, shoot me and email
offlist if you want to hear about those at this stage.

John