Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike

Tero Kivinen <kivinen@iki.fi> Tue, 31 January 2023 14:33 UTC

Return-Path: <kivinen@iki.fi>
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 3794DC1522C8; Tue, 31 Jan 2023 06:33:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdzChMoWdeUu; Tue, 31 Jan 2023 06:33:10 -0800 (PST)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1C9C14F738; Tue, 31 Jan 2023 06:32:46 -0800 (PST)
Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id D696E1B0034E; Tue, 31 Jan 2023 16:32:41 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1675175561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JOwQnSs9Gi+itlPMN40MMceoiVzwbirU+diB81KnUQs=; b=bmb/7oXk7slKJsfh+em7dsztJ0uHhqUMqyV4yqq20+Bp5p8K36Gc+o2opvDrVEXEG2uOSD ysCjffd/cQEcMlmon9foju3cwH0PCw92OnL49zEyRNqnfIoQZhIzaJMG3WwCF+eaLqc2Ro JkQUG/VDilHJdfsn6lUsmtJS7dQMB0z5ahGKNP8mYmu7VODeeaIyiXssbZY3q751xQyV1y oD0X98msSun/JqcFr8bVmFbuahEP5pnhgbC+gz1yngbe4tk/r+jIr4pP4LsgSJCY2FXdZu CrPruswoaZXrJYmRXSQgBx9/VZcUK1MsVaQ0cwIVtYvhYGblufB9IHHgFPTgag==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1675175561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JOwQnSs9Gi+itlPMN40MMceoiVzwbirU+diB81KnUQs=; b=rryzKoEYSWUaYD+7ODUQ68ZMyHc7TdSHOwj04th3XVEBw060w4tTL0UssKGnR+j64SdyZ3 rE2p8inOgqGkuJRQUFPoN4QNwBGEuSRy5k6S5RQ38YYH99xHJ7B0v01FuQ4LzE6Mm3jT/T d3bx6qwIrTL6VY/M6a+X3qGLeCw/m9gqcL4klWPpbzd9WgbH8Xien5ZYlNXvg9DyiQm15X WvKj91VRSjB8nv3PrAQpKyDMRxS5IvSkCpTjxs2W1imVPK3DTWqo8lCasT6vhclgu5ZdXY ujKMifsF8uR1PMiCWDx/HdgIS6IOuvnDL5x8lDzgCrThSdta710w3Bb/g05tiw==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1675175561; a=rsa-sha256; cv=none; b=QDNRxz0aYeKSG+ZlI29zhyYL4Y6N/44pjSCz1BbzJWBLypaj8aCF50XcLUAgf6RYl4OErp wUOG7vfODq1VaGglfZJ1LODu1/OZrnD5RmB8zLsUDX5r9/h85L59MP3bioX2NmfPfJzy4R Z4S2UtSXacsF/P4+4gIRnuyDJUGFWttzbdxRv3oR/PlnnR+AIT4umRZN0RWTTeMkko0YxD ms9XYpWwfFC64en8u+fzDmVNUms56VynVj16FdnWh9gmOu5jeUWAhlyrg4i1bhcVlebopY lXVtfwMXH5YQpNqUMJMSsSLJzrNM/WRCl0jxBFqmRoLN4X+1i3mFZNpyGSfbig==
Received: by fireball.acr.fi (Postfix, from userid 15204) id 7FE0E25C1300; Tue, 31 Jan 2023 16:32:41 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <25561.9865.474004.698166@fireball.acr.fi>
Date: Tue, 31 Jan 2023 16:32:41 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: mohamed.boucadair@orange.com
Cc: Valery Smyslov <smyslov.ietf@gmail.com>, "draft-ietf-ipsecme-add-ike@ietf.org" <draft-ietf-ipsecme-add-ike@ietf.org>, "ipsec@ietf.org" <ipsec@ietf.org>
In-Reply-To: <18000_1675174331_63D921BB_18000_434_1_795d7bff776e4ff7a6812da3dd6d9f6c@orange.com>
References: <25560.18262.145478.996578@fireball.acr.fi> <013a01d9354c$c1fe37b0$45faa710$@gmail.com> <31961_1675155778_63D8D942_31961_164_1_567425c5d78042df9598eeadda785f7c@orange.com> <25561.7242.527268.796400@fireball.acr.fi> <18000_1675174331_63D921BB_18000_434_1_795d7bff776e4ff7a6812da3dd6d9f6c@orange.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 3 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/T8b4v7iYl4wewuktCxtpyoYOEU8>
Subject: Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 31 Jan 2023 14:33:13 -0000

mohamed.boucadair@orange.com writes:
> [Med] Yes, the initiator may include a suggested ALPN (protocol) for
> example to specifically indicate it is looking for DoT (or another
> protocol). The initiator may omit the ADN, but only include service
> parameters (typically, ALPN) to indicate a preferred transport
> protocol.

I was assuming there is some way of indicating that, but I could not
quickly find any examples of that, that is why I wanted to have more
examples in this draft, so I could see what values the alpn can have
:-) 

> 
> > 
> >   CP(CFG_REQUEST) =
> >      ENCDNS_IP6(23, 1, 16,
> >                 (2001:DB8:99:88:77:66:55:44),
> >      	        "doh1.example.com",
> >  	        "???")
> > 
> > initiator requesting the responder for specific information, most
> > likely something that it got last time, and initiator proposes it
> > to the responder, in case it is still valid, and responder can
> > send that same information back if it is valid, or return
> > something else.
> 
> [Med] Yeah, but still this is just a suggested value and it is up to
> the responder to decide to honor it or not. If a preference does not
> make sense, the response will simply ignore it.

Yep, this is standard IKEv2 behavior. 

> > Btw, for the second use case where the initiator fills in some of
> > the information about the server it wants to talk to, it would be
> > usefull to allow Service Priority to be 0, and explictly mention
> > that this is not AliasMode, this is meaning that initiator does
> > not care about the exact priority or does not know the priority,
> > so it used 0 as placeholder.
> 
> [Med] The initiator can use any non-null value for the priority in
> such case. No need to relax the constraint imposed on svcpriority.

My guess is that people are going to use zero still, as that is the
obvious number to use, which is why I think it would be better to
allow that... As long as responders do not start checking that
CFG_REQUEST priority must be non zero everything is fine... 
-- 
kivinen@iki.fi