Re: [quicwg/base-drafts] Padding outside QUIC packet (#3333)

ekr <notifications@github.com> Fri, 17 January 2020 18:46 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 16F5E120098 for <quic-issues@ietfa.amsl.com>; Fri, 17 Jan 2020 10:46:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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, URIBL_BLOCKED=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 j5X3b9O-FZjA for <quic-issues@ietfa.amsl.com>; Fri, 17 Jan 2020 10:46:34 -0800 (PST)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C993120025 for <quic-issues@ietf.org>; Fri, 17 Jan 2020 10:46:34 -0800 (PST)
Date: Fri, 17 Jan 2020 10:46:33 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579286793; bh=3tcWBysEdA707/OfCmETsIWr+KyBa69AkJoF5ki3vRs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iuHuwk7IlWvae6DediHZI6Jo4QbkFVYImJsn/lIHSkeWrSAkTAsn3ofUilKu1biYi vO/wgayLEKuZMkvl+TgqpFR8Vb1XJIF+QAqogYfcYzz17e/tli6mpwnzTNluMK3qth vMRU6FRxXLcaou+nHiIzt5hDQvVpY9nG94ZWfT5k=
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6Q4CSDRROTJZVZJIN4F4ZYTEVBNHHCBMO65M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3333/575748146@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3333@github.com>
References: <quicwg/base-drafts/issues/3333@github.com>
Subject: Re: [quicwg/base-drafts] Padding outside QUIC packet (#3333)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e220109666be_5b113fe74f6cd95c923db"; 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/64hQZYbr6apZZufO8Y5EaWJ0KQA>
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: Fri, 17 Jan 2020 18:46:36 -0000

Well, this is lawyering, but it doesn't say "by adding", but rather
"adding...as necessary". My argument here is that it's not necessary if you
pad in the datagram.

On Fri, Jan 17, 2020 at 3:36 AM Kazuho Oku <notifications@github.com> wrote:

> My point is that while I'm not against making an editorial change stating
> that a receiver should process coalesced packets of a datagram until it
> sees a broken packet, I would not prefer adding a statement that implies
> that a client might pad outside of QUIC packets, because doing so is might
> have negative effects, and trying to resolve those negative effects are
> likely to introduce complexity.
>
> To be clear, my understanding is that this issue is about a misbehaving
> client failing to talk to some servers. The specification says that an
> endpoint MUST expand the packet to 1,200 bytes by "padding to packets in
> the datagram as necessary," (section 8.1.3
> <https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1-3>)
> which explicitly means that padding should happen at the packet level, not
> at the datagram level.
>
> We might even argue that some servers not handling those broken datagram
> is a benefit, as it helps us find bugs in the client.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/3333?email_source=notifications&email_token=AAIPLIOSM5LNHTZ4JC3RV73Q6GJ2PA5CNFSM4KFV7MQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJHNKCA#issuecomment-575591688>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAIPLIP42EHA6Q3RX45QSHLQ6GJ2PANCNFSM4KFV7MQQ>
> .
>


-- 
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/3333#issuecomment-575748146