[secdir] secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.txt

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 25 August 2010 14:44 UTC

Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2BF313A6ADC for <secdir@core3.amsl.com>; Wed, 25 Aug 2010 07:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.051
X-Spam-Status: No, score=-104.051 tagged_above=-999 required=5 tests=[AWL=2.548, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id nztTkcrp+eCL for <secdir@core3.amsl.com>; Wed, 25 Aug 2010 07:44:02 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU []) by core3.amsl.com (Postfix) with ESMTP id B555C3A6A47 for <secdir@ietf.org>; Wed, 25 Aug 2010 07:44:02 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu []) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o7PEiZmN023171 for <secdir@ietf.org>; Wed, 25 Aug 2010 10:44:35 -0400
Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU []) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id o7PEiW5D023152 for <secdir@PCH.mit.edu>; Wed, 25 Aug 2010 10:44:33 -0400
Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU []) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id o7PEhPnk028536 for <secdir@mit.edu>; Wed, 25 Aug 2010 10:44:32 -0400
X-AuditID: 12074425-b7cccae000005f17-da-4c752c472e88
Received: from hermes.jacobs-university.de ( []) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id F0.0D.24343.84C257C4; Wed, 25 Aug 2010 10:44:24 -0400 (EDT)
Received: from localhost (demetrius1.jacobs-university.de []) by hermes.jacobs-university.de (Postfix) with ESMTP id C07F9C0011; Wed, 25 Aug 2010 16:44:30 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([]) by localhost (demetrius1.jacobs-university.de []) (amavisd-new, port 10024) with ESMTP id crPJTk89XJV8; Wed, 25 Aug 2010 16:44:29 +0200 (CEST)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de []) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C42BC0009; Wed, 25 Aug 2010 16:44:23 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1E2521463693; Wed, 25 Aug 2010 16:44:02 +0200 (CEST)
Date: Wed, 25 Aug 2010 16:44:02 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: iesg@ietf.org, secdir@mit.edu, draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.all@tools.ietf.org
Message-ID: <20100825144402.GA1786@elstar.local>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Brightmail-Tracker: AAAAAA==
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Subject: [secdir] secdir review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.txt
X-BeenThere: secdir@ietf.org
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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: Wed, 25 Aug 2010 14:44:04 -0000


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.

The document describes how GMPLS can be used to manage Ethernet
Switched Paths and TE (traffic engineering) Service Instances. As you
will see below, I am not at all familiar with the terminology and the
technology and all the acronyms used in the document.

Security wise, this document essentially refers to other documents,
namely RFC 4872 amd RFC 4873. These documents again refer to other
documents and ultimately to IPsec as a security solution. If this is
correct, perhaps this could be made clearer so people like me do not
have to recursively resolve security considerations to find out how
things are protected.

The security considerations of this document also refer to 802.1AE
Media Access Control Security for the protection of "transport"
Ethernet. It is not clear what "transport" Ethernet is, perhaps it is
the Ethernet traffic carried over the paths. If my interpretation is
correct, I would argue that this pointer does not really belong into
the security considerations of this document since this specification
deals with a part of the signaling plane, not the data plane.

Section 5 states that "configuration should be consistent". What
happens security wise if configuration is not consistent? This might
deserve some discussion in the security considerations.

Editorial nits:

- Expland the acronym PBB-TE in the title

- Explain somewhere what I and B components are; what das I and B
  stand for?

- Explain what the TE in TESI stands for

- dangling ] in item 2) on page 11 (also make it clear that the RFC
  editor may need to adjust the value pending IANA's assignment

- It seems that several of the informative references are in fact
  normative; the citations in the document should all be carefully

- Can a reference be provided where the IEEE defines the set of
  reserved MAC addresses discussed in section 5.2?


Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
secdir mailing list