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

Michael Thomas <> Wed, 10 June 2020 00:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C578A3A0CDB for <>; Tue, 9 Jun 2020 17:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BG6eXs0hZizr for <>; Tue, 9 Jun 2020 17:31:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1044]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35EE73A0CDA for <>; Tue, 9 Jun 2020 17:31:37 -0700 (PDT)
Received: by with SMTP id a45so1486938pje.1 for <>; Tue, 09 Jun 2020 17:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=QSUhuxoj69w3rx1kdmf71CjnZIQKrgOVSh1rAUiPY9E=; b=pDyQb/ZOxlmBv9MJx/XYSyIV/x0ifThDtqaHmTD5KABKz0g/pfM87X2NKiV20Oaf4E v03lmiFblCOvXTfNgtGjpcRw/bAI82KtZmRSuGcwsGhAZWCzmPb7XMOZnkC9HWULW3D3 w977Is4iquiZY6um8mHlRp2YxCLSQQWp3LplXMC9rBnN6hIrWs9lb3KNzMnrRW9SxRa0 q1MDteeI23qskKK340+L7T7ZLwvmSr7L35p9fWQhD7MSktGd1yg7hBbq1GqKmnMsDinJ yXnQ9Jr9id153nCbsL4keNWaP1STXqSUihSpQ8UwNFoFBSVQK1tQ+zgAXxY5G4qhqkR2 DDCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=QSUhuxoj69w3rx1kdmf71CjnZIQKrgOVSh1rAUiPY9E=; b=nXGQsCuqoz+hUurrjg5n4Se27DrhGjLtldBBNj/yqYXCqlBh9XZ2UiEyuAIA4qjSOq DvPwFboYF7WWYKq88EU4/hILbPvrEtN5pawZAEqWytioxHe8Z0DSn0sXNASPqohf7etO DZERgPf5CLzRHC/Qb5iD+DrK7mIfnNC9G7KdbqOwPQmhGRzj8U7jq0hCWzgpK/naoemw 0W2gPnmfaCHmJVziInC4V+nDbEjglqZfBse3Jokok57FFhypyTosYTEy6Mt05jO9kVd3 IVG6QTUKRZvivl7FgwYsDKV2xg2f/d0C4lAEYuc7XDeADVGLp5TTWe1Hgy1ntMNQoyTk V+lQ==
X-Gm-Message-State: AOAM532oeCoFhQpsAjRN13kEknkijh8go9igaBx4UoaaSbfSPXmK+YAf SbK7OfpXOpRBS6LXyj0eUBwmmDGDZ0M=
X-Google-Smtp-Source: ABdhPJzC5zFTRi7Oi+bu+o7sFtFvtQAR+L3Bz2eje4KgK6CuvHX1stw1WdXP8EtqkjpHeeiowRc00Q==
X-Received: by 2002:a17:90a:ac0f:: with SMTP id o15mr377675pjq.105.1591749095584; Tue, 09 Jun 2020 17:31:35 -0700 (PDT)
Received: from MichaelsMacBook.lan ( []) by with ESMTPSA id gm11sm3459138pjb.9.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 17:31:34 -0700 (PDT)
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Nico Williams <>
Cc: Nick Hilliard <>, "" <>
References: <> <> <> <> <> <> <> <> <20200608190220.GA18021@localhost> <> <20200610001225.GD3100@localhost>
From: Michael Thomas <>
Message-ID: <>
Date: Tue, 9 Jun 2020 17:31:32 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <20200610001225.GD3100@localhost>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
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: Wed, 10 Jun 2020 00:31:39 -0000

On 6/9/20 5:12 PM, Nico Williams wrote:
> On Tue, Jun 09, 2020 at 04:32:38PM -0700, Michael Thomas wrote:
>> On 6/8/20 12:02 PM, Nico Williams wrote:
>>> Also, IPsec got a lot of things wrong.  It's simply not usable at
>>> Internet scale as originally intended because... it's IP-layer, so it
>>> deals in discrete packets and IP addresses.  Well, discrete packets do
>>> not define application connections/sessions[*], IP addresses are too
>>> dynamic and useless for authentication and authorization[**], and
>>> configuration is ETOOHARD.
>> Yes, but that's a feature not a bug in this particular case. I really don't
>> find it believable app developers would have had a hard time with making the
>> OS calls needed anymore than making the calls that the TLS libraries
>> require. And as always: when something is widely used, it gets care and
>> feeding. So if ipsec is still clunky, and says it's because it's not being
>> widely used, and the niche cases of vpn's can suck it up.
> The IPsec model is busted even for VPNs.  To mitigate the issues that
> arise in VPNs you really need to assign a unique internal address to
> each user or accept that authorized users may mount certain attacks on
> each other.
Ok, i'm confused. The demultiplexing of the 5-tuple deals with that, 
right? Just like with TLS which implicitly uses that demultiplexing the 
OS provides as well.
> But there's nothing about ESP itself that relegates it to VPN usage
> only!  Only the IPsec architecture (RFC 4301) causes that, not anything
> about ESP.
> ESP would have been _great_ for transport-mode IPsec and widespread
> application use if RFC 5660 or something like it had been widely
> implemented earlier (earlier even than it was written).  The relevant
> idea was invented in the 90s, even, the Solaris/Illumos IP_SEC_OPT
> socket option (invented by Dan McDonald, I believe).
Yeah, I certainly was a fan of the idea of transport mode ESP. But it 
lost and that is that... until suddenly... though i would be being 
overly dramatic to say this was some sort of killer problem.
> So, I wouldn't say that IPsec being needlessly difficult to use is a
> feature.  No, it's a bug.  TLS offload is necessarily harder to
> implement than ESP offload, so we've missed a valuable opportunity to
> increase the performance of network security, thus hindered its
> adoption.
> I would call that a small disaster, honestly.  Not a feature.  A bug.

But bugs can be fixed. And especially if enough love is thrown at them.

So the long and short of this entire issue seems to be is, is the 
uncaught error rate serious enough that warrant rethinking weak 
transport and frankly L2 layer error detection? Crypto hashes certainly 
are a gigantic cannon to make that problem go away if used correctly. 
considering they are becoming almost table stakes for most IP traffic, 
killing two birds with one stone my not be so bad.