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

Richard Barnes <rlb@ipv.sx> Thu, 04 June 2020 21:19 UTC

Return-Path: <rlb@ipv.sx>
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 75CA03A0F89 for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2020 14:19:06 -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=ipv-sx.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 uG0zuMqaaTqq for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2020 14:19:05 -0700 (PDT)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 C8B923A0F86 for <ietf@ietf.org>; Thu, 4 Jun 2020 14:19:04 -0700 (PDT)
Received: by mail-qv1-xf36.google.com with SMTP id f89so3704179qva.3 for <ietf@ietf.org>; Thu, 04 Jun 2020 14:19:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VZKOA1ghU7UWRBm1iOvpDDEwCQkgjNVuWPyrWYxX3TA=; b=u46jdqLm9PcOZuOIFXQ50WJ/Jba9S7aWWFuqLdpjiPIlOPyRnE0dDtjRasFgk5hPl4 gS1aE79b/ftUzAOxHo5pSg60yxgg26/68uU+sGK6jiLaNZ/03E6r9Tgrv7KqI11abPoB gQf+oJyTSucO5burUB94Krt4pmFtVr8AobIoE6aoZ2kP5i1AlJvg31VU0u1PsdvnIoy/ 5SYDpqx3OH8q+p9AnDmjd2nbxwSE5dKXclsxo7+wsvCCTVd7+Zfk8xRkMVKUFq+QYBAi yGCXqRBWy9mTAtBBvAKToj6AEXpyoerrVuRwA2tjWBdZ52GSAHo59HiTNdt/Fq0NJKvF tkjg==
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=VZKOA1ghU7UWRBm1iOvpDDEwCQkgjNVuWPyrWYxX3TA=; b=EHHsd4G5ZB+pVxzGobTvsSE+kSKbU6YUbr3RlnTXItphp/5Yqk0ys05kaEaO8sELvY 2vNaA3BN8rCfSMWqF2G34xKPZaASykR/n9CMqxUaG9z3ztEqAUAwL+ZNaJGVQa0g4GQ3 Ld3odKzkReDbOyIYVILSOFHKRtnS0GK7i9VLj2GJdzKv7IgRfQn4VfDkFfdVogECvAJ1 9E4xjweldeE5S5IouI3YUs3HW5AhynMJuj840sKAd3Ov11UZQGhXbuN/MF3IcfMBIXQw IWCoYTHapxbVBEGGf3F1P6HUdIM+dqv0jW1OhyzIBZIyLzQTlgFRQVgJaLEi+a0coACg GpQw==
X-Gm-Message-State: AOAM532+Zuk6VtKAdi674N0C0Oi2tQIF0+gjj+XAYJql20rF25Lgz8Xj 1wTSEMPi3eeq09vpCcl3JzQsnSd1PQzTFZlL14qG0g==
X-Google-Smtp-Source: ABdhPJxQMoj5uFct2TLgOeQylzvzo7svMh2YdX/CyZYdAbkPcv0SletO6Tb25OiOS264h8ec/xeoibZvPh6vRGAkOzg=
X-Received: by 2002:ad4:4732:: with SMTP id l18mr6903351qvz.43.1591305543494; Thu, 04 Jun 2020 14:19:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAHQj4Cf_vgXYEL=x4DCEnpwNxZpJQSD-h6MWmhMWpYwPF9XFow@mail.gmail.com> <E23EC459-213F-4D19-BC1B-6050EC2CB653@strayalpha.com> <CAHQj4CcOpciujCP9ugegjEjzyT7Oqzv_WtjWyTAGacUxkG9YYg@mail.gmail.com>
In-Reply-To: <CAHQj4CcOpciujCP9ugegjEjzyT7Oqzv_WtjWyTAGacUxkG9YYg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 4 Jun 2020 17:18:52 -0400
Message-ID: <CAL02cgRjMQtcYDF04-3FsN1WOg_7H1fpR2_qPUwa-BegkQqp8A@mail.gmail.com>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Craig Partridge <craig@tereschau.net>
Cc: Joe Touch <touch@strayalpha.com>, IETF discussion list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a64b2105a748b166"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/bUzRBW5rHiQS5LLEHU4lJBNXd2o>
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: Thu, 04 Jun 2020 21:19:07 -0000

Yeah, secure transports already consider the data from the network
untrusted, including TLS and DTLS, but also IPsec/ESP, SSH, SRTP and QUIC.
As long as those protocols are using reasonably modern, AEAD ciphers, the
worst impact of corruption in the transport is DoS.

That said, there might be some pretty hard crashes in cases where the
security protocol relies on the transport for something.  For example, TLS
doesn't have a mechanism for requesting that data be re-sent in the event
of loss/corruption, because it's assumed that TCP provides that.  If
corruption is only detected at the TLS layer, there's not a way to
recover.  That said, I wouldn't be surprised if many TLS stacks close the
connection on bad data anyway.

On the UDP side, there should be no issue.  Anything above UDP has to
tolerate loss anyway, so there should be mechanisms that will require from
corruption-treated-as-loss.

So there may be some feedback loops to close, but that's a more limited,
host-internal problem.

In any case -- one more reason to encrypt everything!

--Richard

On Thu, Jun 4, 2020 at 4:17 PM Craig Partridge <craig@tereschau.net> wrote:

> Ah, I somehow had missed that.
>
> Looks like it does the trick if we need it. Not sure if we'd have to
> update the optional checksum to use a new checksum too.
>
> Craig
>
> On Thu, Jun 4, 2020 at 1:33 PM Joe Touch <touch@strayalpha.com
> <touch@strayalpha..com>> wrote:
>
>> See draft-ietf-tsvwg-udp-options
>>
>> > On Jun 4, 2020, at 12:13 PM, Craig Partridge <craig@tereschau.net>
>> wrote:
>> >
>> > Then there's UDP.  UDP has no options.
>>
>
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
>