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

Michael Thomas <mike@mtcc.com> Mon, 08 June 2020 16:59 UTC

Return-Path: <mike@fresheez.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 4BBDD3A0D4D for <ietf@ietfa.amsl.com>; Mon, 8 Jun 2020 09:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtcc-com.20150623.gappssmtp.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 3BZTmS8aLvdq for <ietf@ietfa.amsl.com>; Mon, 8 Jun 2020 09:59:24 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657CB3A0D6D for <ietf@ietf.org>; Mon, 8 Jun 2020 09:59:23 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id n9so6903874plk.1 for <ietf@ietf.org>; Mon, 08 Jun 2020 09:59:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtcc-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=x1fg+RDPTjHL+O8ZJA3WGw7zUYJNjh6yJoQ92C865mI=; b=CTrnbSJl6ypSaovb+zcC18ks1A9m8KbRf919NJvPZxuoqcZq68Lra8ZdBzPjHZR9T1 LaAHLVgvql4ojRSW2hFylsA/pK68zSpbPv6/376vqL5rW0Nc78DjR1K3daOx2R/I0A0a E5fuG3PigGY8UDOEuouxIcTFImY7QwcLLwCrsXsQo0/gN0v9lfVFzM633tFaJJou7UqZ dMxt0SJK9IuWlKy56omwNPj+c0mTXRm9zOPqf/Fk48IYkWVMAABy1UY/PbQswNsDDAes 6gQydqIQxtRE+mvLyNaaZQ5mCUjqiHmMUwtdqm7yVj59gThL/ZaUMm3KknX74yx4j9pl GiWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=x1fg+RDPTjHL+O8ZJA3WGw7zUYJNjh6yJoQ92C865mI=; b=Sm5lliLr2sfUSUwRqZKhaESvYc1uwQKcNcp+75iHxuhzFSWNWfgho+hNez7PIw5465 mNKTDbjH/555gIPHBgG3CypE419cDAYH9pMahCqfTg+1OgWNNAUODL/OkqDKjU69M7ai Gg5j9I1DgAn27J5VhRIrvXFlX8UCddgHUIwsu4iAYgrxrGI+1EUtwMGs+gfzCxDZ747a PTEgh3KAKJyZhXwY1tzCaxotYGsmQk1ux1GH//2zgIrpXnaRX35Jjlq0ohtUA4FubgOG 8Oqgj1quVtFcTyOf0KEDTK0xtcAf6cORSOq+xBwFXbbds5FbLIqIx+3iSkuGd6Ssj9Y6 Vjkg==
X-Gm-Message-State: AOAM533A2eN0bAHlrmHIZOuxWzF357bQgXEwgHPbhagYMCBC+/Cm7/UO rkBwu+LSNN5qJ2ra/CMbH3pcrQC/mKo=
X-Google-Smtp-Source: ABdhPJxjUQ6pWOz6jZ/B4Eg1QGVExTNu1UV5SUAKA22DgcC/hPFewXmDZRnHp3oSHdPoUqc/QJiQUA==
X-Received: by 2002:a17:90a:aa8f:: with SMTP id l15mr245071pjq.211.1591635561642; Mon, 08 Jun 2020 09:59:21 -0700 (PDT)
Received: from MichaelsMacBook.lan (107-182-45-85.volcanocom.com. [107.182.45.85]) by smtp.gmail.com with ESMTPSA id j186sm7650963pfb.220.2020.06.08.09.59.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 09:59:20 -0700 (PDT)
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Nick Hilliard <nick@foobar.org>
Cc: "ietf@ietf.org" <ietf@ietf.org>
References: <28A2725D-00F8-4739-8A73-ED176F8EF561@strayalpha.com> <3AA98081-A70E-4076-8096-79FFAEE8A738@huitema.net> <830b91c4-0bb5-af5b-f7b8-c5edd43dc87e@mtcc.com> <4512C1BF-5722-479B-8506-24018610BEAD@strayalpha.com> <5b4ea5ea-e2d6-1a01-3676-dd2a72dbd2c1@mtcc.com> <2C425F1E-2E12-4E47-ACEC-AF4C4A93FA3E@akamai.com> <140429ad-af8b-e03f-a641-1e78b6056fa4@mtcc.com> <D55AFBFD-0D59-4176-B6BD-D6A1801FEC2C@akamai.com> <f42134de-3d0f-87e5-b13f-82afdb3689c9@mtcc.com> <96c65ca8-6ed5-2afa-a6d5-14905fc75ce8@foobar.org>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <8946c5bf-0f6b-7a52-6326-dda59a78a798@mtcc.com>
Date: Mon, 8 Jun 2020 09:59:19 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <96c65ca8-6ed5-2afa-a6d5-14905fc75ce8@foobar.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HgXTmkJVDDRHrak2wkzP-LIFQsE>
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: Mon, 08 Jun 2020 16:59:25 -0000

On 6/8/20 2:09 AM, Nick Hilliard wrote:
> 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.
why would you say that? what layer the crypto is performed seems sort of 
irrelevant: rsa, aes and sha don't care who calls them. i assume that 
you can hack ipsec to emulate clients not having certs. what's left?
>
> 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.
>
Quic seems to have done the opposite by moving it down. But do I trust 
higher levels to deal with congestion avoidance correctly? Not at all. 
That's a tragedy of the commons waiting to melt down.

Mike