Yeah, secure transports already consider the data from the network untrusted, including TLS and DTLS, but also IPsec/ESP, SSH, SRTP and QUIC. As long as those protocols are using reasonably modern, AEAD ciphers, the worst impact of corruption in the transport is DoS.
That said, there might be some pretty hard crashes in cases where the security protocol relies on the transport for something.. For example, TLS doesn't have a mechanism for requesting that data be re-sent in the event of loss/corruption, because it's assumed that TCP provides that. If corruption is only detected at the TLS layer, there's not a way to recover. That said, I wouldn't be surprised if many TLS stacks close the connection on bad data anyway.
On the UDP side, there should be no issue. Anything above UDP has to tolerate loss anyway, so there should be mechanisms that will require from corruption-treated-as-loss.
So there may be some feedback loops to close, but that's a more limited, host-internal problem.
In any case -- one more reason to encrypt everything!
--Richard
On Thu, Jun 4, 2020 at 4:17 PM Craig Partridge <craig@xxxxxxxxxxxxx> wrote:
Ah, I somehow had missed that.Looks like it does the trick if we need it. Not sure if we'd have to update the optional checksum to use a new checksum too.
CraigOn Thu, Jun 4, 2020 at 1:33 PM Joe Touch <touch@xxxxxxxxxxxxxx> wrote:See draft-ietf-tsvwg-udp-options
> On Jun 4, 2020, at 12:13 PM, Craig Partridge <craig@xxxxxxxxxxxxx> wrote:
>
> Then there's UDP. UDP has no options.
--*****Craig Partridge's email account for professional society activities and mailing lists.
