Re: [tsvwg] [saag] 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

[Fernando Gont <[e-mail]>]

Hi, Tom,

On 12/2/21 11:47, Tom Herbert wrote:
> On Thu, Feb 11, 2021 at 7:08 PM Fernando Gont <[e-mail]> wrote:
>>
[....]
>>
>> 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

The fact that QUIC employs UDP should probably already say a lot. :-)

(yes, they were right, and very pragmatic about it)



> protocol allowed on the Internet., i.e. identified by UDP port 443,
> then how could we ever deploy a new UDP protocol? 

Please see above.



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

And operators might as well argue that they won't leave their production 
networks open to attack for the sake of not constraining future protocol 
development....



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

If it's voluntary, in many (most?) cases it cannot be relied upon, and 
hence is not of much use.



> IMO, HBH is the best vehicle
> to express this information and there is some good work in Network
> tokens, FAST, and APN around this.

RFC7872 seems to suggest otherwise.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492