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

Lou Berger <lberger@labn.net> Wed, 02 February 2011 22:28 UTC

Return-Path: <lberger@labn.net>
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 28DE03A6C8A for <secdir@core3.amsl.com>; Wed, 2 Feb 2011 14:28:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.16
X-Spam-Level:
X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 AggpO-P0gVVp for <secdir@core3.amsl.com>; Wed, 2 Feb 2011 14:28:20 -0800 (PST)
Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id F3AEC3A6BA9 for <secdir@ietf.org>; Wed, 2 Feb 2011 14:28:19 -0800 (PST)
Received: (qmail 15350 invoked by uid 0); 2 Feb 2011 22:31:40 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 2 Feb 2011 22:31:40 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=c15LsLSo9gDzoWxoKpRkgg8lnccNk3Tsi2k+bXNSy1HakmKZy2wLOj4oeNAQaI+zqT7CHTPnpB+rFISZX5vDlq4HOfP4pnnLAQpmNqYHXFjovZd95Yk20FeEDomgOBL9;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from <lberger@labn.net>) id 1PklEi-0001ET-9a; Wed, 02 Feb 2011 15:31:40 -0700
Message-ID: <4D49DB50.7020702@labn.net>
Date: Wed, 02 Feb 2011 17:31:44 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <AANLkTi=EL2GqrOvePsPoiVZxrbRyFyCckOuYbLE+QCqS@mail.gmail.com>
In-Reply-To: <AANLkTi=EL2GqrOvePsPoiVZxrbRyFyCckOuYbLE+QCqS@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: IESG <iesg@ietf.org>, draft-ietf-ccamp-mpls-tp-cp-framework.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [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 22:28:21 -0000

Barry,
	Thank you for your review and comments.  It's hard to respond to your 
general comments as they are just general concerns.  My feeling is that 
this is just a framework and any specific protocol definitions will take 
place in new documents and, as such, will contain their own security 
considerations sections.  I'm not sure there's much else we can do in 
this document to address the general comments.

As your specific example/comment on separation.  This is already an 
existing capability in GMPLS. So there's nothing really new here other 
than that TP requires GMPLS vs classic MPLS control plane.

Please let me/us know if you think there's something else that should be 
done.

Lou

On 2/2/2011 4:37 PM, Barry Leiba wrote:
> 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
>
>
>
>