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 [127.0.0.1]) 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-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, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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. Martin
- UDP Ports and QUIC version Martin Duke
- Re: UDP Ports and QUIC version Benjamin Kaduk
- Re: UDP Ports and QUIC version Christian Huitema
- Re: UDP Ports and QUIC version Paul Vixie
- Re: UDP Ports and QUIC version David Schinazi
- Re: UDP Ports and QUIC version Christian Huitema
- Re: UDP Ports and QUIC version Zaheduzzaman Sarker