TLS uses TCP, and TCP has checksums and retry logic. It therefore assumes any data corruption that made it all the way to the TLS layer is an unrecoverable scenario, probably indicative of an attack.
replyThe problem here is that the thing computing the TCP checksum on the outgoing frame was the WLAN firmware running on the WLAN NIC itself; this is known as checksum offloading. It saves CPU time if the CPU can just hand off a TCP segment to the NIC and let the NIC checksum it before it sends it out. This only works properly if the data given to the NIC doesn't get corrupted in the meantime.
You do _not_ want to have multiple retry layers if you can help it. That can result in accidentally DoSing yourself, as each layer amplifies the number of retries.
replyBrilliant, one correct answer and three incomplete answers.
replySame reason why you never implement a VPN using TCP sockets, for those readers who solidify their knowledge by triangulation (as it were) from multiple directions.
> one correct answer and three incomplete answers.
replywell, that's what the retries are for! Keep retrying until you get a complete answer
TLS over TCP assumes TCP supplies a reliable uncorrupted stream of data. So it has no retries of its own, and terminates the connection when invalid data arrives.
replyI assume DTLS and QUIC handle MAC verification failures gracefully, like ordinary packet loss.
TLS expects a reliable connection, if the data are corrupted, that means some is tampering with the connection. It's best to avoid retrying until the tampering succeeds.
reply[dead]
reply[flagged]
reply