Re: [quicwg/base-drafts] One Retry/VN per UDP datagram (#2303)

Kazuho Oku <notifications@github.com> Mon, 07 January 2019 04:09 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 86611128D09 for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 20:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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: 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 d-qGit4hEH6v for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 20:09:24 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDCA127133 for <quic-issues@ietf.org>; Sun, 6 Jan 2019 20:09:23 -0800 (PST)
Date: Sun, 06 Jan 2019 20:09:22 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546834163; bh=oydrv601UMVltp5mQFcfUqxXIhCISDTbAtearWizqY0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=INg7x4VjcggcQNlxEKuy/BSZSsB6GuZoc1XBQumVUatctSekw8X5YYaEHvJ72pDmv GjycyRN1uUCMxCFKgspR/NhnxoYxsIdlLHTIHlxpfMBPwyjkb6W9VDNxOE6fN+x1Yy 5I50X9DPMxXBgRdSFtlJ73ENBi8NZCYK/ePgBi+0=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab43c65fb244cae2bac421e81f5059afa400015b9992cf00000001184a92f292a169ce179f536f@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2303/c451816576@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2303@github.com>
References: <quicwg/base-drafts/pull/2303@github.com>
Subject: Re: [quicwg/base-drafts] One Retry/VN per UDP datagram (#2303)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c32d0f2f22e6_26ef3f9aeb0d45c44608c2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/pc63_MFK0sfqDpw-C1t_ZCDGu0Q>
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, 07 Jan 2019 04:09:26 -0000

@marten-seemann Thank you for elaborating.

I think that we should be dispatching each QUIC datagram (instead of each QUIC packet) to the respective connections. That's how load balancers are expected to work, and what you are implementing is essentially a load balancer. The benefit of dispatching at the datagram level is that you'd have less things to do on the receiving thread.

> This wouldn't be a problem at all if a coalesced packet just had a few parts, as it's supposed to be. But since we're maximizing flexibility for no reason, an attacker might send me datagram consisting of around 70 packets, which I would all have to completely parse.

I understand your point on flexibility. However, in my view, the flexibility is not only how you coalesce, but the redundancy in all the long header fields. We have deliberately chosen the design because it is clear and easy to analyze (especially in regard to encryption). My preference goes to retaining the clarity by avoiding introducing restrictions.

-- 
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/pull/2303#issuecomment-451816576