[sidr] [Technical Errata Reported] RFC6482 (7079)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 10 August 2022 14:41 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 C11E1C14792E for <sidr@ietfa.amsl.com>; Wed, 10 Aug 2022 07:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.66
X-Spam-Level:
X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.998, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 RfL3F7J84jNc for <sidr@ietfa.amsl.com>; Wed, 10 Aug 2022 07:41:37 -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 01926C1594AD for <sidr@ietf.org>; Wed, 10 Aug 2022 07:41:36 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 990619606E; Wed, 10 Aug 2022 07:41:36 -0700 (PDT)
To: mlepinski@bbn.com, skent@bbn.com, dkong@bbn.com, aretana.ietf@gmail.com, jgs@juniper.net, andrew-ietf@liquid.tech, morrowc@ops-netman.net, sandy@tislabs.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: job@fastly.com, sidr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20220810144136.990619606E@rfcpa.amsl.com>
Date: Wed, 10 Aug 2022 07:41:36 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/749_A_rSpwUSAAQF7h6_llZDa6c>
Subject: [sidr] [Technical Errata Reported] 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: Wed, 10 Aug 2022 14:41:40 -0000

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

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

--------------------------------------
Type: Technical
Reported by: Job Snijders <job@fastly.com>

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

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. 

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