Encrypted tunneling vs. encrypted media?

[GrumpyOldTroll]

From @michael-scharf (https://mailarchive.ietf.org/arch/msg/mops/eGGPYW2vytPsLwRBlJ38MezPFh0/)

Section 7. Streaming Encrypted Media

As far as I know, streaming users sometimes use encrypted tunnels such as
OpenVPN or WireGuard (or IPsec) to access video content. I may miss something,
but it is unclear to me how that fits into the categories presented in Section
7.

(Seems closely related to #144 )

[acbegen]

The purpose of such tunneling is to circumvent geoblocks and access content from other regions - not to protect the media content. Encrypting the content is done by the content owner for its protection.

[SpencerDawkins]

So, looking at OpenVPN, I'm seeing this text:

OpenVPN multiplexes the SSL/TLS session used for authentication and key exchange with the actual encrypted tunnel data stream. OpenVPN provides the SSL/TLS connection with a reliable transport layer (as it is designed to operate over). The actual IP packets, after being encrypted and signed with an HMAC, are tunnelled over UDP without any reliability layer. So if --proto udp is used, no IP packets are tunneled over a reliable transport, eliminating the problem of reliability-layer collisions -- Of course, if you are tunneling a TCP session over OpenVPN running in UDP mode, the TCP protocol itself will provide the reliability layer.

I think this means that the effect is that the "transport-level information is opaque to intermediaries" effect described in the document

Because HTTPS has historically layered HTTP on top of TLS, which is in turn layered on top of TCP, intermediaries do have access to unencrypted TCP-level transport information, such as retransmissions, and some carriers exploited this information in attempts to improve transport-layer performance [RFC3135]. The most recent standardized version of HTTPS, HTTP/3 [I-D.ietf-quic-http], uses the QUIC protocol [RFC9000] as its transport layer. QUIC relies on the TLS 1.3 initial handshake [RFC8446] only for key exchange [RFC9001], and encrypts almost all transport parameters itself, with the exception of a few invariant header fields. In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the Destination Connection ID [RFC8999], and even in the QUIC long header, the only transport-level parameters sent "in the clear" are the Version, Destination Connection ID, and Source Connection ID. For these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.

applies, with the additional consideration that intermediaries can't see the IP addresses used inside the tunnel, either. I think the same applies to any IPsec-encrypted tunnel.

Do we need to say that? And, if so - can we describe this without using product names and descriptions which may age badly in an RFC?

[SpencerDawkins]

The Wireguard description isn't as easy to read, but I think this is also the rough equivalent of IPsec, from a media operator perspective - all of the transport information and the IP addresses used inside the tunnel are obscured.

[acbegen]

Just for the record, definitely worth checking as it is related to this discussion: https://www.mile-high.video/_files/ugd/3b5446_0530e02f24b8407bb8ada0867cf6d398.pdf