Re: [quicwg/base-drafts] Long Header Packets and Routing Connection IDs (#2834)

Kazuho Oku <notifications@github.com> Mon, 24 June 2019 22:02 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 67BB31201ED for <quic-issues@ietfa.amsl.com>; Mon, 24 Jun 2019 15:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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_IMAGE_ONLY_28=1.404, 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 LZMdhQPKXsvF for <quic-issues@ietfa.amsl.com>; Mon, 24 Jun 2019 15:02:02 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BFB1201E8 for <quic-issues@ietf.org>; Mon, 24 Jun 2019 15:02:02 -0700 (PDT)
Date: Mon, 24 Jun 2019 15:02:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1561413721; bh=QYlgvZym4TXjnM9klhR0Lyq33Xtb98/0TlfrwlE5O34=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Mkf0EZzAuztm3jn3YVc0eHTVmST2NIYD1YaZJk4bRr8QaE27KqL1DxW8gfb+H+Qrp KOhv5nBzRBHAJ0XJWeBGdZLUudM/okDwihzYj6wLyIRJ7kzbjdVVwsZE4P4vCdc87v +SFnZk7h0694H6lMdKMDYeO/+hzIuApOC1jMy6Pw=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKY5SARNRUDP36UGGY53DZ5NREVBNHHBWZGHNE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2834/505198558@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2834@github.com>
References: <quicwg/base-drafts/issues/2834@github.com>
Subject: Re: [quicwg/base-drafts] Long Header Packets and Routing Connection IDs (#2834)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d114858f239c_4fff3fc1884cd96451664e"; 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/DrMPIuwNO2rMcUtUixfVoxBddTY>
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, 24 Jun 2019 22:02:04 -0000

> Also, while I agree that an auth tag would likely be a solution, I do not believe it is acceptable that the only way to statelessly (and securely) load balance Long Header packets is to have an auth tag as part of the CID. We should allow for less complex designs.
> 
> Being able to route based on the CID consistently just by looking at the long header bit and then interpreting the destination CID accordingly would definitely make for simpler load balancing. It could even be version independent. I find the idea of a version independent LB very attractive.

Routing packets based on client-chosen CID is vulnerable to DoS attacks, compared to routing based on server-chosen CIDs (the way I've described in my previous comment).

Besides, if you are fine with routing packets based on client-chosen CID, I'd assume that you'd also be fine with routing long header packets based on the 5-tuple.

Assuming that is the case, it is my view that *not* applying CID change to long header packet narrows the designs we can choose with no practical merit.

-- 
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/2834#issuecomment-505198558