Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06

Tero Kivinen <kivinen@iki.fi> Wed, 12 October 2022 18:58 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 A1E06C14F74F for <ipsec@ietfa.amsl.com>; Wed, 12 Oct 2022 11:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 MTaWTeIEaFl1 for <ipsec@ietfa.amsl.com>; Wed, 12 Oct 2022 11:58:13 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE31C14F742 for <ipsec@ietf.org>; Wed, 12 Oct 2022 11:58:12 -0700 (PDT)
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 meesny.iki.fi (Postfix) with ESMTPSA id 3CCE720167; Wed, 12 Oct 2022 21:58:08 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1665601088; 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=7LEXfUmHPI5Dke+GytHXQy7xCpgMY9pHHheFyrwjBVk=; b=ifUST1oH8xIZyEqWdJTszYYL1yyfr5vqC/yGPkdLnBiMsviCT/BrSDKXLc3ex4ex4QnVyQ Sx6OfmLgRq6zRkb0Bi0Nswu68AOzdkfZQhEPDVA3oKDyRsLjlCz7U7KK/qliZ4v3IdhWd5 1Tx+LOh7XdsM5jDPFVRGdJH4EPbXK9o=
Received: by fireball.acr.fi (Postfix, from userid 15204) id DFE2F25C12D1; Wed, 12 Oct 2022 21:58:06 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <25415.3646.863005.336101@fireball.acr.fi>
Date: Wed, 12 Oct 2022 21:58:06 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Roman Danyliw <rdd@cert.org>
Cc: CJ Tjhai <cjt@post-quantum.com>, Valery Smyslov <svan@elvis.ru>, "ipsec@ietf.org" <ipsec@ietf.org>
In-Reply-To: <BN2P110MB1107E6807021031C3A5B6A0CDC209@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
References: <BN2P110MB1107D456BF345148FADD88CFDC569@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM> <CANs=h-WWnrdv5+ewjKVnBdoC4X4eTosM5uZ1BDfED1EJ=V9UFw@mail.gmail.com> <BN2P110MB1107E6807021031C3A5B6A0CDC209@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 3 min
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1665601088; a=rsa-sha256; cv=none; b=PHZUXVN2rR0k4P54OZDS8E2qC1IGttMgqEvWDPmFRTjE5fTcbC20I4gYbxYO+qOJVgS/xu yOeoqaGnk3kFObhuGsP1JkG2FhdOayxw8ZkxMgEQX88HdC3/qvONfDmqaX5p51eCA0lSGd F1xNlWwxrfLOLjkFKFj1Ej2NKGRBiDU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1665601088; 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=7LEXfUmHPI5Dke+GytHXQy7xCpgMY9pHHheFyrwjBVk=; b=h1JS1cqpka5ihtTSpv6nXzZnfYxn0LmaZ9Si47NKU7m9SF4mqUdBBE5fttPnCpQ6Ij4wq0 dm3gEj+stGw0n7WjsLIB/gOpZ2qsNBgY4swjIjw4Jfh+EaQC6d20UF5IaaFqopsXaUfZLv rLukJwfwjMw5ipeRD/KB/guhQFuvYP8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/ApYYtvPuoB3zIZRZIWbHCKbW-PA>
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06
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: Wed, 12 Oct 2022 18:58:14 -0000

Roman Danyliw writes:
>     ** Section 3.2.4. 
>    
>     The responder MUST handle this
>        situation gracefully and delete the associated state if it does not
>        receive the next expected IKE_FOLLOWUP_KE request after some
>        reasonable period of time.
>    
>     Is there a guidance on the timeout value?
> 
> IKEv2 traditionally does not mandate exact timeouts. For example, the same
> situation happens if the initiator completes IKE_SA_INIT and never starts
> IKE_AUTH. The responder should eventually delete the incomplete IKE SA, but
> RFC 7296 does not specify how long the waiting time is.
> 
> FWIW, our implementations waits 5 seconds by default (which is adjustable
> value).
> 
> Do you think we should recommend (but not mandate) to wait for 5-10 seconds?
> 
> [Roman] A recommended value would help if you are comfortable giving it, or
> explaining why it’s hard to give one.  This is a common question that comes
> from transport review during IETC LC or IESG review.

Suitable values can be between few seconds up to few minutes. For
example timeout between IKE_SA_INIT and IKE_AUTH might require user
interaction, thus it might be up to minutes if PIN code to unlock user
auth device is required etc.

Because the timeouts are so different depending on the environment and
usage scenario we do not give them in the IKEv2 document. 
-- 
kivinen@iki.fi