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

[Michael Richardson <[e-mail]>]

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, just run SSH on port 443.
In fact,  https://packages.debian.org/buster/sslh  does this for you.

Network middle boxes need to get the *($%#$% out of transport protocols.
Back in 1996 (!) I explained how to have authorized audit boxes for IPsec
using securityhop-by-securityhop ESP and end-to-end AH.
It requires the blessing of the end points, and we regularly do way more
complex and stupider things in TLS today.
People thought my solution was crazy.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [