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

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 25 Apr 2011 13:21:44 -0600

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
comments.

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

 Introduction
...
  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
    [RFC5357].

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
depends?

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