[secdir] draft-ietf-bmwg-sip-bench-meth-08 SECDIR Review

Donald Eastlake <d3e3e3@gmail.com> Sat, 27 July 2013 20:10 UTC

Return-Path: <d3e3e3@gmail.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 7FA5321F94FD; Sat, 27 Jul 2013 13:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id i4u6Idtm4+aX; Sat, 27 Jul 2013 13:10:07 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C6C3421F944C; Sat, 27 Jul 2013 13:10:07 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id wc20so406687obb.0 for <multiple recipients>; Sat, 27 Jul 2013 13:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ISPJFGCxcG4sT+zhvBdoj7XB37PkSv2f9VtVNeVDTpw=; b=GH+9TeTYlhyxhTpMYYOd+ssgXNdhCGoyRLNueBZRtuQWyzuPvHvfSDGvilA1ScqDdN DTDRxp8YdGkja252UFG7LWTdzhuoM883mVYN03CqyhhXH0669msV3FUQDn7iLkRvYgJ+ Xre6MewHxKZ0s3lyDkzK+2JWRNZj5spIcr37uETz5I6+xfdD3/QFNwRwxyLpe+RykeNs 08h8Xt7Mpem7nPoisWnoDsZ5/ce3RzjPjuMRdqn+kZ93NUNt6Z95PqPCpJoEvg8SmUtI eeyBVGgs9EK4KifjdClgMfVGq7DP3uXw00FzDhtXiDt044MBdlWidrxnvPV4zmxwRBAl Ch0A==
X-Received: by with SMTP id dt10mr17697219obc.46.1374955807295; Sat, 27 Jul 2013 13:10:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 27 Jul 2013 13:09:47 -0700 (PDT)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sat, 27 Jul 2013 16:09:47 -0400
Message-ID: <CAF4+nEEOcg5BYWw70wEcnSradyQ=kaRpSRxmNdcLojf+eB2zuA@mail.gmail.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-bmwg-sip-bench-meth.all@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [secdir] draft-ietf-bmwg-sip-bench-meth-08 SECDIR Review
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: Sat, 27 Jul 2013 20:10:08 -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.  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.


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.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA