Subject: Re: [Last-Call] Last Call: <draft-ietf-quic-applicability-14.txt> (Applicability of the QUIC Transport Protocol) to Informational RFC

From: "[email-masked]" <[email-masked]>
Date: Mon, 24 Jan 2022 08:01:48 -0800

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-masked]> 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-masked] mailing lists by 2022-02-07. Exceptionally, comments may
> be sent to [email-masked] 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-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Christian Huitema <[email-masked]>
Date: Mon, 24 Jan 2022 10:48:43 -1000

Reading the current draft, I find one small issue regarding packet 
types. The draft mentions in section 2.1 that packet types are defined 
in the Version1 specification. Section 3.1.2 correctly warns against 
using packet types for heuristics because they may changed in further 
version, and section 3.4.1 correctly conditions inspection of Initial 
packet to recognizing version 1. However, I am concerned that 
middle-boxes might ignore these caveats. Could we add a note somewhere, 
maybe in section 2.1, that different versions of QUIC might encode 
packet types differently? Indeed, the version 2 draft 
(https://datatracker.ietf.org/doc/draft-ietf-quic-v2/) uses different 
encodings for the packet types.

-- Christian Huitema