[quicwg/base-drafts] Can Initial/0-RTT CIDs safely be used for routing? (#2026)

Mike Bishop <notifications@github.com> Tue, 20 November 2018 19:01 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 []) by ietfa.amsl.com (Postfix) with ESMTP id C3479130DCD for <quic-issues@ietfa.amsl.com>; Tue, 20 Nov 2018 11:01:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3FzRL8alJauM for <quic-issues@ietfa.amsl.com>; Tue, 20 Nov 2018 11:01:50 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8F0130DC7 for <quic-issues@ietf.org>; Tue, 20 Nov 2018 11:01:50 -0800 (PST)
Date: Tue, 20 Nov 2018 11:01:50 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1542740510; bh=L6t+2a/OgLQmgypWOGNLVhjAhq7yVba+xGgQ/1rFD/k=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=xQ1B57opO+/MOt+eMo1BaSevXFkKulZcV1aKvuMsyXqmcF8NIqVQT3qJaqXxQ4qQM 4DvZza7mVEUv+lLVZf+PCIYvWG3UoS+vZzzL83Nv+ckB6EnPpRPbdjEry9NfL/pQd/ tEI8bQeAJCampXfHrSgP1FY9ojssjtcUZ9e5V8FE=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab06c67b607a29ae11d94a6f4fe5d254b16f920d9392cf00000001180c1c1e92a169ce16d12586@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2026@github.com>
Subject: [quicwg/base-drafts] Can Initial/0-RTT CIDs safely be used for routing? (#2026)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bf45a1ed84f_29133fa8c54d45c4758ae"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/neL9ZUg7DYGL7RioGvi8juwtDMY>
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, 20 Nov 2018 19:01:53 -0000

In Section 7.2, the spec makes an implicit assumption that the CID of the Initial packet is used for routing:
> A client SHOULD select a Destination Connection ID length long enough to fulfill the minimum for every QUIC version it supports. **This increases the chance subsequent Initial packets are routed to the same server.**

 #2008 makes this even more explicit:
> To enable consistent routing through the subsequent Initial packets are routed to the same server.	handshake, a client SHOULD select an initial Destination Connection ID length long enough to fulfill the minimum size for every QUIC version it supports.

However, in the discussion of #1486, part of the conclusion was that, to protect from malicious clients, load balancers cannot safely permit client-chosen fields to influence the routing of their packets to a particular server.  IIRC, this was also discussed in New York as part of the #1486 discussion.

Did we mean that?  If so, we have conflicting text.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: