Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties
draft-ietf-sidrops-rp-06

Section 4.3:

“A Manifest can be classified as either valid or invalid, and a valid Manifest is either current and stale.”

That should be “...or stale”, right?

** In the spirit of this being a pathfinding document, provide additional references as follows:

-- Section 3.2.  Per “An RP is expected to support the amended procedure to handle with accidental over-claim.”, a pointer to these procedures would be helpful.

-- Section 3.3.  Per “CRLs in the RPKI are tightly constrained; only the AuthorityKeyIndetifier and CRLNumber extensions are allowed …”, a pointer to these extensions would be helpful.

-- Section 4.2.4, Per “Additionally, the certificate must contain an AS Identifier Delegation extension …”, a pointer to this extension would be helpful.

** Section 1.  Per “Besides, software engineering calls for how to segment the RP system into components with orthogonal functionalities, so that those components could be distributed across the operational timeline of the user”. I didn’t follow the intent of this sentence.  What are principles of software engineering calling for?

** Section 3.3.  Typo in the extension name.  s/AuthorityKeyIndetifier/AuthorityKeyIdentifier/

** Section 7. Please add text that this document doesn’t introduce any new security considerations but is a resource to implementers.  The individual RPKI RFC need to be consulted for specific guidance.

** Editorial Nits
-- Section 1.  Typo. s/This document will be update …/This document will be updated …/

-- Section 3.1.  Typo. s/must be present and value of each extension/must be present and the value of each extension/

While this document is useful for a RPKI newcomer or implementer, I wonder whether it should become a RFC even if informal... and the "requirements" in the title is also conflicting IMHO with an informational RFC.

I wonder whether the "security considerations" section is really about security considerations linked to this document or to the overall RP system.

Regards

-éric

I agree with Alvaro about Section 4.3.

Section 2

   RP software uses synchronization mechanisms supported by targeted
   repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI
   changed data objects in the repository system and cache them locally.

nit(?): perhaps "changed" requires a bit more explanation.

Section 2.1

   TAL acquisition and processing are specified in Section 3 of
   [RFC8630].

I'm not really convinced that the referenced section discusses
specifically TAL *acquisition*.

Section 2.2

   by using the SIA and AIA extensions.  Detailed specifications of SIA
   and AIA extensions in a resource certificate are described in
   Section 4 of [RFC6487].

(Subsections thereof, though I trust that the reader should be able to
figure this out.)

Section 3.1

   established by Section 4 of [RFC6487].  This means that all
   extensions mandated by Section 4.8 of [RFC6487] must be present and
   value of each extension must be within the range specified by this
   RFC.  Moreover, any extension excluded by Section 4.8 of [RFC6487]

nit: s/this/that/ ("this RFC" is the thing that draft-ietf-sidrops-rp
will become, in this context).

   Section 7.1 of [RFC6487] gives the procedure that the RP should
   follow to verify resource certificate and syntax.

"verify resource certificate and syntax" seems a little broad; the
referenced section seems specific to validating the extension defined in
RFC 3779.

Section 3.2

   Certificate Authorities that want to reduce aspects of operational
   fragility will migrate to the new OIDs [RFC8360], informing the RP of
   using an alternative RPKI validation algorithm.  An RP is expected to
   support the amended procedure to handle with accidental over-claim.

nit: I suggest s/with accidental over-claim/accidental overclaim/.

Section 3.3

   Processing of a CRL that is not consistent with a manifest is a
   matter of local policy, as described in the fourth paragraph of
   Section 6.6 of [RFC6486].

Is the fifth paragraph relevant, also?

Section 4.1

   Note that these checks are necessary, but not sufficient.  Additional
   validation checks must be performed based on the specific type of
   signed object.

These additional validations are covered in the following sections, it
seems -- should we mention that here?

Section 4.2.4

   contain an IP Address Delegation extension.  The validation procedure
   used for BGPsec Router Certificates is identical to the validation
   procedure described in Section 7 of [RFC6487], but using the
   constraints applied come from specification of Section 7 of
   [RFC8209].

nit: if it does something differently, it's no longer "identical"; maybe
"analogous" or it's following the validation procedure [...] with
additional constraints"?
That said, Section 7 of RFC 8209 is the IANA considerations, so I'm not
sure what the "constraints applied come from" is intended to say.

Section 7

The validation steps discussed throughout this document are also pretty
important to the security of the system as a whole.

Section 10.1

I'm not sure that RFC 5280 actually is normative here.  (That might be
the first time I've ever said that!)

Section 10.2

I think that RFCs 6489, 6916, and 8634 are probably better as normative.

Thanks for this - I think that this document is useful.  One issue with the IETF standard format is that it can be difficult to find which RFCs need to be read to fully solve a particular problem, particularly considering that some of those RFCs may be updated or obsoleted by other RFCs.  I agree with Warren's comment that it would make a good living document, if IETF had such things.

In terms of reading the document, I noted that it uses quite a lot of acronyms that I was not immediately familiar with and that are not defined in the document.  Perhaps the document could be improved by having a short terminology section?  The acronyms that didn't appear to be defined include CRL, INR, CA, ROA.


4.2.1.  Manifest

   To determine whether a manifest is valid, the RP is required to
   perform manifest-specific checks in addition to those specified in
   [RFC6488].
   
I found the above paragraph as being unclear, in that I don't know what "those" is referring to, and hence I suggest more clearly identifying “those” checks.

Finally, I agree with Alvaro's comment related to section 4.3:  This document probably shouldn't be giving recommendations.  Perhaps better to just keep this as "However, most RP software ignores such objects.", or combine it with the previous sentence.