Re: QUIC re-chartering: include DNS-over-QUIC?

[Erik Kline <[e-mail]>]

Tangent: is there already, or are there plans for, a document like BCP 56
but for QUIC?  I'm thinking generally about whether there should be
guidance for folks wanting to port Foo protocol to Foo-over-QUIC.

On Sun, Apr 12, 2020 at 12:01 PM Lucas Pardue <[e-mail]>
wrote:

> Mikkel, all,
>
> Thanks for the healthy discussion on this thread. As suggested up thread,
> this proposal was taken to the DPRIVE WG and presented at their interim
> meeting last week.
>
> DPRIVE have issued a call for adoption [1], I encourage continued
> conversation over there.
>
> Cheers
> Lucas
>
> [1]
> https://mailarchive.ietf.org/arch/msg/dns-privacy/kXmy4lZ-MzUKCP5zrca9I4WmiVI/
>
>
> On Sun, 12 Apr 2020, 19:49 Mikkel Fahnøe Jørgensen, <[e-mail]>
> wrote:
>
>> Late to the game.. I support DoQ.
>> Maybe there are too many DNS transports, and maybe DNS as such does not
>> need it, but for all communication endpoints that invest in QUIC as the
>> sole transport it would be very convenient to have DoQ. DNS is a low-level
>> dependency for most QUIC application protocols so if you have a non-HTTP
>> based application, why would you want to drag in HTTP just for the sake of
>> DNS, disregarding attack surfaces? DoQ instead of UDP/TCP DNS handles
>> privacy / security and avoids another dependency.
>>
>> Kind Regards,
>> Mikkel Fahnøe Jørgensen
>>
>>
>> On 12 April 2020 at 01.46.25, Paul Vixie ([e-mail]) wrote:
>>
>> On Thursday, 6 February 2020 21:27:14 UTC Erik Nygren wrote:
>> > On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie <[e-mail]> wrote:
>> > > i see DoQ as nec'y for QUIC's success but not relevant to DNS beyond
>> the
>> > > fact that DNS is a convenient second example of how QUIC can be used.
>> if
>> > > there are use cases or failure modes not handled well by DoT, i'd
>> like
>> > > to learn more about those.
>> >
>> > Some possible reasons (not comprehensive):
>>
>> forgive the long delay in responding, please.
>>
>> > * Reduce the impact of head-of-line blocking during loss. If packets
>> are
>> > lost, only the request(s) associated with the loss are impacted.
>>
>> you're assuming that the loss isn't self-induced. sometimes slowing down
>> is
>> exactly what's needed. for example when a busy full resolver has a queue
>> of
>> hundreds or thousands of requests to be sent to a zone authority, rate
>> limiting of UDP is necessary to prevent a meltdown. bandwidth is
>> finite... we
>> sometimes load-balance toward several of a zone's authority servers even
>> including those known to not have low-ish RTT, just to avoid flooding one
>> of
>> them, or to avoid flooding our nearby links. moving to QUIC won't help
>> with
>> any of that.
>>
>> > * Faster resumption and 0RTT behaviors (although you get some of these
>> with
>> > TFO + TLS 1.3 0RTT). But this substantially reduces the performance
>> impact
>> > when new connections need to be established.
>>
>> in DNS, new connections rarely need to be established. the reason RFC
>> 6013
>> permitted connections to go into a quiet (resumable) state and keep the
>> learned cwin in compressed state so that the cost of that state would be
>> no
>> worse than what was needed for syn flood protection. since you mentioned
>> TFO i
>> want to say two things, first it was insecure and can't be used, exactly
>> as we
>> predicted (william simpson and i), and second TCPCT allowed for payloads
>> as
>> part of the initial or resumptive segments to get exactly the 0RTT
>> benefit.
>> but i don't want to drone on like a sore loser. the point is, in DNS,
>> novel
>> connections are rare, and careful statekeeping to support resumption
>> (such as
>> DNS cookies as defined in RFC 7873) is already present in pre-QUIC DNS.
>>
>> > * The previous also means servers can be more aggressive about timing
>> out
>> > connections to reduce the state they need to keep, but while minimizing
>> > perf impact, which can be critical at-scale.
>>
>> this reduces to a noop because the statekeeping is subject to botnet
>> attacks.
>> just as all TCP listeners have to implement syn flood protection, so it
>> is
>> that all stateful endpoints (whether DNS, TCPCT, TFO, or QUIC) have to be
>> aggressive about timing out connections they need not keep fully open.
>> QUIC
>> has no special capabilities or requirements in this regard.
>>
>> > * Better ability for load balancers at-scale to do creative things,
>> > including being able to recover better when Anycast moves routes
>> between
>> > data centers. (The server-supplied Connection ID means that options
>> become
>> > available to better recover without needing to reset re-establish
>> > connections and without needing to share state between clusters.)
>>
>> while it's theoretically possible to share DNS cookie state (RFC 7873)
>> across
>> many instances of DNS Anycast, the cost:benefit of that complexity is
>> less
>> compelling than the cost:benefit of having to renegotiate during route
>> changes
>> either from mobile-ip or network-in-the-middle attacks. i don't think
>> QUIC has
>> different game theory than DNS cookies have in this regard. route changes
>> are
>> orders of magnitude less frequent than same-pair reuse, and always must
>> be.
>>
>> > * QUIC provides a framework for future extensions that may be useful in
>> the
>> > DNS space. For example, FEC might actually be useful for DNS in some
>> cases.
>> >
>> > I'm sure there are plenty more reasons...
>>
>> i appreciate the time you put into listing these initial motivations.
>> however:
>>
>> > On Thu, Feb 6, 2020 at 4:16 PM Paul Vixie <[e-mail]> wrote:
>> > > i see DoQ as nec'y for QUIC's success but not relevant to DNS beyond
>> the
>> > > fact that DNS is a convenient second example of how QUIC can be used.
>> if
>> > > there are use cases or failure modes not handled well by DoT, i'd
>> like
>> > > to learn more about those.
>>
>> ....my question seems to stand. if the potential motivations you've
>> listed so
>> far were actual, then we'd have had DNS over SCTP decades ago, or
>> something
>> like DTLS that actually worked at scale rather than just in a lab, or we
>> would
>> have been able to get TCPCT the code point we needed to experiment
>> globally,
>> or we would have had UDP options by now.
>>
>> i consider DoQ inevitable, but for QUIC's purposes ("proof of broader
>> applicability"), not DNS's purposes ("working better"). DNS is old and
>> warty
>> but it does move and it has evolved.
>>
>> --
>> Paul
>>
>>
>>