[Last-Call] Artart last call review of draft-ietf-sidrops-roa-considerations-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Jim Fenton
Review result: Almost Ready

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



-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux