Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02
"Tobias Guggemos" <guggemos@nm.ifi.lmu.de> Fri, 22 March 2019 08:49 UTC
Return-Path: <guggemos@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 BF7CA130F32 for <ipsec@ietfa.amsl.com>; Fri, 22 Mar 2019 01:49:29 -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 FLCAUqcG05lR for <ipsec@ietfa.amsl.com>; Fri, 22 Mar 2019 01:49:27 -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 981321315F4 for <ipsec@ietf.org>; Fri, 22 Mar 2019 01:49:26 -0700 (PDT)
Received: from DESKTOP58DFL8T (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id A5A74368011; Fri, 22 Mar 2019 09:49:24 +0100 (CET)
From: Tobias Guggemos <guggemos@nm.ifi.lmu.de>
To: 'Valery Smyslov' <smyslov.ietf@gmail.com>, 'Paul Wouters' <paul@nohats.ca>, ipsec@ietf.org
References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <a1bc12d7-7c8c-cd12-f0fa-cb6bd9bb7265@cip.ifi.lmu.de> <077301d4dfbc$60031f10$20095d30$@gmail.com> <alpine.LRH.2.21.1903210506180.7783@bofh.nohats.ca> <079d01d4dfda$67159800$3540c800$@gmail.com>
In-Reply-To: <079d01d4dfda$67159800$3540c800$@gmail.com>
Date: Fri, 22 Mar 2019 09:49:23 +0100
MIME-Version: 1.0
Message-ID: <002401d4e08c$25d953b0$718bfb10$@nm.ifi.lmu.de>
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHU2U0s6M7rbXuBv0SBwRv3SEEfn6YKvxmAgACvtICABiKNQIABBzyAgABckXCAASJaAIAA10YAgADGmACAABOOgIAAKIGAgAFvdeA=
Content-Language: de
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="=-=xmfapt+igWS0/5=-="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Nul3ode3nXbF4HQDqxXll3Bj8ro>
Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02
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: Fri, 22 Mar 2019 08:49:42 -0000
Hey Paul and Valery, > Hi Paul, > > > > It's a good question. My idea is that each application document must > > > define this, as well as the order of INTERMEDIATE exchanges, if it > > > matters. So, I assume that by default each application will utilize > > > its own INTERMEDIATE , but some applications could benefit from > > > piggybacking. But this must be clearly described in corresponding > > > document. > > > > I would think it quite differently. Each protocol extension just puts > > payloads in the IKE_SA_INIT and once that one becomes too big, the IKE > > daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE. > > This document defines what goes into IKE_SA_INIT, so the rest (eg new > > stuff) ca ngo into IKE_INTERMEDIATE. > > From implementer's point of view it's better if the possible content > of each message be clearly defined. It simplifies parsing message and state > machine... > I think I go with Valery here. Otherwise it feels like fragmenting IKE_SA_INIT, which was (as far as I remember) not what the WG wanted and the main reason for the original IKE_AUX draft. On the other hand, I'd also prefer if not every application uses a new INTERMEDIATE message, but putting all information which can be transported within one INTERMEDIATE in one single message. I think IKE_INTERMEDIATE should be to define the message and the application should define the INTERMDIATE's payload. If any application needs several consecutive IKE_INTERMEDIATE's, it needs to be defined there, but the default case should be *one* INTERMEDIATE. But that might be a discussion for the application's drafts and not for IKE_INTERMEDIATE. > > > I think that corresponding application document must define this. > > > > I don't see why they would need to do that? For example, imagine I add > > a large notify payload that would cause IKE_SA_INIT fragmentation, the > > IKE daemon looks what payloads to put in IKE_SA_INIT and the > > non-listed Notify payload would be put into one or more > > IKE_INTERMEDIATE exchanges. > > I don't see any problem here. You can write an application document saying > that once INTERMEDIATE is negotiated (and some other thing happened, > indicating mutual support for the following), the peers may offload there > whatever they want (and makes sense) from IKE_SA_INIT. I just don't want > such things take place sporadically, by sole fact that INTERMEDIATE is > supported. Otherwise Tobias G.'s concerns are applied. > > Regards, > Valery. > > > Paul > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec
- [IPsec] WG adoptation call for draft-smyslov-ipse… Tero Kivinen
- Re: [IPsec] WG adoptation call for draft-smyslov-… Valery Smyslov
- Re: [IPsec] WG adoptation call for draft-smyslov-… Panos Kampanakis (pkampana)
- Re: [IPsec] WG adoptation call for draft-smyslov-… Tobias Guggemos
- Re: [IPsec] WG adoptation call for draft-smyslov-… Paul Wouters
- Re: [IPsec] WG adoptation call for draft-smyslov-… Valery Smyslov
- Re: [IPsec] WG adoptation call for draft-smyslov-… Tobias Guggemos
- Re: [IPsec] WG adoptation call for draft-smyslov-… Valery Smyslov
- Re: [IPsec] WG adoptation call for draft-smyslov-… Andreas Steffen
- Re: [IPsec] WG adoptation call for draft-smyslov-… Tobias Guggemos
- Re: [IPsec] WG adoptation call for draft-smyslov-… Tobias Heider
- Re: [IPsec] WG adoptation call for draft-smyslov-… Valery Smyslov
- Re: [IPsec] WG adoptation call for draft-smyslov-… Valery Smyslov
- Re: [IPsec] WG adoptation call for draft-smyslov-… Paul Wouters
- Re: [IPsec] WG adoptation call for draft-smyslov-… Tobias Heider
- Re: [IPsec] WG adoptation call for draft-smyslov-… Tobias Heider
- Re: [IPsec] WG adoptation call for draft-smyslov-… Valery Smyslov
- Re: [IPsec] WG adoptation call for draft-smyslov-… Valery Smyslov
- Re: [IPsec] WG adoptation call for draft-smyslov-… Valery Smyslov
- Re: [IPsec] WG adoptation call for draft-smyslov-… Tobias Heider
- Re: [IPsec] WG adoptation call for draft-smyslov-… Tobias Guggemos
- Re: [IPsec] WG adoptation call for draft-smyslov-… Tobias Guggemos