Re: The TCP and UDP checksum algorithm may soon need updating

[Richard Barnes <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]
> <touch@strayalpha..com>> wrote:
>
>> See draft-ietf-tsvwg-udp-options
>>
>> > On Jun 4, 2020, at 12:13 PM, Craig Partridge <[e-mail]>
>> wrote:
>> >
>> > Then there's UDP.  UDP has no options.
>>
>
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
>