RFC Errata
Found 5 records.
Status: Verified (3)
RFC 6482, "A Profile for Route Origin Authorizations (ROAs)", February 2012
Source of RFC: sidr (rtg)
Errata ID: 3166
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Chi
Date Reported: 2012-03-25
Verifier Name: Stewart Bryant
Date Verified: 2012-10-26
Section 4 says:
...EE certificate's IP address delegation extension.
It should say:
...EE certificate's IP address delegation extension. The EE certificate MUST NOT use "inherit" elements as described in [RFC3779].
Notes:
Having spoken to the authors, the authors' intent was to disallow "inherit" in ROA EE certificates in order to simplify validation of ROAs. Implementers agree, and as of March 2012, the three public validator implementations already enforce this.
This erratum simply states it explicitly, whereas the original text might be misread as leaving room for indirectly-specified resources via "inherit".
This errata was discussed by the WG, please see SIDR list archive.
Errata ID: 5881
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-23
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-10-24
Section Appendix A says:
END
It should say:
id-ct-routeOriginAuthz OBJECT IDENTIFIER ::= { 1 2 840 113549 1 9 16 1 24 }
END
Notes:
The object identifier for the ROA content type is mentioned in the document, but it is not included in the ASN.1 Module.
Errata ID: 5609
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Kristoff
Date Reported: 2019-01-20
Verifier Name: RFC Editor
Date Verified: 2019-01-22
Section Table of Contents says:
5. Security Considerations .........................................5
6. Acknowledgments .................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
It should say:
5. Security Considerations .........................................5
6. IANA Considerations .............................................6
7. Acknowledgments .................................................6
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................6
Notes:
The Table of Contents omits the "IANA Considerations" section, which should be section 6, which consequently causes the numbered sections to be follow be labeled incorrectly.
Status: Reported (1)
RFC 6482, "A Profile for Route Origin Authorizations (ROAs)", February 2012
Source of RFC: sidr (rtg)
Errata ID: 7525
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sacha Boudjema
Date Reported: 2023-05-26
Section 3.3 says:
Within the ROAIPAddressFamily structure, addressFamily contains the Address Family Identifier (AFI) of an IP address family. This specification only supports IPv4 and IPv6. Therefore, addressFamily MUST be either 0001 or 0002. Within a ROAIPAddress structure, the addresses field represents prefixes as a sequence of type IPAddress. (See [RFC3779] for more details). If present, the maxLength MUST be an integer ...
It should say:
Within the ROAIPAddressFamily structure, addressFamily contains the Address Family Identifier (AFI) of an IP address family. This specification only supports IPv4 and IPv6. Therefore, addressFamily MUST be either 0001 or 0002. The addresses field represents prefixes as a sequence of type ROAIPAddress. Within the ROAIPAddress structure, the address field represents an IPv4 or IPv6 prefix of type IPaddress (See [RFC3779] for more details). If present, the maxLength MUST be an integer ...
Notes:
Original text contradicts does not align with normative ASN.1 schema.
Status: Rejected (1)
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.