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

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sun, 2 Jul 2006 22:41:33 -0400

See below at @@@

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of John Kristoff
Sent: Friday, June 30, 2006 4:16 PM
To: [email-masked]
Subject: Re: draft-eastlake-dnsext-cookies-00.txt

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 
> http://www.ietf.org/internet-drafts/draft-eastlake-dnsext-cookies-00.t
> xt 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.

@@@ Sure, comments are useful.

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.

@@@ They actually sent two response messages (with the same ID
presumably) to one query? Sounds odd to me. Just ignoring an Additional
Information RR you don't understand and processing the rest of the query
seems like the right thing to me.

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?

@@@ This was just a -00 draft. There are quite a few details that need
to be filled in, such as the priority of the inclusion of COOKIE RRs,
what their owner names, TTL, and CLASS should be (I'm inclined to say
these are ignored), any recommendations related to using multiple types
of DNS security, examples of message sequences, etc.

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".

@@@ I should think that servers would want to reduce the amount of work
they have to do including having to send out big answers. This is
especially true for recursive servers and servers that support DNSSEC
and even more so for recursive servers that support DNSSEC. If this idea
were adopted, how quickly servers would change to which mode I don't
know. But it seems to me that if they have some resolvers they want to
provide service to but that have not implemented COOKIEs but want the
benefits for other resolvers, going to enabled mode makes some sense.

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.

@@@ Nope, I don't think there is any race condition. If you do cache a
cookie for the other side, it never needs to expire. It might get pushed
out due to a cache congestion and it might get overridden by a new
cookie but there is no reason to expire it just due to the passage of
time. The server always reflects back the query resolver cookie in its
response so there is no reason for it to cache it except as part of the
indexing to its server cookie for that resolver to save hash
computation. The resolver does not believe a server cookie it receives
unless accompanied by a correct resolver cookie. If the server cookie is
one it should so believe in, it can override any cached server cookie.

@@@ I'll try to get a bunch of examples into the next version to show
how all this works.

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).

@@@ Due to inclusion of the IP address, a server should always check the
COOKIE, if present first. If bad, it returns an error. If good, it
processes the query. If that results in it transmitting a query, the
COOKIE RR it received is irrelevant and it should insert an appropriate
COOKIE to the query it sends, if called for by its policy with the
server it is querying, or send a query with no COOKIE if its policy for
the server so indicates.

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

@@@ I'd be happy for you to send them directly to me.

John

@@@ Thanks,
@@@ Donald

--
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: Mon, 3 Jul 2006 16:58:50 -0500

On Sun, 2 Jul 2006 22:41:33 -0400
"Eastlake III Donald-LDE008" <[email-masked]> wrote:

> However, I did find one case, where servers that fingerprint (fpdns)
> as a Microsoft Windows DNS 2000 implementation will first send back a
> presumably) to one query? Sounds odd to me. Just ignoring an

If you need some sample code, reply off list and I'll send you a
bit of Perl that uses Net::DNS to exhibit this behavior, but in the
meantime, the DNS server at 207.198.250.119 is just one example of
an implementation, which appears to do exactly that.  Here is what
I see:

  A query for motorola.com to 207.198.250.119 over UDP/53, including
  an additional section with an A record for foo.bar, type A, class
  IN with address of 192.0.2.1.  RD bit set.

First response echoes back the query indicating a format error.

An immediate second packet from the server, with the same ID, but this
time with an answer to the A query for motorola.  My particular resolver
does not expect this response, so it issues an ICMP destination port
unreachable back. I'll keep the pcap for a bit if someone thinks
I'm making this up.  :-)  I guess servers like this would make those
open recursive name server attacks that much more potent eh?  :-/

> Additional Information RR you don't understand and processing the
> rest of the query seems like the right thing to me.

Agreed, all other implementations I tried this agaist appeared to do
exactly that.

> don't know. But it seems to me that if they have some resolvers they
> want to provide service to but that have not implemented COOKIEs but
> want the benefits for other resolvers, going to enabled mode makes
> some sense.

It would seem that way, but I think we might find in practice it
won't be implemented that way.  As I was trying to point out, all
those resolvers that you have to "allow", will be precisely the ones
you would want using cookies.

> @@@ I'll try to get a bunch of examples into the next version to show

I think that will be helpful and I'll withhold further comments on this
particular issue til then.

John