IETF Logo Mail Archive

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

神明達哉 <jinmei@wide.ad.jp> Thu, 13 September 2018 18:25 UTC

Return-Path: <jinmei.tatuya@gmail.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 BA419128B14; Thu, 13 Sep 2018 11:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.524
X-Spam-Level:
X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.146, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 gPR0uZaHfpvN; Thu, 13 Sep 2018 11:25:18 -0700 (PDT)
Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (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 C7C61130E4C; Thu, 13 Sep 2018 11:25:17 -0700 (PDT)
Received: by mail-lj1-f176.google.com with SMTP id j19-v6so5412722ljc.7; Thu, 13 Sep 2018 11:25:17 -0700 (PDT)
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=JA0CXdKW5Leq53m1UdP6fSuQZVwcwg5nc+YKkKvoSbM=; b=HcxcDUXazaT3W7XZgjy5n6En9FDHIfgzVoQ2hPyP09vSiq5zEaNoU3Du4TmniNBLmC dH0U8LMpXnlnOtdRpnHO5UYesDZ5nnVwdJRCXqF5aYEPF1Mfp7SsTmowK/C07InaoD+Y wt9uhpes/T+we6/FgW6ijF6IjMj1oPKWwfHDzHonc5cMsZMzBJXsSrk7dtasneIhG7M2 wG0IYxhiMugFhqz392WkQylJmjuO4NiVf/2Oz8iYBqK3Rppym8BhU8T4iv9uzY17fpeQ TiVnwC4wUMDtEYrBK1PiojfO2rab0APaJpXs5rTuCbPWAkQyl2UjeySlmsqkG35Dlrkb W5xA==
X-Gm-Message-State: APzg51AIxz6OwRfKONryXAjckDkhU5rYKSO/V/hZFPxt7NUYpgpsNbw9 ieIO093XSGw1Gd17qdpsHbWW7uhZwdtVLEOj5wg=
X-Google-Smtp-Source: ANB0VdYvyuDhpcMARw8VdkWMRjpiDBSLimoAPRqEsYVR4IsieGzGNLE2vwK8CamVcapGj7evqGy6GgDvo713eiQS+Es=
X-Received: by 2002:a2e:7113:: with SMTP id m19-v6mr5359088ljc.66.1536863115768; Thu, 13 Sep 2018 11:25:15 -0700 (PDT)
MIME-Version: 1.0
References: <153658244644.26649.463764101726763839.idtracker@ietfa.amsl.com> <CAN6NTqwTt5SZ=_69kAd31qEtFKnZsOu7sShy26uOoShZtyJkkQ@mail.gmail.com> <3EBC432D-6B59-4560-82B8-9CBA449068CA@kuehlewind.net>
In-Reply-To: <3EBC432D-6B59-4560-82B8-9CBA449068CA@kuehlewind.net>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Thu, 13 Sep 2018 11:25:03 -0700
Message-ID: <CAJE_bqcnAhvQDg_KmoSGfBOeKJROkNUrxj=+===8A3EGcSHKvw@mail.gmail.com>
To: ietf@kuehlewind.net
Cc: Ólafur Guðmundsson <olafur@cloudflare.com>, Tim Wicinski <tjw.ietf@gmail.com>, draft-ietf-dnsop-refuse-any@ietf.org, dnsop <dnsop@ietf.org>, dnsop-chairs@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000157a410575c4d415"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GamWXdeFLUwDMCUXLMoVfb0nL4g>
Subject: Re: [DNSOP] Mirja Kühlewind's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)
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 18:25:20 -0000

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

v2.23.0 | Report a Bug | By Email