[IPsec] [Errata Verified] RFC7296 (6940)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 28 July 2023 17:44 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
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 A8C09C14CE46; Fri, 28 Jul 2023 10:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.865
X-Spam-Level:
X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
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 JwDgsGsfgS3U; Fri, 28 Jul 2023 10:44:55 -0700 (PDT)
Received: from rfcpa.amsl.com (unknown [50.223.129.200]) (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 C268AC14CEFA; Fri, 28 Jul 2023 10:44:55 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 798BFAEA0; Fri, 28 Jul 2023 10:44:55 -0700 (PDT)
To: 648936027@qq.com, charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: paul.wouters@aiven.io, iesg@ietf.org, ipsec@ietf.org, iana@iana.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20230728174455.798BFAEA0@rfcpa.amsl.com>
Date: Fri, 28 Jul 2023 10:44:55 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/_1xFEgJMOQ29_ECt_KaNZZSzdgs>
Subject: [IPsec] [Errata Verified] 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: Fri, 28 Jul 2023 17:44:59 -0000

The following errata report has been verified for RFC7296,
"Internet Key Exchange Protocol Version 2 (IKEv2)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6940

--------------------------------------
Status: Verified
Type: Technical

Reported by: warren.wang <648936027@qq.com>
Date Reported: 2022-04-21
Verified by: Paul Wouters (IESG)

Section: .10

Original Text
-------------
o SPI Size (1 octet) - Length in octets of the SPI as defined by the
 IPsec protocol ID or zero if no SPI is applicable. For a
 notification concerning the IKE SA, the SPI Size MUST be zero and
 the field must be empty.


Corrected Text
--------------
o SPI Size (1 octet) - Length in octets of the SPI as defined by the
 IPsec protocol ID or zero if no SPI is applicable. For a
 notification concerning the IKE SA, the SPI Size MUST be zero and
 the SPI field must be empty.


Notes
-----
the field must be empty -> the SPI field must be empty

additional question: so for a notification concerning the IKE SA, the Protocol ID field still shall be zero?

Yes, for IKE SA notifications the SPI can be seen from the header, thus there is no point of repeating the SPIs in notify payload. The Protocol ID field of the notification payload indicates which type of SPI is inside the notification payload, thus if there is no SPI in there, then there is no point of having Protocol ID either.


--------------------------------------
RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04)
--------------------------------------
Title               : Internet Key Exchange Protocol Version 2 (IKEv2)
Publication Date    : October 2014
Author(s)           : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen
Category            : INTERNET STANDARD
Source              : IP Security Maintenance and Extensions
Area                : Security
Stream              : IETF
Verifying Party     : IESG