Last Call Review of draft-ietf-sidr-bgpsec-reqs-11
review-ietf-sidr-bgpsec-reqs-11-secdir-lc-montville-2014-07-03-00

Request Review of draft-ietf-sidr-bgpsec-reqs
Requested rev. no specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-07-03
Requested 2014-06-26
Draft last updated 2014-07-03
Completed reviews Genart Last Call review of -11 by Francis Dupont (diff)
Secdir Last Call review of -11 by Adam Montville (diff)
Assignment Reviewer Adam Montville
State Completed
Review review-ietf-sidr-bgpsec-reqs-11-secdir-lc-montville-2014-07-03
Reviewed rev. 11 (document currently at 12)
Review result Has Nits
Review completed: 2014-07-03

Review
review-ietf-sidr-bgpsec-reqs-11-secdir-lc-montville-2014-07-03

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.

This document is ready with (potential) nits.  When reading this requirements draft I tried to keep an eye on measurability: When implementing drafts are created, how will they be objectively measured to meet the requirements?

Potential Nits:

1. Requirements 3.1 and 3.2 indicate that a “strong level of certainty” is needed, but does not define what that means in context.  This may be common knowledge within the community, however. 

2. Requirement 3.13 indicates that BGPsec “MUST provide backward compatibility”, but we are left to assume that downgrade prevention is enabled.  We might assume that it is, but it’s probably better not to.  Perhaps adding a statement to the effect of “MUST provide backward compatibility…. but also allow for strict BGPsec adherence” or something similar.  I also recognize that there may be obviating circumstances behind this requirement (i.e. it’s not practical to *not* allow strict adherence), which I might also assume as a reader.

3. Requirement 3.18 uses the phrase “necessary degree of assurance” regarding validity of certain data, and I don’t know what that is really saying.  Is this really a statement of integrity and authenticity or something else?  What is the gradient of assurance and how do we know when we’ve reached that “necessary degree”?

4. In the Security Considerations section (6) it seems that more explanation pertaining to the following sentence might be warranted: “The data plane might not follow the control plane.”  This might be readily apparent to anyone in-the-know, but it’s not so apparent to those not-in-the-know.


Regards,

Adam




Attachment:


signature.asc




Description:

 Message signed with OpenPGP using GPGMail