Subject: [secdir] secdir review of draft-ietf-ccamp-lsp-dppm-10

From: Tom Yu <[email-masked]>
Date: Tue, 24 Nov 2009 00:29:09 -0500

This document appears to define a set of performance metrics for
characterizing dynamic LSP provisioning performance in GMPLS networks.

Editorial:

The document claims (in the Introduction) that these metrics
characterize the performance of the signaling protocol.  I find that
the metrics more accurately measure the performance of the LSP setup
and teardown operations, and are only tangentially related to the
performance of the signaling protocol (unless somehow the performance
of the signaling protocol implicitly includes the actions that the
routers take in response, in which case I think the document should
state it more plainly.)

Security:

[Most of these are probably minor points merely requiring clarifying
text.]

The Security Considerations section mentions the consequences of
active traffic injection into the control plane, including skewing the
results of measurements and causing congestion and denial of service.
If the injected control traffic is expected to have the potential
effect of enabling dramatically more data traffic, I think this effect
should also be included in the Security Considerations, perhaps with
advice to select probing control messages that do not materially alter
the flow of data channel traffic.

This document does not address security considerations related to the
protocols communicating of the results of the measurements, or of any
protocol used to request initiation of a measurement, perhaps because
this document does not specify such protocols.  I assume that these
any document that specifies such other protocols will cover those
security considerations, even if this document does not obviously
refer to such specifications.

On the other hand, if this document is intended as guidance for
protocol specifications that describe implementation of the
measurement of and communication of these metrics, perhaps it should
also outline the security considerations that those additional
protocol specifications should address.  For example, what sort of
authentication is required in a protocol that initiates a measurement
of these metrics?

It's not completely clear to me what sort of threat the passive
measurement scenario involves; perhaps a router could repeatedly and
with high frequency initiate LSP changes that overwhelm the monitoring
channel?