UDP Ports and QUIC version

Martin Duke <martin.h.duke@gmail.com> Wed, 24 November 2021 18:45 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E352D3A0A0D for <quic@ietfa.amsl.com>; Wed, 24 Nov 2021 10:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id S0fl4_G5MXfn for <quic@ietfa.amsl.com>; Wed, 24 Nov 2021 10:45:57 -0800 (PST)
Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 588643A0A0B for <quic@ietf.org>; Wed, 24 Nov 2021 10:45:57 -0800 (PST)
Received: by mail-ua1-x932.google.com with SMTP id az37so7050364uab.13 for <quic@ietf.org>; Wed, 24 Nov 2021 10:45:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=/ZJSpPFEMFyxC2HnkGp5whaI/BvquZoLPUezi5/2ZVo=; b=LJSrup0z9eQSHgqP5Va4xEoxCaZZlnj8BMQdyIDC1tTbCuFJll+/4PHdOBrzFTWwtl OIWWXPOY88UFHlaFQeAngzvoH2Q5ewKswzFYp08zqjJwRZQO3LJtDYrj9jhc1uXfODFD HvKCxjTsz65SxwvwDKcKTLmfLAlTB6ogo97oeCRNueCBFKBvc/PeTcWNZYtUPXo8Ye12 6XTpuGac30pcfxNZ1Gsset14HgHrJlwCdm4GA4kUSlHnrvFb9P1CIs3lRBsSzGCpv9nF bojLKQ+kodQjGG1nNUjnoziYcS7TqKO+uYwnzFbrzhzrs7ypV4uKHIspIkwpVbLxWgNn i38w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/ZJSpPFEMFyxC2HnkGp5whaI/BvquZoLPUezi5/2ZVo=; b=Y43Z9diFrYdX4N9uDqxu2Rkfwwowb1MM/VinPIcRHXcfW+/aC1V6JvHybeMyNLefiS nu1/fFMcRTVNG2VYDtuG2JnpwiBk586kzwhLkd9EQfCgjzcbl7MYtQ5eSqvcA+JvBL61 XYXs5ApU0D56V29tK52AUTY/KQv3CGO0YgHa2iqy6sHC+syZQJec+yRS5cAuvlABtxYV KgvL/MMKYMARiD+UE7jiRHTHZ1S3BskLOAVpG14gDDmISJstfFj0vrmwJ+1G6oTo/83K +VRMLKOOETvfMaHOasSmnoKEK936MnCoIEh2ZN/TViVNhr/MG/aiWQa4ROWqw/IoM+dD xi3Q==
X-Gm-Message-State: AOAM532hZFPhECN1YQxMb4RBz6cajqW1Ury8bpehFhqIDGBxDK1MYZUv bT57wSU/NWItmx4N/b1bgwHkKHZgu3uO2w6Fh1/527cXBxk=
X-Google-Smtp-Source: ABdhPJyXVOGJn6vtrnMK5TCvfnmGeBVk3Os/2EvYXs3T0PG7yWayR9YHhT+DE9ySswI7jtaU1jnJtzBbEgBrNTDcxgY=
X-Received: by 2002:a05:6102:c4d:: with SMTP id y13mr26738539vss.43.1637779555028; Wed, 24 Nov 2021 10:45:55 -0800 (PST)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 24 Nov 2021 10:45:43 -0800
Message-ID: <CAM4esxRqTdYYSw5EMkLXjnRdhsYOgW1BDjVHdxG01md5dkEwCw@mail.gmail.com>
Subject: UDP Ports and QUIC version
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000099145905d18d44c1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/SWe2q7KFbq6Xqejq_KiB5cfQ01o>
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: Wed, 24 Nov 2021 18:45:59 -0000

Hello QUIC,

DNS-over-QUIC just requested UDP Port 843, where it would coexist with
DNS-over-DTLS. As long as the DNS server is running QUICv1 without greasing
the QUIC bit, that should work out just fine.

This does lead me to think about how QUIC versions will interact with the
port over which they are intended to operate. In RFC 9000, designed
explicitly for HTTP/443, we took care to make sure the signature was
distinguishable from other things that run there.

So, if someone wanted to deploy QUIC over some other UDP port, we might
have to roll a new version simply to create a signature that doesn't clash
with the protocols already operating over that port.

For any given QUIC application, there is therefore a choice between
(1) Picking an existing port and making sure that either (a) the other UDP
application isn't present, or (b) using only QUIC versions that are
distinguishable, or
(2) Requesting a new port

A few questions:
- Is my analysis correct?
- Are we comfortable with having to take up these new versions when they
arise (which may not be that often)?
- Would it be preferable to have a less balkanized QUIC version space and
more port allocations?

I would like to start thinking through this issue and perhaps issue
guidance to the ports team.