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

Phillip Hallam-Baker <> Fri, 05 June 2020 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF4533A07BA for <>; Fri, 5 Jun 2020 09:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uzbRlepROuCS for <>; Fri, 5 Jun 2020 09:10:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8CAD3A07AF for <>; Fri, 5 Jun 2020 09:10:37 -0700 (PDT)
Received: by with SMTP id e8so2078407ooi.11 for <>; Fri, 05 Jun 2020 09:10:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ejqgt7k85HTm9WJbFcScd/tNE7TwCj7PFg6oJMXgeXk=; b=kuOcPc5vgB+djXD/H61/yM6u/iGcQOMWTmzsnJKoQrPDiXG6uWZzwv+mppet+BkAGF 45YNhqN98cfeWbMHpLVwVe/emuCh7FQw5CS6oi0+BtH/BEFtyl3WHfeVO+tI5m3vb/pc 1t+zQ469wddDf6m4O5318J9OhjPqtbcoo9t1+oNBJehW4o4dSwLo6Qh7Eoq1BdiV/Q88 FXK9zFbW/tjm9dEg/QFoELyvb/bY9oykX/xSVd9nXENsXi0EepiJf/q/0cPGh9402klL WPXi5U3aLs3jlU8w5TQJP9InIeQ2RU+8jDiX1/AJV3nZu9RLfAfdP1RJc0L7Ng/hb+pd P71A==
X-Gm-Message-State: AOAM5309G2sgjMotG88gEAEwHZUBdvsfV8+MtNCUZTrnfDZmMIj8QL74 Z7v35MisfbfITXYZO9BmnmWLq5S3PZ/HPZlFCmFIgO093O8=
X-Google-Smtp-Source: ABdhPJyTOQ76ETvKnKz3E6FH85v59ezaJqPbtG48kt3sA7LPi3Jist02VkJiavUgl245suLfGJ1e6O4e4whIeHoWx/k=
X-Received: by 2002:a4a:e2c1:: with SMTP id l1mr8419042oot.12.1591373436825; Fri, 05 Jun 2020 09:10:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Phillip Hallam-Baker <>
Date: Fri, 5 Jun 2020 12:10:25 -0400
Message-ID: <>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Joseph Touch <>
Cc: Christian Huitema <>, Craig Partridge <>, IETF discussion list <>
Content-Type: multipart/alternative; boundary="00000000000068330f05a75880e9"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Jun 2020 16:10:39 -0000

On Fri, Jun 5, 2020 at 12:01 AM Joseph Touch <> wrote:

> On Jun 4, 2020, at 7:57 PM, Phillip Hallam-Baker <>
> wrote:
> Consider the case in which I am transfering a 60GB 4K movie over the net.
> Say for the sake of argument there is a 1% chance of a one bit failure.
> There are a lot of statistical assumptions in that statement.
> How about somebody showing an actual case where this has happened, please?
> Before we solve a problem in theory rather than in practice.

Has anyone been looking? The security area has always been interested in
theoretical attacks. They are by far the best kind.

I was throwing those numbers out to point out what is now a routine sort of

It is clear that as the size of bulk transfers increase, the probability of
a transmission failure that is not detected by the transport layer
approaches 1. Traditionally, we just ignored the risk. That was probably an
acceptable response in the days when we bought memory in 128K modules.
Those assumptions no longer hold.

SHA-2-256 is good for pretty much any feasible data transfer. But HTTP
certainly isn't and neither is QUIC. And it would be kinda silly to
conflate a protocol designed to support fast interactive response for Web
browsing with bulk data transfer.

The Mathematical Mesh has two separate messaging systems. There is a
control plane where the messages are limited to ~32KB (not certain that is
the sweet spot yet but less than 64K). And there is a data plane for bulk
messages that will be eventually engineered to support Terabyte and
Petabyte transfers.

It is pretty clear that the current transport checksum is sufficient for my
control plane. It is equally clear that the data plane can't rely on any
imaginable transport layer checksum to support Petabyte transfers. So I am
fine with the transport checksum either way.

Sure, I have taken some extreme points on the curve here and there might be
a point inbetween where it makes sense to upgrade the transport checksum
because it is causing issues at the application level. But the burden of
proof is on people suggesting we need to change the transport checksum that
such a position exists.