Re: [secdir] Secdir review of draft-ietf-ccamp-dpm-06

"Adrian Farrel" <> Wed, 15 August 2012 12:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4591121F8487; Wed, 15 Aug 2012 05:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IDdckcDU-FhN; Wed, 15 Aug 2012 05:22:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9506221F85A7; Wed, 15 Aug 2012 05:21:41 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id q7FCLcEE002744; Wed, 15 Aug 2012 13:21:38 +0100
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q7FCLaJs002708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Aug 2012 13:21:37 +0100
From: "Adrian Farrel" <>
To: "'Klaas Wierenga'" <>, "'The IESG'" <>, <>, <>
References: <>
In-Reply-To: <>
Date: Wed, 15 Aug 2012 13:21:32 +0100
Message-ID: <0bc101cd7ae0$826fcb40$874f61c0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQK80gJ7ycw+TYBlnPK8G7KdDShhuJV8G7oA
Content-Language: en-gb
Subject: Re: [secdir] Secdir review of draft-ietf-ccamp-dpm-06
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: Wed, 15 Aug 2012 12:22:47 -0000

Hi Klaas,

Thanks for this. It came in after the end of IETF Last Call so the comments will
get fumbled a bit.

Authors: your I-D has gone forward for the IESG telechat on August 30th. If you
are able to revise the I-D to pick up the comments from Klaas and can get a new
version posted on or before August 23rd, please do so. Otherwise, please do not
update the document yet (to give the IESG a stable target) and we will handle
the comments after IESG review.

Many thanks,

> -----Original Message-----
> From: [] On Behalf Of Klaas
> Wierenga
> Sent: 15 August 2012 12:56
> To: The IESG;;
> Subject: Secdir review of draft-ietf-ccamp-dpm-06
> Hi,
> I have reviewed this document as part of the security directorate's ongoing
> to review all IETF documents being processed by the IESG.  These comments
> were written primarily for the benefit of the security area directors.
> editors and WG chairs should treat these comments just like any other last
> comments.
> This document describes a set of path delay metrics in GMPLS/MPLS-TE for
> troubleshooting the delay between completion of the signalling process and the
> data path establishment and is a such comprehensive. I do have however a
> number of fundamental and less fundamental questions that may be caused for
> my lack of familiarity with the topic at hand, so please indulge..
> Generic:
> The central goal of the document appears to be to remedy the fact that
> applications think that the data path is available whereas it is not. It is to
> completely unclear why:
> - the signalling process can not be changed to terminate only upon
availability of a
> data path or even easier
> - verifying the availability of the data path (send roundtrip packet, if
> ok)
> I can see that the metrics that you are defining may be of use in the control
> plane, but I fail to see how they may help the application, I find it hard to
> that any application would make use of these metrics beyond the binary value
> "is data path available". And that is what you cite as the reason for this
draft. So
> please expand the goal or argue why you need this set of metrics.
> Abstract:
> This was very hard for me to parse. For starters, "this delay" does't seem to
> to any delay previously mentioned. In fact it took me a while to understand
> it is referring to the time lapsed between finishing signalling and data path
> becoming available, I suggest rewording to make that more clear.
> Section  3 (overview):
> please expand RRFD, RSRD, PRFD, PSFD, PSRD on first use
> Section 5.3 (RRFD metric parameters):
> What is the unit of T? UTC?
> Section 5.6 (RRFD discussion):
> It seems to me that the delays that are introduced by the time to propagate
> signal, the delay introduced by the interfaces etc. are well in the various
> milliseconds range, doesn't that invalidate any measurements in that range? Or
> can you argue that those introduce a fixed delay so that variations are due to
> what you are trying to measure.
> The same holds for the other metrics
> Section 11.2 (median of metric):
> It seems to me that the median is of little value if the majority of the
values are
> undefined, is that why you have tyne failure count? If so, please say so.
> Section 12 (Security considerations):
> It is unclear to me what the result of an evil MitM manipulating values of the
> metrics could do. Can they for example introduce a denial of service by
> high delays? Can they prioritise their own traffic by making competitors for
> bandwidth think the data path is not there yet?
> Hope this helps,
> Klaas=