[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?