Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02

"Tobias Guggemos" <guggemos@nm.ifi.lmu.de> Thu, 21 March 2019 15:19 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 659C513124F for <ipsec@ietfa.amsl.com>; Thu, 21 Mar 2019 08:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 dbnHV4EABm6s for <ipsec@ietfa.amsl.com>; Thu, 21 Mar 2019 08:19:45 -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 A670F1311C1 for <ipsec@ietf.org>; Thu, 21 Mar 2019 08:19:44 -0700 (PDT)
Received: from DESKTOP58DFL8T (unknown [IPv6:2001:4ca0:0:f297:c153:9934:5383:c5e4]) (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 EE1B135D39F; Thu, 21 Mar 2019 16:19:42 +0100 (CET)
From: Tobias Guggemos <guggemos@nm.ifi.lmu.de>
To: 'Valery Smyslov' <smyslov.ietf@gmail.com>, 'Tero Kivinen' <kivinen@iki.fi>, 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> <014001d4df3f$492fcc70$db8f6550$@nm.ifi.lmu.de> <077201d4dfba$75e80cc0$61b82640$@gmail.com>
In-Reply-To: <077201d4dfba$75e80cc0$61b82640$@gmail.com>
Date: Thu, 21 Mar 2019 16:19:42 +0100
MIME-Version: 1.0
Message-ID: <001b01d4dff9$823fd860$86bf8920$@nm.ifi.lmu.de>
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHU2U0s6M7rbXuBv0SBwRv3SEEfn6YKvxmAgACvtICABiKNQIABBzyAgABckXCAASJaAIAATTlQgAFM0gCAAHtY0A==
Content-Language: de
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="=-=7zCfYwSakUOxF+=-="
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/2L2lu4T0uorWDf79OBPRhu4UqRQ>
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: Thu, 21 Mar 2019 15:19:57 -0000

> 
> [I snipped some text to make message more readable]
> 
Same here :-)

> > The important thing I'd like to mention:
> > I think, if we can avoid an issue by design - by excluding an option
> > we don't necessarily need - we should do that and not the other way
> around.
> 
> I don't see it's an issue. More precisely, I can see it as a generic issue, not
> particularly concerned with empty INTERMEDIATE messages.
> 

I see your point and I think making explicitly sure that support/negotitation of IKE_INTERMEDIATE without an application addresses the comment anyway!

 
> > The current wording says: The implementation MAY support
> > IKE_INTERMEDIATE but MUST NOT use it without an application.
> > My preferred approach would be: The implementation MUST NOT support
> > IKE_INTERMEDIATE without an application.
> 
> OK, how about:
> 
> The implementation MUST NOT negotiate support for INTERMEDIATE
> without an application.
> 

That sounds good for me. 
The question remains if it is than necessary to negotiate INTERMEDIATE explicitly, but that this is something I really don't care too much! :-)

> > My thinking is, you'd like to negotiate an application  (e.g. PQKE)
> > which needs IKE_INTERMEDIATE, so it's all about the application anyway.
> > So if the application needs IKE_INTERMEDIATE, it wouldn't work if
> > IKE_INTERMEDIATE is not supported anyways.
> 
> It depends. I can imagine extensions that can run w/o INTERMEDIATE, but
> can benefit if it is supported...
> 

Good point!

> > > > I don't say this is the only way to go, but I feel it's cleaner
> > > > than just saying it could be anything. I'd actually prefer what I
> > > > mentioned above, not allowing IKE_INTERMEDIATE to be implemented
> > > > without
> > > another document defining the actual payload.
> > >
> > > Exactly, except that I'd s/implemented/used. You can implement a
> > > pure framework (just for the future), but you cannot use it without
> > > implementing another document utilizing it.
> >
> > Maybe we could replace "used" with "supported"?
> 
> is "negotiated" or "advertised support for" OK here?

I think I like negotiated!

> 
> Regards,
> Valery.
> 
> > Regards
> > Tobias