Re: Opsdir last call review of draft-ietf-quic-manageability-14

["Brian Trammell (IETF)" <[e-mail]>]

Hi Paul,

Thanks for the comments… a couple of points in reply inline...

> On 16 Mar 2022, at 20:57, Paul Vixie <paul=[e-mail]> wrote:
> 
> mirja, et al, in reviewing manageability-15, i see this text:
> 
>>   The QUIC wire image is not specifically designed to be
>>   distinguishable from other UDP traffic by a passive observer in the
>>   network.
> 
> i think this has an excluded middle problem, and should be changed to:
> 
> <<The QUIC wire image is specifically designed to be indistinguishable from other UDP traffic by a passive observer in the network.>> 
> 
> this follows from RFC 7258, and is uncontroversial in the light thereof.

It’s a bit more subtle than this, I think. There is a bit of distance between the QUIC wire image and “indistinguishable from other UDP traffic” in practice. udp/443 gets you most H3 traffic, the V1 wire image has a QUIC bit designed for multiplexing, etc. A truly observation-resistant wire image would have different properties.

What the design of QUIC does do is purposefully eliminate the role of intermediary third parties that do not cooperate with either endpoint, with a background understanding that the opportunities for abuse in this case outweigh the benefits to the first and second parties. It does this by reducing the observable surface (and eliminating the mutable surface) of that wire image. If a non-cooperative intermediate third party wants to interact with the mechanics of an application running over QUIC, it has the option of blocking QUIC, since all such applications must have a fallback to run on networks where UDP is blocked anyway. 

IOW, if you want to run a firewall protecting QUIC servers, you'll need to integrate that functionality with the front-end or load balancers. If you want to run a firewall protecting QUIC clients, or of protecting yourself from QUIC clients (exfil), you'll need to do that integrated with the clients, or through proxies. If you're not in a position to cooperate with either endpoint, then you're not part of the security architecture anymore, aside from forcing fallback to TCP or UDP.

But from a wire image standpoint, I believe the existing text is more accurate than the proposed change.

> further to this point, i'd like to suggest adding a paragraph to the end of section 3.1 (Identifying QUIC Traffic):
> 
> <<Management of QUIC traffic can never be reliable, and if it becomes so over time, then the QUIC wire image would be forced to evolve. Therefore a heuristic along the lines of "any unrecognizable UDP traffic could be QUIC" is the least unappealing way for a network operator to characterize their network's UDP traffic in the QUIC era.>>

This formulation seems to make the following assumptions:

- that management of other traffic can be reliable for some definition thereof, 
- that there is a implementably precise definition of “recognizable UDP traffic”,
- that traffic manageability necessarily requires uncooperative third-party intermediaries to be part of the security architecture,
- that the QUIC WG pursues as a matter of policy that QUIC be indistinguishable from UDP background and would evolve the protocol to protect against changes to that.

I’m not sure that any of those assumptions hold.

Thanks, cheers,

Brian