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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sun, 07 June 2020 03:46 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 4AFEA3A094D for <ietf@ietfa.amsl.com>; Sat, 6 Jun 2020 20:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 L1270zWe51lS for <ietf@ietfa.amsl.com>; Sat, 6 Jun 2020 20:46:54 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id EA4D53A095A for <ietf@ietf.org>; Sat, 6 Jun 2020 20:46:50 -0700 (PDT)
Received: (qmail 80356 invoked from network); 7 Jun 2020 03:29:55 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 7 Jun 2020 03:29:55 -0000
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: ietf@ietf.org
References: <CAHQj4Cf_vgXYEL=x4DCEnpwNxZpJQSD-h6MWmhMWpYwPF9XFow@mail.gmail.com> <0D18B54B-2865-4A3C-813B-595EA17F6D8B@gmail.com> <32750.1591376396@localhost> <CAHQj4CdopwpEfyuOVO3ZywTKveQMpnt_WPh_JDRydgNKHVVmhw@mail.gmail.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <135be980-9c3b-e7f4-28c6-184d0b48c5cc@necom830.hpcl.titech.ac.jp>
Date: Sun, 07 Jun 2020 12:46:33 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAHQj4CdopwpEfyuOVO3ZywTKveQMpnt_WPh_JDRydgNKHVVmhw@mail.gmail.com>
Content-Type: text/plain; charset="iso-2022-jp"; format="flowed"; delsp="yes"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7pC1mVSb7rpth9PSyE1xCO-im6k>
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: Sun, 07 Jun 2020 03:46:57 -0000

Craig Partridge wrote:

> OK, on to what people are seeing today.  This shows that 1 in every 121
> file transfers FTP delivers a file that, when you do the md5 sum, turns out
> not to match the original (note there are multiple possible reasons, but
> TCP checksum is a strong candidate).

That's unreasonable because most errors are detected by datalink
layer checksum and almost all remaining errors are detected by
transport layer checksum, which should have been the reason
why transport checksum need not be so strong.

> Anecdotally, folks are reporting some middlebox vendors are not updating
> the TCP checksum but rather letting the outbound interface simply recompute
> the entire checksum -- which means that if the TCP segment gets damaged
> during middlebox handling, the middlebox will slap a valid checksum on bad
> data.

That should be the real problem to make transport checksum not
to work end to end.

Thus, your proposal to have stronger checksum can not prevent
file corruptions.

So, we should make middlebox vendors to update checksum incrementally
or, check the original checksum just before sending a packet
with the original header (not applicable if payload is also modified).

						Masataka Ohta

PS

This is a old problem documented in the original paper on
the E2E principle.

https://dl.acm.org/doi/pdf/10.1145/357401.357402
2.2 A Too-Real Example
One gateway computer developed a transient
error: while copying data from an input to
an output buffer a byte pair was
interchanged, with a frequency of about one
such interchange in every million bytes passed.