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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 4, 2020 at 5:28 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
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?)

My point was that you could rely on a security layer in between the transport and the app, in particular one that applies authenticated encryption to verify the integrity of incoming data.  And cryptographic integrity checks are in fact bit-sensitive.

Such a layer is in place for ~92% of HTTP traffic nowadays (depending on how you measure), all WebRTC traffic, etc.  So like I said before, this kind of looks like an argument for encrypting everything.

--Richard
 

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@strayalpha..com>> 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.
>


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux