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

Nico Williams <nico@cryptonector.com> Wed, 10 June 2020 00:12 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 9ABAE3A0CAF for <ietf@ietfa.amsl.com>; Tue, 9 Jun 2020 17:12:41 -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 naLsaprnio2A for <ietf@ietfa.amsl.com>; Tue, 9 Jun 2020 17:12:40 -0700 (PDT)
Received: from chocolate.birch.relay.mailchannels.net (chocolate.birch.relay.mailchannels.net [23.83.209.35]) (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 CC2363A0CA7 for <ietf@ietf.org>; Tue, 9 Jun 2020 17:12:39 -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 6AFAA10109D; Wed, 10 Jun 2020 00:12:38 +0000 (UTC)
Received: from pdx1-sub0-mail-a25.g.dreamhost.com (100-97-66-8.trex.outbound.svc.cluster.local [100.97.66.8]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 13377100901; Wed, 10 Jun 2020 00:12:34 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a25.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); Wed, 10 Jun 2020 00:12:38 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Battle-Invention: 7fd763e17e22d14f_1591747958200_2805992959
X-MC-Loop-Signature: 1591747958199:1776945347
X-MC-Ingress-Time: 1591747958199
Received: from pdx1-sub0-mail-a25.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a25.g.dreamhost.com (Postfix) with ESMTP id CC151ADECE; Tue, 9 Jun 2020 17:12:33 -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=MHVGrgIbsX8dIy irnPqYlM6M0Tk=; b=BgDWfKmJDM7tBOnO/E8XeD6VXqerj7gMtSVwUNBBlxPAP9 NDj0qS0VFKGKbMUcjGr7aW+1U83WCjuB28ktWtRUYC77KWSXxRvWUAPMtQeLkt+L SV44KP3u6BlPJjEAcC4Qsj4+BoA9ek4I91JhYLnLXr8L8xArgx1Kl/lYmniEQ=
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-a25.g.dreamhost.com (Postfix) with ESMTPSA id 7FCDAADEBC; Tue, 9 Jun 2020 17:12:31 -0700 (PDT)
Date: Tue, 9 Jun 2020 19:12:28 -0500
X-DH-BACKEND: pdx1-sub0-mail-a25
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: <20200610001225.GD3100@localhost>
References: <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> <20200608190220.GA18021@localhost> <6c9f5bd9-6e26-5d25-e66e-bec206473ff3@mtcc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6c9f5bd9-6e26-5d25-e66e-bec206473ff3@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: gggruggvucftvghtrhhoucdtuddrgeduhedrudehhedgfeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/MJqnJOrdxTSEuViRPPSaZdYbXNk>
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: Wed, 10 Jun 2020 00:12:42 -0000

On Tue, Jun 09, 2020 at 04:32:38PM -0700, Michael Thomas wrote:
> On 6/8/20 12:02 PM, Nico Williams wrote:
> > 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.
> 
> Yes, but that's a feature not a bug in this particular case. I really don't
> find it believable app developers would have had a hard time with making the
> OS calls needed anymore than making the calls that the TLS libraries
> require. And as always: when something is widely used, it gets care and
> feeding. So if ipsec is still clunky, and says it's because it's not being
> widely used, and the niche cases of vpn's can suck it up.

The IPsec model is busted even for VPNs.  To mitigate the issues that
arise in VPNs you really need to assign a unique internal address to
each user or accept that authorized users may mount certain attacks on
each other.

But there's nothing about ESP itself that relegates it to VPN usage
only!  Only the IPsec architecture (RFC 4301) causes that, not anything
about ESP.

ESP would have been _great_ for transport-mode IPsec and widespread
application use if RFC 5660 or something like it had been widely
implemented earlier (earlier even than it was written).  The relevant
idea was invented in the 90s, even, the Solaris/Illumos IP_SEC_OPT
socket option (invented by Dan McDonald, I believe).

So, I wouldn't say that IPsec being needlessly difficult to use is a
feature.  No, it's a bug.  TLS offload is necessarily harder to
implement than ESP offload, so we've missed a valuable opportunity to
increase the performance of network security, thus hindered its
adoption.

I would call that a small disaster, honestly.  Not a feature.  A bug.

> > 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.
>
> Had SSL/TLS not come along first, there would been immense pressure to make
> this all work.

That's likely true, but we can't really know.

> These are OS implementation details, right? There is nothing
> inherently impossible about filtering on 4-tuples where the app
> supplies the root CA it likes to IKE, right? I mean, that's what TLS
> is doing, but it's just doing it implicitly from the OS layer
> filtering.

RFC 5660 gives two implementation designs: tag packets as they move up
(or down) the stack with relevant metadata, or "edit" the RFC 4301 SPD
and PAD in very specific, simple, and narrow ways.  Both schemes allow
the host to guarantee continuity of protection to a logical packet flow
-- a "connection".

The primary scheme given (config "editing") is rather unintrusive,
requiring not changes to how packets move up and down the stack.  The
alternative scheme (packet tagging) is potentially very intrusive for
some operating systems, though it is the simpler scheme.

Nico
--