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

[Paul Vixie <[e-mail]>]

Brian Trammell (IETF) wrote on 2022-03-22 05:53:
> Hi Paul,
> 
> Thanks for the comments… a couple of points in reply inline...

thank you! see also my response, inline.

>> On 16 Mar 2022, at 20:57, Paul Vixie <paul=[e-mail]> wrote:
>>
>> ... 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.

i should have added that while the revised wording is not to my liking, 
it is intended to copy the structure of the existing wording, and thus 
be easier to evaluate. in particular, distinguishability is the wrong 
rubric for the revised language. more on that below.

> 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.

the properties of the V1 wire image already make it unidentifiable for 
purposes such as "allow QUIC V1 traffic through the firewall" or "deny 
QUIC V1 through the firewall" or "change the IP TOS for QUIC V1 
traffic." since that impact is neither accidental or incidental, the 
existing wording of the first paragraph of [3.1] is inaccurate.

> ... 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.

an edge network operator _does not_ have the option of managing QUIC 
(for example, as you say, to block it). both [3.1] and all of [3] 
explain in detail that there is no reliable way to identify QUIC 
traffic. absent such identification, there can be no management. the 
opening paragraph of [3.1] should economically explain that this is so, 
and accurately describe the reason why that is so.

> 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. ...

this ("need to do that integrated with the clients") is what i mean by 
"_does not_ have the option" above. for clarity, there is not a secure 
reliable proxy discovery protocol, and little incentive to create one. 
if the only "option of blocking QUIC" is to "integrate with the clients" 
then there is no actual option.

> ... 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.

there is no reliable way to force fallback to TCP, or even to exempt 
QUIC from an otherwise blanket prohibition against wide area UDP. the 
opening paragraph of [3.1] should be clear about this limitation and 
about the reasons (not accidental, not incidental) why this is so.

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

if we can alter the structure of the opening paragraph of [3.1], then my 
proposed revision would change. something along these lines might be a 
better fit for the facts and for your concerns:

<<The QUIC wire image is designed to be unidentifiable and thus 
unmanageable by third parties such as gateway or firewall or network 
operators. As enumerated below, there are no durable data patterns 
visible "on the wire" and thus the only parties who can manage QUIC 
traffic patterns are the endpoints.>>

>> 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.

as to management and recognition:

current generation firewall technology can allow some UDP protocols by 
looking for a well known port and validating the structure of the 
datagram to test for "exfil". NTP, SNMP, and DNS come to mind here. 
while it is far more common to allow or deny based on the port number 
alone, and in the deny case to therefore require and enforce the use of 
local services, secure private networks today have many options open to 
their operators. QUIC treats this as "oldthink" and deliberately 
obviates the practice. that effect, and its intentionality, ought to be 
called out in this document.

as to cooperation:

cooperation cannot be presumed on a managed private network. for 
example, IoT devices are often distributed cells in the corporate body 
of their makers. in a network of networks, each of the networks can be 
expected to use every means at its operators disposal to detect or 
prevent communication by uncooperative devices, apps, intruders, or 
insiders. QUIC's wire image effectively, and non-accidentally, forbids 
this. as a subjective matter, that forbiddence may seem good or evil, 
but that's out of scope for this document. as an objective matter, that 
forbiddence is real, and deliberate, which is in-scope for this document.

as to evolution, i agree that my proposed summary is a bridge too far.

perhaps this wording will be if lesser concern to you:

<<Identification of QUIC traffic by on-path actors such as network 
operators is not reliable. 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.>>

> Thanks, cheers,
> 
> Brian

and to you, sir.

-- 
P Vixie