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

Tom Yu <tlyu@MIT.EDU> Tue, 24 November 2009 05:33 UTC

Return-Path: <tlyu@MIT.EDU>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA83F3A6862; Mon, 23 Nov 2009 21:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.392
X-Spam-Level:
X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k4Zwj8uk68C; Mon, 23 Nov 2009 21:33:15 -0800 (PST)
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 02B313A67B4; Mon, 23 Nov 2009 21:33:14 -0800 (PST)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id nAO5WfrO005440; Tue, 24 Nov 2009 00:32:44 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id nAO5TLHo021954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Nov 2009 00:29:21 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id nAO5T9MX023407; Tue, 24 Nov 2009 00:29:09 -0500 (EST)
To: secdir@ietf.org, iesg@ietf.org, ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-lsp-dmpp@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Tue, 24 Nov 2009 00:29:09 -0500
Message-ID: <ldvr5rolcd6.fsf@cathode-dark-space.mit.edu>
Lines: 48
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
Subject: [secdir] secdir review of draft-ietf-ccamp-lsp-dppm-10
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: Tue, 24 Nov 2009 05:33:15 -0000

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?