[ih] "how better protocols could solve those problems better"

[Joseph Touch]

> On Oct 1, 2020, at 6:50 AM, Craig Partridge via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> On Wed, Sep 30, 2020 at 6:58 PM Joseph Touch <touch at strayalpha.com> wrote:
> 
>> 
>> 
>>> On Sep 30, 2020, at 4:58 PM, Craig Partridge via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>> 
>>> I've got some NSF funding to figure out what the error patterns are
>>> (nobody's capturing them) with the idea we might propose a new checksum
>>> and/or add checkpointing into the file transfer protocols.  It is little
>>> hard to add something on top of protocols that have a fail/discard model.
>> 
>> We already have TCP-MD5, TCP-AO, TLS, and IPsec.
>> 
>> Why wouldn’t one (any one) of those suffice?
>> 
> 
> Actually no.  These are security checksums, which are different from error
> checksums.  The key differences are:
> 
> * Security checksums miss an error 1 in 2^x, where x is the width of the
> sum in bits.  Error checksums (good ones) are designed to catch 100% of the
> most common errors and miss other errors at a rate of 1 in 2^x.  So a
> security checksum is inferior in performance (sometimes dramatically) to an
> error checksum.

Except for “designed to catch” errors, 1 in 2^ = 1 in 2^x, so the real question is whether there are errors we should be designing to catch - and whether that sort of design is even possible.

> * Security checksums are expensive to compute (because they assume an
> adversary) and so people tend to try to skip doing them.  Error checksums
> are easy to compute.

MD5 is roughly 20-30x more expensive than the IP checksum. CRCs can be similarly expensive when done in software. However, hardware accelerators exist and are already widely deployed for both.

TCP-AO would be very easy to configure to support any checksum (just make the key string constant and public and pick a checksum as the algorithm). IPsec could similarly be extended.

In both cases, we have the framework to solve the problem NOW with existing protocols. The only issue (as with any solution) is adoption and deployment.

Picking an error checksum is relatively straightforward - measure the errors, test against known checksums to see if they suffice, and if so, pick one. The only challenging part of this problem happens if those don’t suffice - and its an algorithm issue, not a protocol one. The rest is legwork.

This doesn’t fit the bill as “better protocols” being needed.

Joe