Re: [IPsec] [Editorial Errata Reported] RFC7296 (5247)

"Valery Smyslov" <smyslov.ietf@gmail.com> Thu, 01 February 2018 13:07 UTC

Return-Path: <smyslov.ietf@gmail.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 51D8712E03A for <ipsec@ietfa.amsl.com>; Thu, 1 Feb 2018 05:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.198
X-Spam-Level:
X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6PuhOTbgLK1s for <ipsec@ietfa.amsl.com>; Thu, 1 Feb 2018 05:07:35 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE13212E87F for <ipsec@ietf.org>; Thu, 1 Feb 2018 05:07:34 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id x196so26094857lfd.12 for <ipsec@ietf.org>; Thu, 01 Feb 2018 05:07:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=wxpeEjEeyspSQv6IbcINmvvos2eziPqMIFGsJKXnruM=; b=KK7BYkvAaT+xxiq0fraAsMAqnqwJuv1oXvAo+8JthiIT7WZE9oaaNTBRNqAkq/IRni Vocx5EyHnhLFaSM78ETZOzZgTUZZErjD15X3IwMSLGs3jZNCIAoMA13Z9+3dvLqmZLns UpRqeZj/nWsRAZfPyZenEljEc2nedw4D1mw8wQkhxBiRM7sfGKV6jeWQd1yzO6JDBkvb ykcl65shMuGayw48PEk6lD12ixkkfnsmXnf6BiKZVTTWjTjIgs+5xgMgX4j7zPwRfNRQ /rq96QBqDANNpHXi/zEskyNRoRRh0u7yZaQHXDvDhwtlS+hwrbh/SMITmN5/bSl0cGzO /mkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=wxpeEjEeyspSQv6IbcINmvvos2eziPqMIFGsJKXnruM=; b=n8GS/RT+tRg6rswsMCXqk+r6DC9vJR6yaB5MjQRpjr6+EVM3DQQh8MNiaO86TX1dRX qje0NzmjyEfeq5ymDdd//j+pgbgT4OWCHZTYzJVBm+DVFrozvb5Ojl8vvxQ0m4wB9RMf KHAbOoln6DjqCl8JrCOcxGBUhrYROxm8BqSM7xIg/YGP87dKWniYQ8h3JaMnx9ioyYW+ Ws/WurPYUgV9Ds/OpMymtk1/QY78LY8yFr8uCI2n9jfT2rl6bAO+p542w2I5TZS1yeci +NlU422fEZYDWn0WpzkmdWthQGeSi9wcnqBANdtifILWAjX8XnJWbw7/JdF2MS/ZJyyf HGSA==
X-Gm-Message-State: AKwxytcXv4h9ygkjWCCKTy9HwfDOsBslulTgoa23k+iFnu8NwKaW/N9a yyagV6ZzU9gSU4489hSPepo=
X-Google-Smtp-Source: AH8x225GC4FPSHDH7+cNRUtH9MQb9jzMmpFJTBKkTLDuwbfK3SbyZ1wn/JaQ5p2GVgbPYaHLhW8RNw==
X-Received: by 10.25.198.201 with SMTP id w192mr20467370lff.40.1517490452980; Thu, 01 Feb 2018 05:07:32 -0800 (PST)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g133sm4355143lfg.89.2018.02.01.05.07.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Feb 2018 05:07:32 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Yoav Nir' <ynir.ietf@gmail.com>, andrew.cagney@gmail.com, 'David Waltermire' <david.waltermire@nist.gov>, 'Tero Kivinen' <kivinen@iki.fi>, 'Eric Rescorla' <ekr@rtfm.com>
Cc: 'pe' <pe@iki.fi>, 'IPsecME WG' <ipsec@ietf.org>, Kathleen.Moriarty.ietf@gmail.com, 'Paul Hoffman' <paul.hoffman@vpnc.org>, 'charliekaufman' <charliekaufman@outlook.com>
References: <20180130215039.EE475B80DE5@rfc-editor.org> <C62D59E0-9EF1-4BAB-B610-46FA66C0B186@gmail.com> <3380F947-18B4-4DDA-B218-B60E7E2DA460@gmail.com>
In-Reply-To: <3380F947-18B4-4DDA-B218-B60E7E2DA460@gmail.com>
Date: Thu, 01 Feb 2018 16:07:32 +0300
Message-ID: <032f01d39b5d$9fadaee0$df090ca0$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0330_01D39B76.C4FF7AC0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQILz9bOFKZfhNrtFRMnelb5NiK/6AIdhUHyANtqQzSjB1HeUA==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/bFp_UfYO5hrKrgS0yOCr_2CCbcU>
Subject: Re: [IPsec] [Editorial Errata Reported] RFC7296 (5247)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 01 Feb 2018 13:07:37 -0000

Hi,

 

I think this erratum should be rejected. First, there is no value NONE

in the IANA registry for the Protocol Type. The value 0 is marked Reserved, note NONE.

 

Then, there are a lot of IPsec documents that require protocol field in Notify payload to be zero.

Should this erratum be accepted, similar errata should be reported for all  these documents.

I don’t think it would help implementers in any respect.

 

Regards,

Valery.

 

 

On 31 Jan 2018, at 7:04, Yoav Nir < <mailto:ynir.ietf@gmail.com> ynir.ietf@gmail.com> wrote:

 

Hi.

 

I don’t see anything wrong with the suggestion (it’s just adding “to indicate NONE” in the last sentence). However:

*	A value marked “Reserved” in IANA just means that IANA should not assign it. It does not mean that it cannot appear in the protocol.
*	Using a zero in a field to indicate no value is common, and IANA registries are inconsistent about whether such zero values are named or just reserved.
*	Unless we want to change the IANA registry, there is no reason to uppercase ‘none’
*	I don’t think we need to update the IANA registry.

 

“Hold for document update”?





On 30 Jan 2018, at 23:50, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

 

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

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

--------------------------------------
Type: Editorial
Reported by: Andrew Cagney <andrew.cagney@gmail.com>

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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

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

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec