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

On 11/2/21 18:44, Michael Richardson wrote:
> Fernando Gont <[e-mail]> wrote:
>      >> When the transport layer is encrypted, network devices would only see
>      >> the plaintext EH and that is only what that is what they can act on.
>      >> At the destination, we could try to rectify transport information in
>      >> HBH with decrypted plaintext transport headers, but I suspect that
>      >> wouldn't typically be done. The HBH information is only operationally
>      >> useful to the network, not the transport endpoints that have access to
>      >> the transport header.
> 
>      > Then this is what an attacker would do: He/she would advertise on a HBH
>      > option something that looks sensible to the guy enforcing a
>      > network-based security policy, and then at transport would do what
>      > he/she needs to do. :-)
> 
>      > e.g., HBH could advertise that my packets are directed to ports 80/443,
>      > while in transport they are actually directed to port, say, 22.
> 
> That's silly amount of subterfuge.
> Since you have the cooperation of the target machine,

Not always. And not always you're so free to change the service port.


> just run SSH on port 443.
> In fact,  https://packages.debian.org/buster/sslh  does this for you.

Indeed. But that's not the point. The point is that if the network wants 
to block specific traffic, I needs to tell what the traffic is about.



> Network middle boxes need to get the *($%#$% out of transport protocols.

There are operational reasons for which the peek at transport.

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