Re: [IPsec] Preliminary minutes for the IPsecME meeting

Tobias Heider <heidert@nm.ifi.lmu.de> Mon, 01 April 2019 11:42 UTC

Return-Path: <heidert@nm.ifi.lmu.de>
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 652431200F5 for <ipsec@ietfa.amsl.com>; Mon, 1 Apr 2019 04:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 U-zZzOg_IyLl for <ipsec@ietfa.amsl.com>; Mon, 1 Apr 2019 04:42:31 -0700 (PDT)
Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC6412002F for <ipsec@ietf.org>; Mon, 1 Apr 2019 04:42:31 -0700 (PDT)
Received: from [192.168.17.134] (unknown [83.135.23.200]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: heidert) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 60A18361F9D; Mon, 1 Apr 2019 13:42:29 +0200 (CEST)
To: Paul Wouters <paul@nohats.ca>
Cc: ipsec@ietf.org, Valery Smyslov <smyslov.ietf@gmail.com>
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>
From: Tobias Heider <heidert@nm.ifi.lmu.de>
Message-ID: <c61f8233-6c25-44ff-e537-28fa35e9c816@nm.ifi.lmu.de>
Date: Mon, 01 Apr 2019 13:42:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.21.1904010629020.25834@bofh.nohats.ca>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US-large
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/caKkz5ZoIrXDJ_3EwaD1ZkNjm20>
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 11:42:35 -0000

I don't think that would make a difference to how it is now.

The INTERMEDIATE draft explicitly allows to specify more than one
roundtrip, and leaves
the order of those exchanges to the documents introducing the new
roundtrips
(if I got Valery right the newer one is supposed to explicitly state how
it interacts with the older).

If I wrote a draft today that adds a single large Notify in an
INTERMEDIATE exchange,
it would not be obvious how it would interact with e.G. the hybrid KE
that adds up to 7
additional INTERMEDIATE roundtrips.
I would have to explicitly specify in my draft that this additional
Notify is always added to the first
INTERMEDIATE specified in the Hybrid KE, if I wanted it to be there.
Otherwise it could be added to any
of the INTERMEDIATES in that draft, or to a new INTERMEDIATE before all
hybrid KE ones, or to a new
INTERMEDIATE after the hybrid KEs...

If I have to specify how the new Notify interacts with any of the
previous INTERMEDIATES,
I don't think it is much more work to specify how it interacts with the
same if they have different names.
It would maybe even make it clearer to some point.

On 4/1/19 12:29 PM, Paul Wouters wrote:
> On Thu, 28 Mar 2019, Tobias Heider wrote:
>
>> On 3/28/19 5:18 PM, Tero Kivinen wrote:
>>> Tobias Heider: ??
>> The question I asked was:
>> The draft already says that INTERMEDIATE can not be used without another
>> document
>> that specifies what payloads are sent in INTERMEDIATE. Why can't that
>> additional
>> document also define it's own exchange ID for that instance of
>> INTERMEDIATE instead of using
>> the same ID for different things.
>
> Because that would not allow different things needing a round trip from
> re-using the same exchange, and lead to more latency/roundtrips ?
>
> Paul
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec