[sidr] [Errata Rejected] RFC6482 (7079)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 06 September 2022 18:54 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07174C157B55; Tue, 6 Sep 2022 11:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.659
X-Spam-Level:
X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.998, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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 sm3SUMOzkPNI; Tue, 6 Sep 2022 11:54:34 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [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 5DBA1C157B56; Tue, 6 Sep 2022 11:54:34 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id E63D0CDA2B; Tue, 6 Sep 2022 11:54:33 -0700 (PDT)
To: job@fastly.com, mlepinski@bbn.com, skent@bbn.com, dkong@bbn.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: jgs@juniper.net, iesg@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20220906185433.E63D0CDA2B@rfcpa.amsl.com>
Date: Tue, 6 Sep 2022 11:54:33 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/3fuRTc-zb1drpGx39g2B7RIUv_4>
Subject: [sidr] [Errata Rejected] RFC6482 (7079)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2022 18:54:38 -0000

The following errata report has been rejected for RFC6482,
"A Profile for Route Origin Authorizations (ROAs)".

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

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Job Snijders <job@fastly.com>
Date Reported: 2022-08-10
Rejected by: John Scudder (IESG)

Section: 4

Original Text
-------------
   Before a relying party can use a ROA to validate a routing
   announcement, the relying party MUST first validate the ROA.  To
   validate a ROA, the relying party MUST perform all the validation
   checks specified in [RFC6488] as well as the following additional
   ROA-specific validation step.

   o  The IP address delegation extension [RFC3779] is present in the
      end-entity (EE) certificate (contained within the ROA), and each
      IP address prefix(es) in the ROA is contained within the set of IP
      addresses specified by the EE certificate's IP address delegation
      extension.

Corrected Text
--------------
   Before a relying party can use a ROA to validate a routing
   announcement, the relying party MUST first validate the ROA.  To
   validate a ROA, the relying party MUST perform all the validation
   checks specified in [RFC6488] as well as the following additional
   ROA-specific validation step.

   o  The IP address delegation extension [RFC3779] is present in the
      end-entity (EE) certificate (contained within the ROA), and each
      IP address prefix(es) in the ROA is contained within the set of IP
      addresses specified by the EE certificate's IP address delegation
      extension.
   o  The AS Resources extension is not used in Route Origin Authorizations
      and MUST be omitted.

Notes
-----
The ROA RFC is a bit under-specified compared to other RPKI Signed Object profile definitions. (For example, RFC 8209 ยง 3.1.3.4 is less ambiguous on the matter of RFC3779 extensions.)
 --VERIFIER NOTES-- 
This is a material (albeit small) change to the spec and doesn't appear to reflect the WG consensus at time of publication. Therefore rejecting, see https://mailarchive.ietf.org/arch/msg/sidr/A_2jMTLbpgpK1H0G3QsVJ44T-kE/ as well.

--------------------------------------
RFC6482 (draft-ietf-sidr-roa-format-12)
--------------------------------------
Title               : A Profile for Route Origin Authorizations (ROAs)
Publication Date    : February 2012
Author(s)           : M. Lepinski, S. Kent, D. Kong
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG