Re: [DNSOP] Summary of the two options in draft-ietf-dnsop-cookies?

Mark Andrews <marka@isc.org> Sun, 29 March 2015 19:47 UTC

To: Paul Hoffman <paul.hoffman@vpnc.org>
From: Mark Andrews <marka@isc.org>
References: <683E2720-66F7-4B45-8787-99BD93FA2496@vpnc.org>
In-reply-to: Your message of "Sun, 29 Mar 2015 10:30:09 -0700." <683E2720-66F7-4B45-8787-99BD93FA2496@vpnc.org>
Date: Mon, 30 Mar 2015 06:47:45 +1100
Message-Id: <20150329194745.D04872C16298@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/IsRj0z8iiBaR2RbjswAQOD3iW_w>
Cc: Donald Eastlake <d3e3e3@gmail.com>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Summary of the two options in draft-ietf-dnsop-cookies?
Precedence: list

In message <683E2720-66F7-4B45-8787-99BD93FA2496@vpnc.org>, Paul Hoffman writes
:
> Greetings again. Can one of you summarize the differences between
> sections 4/5 and 6/7 in the recent -01 draft? It seems that the error
> code processing in 4/5 might either be useful or overkill.

I can't think of a good use for the error codes which is why I
didn't add them to SIT.  They are in -01 so the group has the two
formats written down for evaluation.

BADCOOKIE 

The senarios I can see that would result in this being sent are:

a) The server is under attack
b) The client has a old cookie
c) Mismatched cookie generation between a anycast instances

and the client can retry with the cookie from the response
or stop sending cookies.

A legitimate client doesn't see the (a) responses.  
For (b) retrying should succeed.  That said tc=1 would also be just as
effective at triggering a retry.
For (c) you are likely to get dueling servers and not progress to
giving the client a valid response.  The client will have to maintain
a BADCOOKIE response counter and then fallback to not sending a COOKIE.

MFCOOKIE

The senarios I can see that would result in this being sent are:

a) The server is under attack
b) The client is badly coded

This should really be a FORMERR if the option length is invalid.

NOCOOKIE

This is just a more precise REFUSED and needs to be a rcode if we
need this level of precision.  Spontaneously adding a cookie opt
to a reply without one doesn't help clients that don't understand
cookies.  Additionally it will be decades before anyone could set
this on the Internet.
 
> A related question for Don: how close are you to getting
> draft-eastlake-fnv published? For me, it is mandatory for that draft to
> be stable (and hopefully published) before we publish
> draft-ietf-dnsop-cookies in order to make developers comfortable in
> deploying cookies without possibly opening servers and clients to CPU DoS
> attacks.
>
> --Paul Hoffman
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

[DNSOP] Summary of the two options in draft-ietf-… Paul Hoffman
Re: [DNSOP] Summary of the two options in draft-i… Mark Andrews
Re: [DNSOP] Summary of the two options in draft-i… Donald Eastlake
Re: [DNSOP] Summary of the two options in draft-i… Evan Hunt
Re: [DNSOP] Summary of the two options in draft-i… Mark Andrews
Re: [DNSOP] draft-eastlake-fnv Tony Finch
Re: [DNSOP] draft-eastlake-fnv Donald Eastlake