[secdir] Secdir review of draft-ietf-pce-monitoring-07.txt

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Wed, 06 January 2010 11:44 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 9CE2528B23E for <secdir@core3.amsl.com>; Wed, 6 Jan 2010 03:44:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id jd48087thP7p for <secdir@core3.amsl.com>; Wed, 6 Jan 2010 03:44:49 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net []) by core3.amsl.com (Postfix) with SMTP id 93DA23A68C8 for <secdir@ietf.org>; Wed, 6 Jan 2010 03:44:48 -0800 (PST)
Received: (qmail invoked by alias); 06 Jan 2010 11:44:45 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [] by mail.gmx.net (mp008) with SMTP; 06 Jan 2010 12:44:45 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/IpbFWMNHIFVvAmrypD8niX71y8gQtTve4clZrCK Bgcq3ytA1WScsn
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
To: <secdir@ietf.org>
Date: Wed, 6 Jan 2010 13:48:37 +0200
Message-ID: <005e01ca8ec6$3019dab0$02ffa8c0@nsnintra.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcqOxi6lIVdjFXjoRN6XhquwvXhi9w==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.57
Cc: y.ikejiri@ntt.com, jeanlouis.leroux@orange-ftgroup.com, jpv@cisco.com
Subject: [secdir] Secdir review of draft-ietf-pce-monitoring-07.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 06 Jan 2010 11:44:50 -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.

What does the document do? 

My understanding is that the document defines some payloads for obtaining
information about control plane elements (namely about Path Computational
Elements). The obtained information includes 'Liveness', 'Processing Time',
and 'Overload'. The document does not describe mechanisms for obtaining
information about the data plane elements, as far as I can tell. 

Collecting information about control plane elements is not uncommon
(although other approaches are typically used, such as SNMP MIBs). 

There is often a different philosophy when it comes to writing a
specification. Some people believe that it is sufficient to just define the
packet on the wire (and a minimum of message processing rules) and then
there are folks who are more interested in defining the behavior and
algorithms. Here the former approach was selected and there might be some
problems with doing that (see comments below). 

(Minor note: A figure or an example would have really helped me to
understand this document.)

-- Technical Issues 

The Monitoring-id-number is described as: 

   Monitoring-id-number (32 bits): The monitoring-id-number value
   combined with the PCEP-ID of the PCC identifies the monitoring
   request context.  The monitoring-id-number MUST start at a non-zero
   value and MUST be incremented each time a new monitoring request is
   sent to a PCE.  Each increment SHOULD have a value of 1 and may cause
   a wrap back to zero.  If no reply to a monitoring request is received
   from the PCE, and the PCC wishes to resend its path computation
   monitoring request, the same monitoring-id-number MUST be used.
   Conversely, a different monitoring-id-number MUST be used for
   different requests sent to a PCE.  The path computation monitoring
   reply is unambiguously identified by the monitoring-id-number and the
   PCEP-ID of the replying PCE.  A PCEP implementation SHOULD checkpoint
   the Monitoring-id-number of pending monitoring requests in case of
   restart thus avoiding the re-use of a Monitoring-id-number of an in-
   process monitoring request.

I understand that a sender may want to match requests against responses even
if the responses alone should provide already sufficient information so that
the matching to the request becomes irrelevant. 

But what is the reason to demand a specific way to increment the
Monitoring-id-number? The sender only needs to avoid sending a request with
the same monitor-id-# already used in an previously sent request where the
response is still pending. Why would someone want to re-send the request
with the same number again? Wouldn't this be largely irrelevant? 

>From the PROTO writeup I can read that there are three independent
When I read through the Section 4.1 about the MONITORING object and the
flags that are defined I have some doubts how they can interwork. Just to
give you an example. I (PCE element of domain A) send a request for
monitoring and, for example, set the flag "General". This flag is defined in
the document as: 

   G (General) - 1 bit: when set, this indicates that the monitoring
   request is a general monitoring request.  When the requested
   performance metric is specific, the G bit MUST be cleared.  The G bit
   MUST always be ignored in a PCMonRep or PCRep message.

So, another PCE element in domain B is now receiving this request and is
supposed to include something in the reply message a little later. So, what
would this be? Where does an implementer find a precise description of what
has to be done to fullfill this request? 

The same is true for the other flags as well. Another example: "Processing
Time" ... is set to indicate that the
   processing times is a metric of interest. Section 4.3 provides a bit more
