Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06

Curtis Villamizar <> Wed, 05 February 2014 20:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3A4371A01C1 for <>; Wed, 5 Feb 2014 12:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JVDHwM0GP05m for <>; Wed, 5 Feb 2014 12:24:44 -0800 (PST)
Received: from ( [IPv6:2001:470:88e6:3::232]) by (Postfix) with ESMTP id 1936D1A0197 for <>; Wed, 5 Feb 2014 12:24:44 -0800 (PST)
Received: from ( [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by (8.14.7/8.14.7) with ESMTP id s15KOR0W012286; Wed, 5 Feb 2014 15:24:27 -0500 (EST) (envelope-from
Message-Id: <>
To: Stephen Kent <>
From: Curtis Villamizar <>
In-reply-to: Your message of "Wed, 05 Feb 2014 09:24:52 -0500." <>
Date: Wed, 05 Feb 2014 15:24:27 -0500
Cc:,, secdir <>,,,, Loa Andersson <>,,, Adrian Farrel <>, Stewart Bryant <>,
Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Feb 2014 20:24:47 -0000

In message <>
Stephen Kent writes:
> Curtis,
> Thanks for the quick reply.
> I agree that a thorough summary of the relevant security considerations
> from the many normative references would be a non-trivial task ;-).
> The brief summary you assembled is excellent!
> I am satisfied with the changes/responses.
> Steve


If you don't mind I'd like to add a little to this.  This is the very
last paragraph and follows the numbered list.


   MPLS security including data plane security is discussed in greater
   detail in [RFC5920] (MPLS/GMPLS Security Framework).


   MPLS security including data plane security is discussed in greater
   detail in [RFC5920] (MPLS/GMPLS Security Framework).  THe MPLS-TP
   security framework [RFC6941] build upon this, focusing largely on
   the MPLS-TP OAM additions and OAM channels with some attention
   given to using network management in place of control plane setup.
   In both security framework documents MPLS is assumed to run within
   a "trusted zuone", defined as being where a single service provider
   (SP) has total operational control over that part of the network.

   If control plane security and management plane security are
   sufficiently robust, compromise of a single network element may
   result in chaos in the data plane anywhere in the network through
   denial of service attacks, but not a Byzantine security failure in
   which other network elements are fully compromised.

   MPLS security, or lack of, can affect whether traffic can be
   misrouted and lost, or intercepted, or intercepted and reinserted
   (a man-in-the-middle attack) or spoofed.  End user applications,
   including control plane and management plane protocols used by the
   SP, are expected to make use of appropriate end-to-end
   authentication and where appropriate end-to-end encryption.

I think the original, while not incorrect, was too brief.  This new
text provides a better summary, indicating the underlying "trusted
zuone" assumption and the lack of any meaningful data plane security
if that underlying assumption proves invalid for any reason, but most
likely invalid due to a breach or a physical intercept along
transmission media.

Please let me know if this further change is an improvement or if we
should leave it out (or change it).