[secdir] SecDir Review of draft-ietf-bmwg-sip-bench-term-08

Yoav Nir <ynir@checkpoint.com> Wed, 23 January 2013 08:02 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 402B721F8945; Wed, 23 Jan 2013 00:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id h9IvfPR1tHuB; Wed, 23 Jan 2013 00:02:01 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com []) by ietfa.amsl.com (Postfix) with ESMTP id 326D721F8942; Wed, 23 Jan 2013 00:02:00 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r0N81sR7028289; Wed, 23 Jan 2013 10:01:54 +0200
X-CheckPoint: {50FF960A-0-1B221DC2-2FFFF}
Received: from IL-EX10.ad.checkpoint.com ([]) by DAG-EX10.ad.checkpoint.com ([fe80::80df:1c2c:3d29:3748%11]) with mapi id 14.02.0328.009; Wed, 23 Jan 2013 10:01:54 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org IESG" <iesg@ietf.org>, "draft-ietf-bmwg-sip-bench-term.all@tools.ietf.org" <draft-ietf-bmwg-sip-bench-term.all@tools.ietf.org>
Thread-Topic: SecDir Review of draft-ietf-bmwg-sip-bench-term-08
Thread-Index: AQHN+T/n2XmTl+Xf+0+ZDKEX2UwCQA==
Date: Wed, 23 Jan 2013 08:01:53 +0000
Message-ID: <4613980CFC78314ABFD7F85CC30277211198D6A5@IL-EX10.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30B55300D4BCDE4694820BAF62E73EC0@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] SecDir Review of draft-ietf-bmwg-sip-bench-term-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jan 2013 08:02:02 -0000

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:
   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."
   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.