Re: UDP source ports for HTTP/3 and QUIC

Mark Nottingham <mnot@mnot.net> Sat, 17 July 2021 00:28 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228163A109C for <quic@ietfa.amsl.com>; Fri, 16 Jul 2021 17:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=o3+/Z4xy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qy5hPJTK
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 XsPinO1siR9b for <quic@ietfa.amsl.com>; Fri, 16 Jul 2021 17:28:17 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CB73A1094 for <quic@ietf.org>; Fri, 16 Jul 2021 17:28:16 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 22F005C019A; Fri, 16 Jul 2021 20:28:16 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 16 Jul 2021 20:28:16 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :date:references:to:in-reply-to:message-id; s=fm3; bh=YVr7JJ8QmM b4HXqNBteTkG4eviEaWsrB1Hmmzf4gapg=; b=o3+/Z4xyrnxSqXTljtv8gnLoko hEpUs1RNEu8JrqsA/2eO50JT6BY+kRglTDWXRQQJ/wxw8NRZc6M0iYFzlmiATFTs +eS2s3WXDwBpaphEzFGAk9TtdszMUGRuK0IgCgg5uiMK9ZD3aahGKTOLBLTCM1wH ssKrA6jAXShnawoXVBaiIy3egGaA2lwUEt1K/woqUswa2ebEYM6JoZJnjl26U6fH dFfy6t5qKZqICDcOQJt8dcHDOBtO9B6R/oRvOPXV3ABU0MEXFfsHbvUEwdI6ePI0 bbP8xXdXVnmdyi4ADZl8OJeOV+Xr4V6yuHnzSMjYLo+w3yZmglq7dWPi8dAQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=YVr7JJ8QmMb4HXqNBteTkG4eviEaWsrB1Hmmzf4ga pg=; b=qy5hPJTKArMGEe4XosyhwIDfMqdzzAznd6GwD0EGPDE9wMdDiG9JoQcpg JhikdlWZ1NQKbbsVkkxp6IUolb1jO1z7H1qOsEWwb+YZi6jSh814r1vSwQSNiQR+ Lu88W2EFyzccFJ0lMke0gWk0Qt+OQtq6D2NH8MKcgc+6VSF64rD50UPdnMTj4Wrd t7mpzppZImSe7pmYE/Za9SVyeSVgeeD0rcTIf3lr6fGTHFxwsLHceH7zXOpbhYC4 E+Rljb9uO+n+98YawLo7lyzklA6XEw/kfv+wQBHf4GgvR9ueiI/jasYDfJI2PBiC xUFt+tHQn654Lz6BBQQjane6Eyxbw==
X-ME-Sender: <xms:HSTyYJRaVmY38cz_ez3ebp9EdlYgG4oK2XVJh8_5xJolNc_iyJxsmA> <xme:HSTyYCyli0j_Kha6MvwRLXEx5jNQ-vKfBWVO5vFzQ-HWKZuqJtanT7G-0Nhh1Ls8O 9GRmuXMpXYdi7AS7g>
X-ME-Received: <xmr:HSTyYO0zy71VQpV8mmfONylG_wkLPgCiNe-yqncINNNh4jmfPprhxn9vVCa-sDY9k9Ro5EscGSoUpEaRcUOdxHRYN-wlojKSUGXcADRJNUAd-DQ-STFPlGG->
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdeggddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhtgfgggfuffhfvfgjkffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnheptdehkeetffehheevkeelvdegtdeuteegkedvgeevheehkefhheeifeevfeffjedu necuffhomhgrihhnpehquhhitgifghdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdr nhgvth
X-ME-Proxy: <xmx:HSTyYBB2iwnyL9TGSQsYum3EyMvfEmPprxxdLTYtmww2sXzOp2obWQ> <xmx:HSTyYChpd0-XUBHn8h_DjndhsJm7N5wUmZGewKnSpe_-pr4h7TeueA> <xmx:HSTyYFpSGEAxgDSpAfeNgoWYV7ItPRKbjRXYEDnTWD211nDIXNFg1A> <xmx:ICTyYDvp8hA1YsKptt7YaXyLMeIqhRVteNnrEG72UrUzkZttWQ3Kow>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 16 Jul 2021 20:28:12 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Subject: Re: UDP source ports for HTTP/3 and QUIC
Date: Sat, 17 Jul 2021 10:28:09 +1000
References: <3985895D-D420-4995-831E-332E33693B79@mnot.net> <6F79A78A-1DF8-4A48-9B7F-334B309C9C26@gmail.com> <20210715092937.GC27830@1wt.eu> <20210716014010.GL24216@faui48e.informatik.uni-erlangen.de> <20210716060644.GA3469@1wt.eu> <20210716215311.GP24216@faui48e.informatik.uni-erlangen.de>
To: HTTP Working Group <ietf-http-wg@w3.org>, IETF QUIC WG <quic@ietf.org>
In-Reply-To: <20210716215311.GP24216@faui48e.informatik.uni-erlangen.de>
Message-Id: <EC01548D-C7E3-4C65-9FC7-A3B3B3970EB1@mnot.net>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/lyzLaLvXnO1jSpEvaKyjXjxA33o>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Jul 2021 00:28:22 -0000

I appreciate the enthusiasm for the tangential here :) but to return the original topic -- I realised that this is obliquely discussed in the applicability draft:
  https://quicwg.org/ops-drafts/draft-ietf-quic-applicability.html#name-port-selection-and-applicat

So at a minimum, it seems like we should expand upon that text to make this issue more clear. I'll try to start a PR.

If I read the thread correctly, people seem to think (somewhat pessimistically, but realistically) that protocols susceptible to reflection will continue to be created, so hardcoding a list into the RFC isn't workable.

Instead, I'm currently thinking the best approach will be to:

1. Expand the applicability document as per above, using examples from the list I gave, since they're already pervasive
2. Start a discussion in the TSVWG about the possibility of adding a new column to the port registry to capture this information 

Make sense?

--
Mark Nottingham   https://www.mnot.net/