IETF Logo Mail Archive

Re: [quicwg/base-drafts] Padding requirement seems to be incorrect. (#3053)

ekr <notifications@github.com> Tue, 01 October 2019 20:44 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 F2AFD12006F for <quic-issues@ietfa.amsl.com>; Tue, 1 Oct 2019 13:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.281
X-Spam-Level:
X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, 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
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 d391ZmN_7Goo for <quic-issues@ietfa.amsl.com>; Tue, 1 Oct 2019 13:44:33 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A11E1200C1 for <quic-issues@ietf.org>; Tue, 1 Oct 2019 13:44:33 -0700 (PDT)
Received: from github-lowworker-9bcb4a1.ac4-iad.github.net (github-lowworker-9bcb4a1.ac4-iad.github.net [10.52.25.84]) by smtp.github.com (Postfix) with ESMTP id 578916E0475 for <quic-issues@ietf.org>; Tue, 1 Oct 2019 13:44:32 -0700 (PDT)
Date: Tue, 01 Oct 2019 13:44:32 -0700
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4TLATVU437EZAHLBN3UD5UBEVBNHHB3EM4KU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3053/537222069@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3053@github.com>
References: <quicwg/base-drafts/issues/3053@github.com>
Subject: Re: [quicwg/base-drafts] Padding requirement seems to be incorrect. (#3053)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d93bab030a6d_65103f8a2e4cd964154634"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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/U_VWjWsfMZfjNVkzG6inmWyq9sA>
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: Tue, 01 Oct 2019 20:44:36 -0000

> I think the specification should mandate padding of server initial packets as well.
> 
> When I was traveling a couple weeks ago, I was on a network where, when using IPv6, it allowed 1200-byte UDP packets through from client to server but blackholed them from server to client. Since our implementation pads initials in both directions, we were able to detect this failure during the handshake and fall back to TCP/TLS. If the server didn't pad its initials, we would have succeeded at the handshake but never gotten an HTTP response.

This *definitely* seems like a design issue. The purpose of the padding rule is solely to limit amplification, not to establish a minimum MTU. If you want some sort of MTU rule, that should be discussed separately.



-- 
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/3053#issuecomment-537222069

v2.23.0 | Report a Bug | By Email