Last Call Review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07
review-ietf-bmwg-ipv6-tran-tech-benchmarking-07-secdir-lc-yu-2017-05-11-00

Request Review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-05-02
Requested 2017-04-18
Requested by Al Morton
Draft last updated 2017-05-11
Completed reviews Secdir Last Call review of -07 by Taylor Yu (diff)
Genart Last Call review of -06 by Robert Sparks (diff)
Genart Telechat review of -07 by Robert Sparks (diff)
Assignment Reviewer Taylor Yu
State Completed
Review review-ietf-bmwg-ipv6-tran-tech-benchmarking-07-secdir-lc-yu-2017-05-11
Reviewed rev. 07 (document currently at 08)
Review result Has Nits
Review completed: 2017-05-11

Review
review-ietf-bmwg-ipv6-tran-tech-benchmarking-07-secdir-lc-yu-2017-05-11

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.

Summary: Ready with nits

The "SHOULD" in the following sentence doesn't seem like a valid RFC
2119 keyword usage to me.

   "Any implications for network security arising
   from the DUT/SUT SHOULD be identical in the lab and in production
   networks."

Please consider replacing it with lowercase "should".  (I read it as
predicting a correlation between the network security properties of the
DUT in the lab environment and its behavior in a production environment,
not as a guideline for implementors.)

Comments:

I'm not sure if you would consider this to be in scope, but might it be
useful to instrument implementations being benchmarked with runtime
error or anomaly detection?  (This would be in addition to the
uninstrumented "black-box" measurements.)  This could lead to detecting
security-relevant bounds checking or memory management errors induced by
aggressive benchmarking workloads, possibly identifying vulnerabilities
early enough to fix them before they're exploited.

Some kinds of instrumentation could have a substantial performance
impact, so it might be best to start testing well below the limits of
uninstrumented performance of the devices/systems under test.

Editorial:

Section 13 (Security Considerations) uses "SUT" without a prior
expansion.  Presumably it means "System Under Test" or "Software Under
Test"?