[secdir] Review of draft-ietf-ippm-tcp-throughput-tm-12.txt

"Hilarie Orman" <hilarie@purplestreak.com> Mon, 25 April 2011 19:24 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfc.amsl.com
Delivered-To: secdir@ietfc.amsl.com
Received: from localhost (localhost []) by ietfc.amsl.com (Postfix) with ESMTP id 8F3A0E0691; Mon, 25 Apr 2011 12:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfc.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3FptqUzqYsS1; Mon, 25 Apr 2011 12:24:03 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com []) by ietfc.amsl.com (Postfix) with ESMTP id D1360E067C; Mon, 25 Apr 2011 12:24:02 -0700 (PDT)
Received: from mx02.mta.xmission.com ([]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1QERO1-0007y4-WE; Mon, 25 Apr 2011 13:23:58 -0600
Received: from 166-70-57-249.ip.xmission.com ([] helo=fermat.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1QERO1-0006Ng-1I; Mon, 25 Apr 2011 13:23:57 -0600
Received: from fermat.rhmr.com (localhost []) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3PJLkkd020708; Mon, 25 Apr 2011 13:21:46 -0600
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id p3PJLi6R020707; Mon, 25 Apr 2011 13:21:44 -0600
Date: Mon, 25 Apr 2011 13:21:44 -0600
Message-Id: <201104251921.p3PJLi6R020707@fermat.rhmr.com>
X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f
From: Hilarie Orman <hilarie@purplestreak.com>
To: ietf@ietf.org, secdir@ietf.org, draft-ietf-ippm-tcp-throughput-tm@tools.ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.mta.xmission.com; ; ; ip=; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ; ietf@ietf.org, secdir@ietf.org, draft-ietf-ippm-tcp-throughput-tm@tools.ietf.org
X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600)
X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com)
Subject: [secdir] Review of draft-ietf-ippm-tcp-throughput-tm-12.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Hilarie Orman <hilarie@purplestreak.com>
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: Mon, 25 Apr 2011 19:24:03 -0000

Security review of draft-ietf-ippm-tcp-throughput-tm-12.txt

Do not be alarmed.  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 review

>From the document Intro:
   This framework recommends a methodology for measuring TCP
   Throughput in order to provide meaningful results with respect to
   user experience.

I had a little bit of trouble understanding the purpose of the
document, having stumbled across these two statements which when
juxtaposed, seem to contradict one another:

  Note that the primary focus of this methodology is managed business 
  class IP networks; i.e. those Ethernet terminated services for which 
  organizations are provided an SLA from the network provider.  Because 
  of the SLA, the expectation is that the TCP Throughput should achieve
  the guaranteed bandwidth.  


  2. Scope and Goals
     - This methodology is not intended to measure TCP Throughput as part 
     of an SLA

[Remember the New Yorker magazine's "Our Forgetful Authors"?]

It is difficult to frame the security requirements for a measurement
framework, and this document does not try:

  6. Security Considerations

     The security considerations that apply to any active measurement of
     live networks are relevant here as well.  See [RFC4656] and

I am not sure what to infer from this statement.  That the RFCs define
all possible security requirements and considerations?  That their
definitions coincide with what the authors of the current document
recommend?  That the solutions defined by the other RFCs SHOULD be
be part of the framework defined by the current document?  MAY?  It

It's my recommendation that the security considerations be expanded
to explicitly list the security requirements for the framework.