Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

Ólafur Guðmundsson <olafur@cloudflare.com> Thu, 13 September 2018 21:26 UTC

Return-Path: <olafur@cloudflare.com>
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 1584E130E7C for <dnsop@ietfa.amsl.com>; Thu, 13 Sep 2018 14:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.03
X-Spam-Level:
X-Spam-Status: No, score=-1.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 t1bFw70f0y4u for <dnsop@ietfa.amsl.com>; Thu, 13 Sep 2018 14:26:07 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 26BE4130E80 for <dnsop@ietf.org>; Thu, 13 Sep 2018 14:26:07 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id n2-v6so8197197wrw.7 for <dnsop@ietf.org>; Thu, 13 Sep 2018 14:26:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7tu/PR+dUAawrWqh3qvboz1kU1FAGhr7iM+yfdCRiOM=; b=wZEN7CIUFr7ayr5/o+2obWHIxl/gWIqud5nwX5C285AMQUNJU+luV1JnKCOIm+XmYQ YRAyTwAue2c38v2/+Mu0Fm/qEPahdQlsNnq4nYuXy5dmU+L0EjY7uLiqHx0GiqyDgXcR HrowVFXOXubNUBABkYktI7HHmoMQ3knJVqwGU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7tu/PR+dUAawrWqh3qvboz1kU1FAGhr7iM+yfdCRiOM=; b=kR4r/Nzk5ByLiVzqJGrD8N1OQXPLkpZZQF23JN93UNcLF6NryvFTLhFOqsmf7OKTdZ fXAu5QxuN3o7iuFZ+IETq/HquAryOZsEES70NP6sDZkFmuXn3yv5dX/Cnt1nv1n5D/eH ndLipyE9gdNvNxq9ywZNBzdxS4FFDCwErociFMq/eSQFn1uuFiYYWBdfOocv6xSOOStO ztmupKmUK1ap8aJpSTxSaUeRXjCoWdmJT+pK9HvmMVCi6+nS4YuYUkob1kouJdfIQZO+ a6iq2oTRyxh1mRkGwUqdjv7mzPW2WD4iU7M1ygEgazJTe7UclRLvD8dZRU/f1QhYcA/A 0IPA==
X-Gm-Message-State: APzg51CZAMHGQ42zo6A7N5DlEjKX6DXWBSMFMbowoykSc6NvyLT+0re/ Fu1atalEdlFri+oICdQVh9dqir7694IIuQ2Gmcodfg==
X-Google-Smtp-Source: ANB0VdZBo2ZVVdvaR4OCY0XQW0kxd9trXMHIG53vsbChHvYB8K2QeMZ9NyIV5u8+ZLkmgkmiJ/Vb6dAmIMDyWKcG4WQ=
X-Received: by 2002:adf:9d81:: with SMTP id p1-v6mr6864285wre.12.1536873965425; Thu, 13 Sep 2018 14:26:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:adf:e451:0:0:0:0:0 with HTTP; Thu, 13 Sep 2018 14:26:04 -0700 (PDT)
In-Reply-To: <CAJE_bqcnAhvQDg_KmoSGfBOeKJROkNUrxj=+===8A3EGcSHKvw@mail.gmail.com>
References: <153658244644.26649.463764101726763839.idtracker@ietfa.amsl.com> <CAN6NTqwTt5SZ=_69kAd31qEtFKnZsOu7sShy26uOoShZtyJkkQ@mail.gmail.com> <3EBC432D-6B59-4560-82B8-9CBA449068CA@kuehlewind.net> <CAJE_bqcnAhvQDg_KmoSGfBOeKJROkNUrxj=+===8A3EGcSHKvw@mail.gmail.com>
From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>
Date: Fri, 14 Sep 2018 08:26:04 +1100
Message-ID: <CAN6NTqxPW8+0tLSj06qRkk9A7qP6XzT7e5+Myj7vskUmwL=mhQ@mail.gmail.com>
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>, Tim Wicinski <tjw.ietf@gmail.com>, draft-ietf-dnsop-refuse-any@ietf.org, dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c62a620575c75a9b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Du9UfKotd-CH10mP184WmOpO-Og>
Subject: Re: [DNSOP] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Yes_on_draft-ietf-dns?= =?utf-8?q?op-refuse-any-07=3A_=28with_COMMENT=29?=
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 13 Sep 2018 21:26:10 -0000

Jinmei explained perfectly what I was trying to say

Olafur


On Fri, Sep 14, 2018 at 5:25 AM, 神明達哉 <jinmei@wide.ad.jp>; wrote:

> At Thu, 13 Sep 2018 17:25:04 +0200,
> "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>; wrote:
>
> >>> I'm wondering if it would make sense to provide stronger guidance that
> the
> >>> conventional ANY response SHOULD be provided if TCP is used as TCP
> already
> >>> provides a retrun routability proof...? Also maybe provide a refernce
> to
> >>> RFC7766?
>
> >> This has nothing to do with "retrun routability"  if big answers
> >> are given to resolver via TCP then the resolver can be used as
> >> amplifier and there Millions of those on the net.
>
> > With TCP you usually set up a TCP connection (3-way handshake) then
> > send the request on that connection and get the reply on that
> > connection. You can not change the IP address in the mean time. So
> > there should not be that amplification attack anymore. That was what
> > I was saying.
>
> (I'm not intending to speak for him but) I guess what Ólafur intended
> to say is that if a legacy (so not implementing dnsop-refuse-any) and
> open resolver sends an ANY query over TCP and gets and caches the
> large "conventional" response, that resolver can be exploited as an
> amplifier for subsequent ANY queries with a forged source address (and
> quite likely over UDP).  If so, that's true, but I don't think it
> trivial to force such a resolver to send the ANY query over TCP in the
> first place, and the argument against "a return of routability proof"
> doesn't seem to be strong enough.  In fact, I'd interpret Section 4.4
> of draft-ietf-dnsop-refuse-any-07 as it allows the conventional ANY
> response over TCP exactly thanks to this return of routability proof
> (this "responder" is much less likely to be exploited as an amplifier
> thanks to that).  If the intent of this section has really nothing to
> do with that, I'd like to see some explanation about the actual intent
> in the document.
>
> Whether we *SHOULD* (rather than MAY) allow the conventional response
> in case of TCP is a different question, on which I don't have a strong
> opinion.
>
> --
> JINMEI, Tatuya
>



-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com