[IPsec] [Errata Held for Document Update] RFC7296 (5247)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 11 April 2022 00:15 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 EE6313A17EC; Sun, 10 Apr 2022 17:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.659
X-Spam-Level:
X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 r2z-F_jTPwkQ; Sun, 10 Apr 2022 17:15:02 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819D53A17EA; Sun, 10 Apr 2022 17:15:02 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 39E62E43A5; Sun, 10 Apr 2022 17:15:02 -0700 (PDT)
To: andrew.cagney@gmail.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
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20220411001502.39E62E43A5@rfcpa.amsl.com>
Date: Sun, 10 Apr 2022 17:15:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/z2qd9eSh3WQi8O_Hk_WMv45mvkM>
Subject: [IPsec] [Errata Held for Document Update] RFC7296 (5247)
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: Mon, 11 Apr 2022 00:15:07 -0000

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

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

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Andrew Cagney <andrew.cagney@gmail.com>
Date Reported: 2018-01-30
Held by: Paul Wouters (IESG)

Section: 3.10.

Original Text
-------------
   o  Protocol ID (1 octet) - If this notification concerns an existing
      SA whose SPI is given in the SPI field, this field indicates the
      type of that SA.  For notifications concerning Child SAs, this
      field MUST contain either (2) to indicate AH or (3) to indicate
      ESP.  Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS, REKEY_SA, and
      CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
      sent as zero and MUST be ignored on receipt.

Corrected Text
--------------
   o  Protocol ID (1 octet) - If this notification concerns an existing
      SA whose SPI is given in the SPI field, this field indicates the
      type of that SA.  For notifications concerning Child SAs, this
      field MUST contain either (2) to indicate AH or (3) to indicate
      ESP.  Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS, REKEY_SA, and
      CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
      sent as zero to indicate NONE and MUST be ignored on receipt.

Notes
-----
If I assume that the 'Protocol ID' field in the notification payload is specified by:

  Internet Key Exchange Version 2 (IKEv2) Parameters
  IKEv2 Security Protocol Identifiers

then a notification is using the 'Reserved' value 0.   Since the value is being used,
I think it would be better to give it a name.  Other uses of 'Protocol ID' don't need
updating as they all explicitly list allowed values, and in no case is 0 allowed.

Paul Wouters:

This is about name for Protocol ID 0 to be seen as "NONE", versus giving it a better name. While I agree with the poster the writing could be improved, this change is not required for implementing the RFC. Thus moved to Held for Document Update where this text can then be improved upon.


--------------------------------------
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