RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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: Rejected (2)

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.

Errata ID: 7525
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Sacha Boudjema
Date Reported: 2023-05-26
Rejected by: John Scudder
Date Rejected: 2024-01-11

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.
--VERIFIER NOTES--
See discussion on the sidrops list at https://mailarchive.ietf.org/arch/msg/sidrops/cFCZREOerU-jGWWG5zh5PdXTLKE/

This erratum is filed against RFC 6482. Although RFC 6482 has not yet been marked "obsolete", this is only a formality -- draft-ietf-sidrops-rfc6482bis-09 has been approved for publication and is currently in the RFC Editor queue. When editing is complete and rfc6482bis is published as an RFC, 6482 will indeed be obsolete. In that spirit, I'm applying guideline 7 from https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ and rejecting this erratum. Note that in the thread referenced above, Job says the erratum is fixed in the bis. If it's not, a new erratum should be raised against the bis.

Report New Errata



Advanced Search