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

["Weiqiang Sun" <[e-mail]>]

Hi Tom,

[Seems that the secdir review email does not reach my mailbox. I am 
following up this thread manually. Hope it gets sorted correctly.]

Thanks for your comments. Please see inline for our responses/proposed 
changes.

>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.)
Yes we do have this.
   This document provides a series of performance metrics to evaluate
   the dynamic Label Switched Path (LSP) provisioning performance in
   GMPLS networks, specifically the dynamic LSP setup/release
   performance.  These metrics can be used to characterize the features
   of GMPLS networks in LSP dynamic provisioning.

>
>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?
For the security consideration section, we propose the following text.
Hope it is clearer.

16.  Security Considerations

   Samples of the metrics can be obtained in either active or passive
   manners.

   In active measurement, ingress nodes inject probing messages into the
   control plane.  Since the measurement endpoints must be conformant to
   signaling specifications and behave as normal signaling endpoints, it
   will not incur other security issues than normal LSP provisioning.
   However, the measurement parameters must be carefully selected so
   that the measurements inject trivial amounts of additional traffic
   into the networks they measure.  If they inject "too much" traffic,
   they can skew the results of the measurement, and in extreme cases
   cause congestion and denial of service.

   When samples of the metrics are collected in a passive manner, e.g.,
   by monitoring the operations on real-life LSPs, the implementation of
   the monitoring and reporting mechanism must be careful so that they
   will not be used to attack the control plane.  A typical
   implementation may use the Management Information Base (MIB) to
   collect/store the metrics and access to the MIB is limited to the
   Network Management Systems (NMSs).  In this case, passive monitoring
   will not incur other security issues than implementing the MIBs and
   NMSs.  If an implementation chooses to expose the performance data to
   other applications, then it must take into account the possible
   security issues it may face.  For example, when exposing the
   performance data through SNMP, certain authentication method should
   be used to ensure that the entity maintaining the performance data
   are not subject to unauthorized readings and modifications.  Rate
   limiting on the performance query may also be desirable to reduce the
   risk that the entity maintaining the performance data are overwhelmed
   by too much query requests.  It is RECOMMENDED that implementers
   consider the security features as provided by the SNMPv3 framework
   (see [RFC3410], section 8), including full support for the SNMPv3
   cryptographic mechanisms (for authentication and privacy).

   Besides, the security considerations pertaining to the original RSVP
   protocol [RFC2205] and its TE extensions [RFC3209] also remain
   relevant.

Thanks again,
Weiqiang