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

Michael Thomas <> Thu, 04 June 2020 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34AD23A0EF5 for <>; Thu, 4 Jun 2020 12:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VYDlRrDzTksT for <>; Thu, 4 Jun 2020 12:48:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A83593A0EF4 for <>; Thu, 4 Jun 2020 12:48:10 -0700 (PDT)
Received: by with SMTP id m7so2640921plt.5 for <>; Thu, 04 Jun 2020 12:48:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=y7d7liTGqT8Lj/5+C1JGHaYw58G6WWz/yT8AL5Y0jPQ=; b=fyRwoWPA7WgSHUVvtr/FsHiwafdU6Ez0TvrI8IQ49d7Xh2bo5GHGuvqLip7oiR48Ao MRYPoxVnm6mnwuIDBatfa/HuHUwVu5L/dlC1nawN3oCkPeNB3/gV94FffeyvfGE2+3kw zWCdWexgmXNSlgsYMXBjfIPElavumy8gxLNT0pHAbDfwRNKPeSDdXeMbUWQMVFeJ0Hkx iaQ3XkRw4YXYkXBB4cUSz1H3dfB8P55dSNBdlf1s0nSDOFV6kulN3fu30gsAABVDdfsi NfuUUc2OaFY6l8E7lcDoFRdn3bSYzgcR4XNgg8bLPocsVZAN7TgYschKYQLbDf3mGF/5 EpLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=y7d7liTGqT8Lj/5+C1JGHaYw58G6WWz/yT8AL5Y0jPQ=; b=Tvjd5OY1Z+XVNXPrqkjWqzxD2FPygcB8ighGNqUGhwX71Si299paesLVVfbxeuEkW4 4ftj6lf30RPu3RSKRC9ZSAZWcvyUrObAs+OxVwrNHYZ+87M9ebtd+JIs66UfUbQmq4nY Y1towik62xMnqry3esVJknAeLTY/a3sWEINel2dEuxre7Le5vVpEEK4ZWQWMXHV1esz6 qd22mT+L4wbfk9fvrfWOTzMG5awfbmKIbx4PkukSoUU7DqEh69likt26/2tscyvincCH dhKlVfzUpMDyQ2CKgt5LJ3aS5srVivc0sd2kmaUiI0rYrNx4xQO/RSD51PAGtXvdjARp mdJA==
X-Gm-Message-State: AOAM532vEDLX9zWH62cPnvkOUKuWLxidID3dVK3/E41RAU+4KD1QJS7C 6DJ1LP3zAJ2DXKHad/xniQDOMlou6fk=
X-Google-Smtp-Source: ABdhPJz6hEvcpJe4gCab5v+TgUgDXgOOmEcRrFimcIIJpAs+nSWtyNOG2+o6eEUvWQd29x2Uok1TZw==
X-Received: by 2002:a17:90a:5e0e:: with SMTP id w14mr7738047pjf.128.1591300089353; Thu, 04 Jun 2020 12:48:09 -0700 (PDT)
Received: from MichaelsMacBook.lan ( []) by with ESMTPSA id t64sm4790755pgd.24.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2020 12:48:08 -0700 (PDT)
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
References: <>
From: Michael Thomas <>
Message-ID: <>
Date: Thu, 4 Jun 2020 12:48:06 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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: Thu, 04 Jun 2020 19:48:13 -0000

On 6/4/20 12:12 PM, Craig Partridge wrote:
> Hi folks:
> This note is intended as an invitation to think a bit about a 
> potential hard problem.
> There's a small body of literature suggesting that the TCP checksum is 
> regularly failing to detect errors and that we're getting close the 
> point where using an MD5 authentication check will be insufficient 
> (e.g.. the number of times the TCP checksum fails to detect errors is 
> so large that TCP passes through enough errors that the md5 check 
> won't catch all of them).  This situation is due to the growth in both 
> total traffic and the size of individual data transfers.  This is not 
> a surprise -- it was anticipated 20 years ago, when studies showed the 
> TCP checksum was quite weak.

How does this interact with (D)TLS? Assuming the error is in the packet 
body which would be most likely for data payloads, the TLS layer would 
detect the error too, right? Obviously ack's coming back would still suffer.

Also: since it's clear that any new and improved checksum is going to 
take forever to get upgraded, do we know what the implications are for 
higher error rates? Is there anything non-linear that could happen if we 
don't fix it, or does it just chug along getting more and more uncaught 
errors due to traffic volumes?

Last given L2, can it be a backstop?