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

["Adrian Farrel" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Klaas
> Wierenga
> Sent: 15 August 2012 12:56
> To: The IESG; [e-mail]; [e-mail]
> 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=