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

Barry Leiba <> Wed, 02 February 2011 23:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 781B63A6C80; Wed, 2 Feb 2011 15:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.865
X-Spam-Status: No, score=-102.865 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E9+crU-Bj1nl; Wed, 2 Feb 2011 15:23:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 36F333A6BC2; Wed, 2 Feb 2011 15:23:53 -0800 (PST)
Received: by iwc10 with SMTP id 10so541239iwc.31 for <multiple recipients>; Wed, 02 Feb 2011 15:27:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KVuCdSiSiqrNSNuN9ux+jxe2hrYRjwMahEjE36H4ll8=; b=tkg5LeqFj0ieS8jFdIXRgAMGnEW7UCqLpAFfHE6a4dzkKtzZ3KpVJYPfkr/SoPDMXf sfAgHaIMERJOvotj6zFLlvigonwSFq0QEdUDrU74t0mUxWceR2XmrKb8X1AsJ5e928Sa WCZinsyLcAFIwCX4AF/7eoUpbTVNUZs1FBauc=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fuJ0ndhcb72Lrys9RHzPBhZYoVugaq5ho6sS5jtpdri31xdT1LwsBr0Z5zpbp+o0BX dfI+8TDJuALtJdVgB9LHnMI2Mz+k9nh0IyO1bJmio8NPECg2cJD+MtU5T7dy//3RpK4r m0vpo58p6kQDgpBOAyqpZTJCpIowj1TcRctH0=
MIME-Version: 1.0
Received: by with SMTP id x3mr10732320ibx.76.1296689233705; Wed, 02 Feb 2011 15:27:13 -0800 (PST)
Received: by with HTTP; Wed, 2 Feb 2011 15:27:13 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Wed, 02 Feb 2011 18:27:13 -0500
X-Google-Sender-Auth: -Ha1s25NFDXTCd5tz1SHufGov4M
Message-ID: <>
From: Barry Leiba <>
To: Lou Berger <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: IESG <>,,
Subject: Re: [secdir] secdir review of draft-ietf-ccamp-mpls-tp-cp-framework-05
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Feb 2011 23:23:54 -0000

Hi, Lou.

> It's hard to respond to your
> general comments as they are just general concerns.

Yes, indeed, and I don't necessarily expect anything.  I wish I knew
more about MPLS, for the purpose of giving this review.

> 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

Absolutely.  That's why I tried to be clear that my question isn't
about the security considerations section (which I think is correct as
it is), but about the security *requirements*.  If, as you folks
developed the 130+ functional requirements, you thought about whether
they generated new security requirements that might not have been
there before, and decided that they didn't, then that's fine.  If you
just said, "OK, any security requirements?  No, none that we can think
of," then you might have missed something by not thinking enough about
the requirements in that light.

But, again, I just wanted to raise the issue and ask what sort of
thought was put into it; I don't necessarily expect any specific


> 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