Re: [DNSOP] Asking for TCP and/or cookies: a trend? (Was: my lone hum against draft-wkumari-dnsop-multiple-responses

Mukund Sivaraman <muks@isc.org> Thu, 21 July 2016 15:38 UTC

Return-Path: <muks@isc.org>
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 23C7412D520 for <dnsop@ietfa.amsl.com>; Thu, 21 Jul 2016 08:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 BUFwjf7IZAzb for <dnsop@ietfa.amsl.com>; Thu, 21 Jul 2016 08:38:55 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id E98B912D67B for <dnsop@ietf.org>; Thu, 21 Jul 2016 08:38:52 -0700 (PDT)
Received: from jurassic (unknown [115.118.214.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id B39BC2FA0377; Thu, 21 Jul 2016 15:38:49 +0000 (GMT)
Date: Thu, 21 Jul 2016 21:08:45 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Paul Wouters <paul@nohats.ca>
Message-ID: <20160721153845.GA13632@jurassic>
References: <b00ec4.3833.15606420d47.Coremail.yzw_iplab@163.com> <236F5488-42D4-4A89-ACAB-B55FD2B5782A@fl1ger.de> <20160720051949.8FC154EF155E@rock.dv.isc.org> <36A593C1-1F01-4FE1-BC9A-3279F6460358@rfc1035.com> <D65E8617-107E-4B13-986F-24088D0C57C2@powerdns.com> <20160721133730.GA10324@nic.fr> <alpine.LRH.2.20.1607211101590.17541@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp"
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.20.1607211101590.17541@bofh.nohats.ca>
User-Agent: Mutt/1.6.2 (2016-07-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Le2YCRecervfaNSqEqnlaKm_o5Q>
Cc: IETF dnsop WG <dnsop@ietf.org>, Peter van Dijk <peter.van.dijk@powerdns.com>
Subject: Re: [DNSOP] Asking for TCP and/or cookies: a trend? (Was: my lone hum against draft-wkumari-dnsop-multiple-responses
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 21 Jul 2016 15:38:57 -0000

Hi Paul

On Thu, Jul 21, 2016 at 11:10:10AM -0400, Paul Wouters wrote:
> And I have been wondering if we should allow for a DNS padding in the
> query packet to ensure answer packets (over UDP) are going to be
> smaller then the query packet. And therefore prevents DDOS
> amplification.

This has been mentioned before. Some thoughts:

For DNS, this can affect some cases such as query packets not making it
to the server due to size, lack of ability of the client to guess what
the answer's message size may be, and also EDNS UDP payload size
behavior.

In DNS over UDP and its poor-man's-pMTU-discovery, it's the client that
drives the discovery of what works - the server has no idea of whether a
query+answer roundtrip has succeeded in a reply successfully delivered
to the client, whereas the client does. The client can use this to tweak
the UDP payload size, but if the query itself may get dropped, it can't
tell if it was the query or the reply that disappeared - there is some
faith that an unpadded question-only DNS message will go through
somewhat reliably.

Once a client cookie has been established (associated with a source IP
address), there's no need to use padding, so perhaps this could be a
step in the initial handshake when the cookie is established - there
could be message size limits to these cookie-establishment query and
reply.

DJB's curveCP comes to mind about how it prevents amplification for the
initial handshake.

		Mukund