[quicwg/base-drafts] Padding overhead in DNS over QUIC scenarios (#3523)

Christian Huitema <notifications@github.com> Sat, 14 March 2020 04:58 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 88D3B3A0DD1 for <quic-issues@ietfa.amsl.com>; Fri, 13 Mar 2020 21:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id JpPgYKI4JXLU for <quic-issues@ietfa.amsl.com>; Fri, 13 Mar 2020 21:58:17 -0700 (PDT)
Received: from out-21.smtp.github.com (out-21.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4E33A0DCE for <quic-issues@ietf.org>; Fri, 13 Mar 2020 21:58:17 -0700 (PDT)
Date: Fri, 13 Mar 2020 21:58:16 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584161896; bh=RTkWy+w8Ez7+2bU+z2jeUvrpzBeKgJ9vFDV48yentFI=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=nr4/+srPmgLCOQ89xa8qqoqp8v831r6r2V1345SEjvhu6jF8UqkuymDK6+mgfzI4z Go17D+0PUGevTXfutX1ttuVOtpdYIcrE8k812zq6ucm2FdijNG1pQySeMW/Cocy++o /QRAc7IBI4xcjdo4JuL2H3yk3QEYQAO5SDjlquOw=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK32WGLIIS6AISFNW2F4PBCWREVBNHHCFIPTEI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3523@github.com>
Subject: [quicwg/base-drafts] Padding overhead in DNS over QUIC scenarios (#3523)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e6c646880cf0_25d43ffda0ecd9608853f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/v0_2cROHyYcgtm7aeNx1AKwNK6Y>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Mar 2020 04:58:26 -0000

I am looking at DNS over QUIC scenarios. A common case would be a resumed session in which the client sends the short DNS query as 0-RTT data, and the server then sends the response after the session is confirmed. Assuming a service delay larger than 1-RTT, I expect to see something like:

1- Client initial + 0-RTT (DNS query), 1232 bytes, including 669 bytes of padding
2- Server Initial + handshake + 1-RTT (Crypto ticket, 2x new connection ID), 606 bytes
3- Handshake (finished) + 1 RTT (2x new connection ID) 222 bytes
4- Server 1RTT(handshake done) 55 bytes
5-Client 1-RTT(ACK) 55 bytes
6- Server 1-RTT (DNS response) 85 bytes

That's 2170 bytes total, of which 31% are the initial padding -- which is also 44% of the client's traffic. That's quite a bit of overhead. The question is, is that strictly necessary? 

Suppose for example that the server also provisions a "NEW TOKEN", maybe 40 bytes long. The server can verify the token when receiving the first packet, and validate the IP address. At that point, the concerns about DDOS are mostly mitigated. We could remove the 669 bytes of padding, at the cost of an initial token (1 byte length, 40 bytes data) and a NEW TOKEN frame (1 byte type, 1 byte length, 40 bytes data), i.e. a gain of 486 bytes. The client would send a total of 923 bytes instead of 1503, the total exchange would use 1584 bytes instead of 2170.

What do you think? Would it be OK to relax the "pad to 1200" rule when the Initial carries a valid token? Should we make that part of the main spec, or treat that as an extension?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: