Re: [Sidrops] AD Review of: draft-ietf-sidrops-rfc6482bis - "A Profile for Route Origin Authorizations (ROAs)"

[Job Snijders <[e-mail]>]

On Wed, Sep 20, 2023 at 01:13:16PM +0200, Martin Hoffmann wrote:
> Job Snijders wrote:
> > On Sun, Sep 17, 2023 at 10:10:22AM -0700, Warren Kumari wrote:
> > > How about, at the end of "5.  ROA Validation", at the end of:
> > > "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 steps." you add: "If any of these
> > > constraints fail, the profile is deemed corrupt, and the entire ROA
> > > should be discarded (probably after reporting an error)." or
> > > similar.  
> > 
> > Thank you for the suggestion, how about the following?
> > 
> > https://github.com/job/draft-rfc6482bis/commit/25f14dd674625a4ac526dfcfef26f7345bd10cc1
> 
> I think it still needs to be specified in the validation section
> (because that section claims to exhaustively list all condition for a
> valid ROA) that if any of the requirements given in the Content Type
> section is not met, validation fails.
> 
> This is not obvious to someone with a background in IETF protocols,
> who would rather be inclined to salvage what’s usable.

Did you mean the sentence should be at the bottom of the validation
section? Like so? https://github.com/job/draft-rfc6482bis/commit/b75dbd1f9cb019cec4a88103c6e1c9236743a0f7

Section 5 in its entirety:

-------------
5.  ROA Validation

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

   *  The IP Address Delegation extension [RFC3779] is present in the
      end-entity (EE) certificate (contained within the ROA), and every
      IP address prefix in the ROA payload is contained within the set
      of IP addresses specified by the EE certificate's IP Address
      Delegation extension.

   *  The EE certificate's IP Address Delegation extension MUST NOT
      contain "inherit" elements described in [RFC3779].

   *  The Autonomous System Identifier Delegation Extension described in
      [RFC3779] is not used in Route Origin Authorizations and MUST NOT
      be present in the EE certificate.

   If any of the above checks fail, the ROA in its entirety MUST be
   considered invalid and an error SHOULD be logged.

6.  Security Considerations
....

--------------