Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties

Note: This ballot was opened for revision 06 and is now closed.

Erik Kline Yes

Comment (2020-04-05)



* This is the first time ROA is really used. Consider expanding it here one
  time, or up in the introduction where it first appears in the list of RFCs.


* I had some trouble parsing "but using the constraints applied come from ...".


* s/make decision/make decisions|make a decision/


* s/slate/stale/

Warren Kumari Yes

Comment (2020-03-25)
Notes for IESG reviewers:
The requirements for relying party software is scattered throughout a bunch of different RFCs, and are sometimes buried and easy to overlook within these RFCs - they are generally more descriptive of how the system as a whole should work, not the responsibilities from each component's view.
This has already caused a number of issues and inconsistencies between implementations, and so a document like this is needed.  Like with other "Hitchhikers Guide to the XXX protocol" documents this would be a prime candidate for an "evolving document" type solution - but in the absence of such a thing, having an RFC is much better than a draft...

Benjamin Kaduk No Objection

Comment (2020-04-08)
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

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

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.

Murray Kucherawy No Objection

Comment (2020-03-27)
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?

Robert Wilton No Objection

Comment (2020-04-08)
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
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.

Roman Danyliw No Objection

Comment (2020-04-08)
** 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/

Éric Vyncke No Objection

Comment (2020-04-08)
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.



Alvaro Retana Abstain

Comment (2020-04-07)

This document presents a nice summary, but I am ABSTAINing, and not standing in the way of publication, because I don't think the contribution has enough archival value and it could cause confusion.

  While the document tries to provide "a single reference point", it mostly 
  points at other RFCs, which an implementer will have to consult anyway.  
  IOW, this document seems to add to the list.

  No normative language is used, which is good from the point of view that 
  this document doesn't define a specification, but in some places the text 
  implies a requirement level, which may cause confusion -- again, the reader 
  will have to consult the existing RFCs...

  The document itself recognizes the need to maintain it up to date: "This 
  document will be update to reflect new or changed requirements as these 
  RFCs are updated, or new RFCs are written." (s/be update/be updated)  
  And the difficulty in doing so is evident in the fact that one of the 
  referenced RFCs is already obsolete, but the text doesn't reflect that.

[Even though I'm ABSTAINing, I have a couple of comments.]

(1) This paragraph from §4.3 caught my eye...

   If there are valid objects in a publication point that are not
   present on a Manifest, [RFC6486] does not mandate specific RP
   behavior with respect to such objects.  However, most RP software
   ignores such objects and the authors of this document suggest this
   behavior be adopted uniformly.

...because in it the authors get away from pointing at the existing RFCs to suggest a behavior.  That clearly should not be the job of this document.

(2) Nits:

s/RPKI make use/RPKI makes use

s/one of necessary/one of the necessary

s/RP is required perform/RP is required to perform

s/[RFC8208]and/[RFC8208] and

(Alissa Cooper; former steering group member) No Objection

No Objection (2020-04-09)
I agree with Alvaro about Section 4.3.

(Barry Leiba; former steering group member) No Objection

No Objection ()
No email
send info

(Deborah Brungard; former steering group member) No Objection

No Objection ()
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ()
No email
send info