Re: [quicwg/base-drafts] Client port for new connections (#2061)

Martin Thomson <notifications@github.com> Wed, 28 November 2018 08:55 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 1D8D9130E52 for <quic-issues@ietfa.amsl.com>; Wed, 28 Nov 2018 00:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 CJNpxu_L86LG for <quic-issues@ietfa.amsl.com>; Wed, 28 Nov 2018 00:55:54 -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 C205B130E4F for <quic-issues@ietf.org>; Wed, 28 Nov 2018 00:55:54 -0800 (PST)
Date: Wed, 28 Nov 2018 00:55:53 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543395353; bh=C+STQ6jo7vPrQJ+VLh5Pb8SaIyqBswL7QbVWcl8gtC0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=T5euTFsqDNJg4W45iIfe3sPZnBjxrRYQf3a5fzLuPOpuX6cCQ6L5qgp3BgZ1SNpd0 9g+LlbUi5+z+zLprAwMx2iZdzQaCYkiD4tycqdXvhXa7tRGcmTR/Iuns/OUELrHmtH 7M/29E+aDwgjuzj7XQyRRzT9TVVMV4nTXUYSPHj4=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab1b0ffe62332b1ad50f5e0367733cacae4ee4cb0c92cf0000000118161a1992a169ce16f48073@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2061/442369044@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2061@github.com>
References: <quicwg/base-drafts/issues/2061@github.com>
Subject: Re: [quicwg/base-drafts] Client port for new connections (#2061)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bfe5819dc2e2_60753f97136d45b855574"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/VYG9IHGd5H2zaQUyyW7u5uqmcRY>
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, 28 Nov 2018 08:55:56 -0000

There are a whole bunch of trade-offs here that we need to be cognizant of.  Using the same port could be a proxy for "same device" even in the presence of NAT, which is a nice linkability signal, where the NAT would otherwise create some uncertainty about that.  For connections from the same host, same port indicates "same application".  Using the same port also means that you need to use connection IDs, which is less efficient.

We do already have advice about changing source port after a period (along with a new connection ID), which addresses the final point.  Combining that with advice on reusing ports complicates things a little because you need to observe quiescent period across multiple connections (maybe, I don't know how this might look).

All in, I think that it's probably best to let a system of best practices evolve around this rather than stipulate any specific behaviour.

-- 
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/2061#issuecomment-442369044