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

Richard Barnes <rlb@ipv.sx> Thu, 04 June 2020 21:45 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 E3BE53A0F9B for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2020 14:45:39 -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 NnIb3Ky2qIQ8 for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2020 14:45:37 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 B6C173A0F97 for <ietf@ietf.org>; Thu, 4 Jun 2020 14:45:37 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id 205so7821673qkg.3 for <ietf@ietf.org>; Thu, 04 Jun 2020 14:45:37 -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=DaNZr2lZ4TZ7xwNsBfHKxR0R3HhfcN4a3P6Q+bNOKoo=; b=Ham2Km6b1g+cK5ZbG3BcoGGwrpu6GUliQS2mNLp7HCwWsUYPT/dk0XoKnjSLKjgu5+ u1fbEXaq6noAuSw79OmAOhvgim8uwSdj8ohMxcz1Sj7QTpkOk3cdTeDJMVcm8/x+8S0D Y9g6kYd72V2P00g8lp68IJfxQiY1yCelXkbOR8QWnESYCOCWrx1p5W+D9UEMEFp/uWgV ozv6kFehMaIk/bw2aSyTLrcKRg3hFCGywk9EBCes5TqgoskueMtkENcRktVih/ortU48 z/K2Cmu/PEXqHH5HWpey0BOl43rI4YYrie6TE7Cw1Qf2CyE5+uO8kmZuImuCR3Y+5LYZ flpg==
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=DaNZr2lZ4TZ7xwNsBfHKxR0R3HhfcN4a3P6Q+bNOKoo=; b=gpKqylFWCmQjnZt5NjkPwjhN/YapZshAdklIx9Di4UneRZ9Jrnxwn0f+/G+Y+wAQ8S zKRavIgR63JlvmFQQaMPnbfT6wazZLyh13BeXXjf8A+VmDOHRGBmdEEgwLwbs3AQXbo6 crgmeD43QRFiueiSM2Zfv8k9kteTSSiCcvtRQAr+g9wcL97bFt39251F4lfMWAD4NcmV q2TCdio2d/4VQ39WZW77CZFIvCeKXPjnMwk6UOPGFVEM4S/h4lq9d7LrqK769PT2x91e fULzQR2KQ0DKxqKrIOzvMim+0SEuye1VmybmU76ay2kpjftZ+DC7MseyXVL1Z4hnHP10 r+kA==
X-Gm-Message-State: AOAM5331vE8xVLQHkFJKm1h/EPBGQJzZphBtbbGFegd2s8PIvoS1LZDj /YfEGaB25eJr41lJnynzFmPmuyMwKu32z4IHCBS669KMNp0=
X-Google-Smtp-Source: ABdhPJzYT4JcwORF/hp1ltn6r/54YaJmWcTnSpHDlVEL2MDHkCEf1tQdQe7TCJJ1OPX8pnXGi9BmP1BG7M8nMIB9Ui8=
X-Received: by 2002:a37:79c6:: with SMTP id u189mr6942194qkc.490.1591307136775; Thu, 04 Jun 2020 14:45:36 -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> <CAL02cgRjMQtcYDF04-3FsN1WOg_7H1fpR2_qPUwa-BegkQqp8A@mail.gmail.com> <CAHQj4Cem6YdTXKFPW6Mk6gK9Yt_2qD=M7PAE6nxFEdJrD==ZVA@mail.gmail.com>
In-Reply-To: <CAHQj4Cem6YdTXKFPW6Mk6gK9Yt_2qD=M7PAE6nxFEdJrD==ZVA@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 04 Jun 2020 17:45:25 -0400
Message-ID: <CAL02cgS4ZAks-eXc78r7zq6SnCUZ5Jvush_bVbtL-M-z-7EaEg@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="0000000000009dcd7f05a74910ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/8Md-G-ikRt1s37-ZTGcmn9tCQ9E>
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:45:40 -0000

It seems like you're assuming that file transfer applications are sending a
large file all in one go, over a single TCP session.  All of the serious
file transfer applications that come to my mind protect against this by
handling large things in more manageable chunks -- think BitTorrent,
MPEG-DASH, even HTTP range requests.  That's prudent application design not
just because TCP passes corrupted data sometimes, but because transport
connections fail for all sorts of reasons.

--Richard

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

> The SSH spec says terminate on failure and that it requires a reliable
> underpinning.
>
> Termination on error is no good.  One of the studies shows huge failure
> rates (over 50%) for large file transfers.  One guess is that's due to
> security protocols terminating when TCP hands up something with an error.
>
> Craig
>
> On Thu, Jun 4, 2020 at 3:19 PM Richard Barnes <rlb@ipv.sx> wrote:
>
>> 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.
>>>
>>
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
>