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

Warren Kumari <warren@kumari.net> Sat, 23 June 2018 02:27 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952D912F295 for <dnsop@ietfa.amsl.com>; Fri, 22 Jun 2018 19:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyv9KmZyn_cc for <dnsop@ietfa.amsl.com>; Fri, 22 Jun 2018 19:27:33 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D1B12F1AC for <dnsop@ietf.org>; Fri, 22 Jun 2018 19:27:33 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id p126-v6so3834656wmb.2 for <dnsop@ietf.org>; Fri, 22 Jun 2018 19:27:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Td+7wpaQAdsTQUafviSP+8MG/mI9a6d1Cr//ao20LMk=; b=AA9oEgAffE6cBlVSWRbdpkCMUCQX081rbH+F9ERskWYO2vQOTyOjR6FkJfTIM71bYc tFjkRLZOmDyGDVjQKwAFrOUTIddR6pIEphxoKy1cvRIG3XzXmPai6yYvMP1kIQtdREGP LLX6y8gjGxKB9y0uPklCSALzklU4IIUvBjBJ9FKjr4PDvyjlX39MDAtRa7mojvA+ieJW qg3UqflwBy5tx5VPvhlQjEX3s3LJSXr/gxQzabhV3npWYuQITZN/JuQeCA/BgVAye/yo OyqUBHUg0NJG019duJLA5N6Bx/7FQ5wwOgxrfjNtmDFRvqyVZuNYrMSnYjf+nZPcuqWu znzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Td+7wpaQAdsTQUafviSP+8MG/mI9a6d1Cr//ao20LMk=; b=Mk9ooXhL1DI45J/TfPVViNuSCPM1+VB15/wdHuEXBgcB0q9QrxgFLTuQZweT6dA5UQ dXez/LVT2qMOy37jT+Xo+Uvk+9G4Qp04QpkTGW3oyoRiMogSfQFmV0zrNIOAszvWhW9s AAEw2v0tjQ2abgHUBMZkhsfKAEdTNucwrfT/J2y93ZsiN/vy6hbCbvFN/AND0GDu1U+P dwiiE+5d6viKytUlf/CxD3PrJQCsBGu8UCbpz/l3pbhN9yF+hIBgzXObN/sKi/fvhdda 0QvoE6f0xeARCA/ezWknPomupHOw+ZQNSjPGQLyTofplb7onXQQp3zd7ByieoZteTsge xAOg==
X-Gm-Message-State: APt69E19CkRF8tTIGlXKR0e6H0jn3Af4FevyO61cLMYeET4yCoBIRgss nKnyVx763fhvxeqst2Cfm32FQMxOUWWlFzmYvdTqFA==
X-Google-Smtp-Source: ADUXVKJnKcJLDBc1jbx8iX8b5eXwVAJ9TML7R5O1+BO/42AFiSVJhUmnPwJrW/qX42Kqx7Kn39ykA7UBx5MiuBxyxqk=
X-Received: by 2002:a1c:d70c:: with SMTP id o12-v6mr3083819wmg.71.1529720851650; Fri, 22 Jun 2018 19:27:31 -0700 (PDT)
MIME-Version: 1.0
References: <c70f058c-8e82-f905-e352-f3e2fd0d4cfc@nic.cz> <alpine.LRH.2.21.1806201006530.6077@bofh.nohats.ca> <107c3532-a07d-9821-70ab-94c00a9dd2f0@nic.cz> <F6CB5212-461C-4E91-8E56-43B9E6377A7C@isc.org> <CAHw9_iLdsTPjxwm6Tpah0kMXwwM894SG+407Muv3AcN3js-ZbQ@mail.gmail.com> <20180623002916.GD83312@isc.org>
In-Reply-To: <20180623002916.GD83312@isc.org>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 22 Jun 2018 22:26:55 -0400
Message-ID: <CAHw9_iJqt7QVaCRJijm_TXPN7JDJQRPuUdW9ef96dzgQm43nXQ@mail.gmail.com>
To: Evan Hunt <each@isc.org>
Cc: Mark Andrews <marka@isc.org>, dnsop <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>, daniel.salzman@nic.cz
Content-Type: multipart/alternative; boundary="000000000000f7f4d0056f45e31c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/S8dxlLlp4Pxu_RZEq2CWpnL5b-4>
Subject: Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Jun 2018 02:27:36 -0000

On Fri, Jun 22, 2018 at 8:29 PM Evan Hunt <each@isc.org>; wrote:

> On Thu, Jun 21, 2018 at 11:19:55AM -0400, Warren Kumari wrote:
> > There are a number of anycast clusters which run different
> > implementations on the same IP.
>
> Sure, but as long as the algorithm is settable for each server in the
> anycast so that all of them can match, then I don't think it matters
> if the different implementations have different defaults, does it?
>

​Yup, as long as they can be set to be the same algorithm, and same inputs,
you are correct. ​

​I was responding to Mark's response to Petr (?):
>> 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.
​

I have not tried configuring cookie on Knot, but looking
in alg_containers.c, I can configure:
{ 0, "FNV-64" },
{ 1, "HMAC-SHA256-64" }

Under BIND:
cookie-algorithm:
Set the algorithm to be used when generating the server cookie. One of
"aes", "sha1"
or "sha256". The default is "aes" if supported by the cryptographic library
or otherwise
"sha256".

So, if I set both to use their (non-default) of SHA256 (and set the same
secret:-)) do they actually generate compatible cookies?
I'd guess / assume so, but I haven't tested this...
W



>
> --
> Evan Hunt -- each@isc.org
> Internet Systems Consortium, Inc.
>


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