Re: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

[Paul Vixie <[e-mail]>]

On Wednesday, 10 June 2020 15:45:50 UTC Mike Bishop wrote:
> ...
> Interestingly, this includes at least one example of exactly the behavior
> that’s discussed as a problem in Section 2:
 
>       A network operator can observe the headers of transport protocols
>       layered above UDP to understand if the datagram flows comply with
>       congestion control expectations.

for managed secure networks in homes and businesses, unclassified traffic 
won't be permitted. UDP itself is a privileged protocol in those environments, 
allowed to pass through the outbound firewall only if the source or 
destination address or port or some combination. this constraint should be 
highlighted for all protocol designers. things like QUIC need a "hook".

i know that public networks might use such a hook for the opposite purpose -- 
to deny what they can recognize rather than to allow what they can recognize. 
if that risk isn't already well enough described in the IAB's PM dictates, i 
have no objection to adding references or even new text to this draft to make 
sure this document isn't accidentally misleading.

i don't agree with the restriction quoted above that it be for "congestion 
control expectations" although flow-aware rate limiting is one important 
manageability concern. for policy or legal regime reasons, a protocol which 
maximizes entropy such that there's no way to identify its flows so as to 
allow them to exit, will be less deployable and less deployed.

> Dropping packets which don’t comply with the operator’s “expectations” in a
> protocol they don’t understand is exactly why new protocols and evolution
> of existing protocols want to limit the ability of these devices to inspect
> their traffic.

while true, that's unbalanced. forget about dropping packets which don't 
comply, and consider the networks who won't forward packets unless they 
comply, and who very much want the benefits of modern encrypted protocols but 
who cannot enjoy those benefits because they cannot identify that traffic.
 
> On the whole, I think this document could be suitable for publication as an
> Informational RFC; it provides real-world context for a trade-off that
> every protocol designer needs to consider carefully.  However, I don’t
> believe its current state reflects, in Ekr’s words, “the IETF community's
> view of the relative priority of these concerns.”

the ietf community is incredibly narrow compared to the world it serves. very 
few of the people and companies whose future will be chosen for them by ietf 
work can afford the time or travel it takes to be represented. this may be an 
inconvenient truth, but it is my reason for considering whether this document 
reflects the broader view of the world's digital economy. i think it does.

-- 
Paul