Subject: UDP Ports and QUIC version

From: Martin Duke <[email-masked]>
Date: Wed, 24 Nov 2021 10:45:43 -0800

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 Nov 2021 10:58:23 -0800

> DNS-over-QUIC just requested UDP Port 843, where it would coexist with

I assume you mean 853, though that does not affect the rest of your note at all.

-Ben

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Nov 2021 12:02:11 -0800

> I assume you mean 853, though that does not affect the rest of your note at all.

Note that port 853 is a bit of a special case. TCP port 853 was first 
reserved for DNS over TLS. UDP port 853 was then reserved for DNS over 
DTLS, which was defined in an experimental RFC. Turns out that several 
years later we are not aware of any deployment of DNS over DTLS. So we 
believe that having UDP port 853 for DNS over QUIC and TCP port 853 for 
DNS over TLS would keep the nice symmetry that was originally intended. 
It would for example make management of firewalls easier, "port 853 is 
encrypted DNS for both UDP and TCP". The downside would the case of 
servers trying to run both DNS over QUIC and DNS over DTLS. We don't 
know any such server, but it is nice to have a fallback mechanism in the 
unforeseen case of some server somewhere trying to do that. The ability 
of multiplexing QUIC and DTLS on the same port gives us that.

-- Christian Huitema

---

From: Paul Vixie <[email-masked]>
Date: Wed, 24 Nov 2021 12:17:07 -0800

Christian Huitema wrote on 2021-11-24 12:02:
> ...

who is "we"?

> of multiplexing QUIC and DTLS on the same port gives us that.

i likewise think UDP/853 for both DoD and DoQ is fine.

the reason for widespread lack of deployment of DoT (TCP/853) and DoD 
(UDP/853) is simply because the TLS (middleware) supply chain does not 
broadly know how to authenticate a server whose domain name is unknown. 
that is, all DNS has at the time it wishes to transmit some kinds of 
queries is an IP6/IP4 address. putting these into presentation form and 
comparing the certificate's common name with that converted string can 
be done, but the logic to do so is in the TLS library not the DNS 
server. so, deployment of DoD (DTLS, UDP/853) is "stuck" at the moment.

vixie

-- 
Sent from Postbox
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: David Schinazi <[email-masked]>
Date: Wed, 24 Nov 2021 12:20:05 -0800

Reusing 853 sounds like the simplest solution here.

QUICv1 can coexist with DTLS, and there is no reason
to believe that future IETF versions of QUIC will not
have the same feature. If someone decides to run
their custom version of QUIC on the same port as DTLS,
they'll also make sure to have their version of QUIC
coexist with DTLS.

The QUICv1 "grease the QUIC bit" extension is not
relevant to this discussion, because no one who cares
about coexisting with DTLS will deploy this extension.

David

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Nov 2021 12:28:38 -0800

On 11/24/2021 12:17 PM, Paul Vixie wrote:
>> reserved for DNS over TLS. UDP port 853 was then reserved for DNS 
>> over DTLS, which was defined in an experimental RFC. Turns out that 
>> several years later we are not aware of any deployment of DNS over 
>> DTLS. So we believe that having UDP port 853 for DNS over QUIC and 
>> TCP port 853 for DNS over TLS would keep the nice symmetry that was 
>> originally intended. 
>
> who is "we"?
The DNS over QUIC draft authors. Sorry, I should have specified.
>
>> It would for example make management of firewalls easier, "port 853 
>> is encrypted DNS for both UDP and TCP". The downside would the case 
>> of servers trying to run both DNS over QUIC and DNS over DTLS. We 
>> don't know any such server, but it is nice to have a fallback 
>> mechanism in the unforeseen case of some server somewhere trying to 
>> do that. The ability of multiplexing QUIC and DTLS on the same port 
>> gives us that.
>
> broadly know how to authenticate a server whose domain name is 
> unknown. that is, all DNS has at the time it wishes to transmit some 
> kinds of queries is an IP6/IP4 address. putting these into 
> presentation form and comparing the certificate's common name with 
> that converted string can be done, but the logic to do so is in the 
> TLS library not the DNS server. so, deployment of DoD (DTLS, UDP/853) 
> is "stuck" at the moment.

Yes. In theory, practical solutions must exist. In practice, we need 
practice...

-- Christian Huitema

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Fri, 26 Nov 2021 15:10:26 +0000

Reading this thread made me worder if we should cover this analysis in the applicability draft or not. I have opened an issue regarding this (https://github.com/quicwg/ops-drafts/issues/428#issue-1064583264). 

BR
Zahed

On 2021-11-24, 21:29, "QUIC on behalf of Christian Huitema" <[email-masked] on behalf of [email-masked]> wrote:

    -- Christian Huitema