Re: [quicwg/base-drafts] Spin bit should be applied per each 5-tuple rather than per connection (#1828)

Kazuho Oku <notifications@github.com> Wed, 03 October 2018 13:11 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 C89CF131029 for <quic-issues@ietfa.amsl.com>; Wed, 3 Oct 2018 06:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.455
X-Spam-Level:
X-Spam-Status: No, score=-8.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, 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, 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 7H2RkYy1v2J7 for <quic-issues@ietfa.amsl.com>; Wed, 3 Oct 2018 06:11:21 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121F4130FBD for <quic-issues@ietf.org>; Wed, 3 Oct 2018 06:11:21 -0700 (PDT)
Date: Wed, 03 Oct 2018 06:11:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538572279; bh=Fw/jLLgQVXt0HRiMAerDhRkp7H229qr5TZnT7ZHHkME=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Of9XRb2ZABzTh+E7pfxG+7oJorRjFCPdTWBqDFDctFLtFRB9lXPtGJobHMSkZDwX+ 4h6kUl2VNO2Evz/TAkU7kSxH6/8HyX60wc2YejaRnqGtgAHFLbPEZa/vtam1foxP3t cjmt4R9smAdMuSQYASLOqFRPHlXFd96SyWGT4hlo=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abdfbd5548b8526fbf60ff5858f7fa221c9d24ef3592cf0000000117cc81f792a169ce15d27d33@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1828/426631755@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1828@github.com>
References: <quicwg/base-drafts/issues/1828@github.com>
Subject: Re: [quicwg/base-drafts] Spin bit should be applied per each 5-tuple rather than per connection (#1828)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bb4bff7ce6b6_20a23f988e2d45b828725b"; 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/kln9H6RjH5a2sKA6p8Zr9HH5vlY>
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: Wed, 03 Oct 2018 13:11:23 -0000

> Actually two bridges could route traffic between two cloud private networks over a fixed 5-tuple. I'm not sure it is safe it mix any information across connections.

It is impractical (if not impossible) for an uncoordinated middlebox to coalesce multiple QUIC connections onto a single 5-tuple, even in case both endpoints use non-zero-length CIDs.

This is because, as I have stated, it is impossible for such a middlebox to track a connection across CID changes. Consider the case where a NAT is coalescing multiple QUIC connections coming from more than one client machine. When a CID change is initiated for one of the connections *by a server*, the NAT cannot determine to which client it should forward the packet that contains the new CID.

Therefore, my view is that it is safe for an observer running on the Internet to consider QUIC connection(s) using a 5-tuple to be a communication between two machines, and that it is safe to expect the Spin bit state to be shared among such connections.

FWIW, my expectation is that it would not be uncommon to see multiple QUIC connections coalesced onto one 5-tuple (at least that will happen when H2O/quicly is run as an edge server), and that spin bit design should take such deployments into consideration.

-- 
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/1828#issuecomment-426631755