Skip to main content

Last Call Review of draft-ietf-ippm-model-based-metrics-10
review-ietf-ippm-model-based-metrics-10-secdir-lc-mandelberg-2017-03-15-00

Request Review of draft-ietf-ippm-model-based-metrics
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-03-14
Requested 2017-02-28
Authors Matt Mathis , Al Morton
I-D last updated 2017-03-15
Completed reviews Secdir Last Call review of -10 by David Mandelberg (diff)
Genart Last Call review of -10 by Robert Sparks (diff)
Genart Telechat review of -11 by Robert Sparks (diff)
Assignment Reviewer David Mandelberg
State Completed
Request Last Call review on draft-ietf-ippm-model-based-metrics by Security Area Directorate Assigned
Reviewed revision 10 (document currently at 13)
Result Has nits
Completed 2017-03-15
review-ietf-ippm-model-based-metrics-10-secdir-lc-mandelberg-2017-03-15-00
Hi,

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 experimental draft "provides a framework for designing suites of IP
diagnostic tests" to measure a network path's bulk transport capacity.

As mentioned in the security considerations, actual attempts at
measurement might be subject to manipulation by an attacker. As I
understand it, the framework in this document neither attempts to
prevent such attacks, nor makes them any more likely.

The only other relevant potential security issue I could think of is
whether measurement system(s) using this framework could be co-opted by
an attacker to cause a denial of service to a specific network path. I
think this would depend entirely on the implementation of a system
designed using the framework in this document, and is therefore pretty
far removed from this document itself. An attack like this also might
not be possible because of some part of the framework that I missed. So
I'll trust the authors' and/or working group's judgment on what to do
with this comment.

I think this draft is somewhere between (inclusive) Ready and Ready With
Issues, depending on how far off-base my point about denial of service
is. I'm leaning towards Ready.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/