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