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

Al Morton <> Sun, 08 April 2012 00:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 072B921F85B4; Sat, 7 Apr 2012 17:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.796
X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[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 y7+YOHWlnKDz; Sat, 7 Apr 2012 17:18:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 262B521F85A8; Sat, 7 Apr 2012 17:18:55 -0700 (PDT)
Received: from unknown [] (EHLO by over TLS secured channel with ESMTP id (envelope-from <>); Sun, 08 Apr 2012 00:18:55 +0000 (UTC)
X-MXL-Hash: 4f80d96f7d417c7a-00de33143131ed23b01daebd12e059f8ad09cbab
Received: from (localhost.localdomain []) by (8.14.5/8.14.5) with ESMTP id q380IsWY001138; Sat, 7 Apr 2012 20:18:54 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q380InPA001115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Apr 2012 20:18:50 -0400
Received: from ( []) by (RSA Interceptor); Sat, 7 Apr 2012 20:18:10 -0400
Received: from (localhost.localdomain []) by (8.14.4/8.14.4) with ESMTP id q380I9Dx008153; Sat, 7 Apr 2012 20:18:10 -0400
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id q380I1Wi007745; Sat, 7 Apr 2012 20:18:02 -0400
Message-Id: <>
Received: from ([](misconfigured sender)) by (mailgw1) with SMTP id <20120408001459gw1004or31e>; Sun, 8 Apr 2012 00:15:05 +0000
X-Originating-IP: []
X-Mailer: QUALCOMM Windows Eudora Version
Date: Sat, 07 Apr 2012 20:19:04 -0400
To:, 'Samuel Weiler' <>, 'The IESG' <>
From: Al Morton <>
In-Reply-To: <07e001cd14e0$41b408c0$c51c1a40$>
References: <> <> <07e001cd14e0$41b408c0$c51c1a40$>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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=u9h4ZY5ZTRIA:10 a=ZswZ2TFLv48A:10 a=ofMgfj31e3]
X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8]
X-AnalysisOut: [UMqPvVAA==:17 a=yHZoGYZOrkWJAXPRocgA:9 a=7ZIazfIgaURd4f79Y]
X-AnalysisOut: [E4A:7 a=CjuIK1q_8ugA:10]
Cc:,, 'Dan Frost' <>, "'Murphy, Sandra'" <>,
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: Sun, 08 Apr 2012 00:18:56 -0000

Hi Adrian,

Thanks for your reply.
We've narrowed the discussion down to two issues.
see below,

At 01:02 PM 4/7/2012, Adrian Farrel wrote:
> > > > 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.
>I can see how that would lead to the verbatim reproduction of text. I have no
>problem with that per se, but I worry that the process has become formulaic
>without any new consideration of security for the specific document in hand.
>If you tell me that this is adequate for this document and no refinement is
>needed in this case, I will clear and let the Security ADs and 
>Directorate worry
>about the security details.

I think it is. We are essentially conducting a two-way version of RFC 2680
(one-way loss), so all the same considerations apply. We have exposure in
two (possibly different) paths, but the threats are the same.

> > > > 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.
>Well, this is only a Comment, and you do not have to address it, but "as
>immediately as possible" is hogwash. It is a butchery of the 
>language and means
>In fact, and as a general principle of writing standards, even "as quickly as
>possible" would be poor. The English would be fine, but it is a subjective
>statement against which conformance cannot be measured.

Under typical protocol development circumstances, we could write a
real requirement:
         The response MUST be prepared and sent on the wire in <X seconds.

But that's not the case here.  Instead we have desire that the response
will be sent immediately, yet we understand that measurement systems will:

  - occasionally execute higher priority processes that delay the response
    (processing routing updates comes to mind)
  - carry 2 time stamps that allow the tester to determine if the response
    was generated fast enough for the intended purpose
  - serve purposes with greater or lesser need for immediacy
  - either meet the variable needs for measurement immediacy or not, and
    this is a judgement that can be made on each and every measurement packet

Is it useful to explain some/all of this in the memo?