Skip to main content

Last Call Review of draft-ietf-bmwg-sip-bench-meth-08
review-ietf-bmwg-sip-bench-meth-08-secdir-lc-eastlake-2013-08-02-00

Request Review of draft-ietf-bmwg-sip-bench-meth
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-01-30
Requested 2013-06-13
Authors Carol Davids , Vijay K. Gurbani , Scott Poretsky
I-D last updated 2013-08-02
Completed reviews Genart Last Call review of -08 by Miguel Angel García (diff)
Genart Last Call review of -11 by Tom Taylor (diff)
Secdir Last Call review of -08 by Donald E. Eastlake 3rd (diff)
Assignment Reviewer Donald E. Eastlake 3rd
State Completed
Request Last Call review on draft-ietf-bmwg-sip-bench-meth by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 12)
Result Has nits
Completed 2013-08-02
review-ietf-bmwg-sip-bench-meth-08-secdir-lc-eastlake-2013-08-02-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.  Document editors and WG chairs should treat these comments just
like any other last call comments. Sorry for how long it has taken me
to get to this review.

From a Security Considerations perspective, I believe this draft is
ready with relatively minor changes.

This draft draft-ietf-bmwg-sip-bench-meth-08 ("Methodology for
Benchmarking SIP Networking Devices") specifies methodology for
benchmarking SIP performance and cannot be really understood or
analyzed without reference to draft-ietf-bmwg-sip-bench-term-08
("Terminology for Benchmarking Session Initiation Protocol (SIP)
Networking Devices"). That terminology draft also specified
"Benchmarking Models", this is the network topology of various test
cases, which is more than I would expect in a "terminology"draft.

The Security Considerations sections of these two drafts are very
similar. Both indicate that testing would normally be done isolated
from the Internet or other production networks which eliminates
security threats. While such isolation would be helpful, it is very
hard to have truly isolated networks, at least if they are of any size
or complexity, given wide variety of means by which malware propagates
these days. I don't know anything about the prevalence of SIP related
malware but if it existed in a test rig I think it would likely to
corrupt benchmarking results. Some warning about this seems warranted
such as "To improve the fidelity of SIP benchmarking, appropriate
precautions should be taken against SIP related and other malware."

The Security Considerations sections in both drafts reference the same
other RFC Security Considerations Section: RFC 3261, RFC 3550, and RFC
3711. Those appear to be a good set of references and the Security
Considerations in RFC 3261 are pretty thorough.

The terminology draft Security Considerations section includes the
following: "Packets with unintended and/or unauthorized DSCP or IP
precedence values may present security issues.  Determining the
security consequences of such packets is out of scope for this
document." If it was thought worthy to include that in the terminology
draft, it seems like there is also a good case for including it in the
methodology draft.

Editorial

It is not entirely clear what "this" means in the first line of the
Security Considerations Section, I would suggest adding the words
"Benchmarking methodology" so it reads "Benchmarking methodology
documents of this type ..."

The RFC reference strings ("RFC3261" etc.) in the Security
Considerations section should be in square brackets.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 at gmail.com