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

Benjamin Kaduk <kaduk@mit.edu> Mon, 08 June 2020 02:46 UTC

Return-Path: <kaduk@mit.edu>
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 BFC993A0965; Sun, 7 Jun 2020 19:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbQXMVyjcVYP; Sun, 7 Jun 2020 19:46:54 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335F53A0964; Sun, 7 Jun 2020 19:46:53 -0700 (PDT)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0582kmoN022425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 7 Jun 2020 22:46:51 -0400
Date: Sun, 07 Jun 2020 19:46:47 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Cc: Michael Thomas <mike@mtcc.com>, Joseph Touch <touch@strayalpha.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
Message-ID: <20200608024647.GU58497@mit.edu>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <D55AFBFD-0D59-4176-B6BD-D6A1801FEC2C@akamai.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NwqTUhbQ2PC9UT5Kmw0KHWL66xk>
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 02:46:56 -0000

On Sun, Jun 07, 2020 at 11:52:36PM +0000, Salz, Rich wrote:
> >    Because the TCP headers aren't part of the hmac digest? Am I missing 
>     something?
> 
> And how does that affect the application data?  What corruption of TCP headers would not end up being noticed at the application layer and therefore TLS?

A sometimes significant issue is that if TLS is the thing that notices the
corruption, the stream shuts down and any recovery steps need to be done by
the application.  Some applications don't do this well, so their
application data can be badly affected.  But in general a well-designed
application protocol should have a way to recover fairly gracefully, as has
been noted a few times upthread.

-Ben