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

Nick Hilliard <> Mon, 08 June 2020 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2AEC83A03ED for <>; Mon, 8 Jun 2020 02:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U_QPLQAKr5JG for <>; Mon, 8 Jun 2020 02:09:36 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDF303A03F2 for <>; Mon, 8 Jun 2020 02:09:35 -0700 (PDT)
Received: from crumpet.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 05899VPD034545 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2020 10:09:32 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] claimed to be crumpet.local
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Michael Thomas <>
Cc: "" <>
References: <> <> <> <> <> <> <> <> <>
From: Nick Hilliard <>
Message-ID: <>
Date: Mon, 8 Jun 2020 10:09:30 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.17
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
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: Mon, 08 Jun 2020 09:09:38 -0000

Michael Thomas wrote on 08/06/2020 01:21:
> well, it could send it to the wrong port, but i'll guess that tls is on 
> to that problem. i mean, it kind of sounds like you're saying the 
> transport checksum failing isn't a big deal? creating a gigantic window 
> would certainly not be a good thing in the face of congestion. transport 
> mode ipsec wouldn't suffer those kinds of problems.

in their current incarnations, transport mode ipsec and tcp-ao aren't 
deployable at scale in the same way that tls is.

Regarding transport layer integrity, there are distant echoes of the old 
circuit-switched vs packet-switched arguments going on here.  tcp/ip 
made circuit switching redundant by loosening its assumptions about 
transport layer reliability.  I wonder are we now seeing something 
similar with TLS, which no longer depends on either underlying transport 
or ip header integrity by pushing data stream integrity management 
higher up the stack.