details but stops more or less when it comes to the real meat with something
like " out of the scope of this document". 
I am not sure how to get meaningful measurement results at different PCE
elements (potentially provided by different vendors). What conclusions could
I then draw from the information that comes back with the response message?
The same is true for the OVERLOAD Object. 

So, while the authors (and the group) may believe that they have indeed
developed a standard it will not lead to interoperability without a number
of other things happening. I would at least appreciate a discussion in the
document (maybe related to operational considerations) that the values are
only meaningful if the entities operating the PCEs have a way to agree on
the same mechanism to perform the value calculation. Typically, this will
not easily work in a multi-vendor fashion. So, I believe that the authors
might have had another document in mind in the future that actually provides
the algorithms. This would then raise the question of the usefulness of the
flags if the calculation of the values are done in many differents. Example.
I could imagine that the overload being calculated in, for example, 5
different ways. Vendor A supports only 2 and vendor B supports 4 different
algorithms but there is only one flag to indicate "overload". 

-- Specification Writing Style

Below I list two examples where I had hoped for a stricter style:

4.1.  MONITORING Object

   The MONITORING object MUST be present within PCMonReq and PCMonRep
   messages ("out of band" monitoring requests) and MAY be carried
   within PCRep and PCReq messages ("in band" monitoring requests).
   There SHOULD NOT be more than one instance of the MONITORING object
   in a PCMonReq or PCMonRep message: if more than one instance of the
   MONITORING object is present, the recipient MUST process the first
   instance and MUST ignore other instances.

Why couldn't you say that there MUST only be one instance of the MONITORING 
object in the message. Everything else is an error (and you already have an
error message for that).
  I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message
   and that message does not trigger any policy violation, but the PCE
   cannot provide any of the set of requested performance metrics for
   unspecified reasons, the PCE MUST set the I bit.  The I bit has no
   meaning in a request and SHOULD be ignored on receipt.

If you say "SHOULD" in the last sentence then you have to say what happens
In this specific case I believe you would just put a MUST in there. 

Additionally, the document defines multiple ways to accomplish the same
effect on how monitoring takes place (In-band vs. out-of-band requests). Is
there some text that could be referenced to give some guides on when to use

For some reason you decided to re-use the same object for the request and
the response. This typically leads to a more complex description because the
semantic of the object content is different in the two directions. 

-- Operations & Management 

How does the information being collected here related to other mechanisms to
potentially collect similar information? For example, network management
systems might collect information already and two systems collect lead to
conflicting conclusions. 

Wouldn't it be good to discuss how the monitoring requests are treated
differently from any other request. Particularly for the overload handling
request this would be interesting. You don't want to the monitoring starve
because the request is stuck in the queues somewhere. 

The document does not discuss what is actually being done with the collected
information. Obviously, there is a lot of potential for messing up the

-- Security 

The description focuses on securing communication. With the scope of the
document this seems to be fine. However, the real security problems will
show up when an adversary is able to control one of the PCE elements and is
therefore able to impact larger parts of the network. On the other hand,
adversaries could have a huge impact already without this specific extension
being defined. A PCE represents a single point of failure and a nice target.

-- IANA Considerations

To help IANA it is always useful to state whether you enter new values into
an existing registry (and where that registry has initially been defined) or
whether you create a new registry (and what the policy is). 

* The new PCEP messages are being added to an existing registry (one that
was created with [RFC5440]). 
* The new PCEP objects are also added to an existing registry. Most likely
one that was also created by [RFC5440].
* The same is true for the new Error-Values. Sentences like "A registry was
created for the Error-type and Error-value of the PCEP Error Object." are
* Then, you create a new registry for a few other items. You may want to
reference http://tools.ietf.org/html/rfc5226. Are you sure that you really
want to put the bar so high for adding new entries to the registry, namely
"IETF review"? I would have said that "Specification Required" is more than
enough. You might also want to indicate whether bits can be re-assigned, the
semantic updated, etc. For example, assume that you revise the RFC to
strengthen the description. Under what conditions would it be OK to just
update the existing registry entries and under what conditions would you
need new entries? Because of the encoding you have chosen you have some
space constraints. You also say that "Each bit should be tracked with the
following qualities:". Why "should"? Just indicate what has to be included
in the registry. Additionally, I believe the second column isn't really a
description but rather a label. 

-- Editorial

s/section Section 4.1/Section 4.1

In general, always write "Section X" instead of "section X". 
Capitalize headings. Example: s/Path Computation Monitoring messages/Path
Computation Monitoring Messages