[quicwg/base-drafts] Clarify padding of INITIAL packets (#3255)

Robin Marx <notifications@github.com> Mon, 18 November 2019 04:04 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BD1120876 for <quic-issues@ietfa.amsl.com>; Sun, 17 Nov 2019 20:04:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ccb_CSHiWHF for <quic-issues@ietfa.amsl.com>; Sun, 17 Nov 2019 20:04:35 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B051208BF for <quic-issues@ietf.org>; Sun, 17 Nov 2019 20:04:34 -0800 (PST)
Date: Sun, 17 Nov 2019 20:04:34 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1574049874; bh=hnn3QwhyXE4WJbcx8MIdwhi31mqJobPrPR4ZV+ImtTE=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=OdOYftOy4YwlJwYzcOJuvVqZ3X8vMTOtmRIMsNAucUNmRzo3q0Mfc3gAPyKO+Mhjx nZcv/6SauctLfYoUdfRfPli9w0yLP9bgXJ5Fp1PKd6iTKthnV5yRJIeQTCltkU6qaZ vtopNw/89HfSCNb0EVLZtyOLULgtNoHr413PkMh0=
From: Robin Marx <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3YJYIFZJQSIFKBW4N335FNFEVBNHHB6PLW5A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3255@github.com>
Subject: [quicwg/base-drafts] Clarify padding of INITIAL packets (#3255)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dd21852254d2_68463fa191ecd96c15147a2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: rmarx
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/QNVDOCd-TRk2bMMSJpzMbwmbeuI>
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: Mon, 18 Nov 2019 04:04:42 -0000

Following a discussion on Slack (cc @jlaine, @nibanks, @rpaulo ), I feel a clarification might be needed on how/which INITIAL packets should be padded to 1200 bytes.

E.g.,  https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-8.1 states:

> Clients MUST ensure that UDP datagrams containing Initial packets
   have UDP payloads of at least 1200 bytes, adding padding to packets
   in the datagram as necessary.

Some people (cc @nibanks) interpret this to mean ALL packets containing initials should be padded (e.g., also an initial ACK from the client to the server) and not just the first initials with crypto data from the client. 

However, https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-14 somewhat contradicts/restates this:

> The payload of a UDP datagram carrying the first Initial packet MUST
   be expanded to at least 1200 bytes, by adding PADDING frames to the
   Initial packet and/or by coalescing the Initial packet (see
   Section 12.2).

@nibanks said he feels this should be removed/restated.

I personally don't know why ALL initials should be padded outside of the first flight... @nibanks mentioned the stateless LB use case, where they could drop all initials < 1200 bytes, though I'm not sure why a LB would do this... @rpaulo mentioned that padding the client's initial ACKs gives additional allowance towards the 3X amplification factor limit, but as those intitial ACKS will arrive with/close to the client's first handshake packet (which validates the path, IIUC, https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-8.1). 

Either way, I feel the text should be tightened to clarify the intended use.
Full disclosure: we're working on some dirty stuff that spoofs/abuses QUIC initials to carry in-band metadata, so we'd really not like intermediaries dropping < 1200 byte initials by default. 


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3255