IETF Logo Mail Archive

[IPsec] 回复：[Editorial Errata Reported] RFC7296 (6940)

Tero Kivinen <kivinen@iki.fi> Sun, 12 June 2022 09: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 6BB30C14CF0E for <ipsec@ietfa.amsl.com>; Sun, 12 Jun 2022 02:58:56 -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, 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 jTraYPHdy90N for <ipsec@ietfa.amsl.com>; Sun, 12 Jun 2022 02:58:55 -0700 (PDT)
Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::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 0A933C14CF0C for <ipsec@ietf.org>; Sun, 12 Jun 2022 02:58:54 -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 88EF920054; Sun, 12 Jun 2022 12:58:50 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1655027930; 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=DCDLbXZZi2ow1IyTjXHLNBDISR+TvcqK8p5shRRQGMs=; b=dMrVENYPAw4yjPie4JsBeuvTT3aSXjXjrHVNkkEaa8FF6V2QYm/ILgoBA0jOebgbKbmDAd dDDTuRRUkIBKo/hMPuzjPMWCqLcBzMSa4QhLESC9HXc6xTgx5ETarVhmbcRc4XqCDeYNcR N9JA2OCNHqwrmA2+V/EHs9QS27AwVGk=
Received: by fireball.acr.fi (Postfix, from userid 15204) id 8A43C25C12ED; Sun, 12 Jun 2022 12:58:49 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <25253.47321.468594.661741@fireball.acr.fi>
Date: Sun, 12 Jun 2022 12:58:49 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "\"\\�\\�\\�\\�\\�\\�\\�\\�\\�\"" <648936027@qq.com>
Cc: ipsec <ipsec@ietf.org>
In-Reply-To: <tencent_835DFBA01C3F654B98F7D362515D5EDF9308@qq.com>
References: <20220421163101.D6ECF1E65D@rfcpa.amsl.com> <25186.24443.897408.821601@fireball.acr.fi> <tencent_0F97C6374C173CE8E64FCED2DFFDAA586206@qq.com> <25187.49507.645124.522333@fireball.acr.fi> <tencent_835DFBA01C3F654B98F7D362515D5EDF9308@qq.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 1 min
X-Total-Time: 1 min
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1655027930; 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=DCDLbXZZi2ow1IyTjXHLNBDISR+TvcqK8p5shRRQGMs=; b=ij3wd8D8heYUB/4w+fpOf2ShlpscH/dOMMJzQkJLpRBSpoIgus3PCBZGvmlKtLdcfJtCnl t5gbYrXCaJsZJCEy2jQUooW3isrw+9+9VRlgOnhjVjZ59WjHzvbJbfKzcO/vP6GOgBrYoe AEr+50hX1AZ+vJtB9OlJI9maJvrhMak=
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=1655027930; a=rsa-sha256; cv=none; b=kRMSovTnHc9pbYszJ3f/4yyYALjoRGHQOmKPJNaT99XCIi/BInXzuL7A/jSGLKFsxBAZgA FYxr1zSZCiWCb2C3gWdyWQdynS+6TRu/1sho9qYgC7TnFM6gUoI4N0p2u5XqF5Wv0cHft+ 3EqHDpbjWa/F7r7GBsiAgJYPlofGV2I=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/1kfx17uiH9hp_Ef0UV3Phyk6rAw>
Subject: [IPsec] 回复：[Editorial Errata Reported] RFC7296 (6940)
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: Sun, 12 Jun 2022 09:58:56 -0000

黯乡魂 writes:
> Thank you for your reply. There is another issue about  IKE SA rekey. After
> IKE SA rekey, a new SK_d is generated for the new IKE SA, so shall we update
> any existing child SA's key according to the new SK_d? I noticed that the
> child SA's key is derived from SK_d.

No. SK_d is used only to derive new Child SAs. Once the Child SAs are
created they keep their keys until they themselves are rekeyed, and
that is done by creating new SA with new keys and deleting the old SA.
Keys of the exisiting SAs will never be updated.
-- 
kivinen@iki.fi

v2.23.0 | Report a Bug | By Email