IETF Logo Mail Archive

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

Nico Williams <nico@cryptonector.com> Fri, 05 June 2020 16:39 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 5E1B73A08EC for <ietf@ietfa.amsl.com>; Fri, 5 Jun 2020 09:39:33 -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 S-6ZHPi3LKU7 for <ietf@ietfa.amsl.com>; Fri, 5 Jun 2020 09:39:32 -0700 (PDT)
Received: from bonobo.birch.relay.mailchannels.net (bonobo.birch.relay.mailchannels.net [23.83.209.22]) (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 C25B93A08E9 for <ietf@ietf.org>; Fri, 5 Jun 2020 09:39:31 -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 7AE7F1E12F6; Fri, 5 Jun 2020 16:39:30 +0000 (UTC)
Received: from pdx1-sub0-mail-a57.g.dreamhost.com (100-96-12-34.trex.outbound.svc.cluster.local [100.96.12.34]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 9DC111E0EEB; Fri, 5 Jun 2020 16:39:19 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a57.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); Fri, 05 Jun 2020 16:39:30 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Fearful-Chief: 44a0d902753150ed_1591375170193_3549846679
X-MC-Loop-Signature: 1591375170193:2894825123
X-MC-Ingress-Time: 1591375170192
Received: from pdx1-sub0-mail-a57.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a57.g.dreamhost.com (Postfix) with ESMTP id 353D17F004; Fri, 5 Jun 2020 09:39:19 -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=hoayv3TO3xOjHC XRnw5Yf91pe34=; b=f9yoyBj6wh4qxGqfcJLClToQ54jP/oJo7+V+hnPHKJCmWG FdAatkqhp6lUCMn67DHO9BM4n9UH7CItPdLkeqC7O/zqpg4xjuohvQumSaCX8Khs m68ugooUOxjcvPXtqaF+jxUeZoiDDRToEm8S2kzM/uOd6TVscClsO6Jwj0s10=
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-a57.g.dreamhost.com (Postfix) with ESMTPSA id 998007F001; Fri, 5 Jun 2020 09:39:15 -0700 (PDT)
Date: Fri, 05 Jun 2020 11:39:12 -0500
X-DH-BACKEND: pdx1-sub0-mail-a57
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: Joseph Touch <touch@strayalpha.com>, Craig Partridge <craig@tereschau.net>, Christian Huitema <huitema@huitema.net>, IETF discussion list <ietf@ietf.org>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
Message-ID: <20200605163910.GV18021@localhost>
References: <CAHQj4Cem6YdTXKFPW6Mk6gK9Yt_2qD=M7PAE6nxFEdJrD==ZVA@mail.gmail.com> <8CDB0383-41B9-4D10-BCA8-FF6FC7AFF2DD@huitema.net> <db8943fc-5cd3-9ea7-2876-a5468216d86f@huitema.net> <CAMm+Lwj=5h_zgm0=fD6AjbLmsg91ctv7a6pW0fh8L9o38C1GmQ@mail.gmail.com> <76F7B5D1-27E3-467C-9375-0030AD5B839F@strayalpha.com> <CAMm+Lwj6jAW2w-Q7RuWrJJfrfii4L7zcdykdaYHw_w_0h89ZSQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMm+Lwj6jAW2w-Q7RuWrJJfrfii4L7zcdykdaYHw_w_0h89ZSQ@mail.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: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedgkeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/io_ls46Zq3VxSL-rxKHKrgPxBYI>
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: Fri, 05 Jun 2020 16:39:33 -0000

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 <touch@strayalpha.com> wrote:
> > On Jun 4, 2020, at 7:57 PM, Phillip Hallam-Baker <phill@hallambaker.com>
> > 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

No one looks for this.

> theoretical attacks. They are by far the best kind.

This is a real problem, not theoretical.

I described an accident that happened some... I don't remember, 12? 15?
years ago at Sun.  The NIC in question showed lots and lots of errors,
but nobody noticed.  And some of those errors went undetected until
eventually corruption was detected in an application that led to a bug
hunt that found the NIC to be busted.

Nobody looks at NIC error counts.

As MTU/MSS sizes go up, as bandwidth goes up, this becomes more of a
risk.

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.

Nico
--

v2.23.0 | Report a Bug | By Email