IETF Logo Mail Archive

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

Joseph Touch <touch@strayalpha.com> Fri, 05 June 2020 16:30 UTC

Return-Path: <touch@strayalpha.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 AE0AA3A091F for <ietf@ietfa.amsl.com>; Fri, 5 Jun 2020 09:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level:
X-Spam-Status: No, score=-1.319 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 weAW_n6BXGIf for <ietf@ietfa.amsl.com>; Fri, 5 Jun 2020 09:30:24 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 00C9B3A08F9 for <ietf@ietf.org>; Fri, 5 Jun 2020 09:30:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YiV+WpWWKFOqzV28XXKqnV5NOCyVZHaZK/uUJsnuqBA=; b=MsNvLB3Ut6G3cQH1jpS524qDW o2ZK9KxYPN5yKMtrT402A/gKCiHdXC+OFkpGSsc1UMbRi3DcM9D023b87NYFJSS7PKlP0LNdFGLL/ SVyc/4uZWWeCjMMN7m8zjeYCW8kg/t3lZlrBo7U7lXo+qoUKl2N2wR1fS7LPZjc0eEd9CY0UjNltU pwxvg6ZwTFnrgEvVQJyAwTJjKUyVoRg24pZRNCDLWOWG5n5HL74lTNOm0vXkYBKQS6izb3sC7Lzgr xp92wXgO6PE0vsYMIVHdc+eZvMUgCqiQtqsW9TQgSCcy9ukX7VzBb3ipVKIGgDWcZtB/2dZq+oDlX NDz855OQw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61175 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1jhFEQ-002rOR-Ig; Fri, 05 Jun 2020 12:30:15 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <CAMm+Lwj6jAW2w-Q7RuWrJJfrfii4L7zcdykdaYHw_w_0h89ZSQ@mail.gmail.com>
Date: Fri, 05 Jun 2020 09:30:09 -0700
Cc: Christian Huitema <huitema@huitema.net>, Craig Partridge <craig@tereschau.net>, IETF discussion list <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FFA92FA3-4349-419F-A650-F7796A04A004@strayalpha.com>
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>
To: Phillip Hallam-Baker <phill@hallambaker.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/DI62OgKr8UowLlCwTt0ETgiuvv0>
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:30:32 -0000

Hi, Philip,

All these statistical analyses assume that errors are not correlated in many dimensions. If that were to happen on the wire, it would likely be caught by things like Ethernet’s CRC. The issue we’re dealing with are errors that are either not caught on the wire OR happen in memory or processing, neither of which are very likely to be uncorrelated.

The only thing that’s “pretty clear” to me is that if this were actually as uncorrelated as you’re assuming, we would have lots of examples of transfers that failed. I asked a simple question - are we seeing that? I’ll admit that doesn’t come up for me, but by everyone’s “analysis” they ought to be raining down everywhere, esp. in large data centers. But I haven’t heard anyone screaming yet.

So either the other protections we have (as others have mentioned) are sufficient or these errors are not correlated the way that’s been assumed (and thus they’re being caught by the existing checksum).

There’s no law against repeating a checksum with different data if all the data gets there OK.

Joe

v2.23.0 | Report a Bug | By Email