[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, 06 Sep 2022 11:54:33 -0700
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
- [sidr] [Errata Rejected] RFC6482 (7079) RFC Errata System