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

Michael Thomas <> Tue, 09 June 2020 23:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F3E03A0C6F for <>; Tue, 9 Jun 2020 16:32:43 -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 G10YhSZtRBcu for <>; Tue, 9 Jun 2020 16:32:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E7713A0C61 for <>; Tue, 9 Jun 2020 16:32:41 -0700 (PDT)
Received: by with SMTP id k2so67406pjs.2 for <>; Tue, 09 Jun 2020 16:32:41 -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=pPEGLTnOg+FxPxHU7oZG+z6PwCVNegu6G2RqGho9Fp8=; b=vWtLc0wwWNYoCusGVohX+GbKi6k08mLiZmgIy0eY6MbD4f4ZEuE7Ee27humpqv+q4N cFMQCpuUTMfron5JNAOmXhTUaOYK9wDd3EffnO8QwStJIbLDDyYRjuHwLeX+0P72oNsJ D2KC9AJcWa1hPUzn4sGYg/vXMehus5etnD0Zquj3olyU/Kij+aGotCoPDF4/noRH84Pi NzDDLDisHTRuVQx1stBM1Ing12NHTIh0nXyLUAIGEYrdHaAoUs+nTciXKWeUGk3698j8 PZclBktjGMXpF8h/ujimkBqE6EwcP/NqWkdcQq1ny1Jgou5RYArmwUEbiN6bLt0bxFGV NTVA==
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=pPEGLTnOg+FxPxHU7oZG+z6PwCVNegu6G2RqGho9Fp8=; b=k7lWXMbzhMTkK+nP19IzYINJq+mlz0TEItjbBUZUTLClFHpH4OaFabkBflAzkxSBi/ 3+OOajnNFn4OX31v3nTpm433mD0L+1bdurOKU3lX9vREXwAPrl7kiI4u5/aR2rnXPl/9 09QkHhiiVIfNlcTtGrKXGJViPCq7Qx0YFUmE6Iq0g9sHRZO7zWKQcfJmJ7mrRs/MvBss n3Nor21yISvC+nhABaHOQdJQ3X1PGgnEz0d/ZA7e/Byd+gZB+nbo1/IWQVli6fJO6WaS hGFC6fnho6rtSmeKGcFOe9+YfZ1ll6x398p5hYCUcuE/PF7u54Y2zeZ7x+vre9FHKdKO EXFQ==
X-Gm-Message-State: AOAM532U/bLuc3gzG0PjMaaCDX8eG8O2qkCbJP18c4fgh8ZaYe3VrSlw cppwKgu5KPbFStSvR34hXRiTcuwWt4Y=
X-Google-Smtp-Source: ABdhPJxj1pxo+YY/LDuMQE+tOzGYQjd83euWUrue65mxW2ZG6zlFWXpazIWJ0RiSgjcoWKHaVcsbgg==
X-Received: by 2002:a17:90b:705:: with SMTP id s5mr175285pjz.147.1591745560525; Tue, 09 Jun 2020 16:32:40 -0700 (PDT)
Received: from MichaelsMacBook.lan ( []) by with ESMTPSA id 63sm10877129pfd.65.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jun 2020 16:32:39 -0700 (PDT)
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Nico Williams <>
Cc: Nick Hilliard <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <20200608190220.GA18021@localhost>
From: Michael Thomas <>
Message-ID: <>
Date: Tue, 9 Jun 2020 16:32:38 -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: <20200608190220.GA18021@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: Tue, 09 Jun 2020 23:32:43 -0000

On 6/8/20 12:02 PM, Nico Williams wrote:
> On Mon, Jun 08, 2020 at 11:23:09AM -0700, Michael Thomas wrote:
>> ssl had the advantage that it 1) beat ipsec to market, and 2) wasn't subject
>> to API differences from OS layer calls like IPsec was, and with quite a bit
>> of churn as i recall too. it's really too bad, imo. we wouldn't have had to
>> do the contortions of dtls, for example. and now there's this problem. none
>> of them are earth shattering, but it would have been cleaner.
> You can sprinkle TLS anywhere you have an octet stream.  You can
> sprinkle DTLS anywhere you have datagram flows.  No need for OS support
> -- it will just work.  IPsec?  IPsec requires OS support.

Yes, but that's also the reason a long on the tooth transport checksum 
becomes a concern. any cryptographic hash is good enough to detect errors.

> 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.

> As you can see, a dozen years ago was already too late, but our idea
> then was to
>   - construct protection guarantees for packet flows using IPsec,
>   - to use anonymous or anonymous-like key exchanges to key IPsec,
>   - and to use channel binding from application layer protocols that can
>     authenticate more useful names than IP addresses.
Had SSL/TLS not come along first, there would been immense pressure to 
make this all work.
> Nico
> [*] In the IPsec architecture, RFC 4301, there is no guarantee that the
>      packets making up a TCP connection, say, will have anything like
>      similar protection for the lifetime of the TCP connection.
>      Everything about how a TCP conenction is protected by IPsec depends
>      entirely on *configuration* with no standard interfaces _at all_ for
>      applications to manipulate said configuration.
> [**] Yes, in RFC 4301 you're supposed to specify things like trust
>       anchors and policies like "any peer with a certificate from this CA
>       can _claim_ IP addresses in the following prefixes/ranges".  This
>       _cannot_ scale to Internet scale.

These are OS implementation details, right? There is nothing inherently 
impossible about filtering on 4-tuples where the app supplies the root 
CA it likes to IKE, right? I mean, that's what TLS is doing, but it's 
just doing it implicitly from the OS layer filtering.