Richard, > 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. That depends. If a single bit inversion can get through undetected, the application layer might never detect an anomalx. (See what I did there?) Regards Brian Carpenter On 05-Jun-20 09:18, Richard Barnes wrote: > 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 <mailto: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. > > Craig > > On Thu, Jun 4, 2020 at 1:33 PM Joe Touch <touch@xxxxxxxxxxxxxx <mailto:touch@xxxxxxxxxxxxxxx>> wrote: > > See draft-ietf-tsvwg-udp-options > > > On Jun 4, 2020, at 12:13 PM, Craig Partridge <craig@xxxxxxxxxxxxx <mailto:craig@xxxxxxxxxxxxx>> wrote: > > > > Then there's UDP. UDP has no options. > > > > -- > ***** > Craig Partridge's email account for professional society activities and mailing lists. >
