Re: [IPsec] Preliminary minutes for the IPsecME meeting

Paul Wouters <paul@nohats.ca> Mon, 01 April 2019 12:07 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9512010C for <ipsec@ietfa.amsl.com>; Mon, 1 Apr 2019 05:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 WASkXfa7oM6r for <ipsec@ietfa.amsl.com>; Mon, 1 Apr 2019 05:07:32 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 C80A6120100 for <ipsec@ietf.org>; Mon, 1 Apr 2019 05:07:31 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44Xrgj5tYhz7Yn for <ipsec@ietf.org>; Mon, 1 Apr 2019 14:07:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1554120449; bh=ImcZsMhq/DlbowDJaSXpz9pZczzRZ1PdTt10QWvKPXw=; h=Date:From:To:Subject:In-Reply-To:References; b=fTGitVPwuwcw2ZC6W73COnparc4vt2LfD9WO2A78z8JxcAeKJG6osQqfESN95AfCI Wc/bRsJRWAEGSh5oCUTmhE52ElbHZCGsKXlGLqqZPJY2s3VKwH7E4PlyBED4U0JU/q mUlWDC1x72dtDM8MwKJoZ/nf+RG1zAenYh9SKXHU=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 40TFgo4Om5Ck for <ipsec@ietf.org>; Mon, 1 Apr 2019 14:07:28 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <ipsec@ietf.org>; Mon, 1 Apr 2019 14:07:27 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id CCBFC94F; Mon, 1 Apr 2019 08:07:26 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca CCBFC94F
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C902540D358A for <ipsec@ietf.org>; Mon, 1 Apr 2019 08:07:26 -0400 (EDT)
Date: Mon, 01 Apr 2019 08:07:26 -0400
From: Paul Wouters <paul@nohats.ca>
To: "ipsec@ietf.org WG" <ipsec@ietf.org>
In-Reply-To: <0a5901d4e882$c42fda90$4c8f8fb0$@gmail.com>
Message-ID: <alpine.LRH.2.21.1904010804370.25834@bofh.nohats.ca>
References: <23708.62392.134470.902330@fireball.acr.fi> <0d678659-9be6-fe1f-600a-e9fa79f4db3c@nm.ifi.lmu.de> <alpine.LRH.2.21.1904010629020.25834@bofh.nohats.ca> <c61f8233-6c25-44ff-e537-28fa35e9c816@nm.ifi.lmu.de> <alpine.LRH.2.21.1904010743160.25834@bofh.nohats.ca> <0a5901d4e882$c42fda90$4c8f8fb0$@gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/1sGutOk-zkvCDEWoPWT8hPECAY8>
Subject: Re: [IPsec] Preliminary minutes for the IPsecME meeting
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2019 12:07:33 -0000

On Mon, 1 Apr 2019, Valery Smyslov wrote:

> The RFCs are always being published in serial :-)

We have clusters :)

> So, my idea that every new application RFC must define its relative
> order in regard to all already published application RFCs
> and whether piggybacking with each of them is allowed.

Joking aside, I do feel it is important that the intermediate exchange
is a general concept, and should have the least amounts of hooks and
order of payloads or what not. I do not think it is a good idea to
insist on building a linked list of RFCs/payloads. The generic model of
IKE is payloads can be in any order. And if a payload won't fit in the
first intermediary exchange, it should be able to send it in the next
one without knowing anything about the other things going on.

Of course, there are exceptions, such as if we need QSKE before our new
imaginary payloads, but than those payloads might belong better in
IKE_AUTH.

Paul