Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT)

Al Morton <> Fri, 06 April 2012 15:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDF6C21F85C2; Fri, 6 Apr 2012 08:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.196
X-Spam-Status: No, score=-104.196 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v45Mt3t9uu6I; Fri, 6 Apr 2012 08:54:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E675A21F85A1; Fri, 6 Apr 2012 08:54:09 -0700 (PDT)
Received: from unknown [] (EHLO by over TLS secured channel with ESMTP id (envelope-from <>); Fri, 06 Apr 2012 15:54:10 +0000 (UTC)
X-MXL-Hash: 4f7f11a26a92ad75-585a877889d8f4699ce311f12150af9cf856e916
Received: from (localhost.localdomain []) by (8.14.5/8.14.5) with ESMTP id q36Fs6kT029708; Fri, 6 Apr 2012 11:54:09 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q36Frx6a029576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Apr 2012 11:54:01 -0400
Received: from ( []) by (RSA Interceptor); Fri, 6 Apr 2012 11:53:18 -0400
Received: from (localhost.localdomain []) by (8.14.4/8.14.4) with ESMTP id q36FrInc008191; Fri, 6 Apr 2012 11:53:18 -0400
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id q36FrBRV007699; Fri, 6 Apr 2012 11:53:12 -0400
Message-Id: <>
Received: from ([](misconfigured sender)) by (mailgw1) with SMTP id <20120406155014gw1004or2ee>; Fri, 6 Apr 2012 15:50:16 +0000
X-Originating-IP: []
X-Mailer: QUALCOMM Windows Eudora Version
Date: Fri, 06 Apr 2012 11:54:19 -0400
To: Adrian Farrel <>, Samuel Weiler <>, The IESG <>
From: Al Morton <>
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_16846153==_"
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-RSA-Action: allow
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-AnalysisOut: [v=1.0 c=1 a=dit6Jc5sqrAA:10 a=PLurumnWQikA:10 a=ofMgfj31e3]
X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=48]
X-AnalysisOut: [vgC7mUAAAA:8 a=EMLI_BE5mvm9JbZNRLYA:9 a=oeBJXHtBx7puNK96VC]
X-AnalysisOut: [wA:7 a=CjuIK1q_8ugA:10 a=mYAOWqAtFUkA:10 a=zQP7CpKOAAAA:8 ]
X-AnalysisOut: [a=KI9qLmWpAAAA:20 a=bN6E18yrVWTlGgkc5MIA:9 a=cMiAqtFLv3t6Y]
X-AnalysisOut: [XRXfw8A:7 a=JlbW2Bu-4FEA:10 a=uOmZzfvve58A:10 a=ISSXQUU-yz]
X-AnalysisOut: [IA:10 a=Hz7IrDYlS0cA:10 a=gBHw4jxdwhUfQ-f6:21 a=mByhXr5mLi]
X-AnalysisOut: [flxYEd:21 a=bmb9Z_KCjwIdY-NzA44A:9 a=osKTAfFAxhsyI6CC-WoA:]
X-AnalysisOut: [7 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=vgu2m8Mm752vdwO0:2]
X-AnalysisOut: [1 a=Q5K-Iz6U6mBRZnxG:21]
Cc: "" <>, "Murphy, Sandra" <>, Dan Frost <>,,
Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Apr 2012 15:54:16 -0000

Hi Adrian and Sam,

This preliminary revision of the -rt-loss-draft addresses
DISCUSSes, Comments, Rtg-area and sec-dir reviews.
The diff to 03 and 04 prelim are attached.

Also, see replies below (to both Adrian's and Sandy's messages).


At 10:44 AM 4/6/2012, Adrian Farrel wrote:
>Adrian Farrel has entered the following ballot position for
>draft-ietf-ippm-rt-loss-03: Discuss
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>Please refer to
>for more information about IESG DISCUSS and COMMENT positions.
>The Routing Diretorate review by Dan Frost missed the IETF Last Call
>period by two days, but I would like the following points from his
>review to be considered as part of this Discuss. Other smaller issues
>are recorded as Comments.
> > General observation: It's not clear to me what the IPPM WG strategy
> > is for security considerations sections in metric definition
> > documents.  For example, the security section of this document more or
> > less repeats the one in (for example) RFC 2681, which itself
> > duplicates verbatim the one in RFC 2680, and the issues discussed are
> > general ones with measurement protocols rather than specific ones with
> > the metric that is the subject of the document.  There's probably a
> > better way to organize this.

