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

Eric Rescorla <ekr@rtfm.com> Tue, 09 June 2020 19:48 UTC

Return-Path: <ekr@rtfm.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 DE26E3A0D52 for <ietf@ietfa.amsl.com>; Tue, 9 Jun 2020 12:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 4Hbu3R74drJD for <ietf@ietfa.amsl.com>; Tue, 9 Jun 2020 12:48:41 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 04D933A0D4F for <ietf@ietf.org>; Tue, 9 Jun 2020 12:48:41 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id x18so10142333lji.1 for <ietf@ietf.org>; Tue, 09 Jun 2020 12:48:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AsHpfUTbijuQpCprI6kuIhHIllVFQyVux8UPiFWnwmU=; b=iJK8bpmBZE4xco3dvvAyS5M0Lhe07vykx0ENztPoUc7Jr6ycl9tRpA/fNC15R8rMit bIYsly5qJdbVNaH/1mOLz6AII5EtqF1f7Aiyb0TUdoZPm0rqZXdZgZC/KkqJtQb0yJpK e0z8uX5p2D3298IC5lClO7KXU8wif6D1P7MCy4uV4k1UPpj6SNwOIqpXmFINHLNkoJqO zpR/hdgvn99gTm4ys8Ib8xZb+wif0cOUoZCFt4kVyKwtsO/sK5arm0l3Vvao0Ua5dbMA jB5baVmV9xwvlUsM6R38a5uidZWSDs76Uv6upijazryeAOfWa1I1SLsTIX4lTIewU9Pu vHaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AsHpfUTbijuQpCprI6kuIhHIllVFQyVux8UPiFWnwmU=; b=O/9B0+9zNxyTsCxEeSz3y1qzVVmf/cfSbXba75VSLcKzgiDUDUMkcKVfIK2uHj+xlD w6KI94+edBiShsNKBnMb6GKheK6/wrKKuFNB9k/UUK+1ErqOehOt9+Em3SN8JA0LJCe6 bIJd4mkpxicpnf3HjNUGhaxnBTg5C+HvautjKoyPrWMSnVOKnN/sWN2fZ/zYqtjcQKav WF2CdMlmjpWItAQxMwLktdbrJIwmoqvqwB1mH35QruTaeyIh5NyE3gvFiEpsp4VberG1 ifTL6cYJ+i9shJACWZBfk4f2mbrKLkURblRj4CHnUIuGI0VKtdNbMHjotL7FGB9zhtdA nT+g==
X-Gm-Message-State: AOAM531wdohqsCHHEcRTgHFN0dKY3DNBt/7VS/BnF9JHLMWrI2CP7nGM buUnnE9+aB0UeO+FQEyBxKOlXq3mnKsmA3uFmhOI5w==
X-Google-Smtp-Source: ABdhPJwz2B32qvBneihFL5ceN5xUR+GusWAkEY2ahPZ95vrc6ZvoqPSQ0JOXeUoOYEgZb50u5atGo7UL873tM5Lj4Es=
X-Received: by 2002:a05:651c:299:: with SMTP id b25mr11166577ljo.13.1591732119075; Tue, 09 Jun 2020 12:48:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAHQj4CcRanB9c6_cEVcLgUNJBFMqXb_aH6eBBSaR0-_rQO5i9Q@mail.gmail.com>
In-Reply-To: <CAHQj4CcRanB9c6_cEVcLgUNJBFMqXb_aH6eBBSaR0-_rQO5i9Q@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 09 Jun 2020 12:48:03 -0700
Message-ID: <CABcZeBPNqmX0bdragemR3WsbyjWmFa0MVMH-NdPC0ozRFqAY8Q@mail.gmail.com>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Craig Partridge <craig@tereschau.net>
Cc: IETF discussion list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000890eb405a7ac035e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/nZZohLqMN9Et1SI9_BeKVGpvJnM>
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: Tue, 09 Jun 2020 19:48:43 -0000

On Tue, Jun 9, 2020 at 12:32 PM Craig Partridge <craig@tereschau.net> wrote:

> Following up on notes from various folks, most notably John K. and
> Christian H., about checksums and encryption-based integrity protection, I
> wanted to make a couple of clarifying points.
>
> * If you are not worried about an adversary who seeks to alter your data
> in transit, then integrity protection is a lousy method for ensuring the
> received data is correct.
>

I agree with this statement.

However, with that said, we *should* generally be worried about such an
adversary and so in general our protocols should have integrity protection
at some layer in the stack, and while inefficient, the adversarial
requirements also mean that the chance of detecting non-adversarial error
is also very high. As you note in your original email, the issue arises
when integrity check failures occur at a layer which cannot recover from
them (as has been noted, TLS over TCP but not QUIC). Faced with this, we
can do one of three things:

- Create higher layer recovery mechanisms which can recover from lower
layer failures (as Richard alluded to with TCP)
- Move to protocols which can recover from errors (e.g., QUIC)
- Improve the non-adversarial checksum (in this case the TCP checksum) so
that the chance of undetected non-adversarial error is very low (the topic
that kicked off this thread).

It's worth noting that the first two are already happening and will most
likely continue regardless of what happens at the lower layers (in part
because they need to take the lower layers as they are now).

-Ekr