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

Nico Williams <nico@cryptonector.com> Thu, 04 June 2020 21:41 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95373A0F9B for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2020 14:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHLWXsPMNk7J for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2020 14:41:50 -0700 (PDT)
Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4C53A0F97 for <ietf@ietf.org>; Thu, 4 Jun 2020 14:41:49 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E1043180D10; Thu, 4 Jun 2020 21:41:48 +0000 (UTC)
Received: from pdx1-sub0-mail-a22.g.dreamhost.com (100-96-10-13.trex.outbound.svc.cluster.local [100.96.10.13]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6861718090A; Thu, 4 Jun 2020 21:41:48 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a22.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Thu, 04 Jun 2020 21:41:48 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Supply-Spot: 00bd33c244e5a2c1_1591306908706_86804371
X-MC-Loop-Signature: 1591306908705:1438078660
X-MC-Ingress-Time: 1591306908705
Received: from pdx1-sub0-mail-a22.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a22.g.dreamhost.com (Postfix) with ESMTP id 2792782563; Thu, 4 Jun 2020 14:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=d9CLbsR/sReBq3 R6lSXhBCpynl8=; b=EkI4pOi9spTx1eQjtX+z4bIZuuXuWQkLZe/97EA4q9Iaz6 Kc5NBfOabhc8t40um7fxT5tN9LDnTdhrp0zAMsBf2wCvRuSmfGsEE9OL/Lcg+KJG ZEJCmZvXBL4cK+eO6yntyojtkdko6o2I1sUxIlEThZoPsrUsjHs2VYjvZa938=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a22.g.dreamhost.com (Postfix) with ESMTPSA id 01AF082198; Thu, 4 Jun 2020 14:41:46 -0700 (PDT)
Date: Thu, 04 Jun 2020 16:41:43 -0500
X-DH-BACKEND: pdx1-sub0-mail-a22
From: Nico Williams <nico@cryptonector.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Richard Barnes <rlb@ipv.sx>, Craig Partridge <craig@tereschau.net>, IETF discussion list <ietf@ietf.org>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
Message-ID: <20200604214142.GU18021@localhost>
References: <CAHQj4Cf_vgXYEL=x4DCEnpwNxZpJQSD-h6MWmhMWpYwPF9XFow@mail.gmail.com> <E23EC459-213F-4D19-BC1B-6050EC2CB653@strayalpha.com> <CAHQj4CcOpciujCP9ugegjEjzyT7Oqzv_WtjWyTAGacUxkG9YYg@mail.gmail.com> <CAL02cgRjMQtcYDF04-3FsN1WOg_7H1fpR2_qPUwa-BegkQqp8A@mail.gmail.com> <528f3f54-28ad-a3ec-d693-2126a8397e67@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <528f3f54-28ad-a3ec-d693-2126a8397e67@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeguddgudehhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuggftrfgrthhtvghrnhepffdtkeethfeuteeviefgfeegjeetjedvhfehgfdvtdefueejheelgeeuhffghffgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/9V3eg7CAJtgJNh0JHLW2TTeVQPw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2020 21:41:52 -0000

On Fri, Jun 05, 2020 at 09:28:23AM +1200, Brian E Carpenter wrote:
> > On the UDP side, there should be no issue.  Anything above UDP has
> > to tolerate loss anyway, so there should be mechanisms that will
> > require from corruption-treated-as-loss. 
> 
> That depends. If a single bit inversion can get through undetected,
> the application layer might never detect an anomalx. (See what I did
> there?)

A long time ago, back at Sun, we had a NIC on a server that would
introduce paired-bit errors at offsets such that all checksums in the
stack were defeated occasionally, which then corrupted Teamware back
when Sun used Teamware over plain NFS for its source repositories(!).
IIRC there was a nifty blog entry about this, but I'm not sure how I'll
ever find it.  Anyways, that one achieved legendaray status at Sun.  It
was very hard to find, much harder than your typo :)

Nico
--