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, 08 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.
- The TCP and UDP checksum algorithm may soon need … Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Joe Touch
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Richard Barnes
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Brian E Carpenter
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Richard Barnes
- Re: The TCP and UDP checksum algorithm may soon n… Richard Barnes
- Re: The TCP and UDP checksum algorithm may soon n… Christian Huitema
- Re: The TCP and UDP checksum algorithm may soon n… Christian Huitema
- Re: The TCP and UDP checksum algorithm may soon n… Phillip Hallam-Baker
- Re: The TCP and UDP checksum algorithm may soon n… Joseph Touch
- Re: The TCP and UDP checksum algorithm may soon n… Stewart Bryant
- Re: The TCP and UDP checksum algorithm may soon n… Phillip Hallam-Baker
- Re: The TCP and UDP checksum algorithm may soon n… Joseph Touch
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Michael Richardson
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Masataka Ohta
- Re: The TCP and UDP checksum algorithm may soon n… John Levine
- Re: The TCP and UDP checksum algorithm may soon n… Phillip Hallam-Baker
- Re: The TCP and UDP checksum algorithm may soon n… Joseph Touch
- Re: The TCP and UDP checksum algorithm may soon n… Christian Huitema
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Joseph Touch
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Salz, Rich
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Salz, Rich
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Michael Richardson
- Re: The TCP and UDP checksum algorithm may soon n… Benjamin Kaduk
- Re: The TCP and UDP checksum algorithm may soon n… Nick Hilliard
- Re: The TCP and UDP checksum algorithm may soon n… Carsten Bormann
- Re: The TCP and UDP checksum algorithm may soon n… Nick Hilliard
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Joe Touch
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Nick Hilliard
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Nick Hilliard
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Carsten Bormann
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… John C Klensin
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Richard Barnes
- Re: The TCP and UDP checksum algorithm may soon n… Russ Housley
- Re: The TCP and UDP checksum algorithm may soon n… Brian E Carpenter
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Warren Kumari
- Re: The TCP and UDP checksum algorithm may soon n… John C Klensin
- Re: The TCP and UDP checksum algorithm may soon n… Christian Huitema
- Re: The TCP and UDP checksum algorithm may soon n… John C Klensin
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Eric Rescorla
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… John Levine
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Brian E Carpenter
- Re: The TCP and UDP checksum algorithm may soon n… Warren Kumari
- Re: The TCP and UDP checksum algorithm may soon n… John R Levine
- Re: The TCP and UDP checksum algorithm may soon n… tom petch
- Re: The TCP and UDP checksum algorithm may soon n… Salz, Rich
- Re: The TCP and UDP checksum algorithm may soon n… Carsten Bormann
- Re: The TCP and UDP checksum algorithm may soon n… Salz, Rich
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas