Why encapsulates the IP layer vpn is a Bad Idea using the TLS record Protocol

A natural idea is to use TLS to encapsulate an IP datagram to implement a layer-3 VPN.
This idea must have been well thought out, but unfortunately this is a wrong idea. There Is an article Why TCP Over TCP Is A Bad Idea, which explains Why in detail. In fact, the retransmission superposition problem cannot be solved. You must know that the RTO Calculation of TCP is extremely complex and there are many factors that affect it. That is to say, as long as you use one TCP to encapsulate another TCP, the outer TCP packet loss, and the RTO is smaller than the RTO of the inner TCP, the connection will crash. The above conditions are easily met.
Using TLS to encapsulate IP datagram is a misuse of TLS! The original intention of SSL/TLS is to provide the security layer above the transport layer, which runs reliably on TCP. The record layer protocol encapsulates application layer data. Therefore, SSL/TLS is a security enhancement for TCP-based applications and is not a common transmission protocol. The reason for TLS running on TCP is that the application is based on TCP. If you want to implement an IP-layer VPN and use TLS to encapsulate IP datagram, it is equivalent to using IP datagram as a TCP-based application data, isn't this the scenario of connection crash described in Why TCP Over TCP Is A Bad Idea? The fact is that IP datagram is obviously not TCP-based application data.
Later, DTLS emerged, obviously removing many constraints and being much more lightweight. If you want to encapsulate IP data packets using TLS, you should first think of DTLS instead of TLS. DTLS is derived from TLS and retains the unordered semantics of UDP, but it still inherits many complicated things from TLS. In essence, DTLS also encapsulates application data, which is based on UDP. Following this idea, if we can regard IP datagram as a UDP-based application data, we can use DTLS to encapsulate it, can we? Of course! UDP itself is the layer-4 image of the IP, but there is an additional multiplexing mechanism. Using DTLS to encapsulate IP datagram to implement an IP-layer VPN would be a good choice, but there are still better methods.
OpenVPN provides a better way to implement control channels only through TLS, while the data channel that encapsulates encrypted IP data packets is the preferred normal UDP channel. This is a bit IPSec shadow, isn't it? IPSec uses independent IKE to negotiate with SA, and then uses the independent ESP/AH protocol to encapsulate and encrypt IP datagram. In fact, this is the correct way to implement the IP-layer VPN. Originally, security parameter negotiation and authentication/encryption are two independent processes. TLS/DTLS encapsulates these into a session. The session is established through a process called SSL handshake, and the security parameters are negotiated during the handshake, after the handshake is complete, the negotiated security parameters will be used to protect subsequent application data. This approach is not flexible because you cannot add your own negotiation mechanism unless you modify the TLS protocol. In addition, as a TLS Record, IP datagram is encapsulated in Application data. What can be seen externally is a TLS Record, which is difficult for the intermediate system to identify and control. That is to say, as the encrypted IP datagram transmission protocol, TLS is suitable, but it is difficult to control it from the outside. What you see is always a TLS Record header, rather than the VPN protocol header.
For the protection of IP datagram, the final idea is still the idea of IPSec, that is, to define the security endpoint, to define the security alliance, to negotiate security parameters, to protect IP datagram, the four processes are completely independent. Although you can regard IP datagram as "Application Data", it is not application data after all. TLS is derived from the security requirements of application data. It is applicable to a single application, individual business logic can play a very good role in security reinforcement, such as implementing HTTPS, such as the control channel of OpenVPN, which is a single and fixed business application, but it is not suitable for encrypting IP data packets, aside from the TCP over TLS connection crash issue, introducing DTLS, adding control and transmission in one session will make expansion difficult. For example, the firewall cannot distinguish VPN data from other TLS application data, for example, you cannot implement multicast encryption. For example, you cannot re-negotiate individual security parameters. The same SSL session cannot be shared by different security endpoints...
Therefore, using the TLS record protocol to encapsulate the IP layer vpn is a Bad Idea. dtls is better, but it IS not absolute. The real good solution is to use TLS as the control channel to negotiate and exchange security parameters to the maximum extent, and then define an independent encapsulation protocol to encapsulate IP datagram protected by security parameters. There are too many examples, such as IPSec and OpenVPN, but the OpenVPN code is too disgusting. It may be better to write it by yourself after you understand it.