Re: [quicwg/base-drafts] Clarify initial UDP datagram padding (#2519)

Martin Thomson <> Thu, 14 March 2019 01:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 270AA131162 for <>; Wed, 13 Mar 2019 18:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uTY4sz1dkswY for <>; Wed, 13 Mar 2019 18:43:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF6E7131164 for <>; Wed, 13 Mar 2019 18:43:30 -0700 (PDT)
Date: Wed, 13 Mar 2019 18:43:29 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1552527810; bh=tq6ig3u+0Y5UtVllYETQ+/al9b4dWvTkuup7TMZGLLk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pqmrmL7ILe/fZTRbFVQwUaYHhfKqBYvZgcqVIDHdahosHmv7kHwlWKD+qLU172x4T J8Jcbr07TeEdE0PtU0FrDrOQUqTKRUEK4LAhv/0q26jO6HbFfcFZNjQQjJ+tG0vBHY CpXdt4BkNqJPvVEU7d9PIWsOF98Yj67uruW1EWig=
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2519/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Clarify initial UDP datagram padding (#2519)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c89b1c1da35f_55123ffb9a2d45bc258092"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Mar 2019 01:43:33 -0000

tl;dr: we should always pad to 1200 for UDP datagrams that contain Initial packets.

The reason we pad to 1200 is to provide a server with plenty of inbound bytes so that it can send outbound bytes prior to path validation.  Padding to 1200 has sub-optimal performance in certain cases.  In particular, it makes datagrams containing a simple ACK enormous.  So the original thought was to try to find a case where we could allow for smaller datagrams to be sent.

I think that in both alternative designs we have a problem with the interaction with our DoS defense.  And while those problems might only exist in the abstract for now, I think that the best answer is to pad to 1200 always.

(I will suggest rewording the text separately.)

### Details

An ACK-only Initial packet is sent at the tail of the Initial phase.  That is the obvious candidate for consideration here.  But there are other cases where small Initial packets might be sent.

The looser requirement @kazuho suggests is less than ideal for HelloRetryRequest.  A client can receive a HelloRetryRequest and be forced to send another ClientHello.  We can't assume here that the server is using the HelloRetryRequest to validate the client address (though it certainly can).  

If the ClientHello message is small, the number of bytes that a server can send is still limited.  If the client doesn't pad, the server can still count the original ClientHello toward its budget, but it doesn't get significant additional budget from the client.  And that budget doesn't increase when packets are lost.  So it could be that the server is stuck with 3x whatever it gets in ACKs, which is not a lot.

It's worse if you consider the possibility of the ServerHello being enormous (hello PQ crypto). At this point, the server won't have validated the client address and so is still limited in what it can send.  Ideally, we want the packets to be big so that the server gets more budget for sending and isn't limited to sending tiny packets.  But if all the client sends is small ACK-only packets (under either proposed amendment, either what @ianswett or @kazuho describe), the increased allowance is very small. 

Based on this, I would suggest that we reluctantly say that all Initial-carrying datagrams need to be 1200 bytes or more.

For the case of the ACK at the tail, most of the designs proposed for key discard will result in that packet not being sent.  If it is sent, there are plenty of cases where it will be a packet with Initial (ACK), Handshake (ACK + ...Finished) and 1-RTT data, so the requirement is met without wasting bytes at all.  But for ACK of big ServerHello messages or HelloRetryRequest, the overhead is regrettably necessary.

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