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

Phillip Hallam-Baker <> Sun, 07 June 2020 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F05913A003E for <>; Sun, 7 Jun 2020 11:38:07 -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 GwA0a_JFarWb for <>; Sun, 7 Jun 2020 11:38:06 -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 8D9AE3A080E for <>; Sun, 7 Jun 2020 11:38:06 -0700 (PDT)
Received: by with SMTP id 7so3039386oof.8 for <>; Sun, 07 Jun 2020 11:38:06 -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=JyKPff2PzG8vlJEu4Unk0R2aDlAhTPEy0LcvvuFT0KQ=; b=DfS/Uq3sgYu8Wy9c/olTaVBol59ApnRwGEib7iTALu9uQ5QVrDYJzV6vtsXnKlPgxz iEaPFQ9qK3LOvY3yLU2nwj07j3rMm/zq+hL2lBLZ8gQ6iETOllROgdEaKioVvwUFcqyI RZ8l4mjnOPmkrXOoiV/FiQRC7sVlOmZfMXOIZjxJvUzeRVIOt+ONZmM7vvjXE9JpS1aP /fuQ0IFX7V3rr8mN7b7fjUUte0vstH0VdHxt7Rvp8aRG+n0s3/H2A+jhtMLvYLFhD4FQ ZaWd6DLq4oecjpg5u6HP1pI82eJEPA5c2hkSbmGYdBSqomiGPJpenx2hbQVfXsnRsQcW wVIA==
X-Gm-Message-State: AOAM531FON3jYFXcVTj4c8+PFYF/lRlrwafWtGPVjnNYRvFm0QTjsIir xvwwIJG/hTH5y0vj98jHE4f4sH0oQfkd+Ra2RmA=
X-Google-Smtp-Source: ABdhPJxrmckmabxB0Y/sapTyqD/jV/i16HyMc1p9ROecjMNJURDEU+71gNB4mRf93xzTxmitNs56x1gZTcurw02sLg4=
X-Received: by 2002:a4a:e2c1:: with SMTP id l1mr15190176oot.12.1591555085577; Sun, 07 Jun 2020 11:38:05 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <20200605163910.GV18021@localhost>
In-Reply-To: <20200605163910.GV18021@localhost>
From: Phillip Hallam-Baker <>
Date: Sun, 7 Jun 2020 14:37:54 -0400
Message-ID: <>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Nico Williams <>
Cc: Joseph Touch <>, Craig Partridge <>, Christian Huitema <>, IETF discussion list <>
Content-Type: multipart/alternative; boundary="00000000000084328305a782cb42"
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: Sun, 07 Jun 2020 18:38:08 -0000

On Fri, Jun 5, 2020 at 12:39 PM Nico Williams <> wrote:

> On Fri, Jun 05, 2020 at 12:10:25PM -0400, Phillip Hallam-Baker wrote:
> > On Fri, Jun 5, 2020 at 12:01 AM Joseph Touch <>
> wrote:
> > > Before we solve a problem in theory rather than in practice.
> >
> > Has anyone been looking? The security area has always been interested in
> No one looks for this.

Does anyone have infrastructure that works so well and so dependably that
they can afford the time to perform a full post mortem on every error?

How many people do post mortems versus turning it off and on again? There
are so many bugs in the application layer that hardware errors are rarely

Case in point, I have close to $10K worth of consumer level Internet gear
in my house. Every so often the network will go into some weird race
condition that is clearly a consequence of buffer bloat or some piece of
connected hardware spamming the network with garbage. The manufacturers
provide precisely zero support for debugging. None, nil, nadda.

The reason I try to use consumer grade equipment is that I want to
understand the system from the consumer's perspective and right now I don't
have any respect for any of the hardware suppliers involved. That said, 24
port PoE internet switches are probably not consumer grade.

> > theoretical attacks. They are by far the best kind.
> This is a real problem, not theoretical.

Of course it is real. The Internet is a sufficiently large network that
everything that can happen will happen.

> Now, we've talked about how some applications are or can easily be
> impervious to this.  If you're transferring static data, this is not a
> problem because you just use crypto that detects TCP checksum failures
> and then make the application protocol recover.  But some applications
> are more difficult to address than others.
> I wonder how much TCP offload HW will complicate the upgrade path here.

The argument I was making was actually somewhat different to the one Joe
responded to.

My point is actually that data transfers are becoming sufficiently large
that it is no longer sensible or useful to adopt the assumption that TCP is
a perfect, error-free transport at the application layer.

But the memory issue Michael raised is also rather important. The UNIX
assumption that 'everything is a stream of bits' was a viable assumption at
one point in time. But as we build larger and larger systems, that
assumption also becomes weak. We need to think about how we store large
quantities of data on SSD etc. as well. I already have RAIDs that are
approaching 100TB and soon we will be at the point where PetaByte SSD
stores are common.

If we want systems to work well, we cannot build systems that are hurling
terabytes of data about in the exact same way that we used to build systems
when a 20MB drive was the acme of luxury.

Rather than trying to make TCP/IP a flawless transport, we have to apply
the same principle of making a lossy channel robust at the higher level.