[secdir] secdir review of draft-ietf-ccamp-mpls-tp-cp-framework-05

Barry Leiba <barryleiba@computer.org> Wed, 02 February 2011 21:34 UTC

Return-Path: <barryleiba@gmail.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 91DB13A6DD9; Wed, 2 Feb 2011 13:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.864
X-Spam-Level:
X-Spam-Status: No, score=-102.864 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 1BY8kNGGXFg1; Wed, 2 Feb 2011 13:34:28 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 95C373A6D79; Wed, 2 Feb 2011 13:34:28 -0800 (PST)
Received: by iyi42 with SMTP id 42so426551iyi.31 for <multiple recipients>; Wed, 02 Feb 2011 13:37:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=3kyQdEA9Yyvv9WlqUDOvR+JOquSLuhn8020o+FmSF50=; b=DojnwYAyoaeB9ygOXONN2Zz59sl3lzFWb/9Da/Wz7+y8FlVPW008+VT/deqyT/nKRe UQSabPHgbesAoauEBfA/4GtQH1ObyyivXTVBhZL5aljcqOa4w2eEo2uq5szfJ1ri6lVN Ft4E+9gUNAiP36mrN36Zu0brQ9yR/OnNwullE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=E79TZsnfBfXr6Cc/EOdA5Zgcwi+YBe21rSiQhjP/rCVXvHGKjLfgDXqfNN77bAQ9dw Lec4bM2EdyMijR2G1vRWawdmVKn+0dvZfxPI+JorNniTOQ5usOk9dttMl3kqr/dpjfqJ xHKqWWSw/3HYGzr1fmtuY7IRAaUDz72S5dufw=
MIME-Version: 1.0
Received: by 10.231.208.8 with SMTP id ga8mr10642993ibb.1.1296682668931; Wed, 02 Feb 2011 13:37:48 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.231.34.13 with HTTP; Wed, 2 Feb 2011 13:37:48 -0800 (PST)
Date: Wed, 2 Feb 2011 16:37:48 -0500
X-Google-Sender-Auth: 0dzHPrKPHrlvb6E5GoRoCiYmq0w
Message-ID: <AANLkTi=EL2GqrOvePsPoiVZxrbRyFyCckOuYbLE+QCqS@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, secdir@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: IESG <iesg@ietf.org>
Subject: [secdir] secdir review of draft-ietf-ccamp-mpls-tp-cp-framework-05
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: Wed, 02 Feb 2011 21:34:29 -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.

In particular, I don't know a lot about MPLS, whatever "TP"s and "G"s
and "PWE"s are attached to it.  I've tried to read this from a
security point of view only.  The GenART review has given an excellent
editorial look at the document, so I won't try to repeat that.

I have only one concern, from the security viewpoint, and I'm not sure
how much of a concern it is.
Sections 2.1 to 2.3 list more than 130 requirements for the MPLS-TP
control plane.  Section 2.4, "Security Requirements", then says this:

   There are no specific MPLS-TP control plane security requirements.
   The existing framework for MPLS and GMPLS security is documented in
   [RFC5920] and that document applies equally to MPLS-TP.

I have no way to tell whether, perhaps, some of those 130+ functional
requirements ought to be generating some security requirements beyond
what's in RFC 5920.  For example, requirement 14, just to pick one:

     14. The MPLS-TP control plane must support the logical separation
         of the control plane from the management and data plane
         [RFC5654, requirement 15]. Note that this implies that the
         addresses used in the control plane are independent from the
         addresses used in the management and data planes.

Is it possible that requiring logical separation of the control plane
from the management and data planes might also introduce a security
requirement with respect to that separation?  Perhaps the working
group and the joint effort have already considered this for each
requirement, and all is well.

I can't tell: there are far too many requirements and variables here,
and my knowledge of MPLS is far too slight.  I just think it's
important to bring up this point, and whenever I see discussion of
out-of-band controls, I wonder about the security implications.

The security considerations section (6) points out that this document
is showing how other specifications provide the means to meet the
requirements listed here, and that those specifications have (and
possible future extension specifications will have) security
considerations sections that properly cover the issues.  I think
that's correct; my concern is only about whether any security
requirements might have been overlooked, which might necessitate an
unanticipated adaptation in order to use, say, GMPLS to satisfy
functional requirements here.

Barry