Although IPPM has never formalized a strategy, we have been repeating
security material in metrics RFCs. This allows new folks to read
and improve the text, rather than be referred to a fixed reference.
It seems to work.

> > 3. Section 9.3 mentions the use of cryptographic hashing "to
> > discourage the kind of interference mentioned above"; while this
> > would mitigate the second form of interference, it wouldn't help
> > with the first.
>I would add that "discourage" might not be an appropriate word.

New paragraph addresses Sandy and Dan's points.

>Other comments coming from Dan Frost's review
> > 1. Although it's probably obvious to most readers, it would be helpful
> > to provide a brief informal definition of "round-trip loss" early in
> > the introduction.  A mention of the venerable "ping" procedure would
> > also not be amiss.

Did both.

> > 2. Most of the text seems to assume an "active" or test-based
> > measurement approach, but Section 9.2 refers to passive measurement.
> > It would be helpful to discuss the applicability of the latter
> > approach.

Clarified the scope for passive.

> > Nits:
> >
> > 1. The phrase "as immediately as possible" that appears a couple of
> > times in the text (and that seems to originate in RFC 5357) is a bit
> > unfortunate.  "Immediately" or "as quickly as possible" are better.

This odd turn of phrase resulted from many hours of discussion
dating back to TWAMP's development.  We wear the scar proudly.

> >
> > 2. Section 5.4, second paragraph: s/affects/effects/
> >
> > 3. Section 8, second paragraph: s/Two key features ... is described/
> >  Two key features ... are described/
> >
> > 4. Section 9.3, first paragraph:
> > OLD
> >  it is possible to change the processing of the packets (e.g.
> >  increasing or decreasing delay) that may distort the measured
> >  performance.
> > NEW
> >  it is possible to change the processing of the packets (e.g.
> >  increasing or decreasing delay) in a way that may distort the
> >  measured performance.
> > END

thanks for pointing out the above.


At 01:23 PM 3/15/2012, Murphy, Sandra wrote:
>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.
>The draft-ietf-ippm-rt-loss-03 draft defines a round trip loss 
>metric.  A round trip loss measurement capability is specified in 
>RFC5357 ("Two-Way Active Measurement Protocol (TWAMP)"), but no 
>metric has been defined in the defined RFC2330 framework.
>As this draft defines a new metric, not the means to implement 
>measurements with the metric, I do not see that security 
>considerations apply.  But I see no problem with discussion of the 
>considerations that should guide implementations.
>(Indeed, RFC2861 which defines a delay metric says much the same:
>    Conducting Internet measurements raises both security and privacy
>    concerns.  This memo does not specify an implementation of the
>    metrics, so it does not directly affect the security of the Internet
>    nor of applications which run on the Internet.  However,
>    implementations of these metrics must be mindful of security and
>    privacy concerns.)
>I have a few comments about the security considerations section.
>The section mentions both active and passive use of the metric.  But 
>the abstract and intro imply this metric is for use in TWAMP, which 
>is active.  Is use of the metric possible in passive measurements as well?

Yes, but it is beyond the scope for adding the many additional considerations
needed when using a passive scenario. However, we leave the door open
to do this work in the future.

>In section 9.3, it says:
>    It may be possible to identify that a certain packet or stream of
>    packets is part of a sample.  With that knowledge at the destination
>    and/or the intervening networks, it is possible to change the
>    processing of the packets (e.g. increasing or decreasing delay) that
>    may distort the measured performance.  It may also be possible to
>    generate additional packets that appear to be part of the sample
>    metric.  These additional packets are likely to perturb the results
>    of the sample measurement.
>    To discourage the kind of interference mentioned above, packet
>    interference checks, such as cryptographic hash, may be used.
>How would a simple crypto hash prevent either the distortion of 
>performance (delaying a packet will not change its hash) or the 
>injection of additional packets (a cryptographic hash can be 
>computed for the injected packets as well).
>RFC2861 mentions similar injection concerns and recommends:
>                    Authentication techniques, such as digital signatures, may
>    be used where appropriate to guard against injected traffic attacks.
>Is there reason to suggest authentication in this metric definition as well?

Yes, as you point out:

>   TWAMP provides (but does not mandate) both authentication and 
> encryption.  If TWAMP is the only use of the metric, those features 
> should be mentioned.  If TWAMP is just one important use of the 
> metric, it could be good to mention the features here.

The new paragraph mentions TWAMP as well, but it is only one of many
protocols that can/will make this measurement.