Skip to main content

Last Call Review of draft-ietf-sidr-adverse-actions-03
review-ietf-sidr-adverse-actions-03-secdir-lc-weis-2017-01-05-00

Request Review of draft-ietf-sidr-adverse-actions
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-01-10
Requested 2016-12-20
Authors Stephen Kent , Di Ma
I-D last updated 2017-01-05
Completed reviews Secdir Last Call review of -03 by Brian Weis (diff)
Genart Last Call review of -03 by Dan Romascanu (diff)
Opsdir Last Call review of -03 by Qin Wu (diff)
Assignment Reviewer Brian Weis
State Completed
Request Last Call review on draft-ietf-sidr-adverse-actions by Security Area Directorate Assigned
Reviewed revision 03 (document currently at 04)
Result Has nits
Completed 2017-01-05
review-ietf-sidr-adverse-actions-03-secdir-lc-weis-2017-01-05-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

As stated in the Abstract, this document analyzes actions by or against a CA or
independent repository manager in the RPKI that can adversely affect the
Internet Number Resources (INRs) associated with that CA or its subordinate
CAs. Put another way, it documents threats to the RPKI/BGPSEC PKI, in which
there are unique threats to the PKI that can adversely affect Internet routing.
The document is well written and internally consistent. The Security
Considerations section is adequate.

I consider this draft Ready to publish, but here are a couple of discretionary
comments for the authors.

1. The end of section 2 says "Note that not all adverse actions may be
addressed by this taxonomy.”. The phrase “addressed by” confused me a little
bit, as it implies some recommendation or remediation — which this document
does not attempt to do. This might be more clearly worded as “described by” or
“included in”.

2. In section 2.1, A-1.2 (Suppression), it seems that suppression could result
in the CA certificate intended to be replaced to expire before an intended CA
rollover operation happens due to thes suppressed replacement certificate.
Perhaps it is not noted because this threat is not specific to RPKI/BGPSEC, but
it could be another serious suppression affecting Internet routing.

Brian