Skip to main content

Last Call Review of draft-ietf-sidrops-roa-considerations-07
review-ietf-sidrops-roa-considerations-07-artart-lc-fenton-2023-02-17-00

Request Review of draft-ietf-sidrops-roa-considerations
Requested revision No specific revision (document currently at 08)
Type IETF Last Call Review
Team ART Area Review Team (artart)
Deadline 2023-02-24
Requested 2023-02-10
Authors Zhiwei Yan , Randy Bush , Guanggang Geng , Ties de Kock , Jiankang Yao
I-D last updated 2023-08-23 (Latest revision 2023-04-25)
Completed reviews Rtgdir IETF Last Call review of -07 by Carlos Pignataro (diff)
Artart IETF Last Call review of -07 by Jim Fenton (diff)
Genart IETF Last Call review of -07 by Dale R. Worley (diff)
Secdir IETF Last Call review of -07 by Sean Turner (diff)
Assignment Reviewer Jim Fenton
State Completed
Request IETF Last Call review on draft-ietf-sidrops-roa-considerations by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/u5jsVYc221FPTkVsJm5WweRqe3M
Reviewed revision 07 (document currently at 08)
Result Almost ready
Completed 2023-02-17
review-ietf-sidrops-roa-considerations-07-artart-lc-fenton-2023-02-17-00
I am the assigned ARTART reviewer for this draft. Please note that while I have
experience with PKI in general, I am not familiar with specific aspects of RPKI
or the use of ROAs in routing authorization.

Substantive comments:

Section 3 paragraph 2: "Certification Authority (CA) certificate issued by a
parent CA": does this apply to end-entity certificates as well? From my read of
RFC 6480 these directly sign the ROA and it seems like they might more
frequently change.

Section 3 paragraph 2: "may be replaced by the parent at any time": RFC 6480
doesn't mention replacement of certificates, but does talk about revocation.
Should this be "may be revoked..."?

Section 3 paragraph 3: Second word seems like a normative SHOULD and ought to
be in all caps.

Section 4 paragraph 2: "not recommended" seems normative and ought to be in all
caps.

Section 5 seems like it is discussing performance considerations, not security
considerations. Are there any aspects of this that would be better or worse in
the event of an attack?

General: Are there other approaches to this problem that don't involve creation
of a much larger number of ROAs (and corresponding end-entity certificates that
require management)? For example, if CAs reliably first issue new ROAs before
revoking an ROA containing more than one prefix, it seems like the problem
being addressed here would be avoided. Perhaps this is the situation described
in the third paragraph of Section 3. I presume the WG has discussed this, and
studied the growth in ROAs that would result.

Editorial comments:

Title: I think "Avoidance of ROA..." would read better than "Avoidance for
ROA..."

Several places: which -> that. The RFC Editor will probably correct these, as
they have for my drafts.

Section 1 paragraph 2: one single AS -> a single AS

Section 1 paragraph 3: for choosing to issue -> recommending the issuance of

Section 3 paragraph 2: is not yet discovered -> has not yet been discovered

Section 3 paragraph 4: would only affected -> would only be affected

Section 4 paragraph 1: "Unless the CA has good reasons to the contrary": This
is basically the definition of the SHOULD in the following clause. Is this
necessary? Also, consider: the issued ROA -> issued ROAs

Section 4 paragraph 2: Protoco -> Protocol