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
- [IPsec] Preliminary minutes for the IPsecME meeti… Tero Kivinen
- Re: [IPsec] Preliminary minutes for the IPsecME m… mohamed.boucadair
- Re: [IPsec] Preliminary minutes for the IPsecME m… Tobias Heider
- Re: [IPsec] Preliminary minutes for the IPsecME m… Valery Smyslov
- Re: [IPsec] Preliminary minutes for the IPsecME m… mohamed.boucadair
- Re: [IPsec] Preliminary minutes for the IPsecME m… Paul Wouters
- Re: [IPsec] Preliminary minutes for the IPsecME m… Valery Smyslov
- Re: [IPsec] Preliminary minutes for the IPsecME m… Tobias Heider
- Re: [IPsec] Preliminary minutes for the IPsecME m… Paul Wouters
- Re: [IPsec] Preliminary minutes for the IPsecME m… Valery Smyslov
- Re: [IPsec] Preliminary minutes for the IPsecME m… Valery Smyslov
- Re: [IPsec] Preliminary minutes for the IPsecME m… Paul Wouters
- Re: [IPsec] Preliminary minutes for the IPsecME m… Valery Smyslov