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

Klaas Wierenga <klaas@cisco.com> Wed, 15 August 2012 11:56 UTC

Return-Path: <klaas@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3124C21F853B; Wed, 15 Aug 2012 04:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1sSsx4V+vmuY; Wed, 15 Aug 2012 04:56:15 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7B11621F853A; Wed, 15 Aug 2012 04:56:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=3064; q=dns/txt; s=iport; t=1345031775; x=1346241375; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=Q+8KZ+r1zZfmR18dLvZk1DUZ+49K2s/tlFgSPndQZIE=; b=hRdFcLx8e5pxT1CT1tcnTZTHYIxjzZmbhUVbSknpuxJqEb8BHgnf2rXX 9bl6o2Nbi8o5TkG6+sTeHHIEVx7YqDY8ydys9+ZYd/Dg12aLWFUfEgLI+ 8VLBgvDjHal6WKhCRAEbAYLWYM8pGdi75O0QMSTjHMAp3b6TWA4zObzWR w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAL+NK1CtJXG9/2dsb2JhbABFuh2BB4I5AYIkATSHa5kdoFaQfWADlUuOKoFmgmE
X-IronPort-AV: E=Sophos;i="4.77,772,1336348800"; d="scan'208";a="111778371"
Received: from rcdn-core2-2.cisco.com ([]) by rcdn-iport-7.cisco.com with ESMTP; 15 Aug 2012 11:56:15 +0000
Received: from rtp-vpn5-1828.cisco.com (rtp-vpn5-1828.cisco.com []) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7FBuCxg014292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Aug 2012 11:56:14 GMT
From: Klaas Wierenga <klaas@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <21E590DF-6035-4790-9171-9B46F0A849E7@cisco.com>
Date: Wed, 15 Aug 2012 13:56:12 +0200
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-ccamp-dpm.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
X-Mailer: Apple Mail (2.1485)
Subject: [secdir] Secdir review of draft-ietf-ccamp-dpm-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 15 Aug 2012 11:56:16 -0000


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.

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


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 me 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 successful 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 believe that any application would make use of these metrics beyond the binary value of "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.


This was very hard for me to parse. For starters, "this delay" does't seem to refer to any delay previously mentioned. In fact it took me a while to understand  that 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 the 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 reporting high delays? Can they prioritise their own traffic by making competitors for bandwidth think the data path is not there yet?

Hope this helps,