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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 15 August 2012 12:22 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4591121F8487; Wed, 15 Aug 2012 05:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.503
X-Spam-Level:
X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDdckcDU-FhN; Wed, 15 Aug 2012 05:22:46 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9506221F85A7; Wed, 15 Aug 2012 05:21:41 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7FCLcEE002744; Wed, 15 Aug 2012 13:21:38 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (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" <adrian@olddog.co.uk>
To: "'Klaas Wierenga'" <klaas@cisco.com>, "'The IESG'" <iesg@ietf.org>, <secdir@ietf.org>, <draft-ietf-ccamp-dpm.all@tools.ietf.org>
References: <21E590DF-6035-4790-9171-9B46F0A849E7@cisco.com>
In-Reply-To: <21E590DF-6035-4790-9171-9B46F0A849E7@cisco.com>
Date: Wed, 15 Aug 2012 13:21:32 +0100
Message-ID: <0bc101cd7ae0$826fcb40$874f61c0$@olddog.co.uk>
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-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
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 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,
Adrian

> -----Original Message-----
> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Klaas
> Wierenga
> Sent: 15 August 2012 12:56
> To: The IESG; secdir@ietf.org; draft-ietf-ccamp-dpm.all@tools.ietf.org
> Subject: Secdir review of draft-ietf-ccamp-dpm-06
> 
> Hi,
> 
> 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..
> 
> 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
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.
> 
> Abstract:
> 
> 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,
> 
> Klaas=