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

Nico Williams <nico@cryptonector.com> Mon, 08 June 2020 19:03 UTC

Return-Path: <nico@cryptonector.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 7477C3A122F for <ietf@ietfa.amsl.com>; Mon, 8 Jun 2020 12:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 wWrQ2NXf-Vx7 for <ietf@ietfa.amsl.com>; Mon, 8 Jun 2020 12:03:15 -0700 (PDT)
Received: from cadetblue.birch.relay.mailchannels.net (cadetblue.birch.relay.mailchannels.net [23.83.209.28]) (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 D99583A10F0 for <ietf@ietf.org>; Mon, 8 Jun 2020 12:02:31 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4A0D8121F60; Mon, 8 Jun 2020 19:02:30 +0000 (UTC)
Received: from pdx1-sub0-mail-a99.g.dreamhost.com (100-96-23-33.trex.outbound.svc.cluster.local [100.96.23.33]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6B910121DFC; Mon, 8 Jun 2020 19:02:29 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a99.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Mon, 08 Jun 2020 19:02:30 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Whimsical-Cooperative: 3b70d64a2a44befc_1591642949735_1654732574
X-MC-Loop-Signature: 1591642949735:4006088354
X-MC-Ingress-Time: 1591642949734
Received: from pdx1-sub0-mail-a99.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a99.g.dreamhost.com (Postfix) with ESMTP id 1FCDF7F0E2; Mon, 8 Jun 2020 12:02:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=uqPPd9bTC1GRzZ TPheGW/kHXjLw=; b=X2MBW9XS9GK/aSicKvWBLF17g12Envz0crPwfz1Hp7nIn7 c+vu8FY8iyPtRp5HTvsRiwjyLeJyJJ3i5JGhgqQxj83K8dNwdxSgCKqhqR0bevGq WnwOCHSM+Z+nMh3P7E1OAY6f9oy4bv/7nE9c8Q/s7+1jRMDsUCwX23xE4iP50=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a99.g.dreamhost.com (Postfix) with ESMTPSA id C0B657F0EA; Mon, 8 Jun 2020 12:02:25 -0700 (PDT)
Date: Mon, 8 Jun 2020 14:02:21 -0500
X-DH-BACKEND: pdx1-sub0-mail-a99
From: Nico Williams <nico@cryptonector.com>
To: Michael Thomas <mike@mtcc.com>
Cc: Nick Hilliard <nick@foobar.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
Message-ID: <20200608190220.GA18021@localhost>
References: <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> <8946c5bf-0f6b-7a52-6326-dda59a78a798@mtcc.com> <995f5e46-b79a-ec9a-5465-9ec5abcdb759@foobar.org> <9d18c630-8506-9097-fc8c-86d6264afcbe@mtcc.com> <1783a7fa-fed4-2973-05dd-236f1120a74c@foobar.org> <5bf95457-5d44-86fa-5062-800680cc5a6a@mtcc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5bf95457-5d44-86fa-5062-800680cc5a6a@mtcc.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudehvddgjedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/0rMIF84gk9zzzJrpqR0mjsG8rGc>
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 19:03:24 -0000

On Mon, Jun 08, 2020 at 11:23:09AM -0700, Michael Thomas wrote:
> ssl had the advantage that it 1) beat ipsec to market, and 2) wasn't subject
> to API differences from OS layer calls like IPsec was, and with quite a bit
> of churn as i recall too. it's really too bad, imo. we wouldn't have had to
> do the contortions of dtls, for example. and now there's this problem. none
> of them are earth shattering, but it would have been cleaner.

You can sprinkle TLS anywhere you have an octet stream.  You can
sprinkle DTLS anywhere you have datagram flows.  No need for OS support
-- it will just work.  IPsec?  IPsec requires OS support.

Also, IPsec got a lot of things wrong.  It's simply not usable at
Internet scale as originally intended because... it's IP-layer, so it
deals in discrete packets and IP addresses.  Well, discrete packets do
not define application connections/sessions[*], IP addresses are too
dynamic and useless for authentication and authorization[**], and
configuration is ETOOHARD.

As you can see, a dozen years ago was already too late, but our idea
then was to

 - construct protection guarantees for packet flows using IPsec,
 - to use anonymous or anonymous-like key exchanges to key IPsec,
 - and to use channel binding from application layer protocols that can
   authenticate more useful names than IP addresses.

Nico


[*] In the IPsec architecture, RFC 4301, there is no guarantee that the
    packets making up a TCP connection, say, will have anything like
    similar protection for the lifetime of the TCP connection.
    Everything about how a TCP conenction is protected by IPsec depends
    entirely on *configuration* with no standard interfaces _at all_ for
    applications to manipulate said configuration.

[**] Yes, in RFC 4301 you're supposed to specify things like trust
     anchors and policies like "any peer with a certificate from this CA
     can _claim_ IP addresses in the following prefixes/ranges".  This
     _cannot_ scale to Internet scale.

     Giving up on authentication and authorization in the RFC 4301
     scheme (BTNS, RFC 5387) and constructing logical packet flows with
     consistent protection during their lifetimes (RFC 5660), fixes the
     problem.  It didn't get implemented -- even if it had been, TLS was
     already king.  This would all have to have happened at least half a
     decade earlier, if not a whole decade earlier, to have had a
     chance.

     What was particularly appealing at one point was the possibility of
     having ESP offload in NIC HW.  The lower in the stack the crypto
     happens, the easier it is to offload it.