Speaking in my role on the port experts review team:
As QUIC is a general-purpose transport protocol, there are no
requirements that servers use a particular UDP port for QUIC. For
applications with a fallback to TCP that do not already have an
alternate mapping to UDP, usually the registration (if necessary) and
use of the UDP port number corresponding to the TCP port already
registered for the application is appropriate. For example, the
default port for HTTP/3 [QUIC-HTTP] is UDP port 443, analogous to
HTTP/1.1 or HTTP/2 over TLS over TCP.
The above section glosses over two critical issues that should be addressed:
1. Whether QUIC should use port number assigned to an existing transport that
does not currently assume QUIC
2. Whether / when QUIC designers should seek new port numbers
Both issues come back to a key issue that this document does not yet address:
although QUIC is a new “transport”, it does not use or have its own transport
protocol code point. This is by design, i.e., QUIC could easily have been
designed with as a true Internet transport layer, but instead leverages NAT
traversal support and other benefits of existing transports.
IMO, this section should be more clear and detailed on the consequence if this
decision in the advice in this doc, e.g., IMO:
- QUIC MUST use existing port assignments where they already exist
- QUIC MUST differentiate between non-QUIC and QUIC use of that
port, if preexisting non-QUIC assignment exists
- the doc needs to address the cases where QUIC doesn’t have an
assignment
i.e., IMO, because QUIC isn’t a transport, it would not itself
be eligible for a port assignment
so again, it seems like applications for new ports need to be
for “QUIC and non-QUIC use over UDP" (or TCP, or both)
It wouldn’t hurt to also refer to RFC7605, notably its SHOULD for use of
security and to be explicit about exceptions, if any.
Joe
—
Joe Touch, temporal epistemologist
www.strayalpha.com
> On Jan 24, 2022, at 7:49 AM, The IESG <[email protected]> wrote:
>
>
> The IESG has received a request from the QUIC WG (quic) to consider the
> following document: - 'Applicability of the QUIC Transport Protocol'
> <draft-ietf-quic-applicability-14.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email protected] mailing lists by 2022-02-07. Exceptionally, comments may
> be sent to [email protected] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document discusses the applicability of the QUIC transport
> protocol, focusing on caveats impacting application protocol
> development and deployment over QUIC. Its intended audience is
> designers of application protocol mappings to QUIC, and implementors
> of these application protocols.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-announce
