Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

On Thu, Jun 21, 2018 at 10:36 AM Mark Andrews <marka@isc.org> wrote:

>
> > On 21 Jun 2018, at 12:25 am, Petr Špaček <petr.spacek@nic.cz> wrote:
> >
> > On 20.6.2018 16:10, Paul Wouters wrote:
> >> On Wed, 20 Jun 2018, Petr Špaček wrote:
> >>
> >>> it seems that current specification of DNS cookies in RFC 7873 is not
> >>> detailed enough to allow deployment of DNS cookies in multi-vendor
> >>> anycast setup, i.e. a setup where one IP address is backed by multiple
> >>> DNS servers.
> >>>
> >>> The problem is lack of standardized algorithm to generate server
> >>> cookie from a shared secret. In practice, even if users manually
> >>> configure the same shared secret, Knot DNS and BIND will use diffrent
> >>> algorithm to generate server cookie and as consequence these two
> >>> cannot reliably back the same IP address and have DNS cookies enabled.
> >>>
> >>> One of root server operators told me that they are not going to enable
> >>> DNS cookies until it can work with multi-vendor anycast, and I think
> >>> this is very reasonable position.
> >>>
> >>> So, vendors, would you be willing to standardize on small number of
> >>> server cookie algorithms to enable multi-vendor deployments?
> >>
> >> I think this is a good idea but there are already two examples in RFC
> >> 7873 for cookie generation. Is there a problem with those examples, or
> >> is there only a lack of options in the implementation to configure
> >> these? If the latter, than no new IETF work would be needed.
> >
> > These are mere examples and not specifications with all the details
> > necessary for reliable interoperability.
> > E.g. when a cookie is "old" according to B.2.?
>
> I really depends on the algorithm being used.
>
> > E.g. are there privacy considerations with plain HMAC vs. encryption?
>
> Not the way AES is being used.
>
> > Besides this, BIND defaults to AES-based algorithm which is not
> > specified in the RFC and Knot DNS has its own because developers
> > considered the BIND's approch overkill.
>
> What does it matter what the default algorithm is.  Unless you are
> running a anycast cluster IT DOES NOT MATTER.  If you are running
> a anycast cluster you just needs to make sure all the server are set
> up the same way.
>
>
There are a number of anycast clusters which run different implementations
on the same IP.

As an example: https://www.ripe.net/analyse/dns/k-root
"A K-root node consists of one or more servers running BIND, Knot or NSD."

Unless I'm missing something obvious, it would be good having cookies be
valid when you e.g happen to hit a node in Lyon then a node in Geneva
(because of routing changes).

W

> > If we decide to standardize we need to find a reasonable algorihm and
> > standardize all its variables to make it work without run-time
> > synchronization (posssibly except key rotation but it can be done
> > avoided as well).
>
> BIND implemented 3 algorithms.  All three were similar.  The only
> difference was how the hash is generated.  The hmac-sha1 and hmac-sha256-8
> take identical inputs.  AES is slightly different because it is AES.
>
> > This message is for other DNS vendors to see if there is an interest in
> > standardizing something we can all share and operators use in practice.
> >
> > --
> > Petr Špaček  @  CZ.NIC
> >
> > _______________________________________________
> > 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: marka@isc.org
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf