[secdir] Security area review of draft-ietf-mpls-tp-nm-framework-04

"pat cain" <pcain2@mail2.coopercain.com> Sat, 13 February 2010 00:26 UTC

Return-Path: <pcain2@mail2.coopercain.com>
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 CC0623A7924; Fri, 12 Feb 2010 16:26:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 P2Bd84pgrlXR; Fri, 12 Feb 2010 16:26:17 -0800 (PST)
Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id BA4A03A70D4; Fri, 12 Feb 2010 16:26:17 -0800 (PST)
Received: from familyroom (c-76-118-182-57.hsd1.ma.comcast.net [76.118.182.57]) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id o1D0RW8b004239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Feb 2010 18:27:36 -0600
Received: from familyroom by familyroom (PGP Universal service); Fri, 12 Feb 2010 19:27:33 -0500
X-PGP-Universal: processed; by familyroom on Fri, 12 Feb 2010 19:27:33 -0500
From: pat cain <pcain2@mail2.coopercain.com>
To: draft-ietf-mpls-tp-nm-framework@tools.ietf.org, draft-ietf-mpls-tp-nm-framework.chairs@tools.ietf.org
Date: Fri, 12 Feb 2010 19:27:29 -0500
Message-ID: <02e701caac43$55881b50$009851f0$@coopercain.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqsQ0lXYQjh7jT0SbSDo/DvdLO3gw==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] Security area review of draft-ietf-mpls-tp-nm-framework-04
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: Sat, 13 Feb 2010 00:26:18 -0000

Hi,

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.

This document provides the network management framework for the
Transport Profile for Multi-Protocol Label Switching (MPLS-TP).

This framework relies on the management terminology from the ITU-T to
describe the management architecture that could be used for an
MPLS-TP management network.

The Security Considerations section is the basis of my comment. I don't
think the first two sentences are sentences. At least I think they need to
be restated to clarify their meaning. The section states: " 
   Provisions to any of the network mechanisms designed to satisfy the
   requirements described herein need to prevent their unauthorized use
   and provide a means for an operator to prevent denial of service
   attacks if those network mechanisms are used in such an attack.

   Solutions need to provide mechanisms to prevent private information
   from being accessed by unauthorized eavesdropping, or being directly
   obtained by an unauthenticated network element, system or user."

Using terminology from the document, I think the paragraphs should really
say something to the effect of:
"Many of the EMF Interfaces (Section 2.3) are critical to proper NE
operation and 
need to be protected from denial of service conditions or attack. The EMF
Interfaces
that use or access private information should be protected from
eavesdropping or being
accessed by unauthorized network elements, systems, or users. 
"
Since the next part of the section points the reader to the ITU and other
RFC documents, it should flow okay.

Although I am by no means an MPLS expert, the rest of the document looked
fine.


[As a side note, normally the term 'unauthorized eavesdropping' is not used.
Eavesdropping is always performed by an unauthorized party; if they are
authorized it's called 'network monitoring'.  ;) ]

Pat Cain