It seems like you're assuming that file transfer applications are sending a large file all in one go, over a single TCP session. All of the serious file transfer applications that come to my mind protect against this by handling large things in more manageable chunks -- think BitTorrent, MPEG-DASH, even HTTP range requests. That's prudent application design not just because TCP passes corrupted data sometimes, but because transport connections fail for all sorts of reasons.
--Richard
On Thu, Jun 4, 2020 at 5:26 PM Craig Partridge <craig@xxxxxxxxxxxxx> wrote:
The SSH spec says terminate on failure and that it requires a reliable underpinning.Termination on error is no good. One of the studies shows huge failure rates (over 50%) for large file transfers. One guess is that's due to security protocols terminating when TCP hands up something with an error.
CraigOn Thu, Jun 4, 2020 at 3:19 PM Richard Barnes <rlb@xxxxxx> 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!--RichardOn 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.--*****Craig Partridge's email account for professional society activities and mailing lists.
