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

Michael Thomas <> Thu, 11 June 2020 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C5DA3A0CF2 for <>; Thu, 11 Jun 2020 11:33:19 -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 7tFEuZD39bH2 for <>; Thu, 11 Jun 2020 11:33:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70C653A105E for <>; Thu, 11 Jun 2020 11:32:32 -0700 (PDT)
Received: by with SMTP id t7so2888278pgt.3 for <>; Thu, 11 Jun 2020 11:32:32 -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=dYcwY0QxIzs8Lwv8k7AyRmUT0q4rm8cZjTp2V3Szyek=; b=pfV/kKoYM4A/dccWFAlZnEJLAKL7hGV7Dn17BtS+h14GVbbQuwkx6t0B196bvyYGmf RnkrPLqaMOJXEQblAbuBDmJ8KPKES+Xu5N6RMl+0s7l1YCx7VIolc8yU5O46O3P2L4A+ VYafJn4f1MM2WUcwCgbKEdiIkiH6gmc3kP3H95HY6Qd9W99DPMeNseKNG/om2Nz25ekX sLTumeFd2DiL9nzaNxHmNRbF7BVfEF9/ye2IlaCziiy54Lo0gz8FHg75QpgwO37w1rC1 tKpPiOt4JhffiIbvA6qblt8hhL8RDN7eTpsy6ckVqdMnsE3yfOPhx7ePwzkyEgyWQrid fzCQ==
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=dYcwY0QxIzs8Lwv8k7AyRmUT0q4rm8cZjTp2V3Szyek=; b=Ju3YlPhRbZnWT4MQvWU4myMQQr1yi293OcXw3Uiv7kcNMg2QYD5IeHg038AtoJhaZd OJ+l26s/PwqwLR9JdDknZSQwgdEk1f8XFcJmEJghmIFe2ue+5gwc1OVpNXq4UslrSEBH CEnyqEqUh2S08yJBXtAXsUEqbChj95XKhJEcaglmY1uCaMlwhYz/GpXmhHIrtIgncFQN 9raO+28oOC9N+hUa78VYfNbrgEtCuPeoeWv0GK+yQnNtLnXb40phcwEwKPczyOODnAj1 LGePH90VAb3sIrYvORIX6losGL3HkSCdN2RpGkMVXUkp8U49fw3/UaL4Uo2S2m+Pjiec G6gw==
X-Gm-Message-State: AOAM531bZL12tD7Qtg8htq/CoDSR0jcfGYUmxknrCfVYEGN6Hcom2mam 3YeROZ9mWiiG9Ya6hVQ4cKhGq909G7U=
X-Google-Smtp-Source: ABdhPJwdv/a4qmN9H4KvWWeLnUVi+oBOVG7P8fulf9fm5uSOxCon14hJ1lQ5DNMTZmIh39wfhD9hpQ==
X-Received: by 2002:a63:a062:: with SMTP id u34mr7950664pgn.62.1591900351240; Thu, 11 Jun 2020 11:32:31 -0700 (PDT)
Received: from MichaelsMacBook.lan ( []) by with ESMTPSA id b5sm3260701pjz.34.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Jun 2020 11:32:30 -0700 (PDT)
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
References: <>
From: Michael Thomas <>
Message-ID: <>
Date: Thu, 11 Jun 2020 11:32:28 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
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, 11 Jun 2020 18:33:19 -0000

On 6/11/20 11:26 AM, Craig Partridge wrote:
> Two comments on the several notes that have gone past.
> Michael Thomas raises a point about bugs.  He's quite right and 
> there's reason to believe that if we tracked the Internet paths on 
> which checksum errors took place, and compared the paths to find 
> commonalities, we'd locate broken/buggy equipment.  Jonathan Stone did 
> some of that 20 years ago and found a software bug in a vendor TCP 
> (which the vendor updated in a matter of days -- kudos to them) and a 
> network interface vendor who was shipping cards with defective 
> hardware (and adamantly claimed our measurements identifying their 
> cards were wrong).

Ha! I once got sent on site to find a tcp bug for my stack which we 
couldn't reproduce. Found it in about an hour or two. Got to see the 747 
that transported the space shuttle. Now *that's* a transport layer you 
don't want to find bugs in :)

> There was also a note (which I can't seem to find) to the effect of 
> "the errors in the papers don't match what I'm seeing on my systems."  
> That's not a surprise.  Errors cluster around particular links or 
> devices.  There's also some reason to believe error rates are higher 
> on the fast links.  So, depending on your environment and where your 
> traffic goes, your error rates may vary widely.  All the more reason 
> to measure.
It also wouldn't be surprising that it highly correlates with version 
1.0 vs 1.1. One of the depressing things about mobile phone stuff is the 
degree that vendors stop supporting updates, with it being particularly 
bad for Android.