RFC Errata
RFC 6482, "A Profile for Route Origin Authorizations (ROAs)", February 2012
Source of RFC: sidr (rtg)
Errata ID: 7079
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Job Snijders
Date Reported: 2022-08-10
Rejected by: John Scudder
Date Rejected: 2022-09-06
Section 4 says:
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.
It should say:
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.