Last Call Review of draft-ietf-bmwg-sip-bench-term-08
review-ietf-bmwg-sip-bench-term-08-secdir-lc-nir-2013-01-25-00
| Request | Review of | draft-ietf-bmwg-sip-bench-term |
|---|---|---|
| Requested revision | No specific revision (document currently at 12) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2013-01-30 | |
| Requested | 2013-01-17 | |
| Authors | Carol Davids , Vijay K. Gurbani , Scott Poretsky | |
| Draft last updated | 2013-01-25 | |
| Completed reviews |
Genart Last Call review of -11
by
Suresh Krishnan
(diff)
Secdir Last Call review of -08 by Yoav Nir (diff) Opsdir Last Call review of -11 by Scott O. Bradner (diff) |
|
| Assignment | Reviewer | Yoav Nir |
| State | Completed | |
| Review |
review-ietf-bmwg-sip-bench-term-08-secdir-lc-nir-2013-01-25
|
|
| Reviewed revision | 08 (document currently at 12) | |
| Result | Ready | |
| Completed | 2013-01-25 |
review-ietf-bmwg-sip-bench-term-08-secdir-lc-nir-2013-01-25-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.
Summary: I think it is ready for publication.
This informational document describes terminology for benchmarking of the SIP
protocol.
As the document mentions in the Security Considerations section, benchmarking
activity does not affect the security of the Internet or of corporate networks,
because it is carried on in closed environments. I think it should be
explicitly said that such activity should not be done on corporate networks for
fear of causing DoS to other components, but this is an appropriate comment for
the companion methodology document, not for this one.
In fact, a terminology document should not affect security, as it is not
something that is "implemented" or "deployed". Having said that, I found some
definitions in section 1, and in section 3, and models for benchmarking in
section 2.2. All these seem appropriate. I was surprised to find a lot of MUSTs
and SHOULDs in section 2.1 ("Scope"). Most of them could be re-written as
definitions. For example: OLD:
o The DUT MAY include an internal SIP Application Level Gateway
(ALG), firewall, and/or a Network Address Translator (NAT). This
is referred to as the "SIP Aware Stateful Firewall."
NEW:
o A DUT that includes an internal SIP Application Level Gateway
(ALG), firewall, and/or a Network Address Translator (NAT)
is referred to as the "SIP Aware Stateful Firewall."
But that is a stylistic issue that I don't feel strongly about. OTOH consider
this example:
o The DUT or SUT MUST NOT be end user equipment, such as personal
digital assistant, a computer-based client, or a user terminal.
This is a real requirement, so why MUST benchmarking not be done on a personal
computer? The document doesn't say, and I think this should be part of the
methodology document, not terminology.
I also noticed that this document makes extensive use of diagrams. For the most
part, those are acceptable usage of 72-column ASCII art, although I think this
document is a great example of why we need better diagramming formats in the
future RFC format. This is especially evident in figure 12 on page 17.
Yoav