Re: [saag] [tsvwg] Fwd: Last Call: <draft-ietf-tsvwg-transport-encrypt-19.txt> (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC

[Tom Herbert <[e-mail]>]

On Thu, Feb 11, 2021 at 7:08 PM Fernando Gont <[e-mail]> wrote:
>
> On 11/2/21 20:19, Tom Herbert wrote:
> > On Thu, Feb 11, 2021 at 3:32 PM Michael Richardson
> > <[e-mail]> wrote:
> [....]
> >
> > It's also hard not to notice how similar these discussions are with
> > those that occurred when TLS was being brought up. Some network
> > providers argued vehemently that if they aren't able to inspect HTTP
> > payload they can't provide the services and security their customers
> > need. They lost those arguments, as I suspect similar arguments that
> > transport layer shouldn't be encrypted will also fail.
>
> FWIW, I'm certainly *not* arguing that the transport layer should not be
> encrypted. I'm simply pointing out that operators do more things with
> packets that blindly forward packets on a per-packet and per-dst-address
> basis. And that that, there are consequences of them not being able to
> access IP+transport metadata.
>
Fernando,

Yes, this draft describes those consequences. But what has not been
adequately discussed IMO has been the negative consequences of network
devices acting on transport layer information. In particular, this
leads to protocol ossification and creates a myriad of impediments for
application developers trying to build applications to work across the
whole Internet. For instance, if you say that QUIC is the only UDP
protocol allowed on the Internet., i.e. identified by UDP port 443,
then how could we ever deploy a new UDP protocol? This also leads to
arms escalation between application developers and network operators,
for instance if I do know that UDP port number 443 is the only port
number allowed the network then I'll simply wrap my new UDP protocol
in a UDP datagram to 443. You might complain that such things might be
purposely bypassing your network security, yes they do, however host
developers have no obligation to abide by some arcane set of network
security policies that are unwritten and inconsistent across the
Internet.

I do believe that network operators and their users could benefit from
getting more information in a packet than just Ip addresses. But I
also believe that exposure of information should be volutary as
opposed to mandatory, and it should be be very clear what the value is
the to the user in exposing information. IMO, HBH is the best vehicle
to express this information and there is some good work in Network
tokens, FAST, and APN around this.

Tom

> When it comes to QUIC, it could well be the case that then only thing
> they care in this respect is IP header + UDP header... and e.g. rate
> limit as they do for some other UDP traffic.
>
> Thanks,
> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>