Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06
Curtis Villamizar <curtis@ipv6.occnc.com> Wed, 05 February 2014 20:24 UTC
Return-Path: <curtis@ipv6.occnc.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4371A01C1 for <secdir@ietfa.amsl.com>; Wed, 5 Feb 2014 12:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVDHwM0GP05m for <secdir@ietfa.amsl.com>; Wed, 5 Feb 2014 12:24:44 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1936D1A0197 for <secdir@ietf.org>; Wed, 5 Feb 2014 12:24:44 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s15KOR0W012286; Wed, 5 Feb 2014 15:24:27 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201402052024.s15KOR0W012286@maildrop2.v6ds.occnc.com>
To: Stephen Kent <kent@bbn.com>
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Wed, 05 Feb 2014 09:24:52 -0500." <52F249B4.6020301@bbn.com>
Date: Wed, 05 Feb 2014 15:24:27 -0500
Cc: swallow@cisco.com, samante@apple.com, secdir <secdir@ietf.org>, kireeti@juniper.net, cpignata@cisco.com, agmalis@gmail.com, Loa Andersson <loa@pi.nu>, curtis@occnc.com, rcallon@juniper.net, Adrian Farrel <adrian@olddog.co.uk>, Stewart Bryant <stbryant@cisco.com>, curtis@ipv6.occnc.com
Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 05 Feb 2014 20:24:47 -0000
In message <52F249B4.6020301@bbn.com> 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 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. OLD PROPOSED MPLS security including data plane security is discussed in greater detail in [RFC5920] (MPLS/GMPLS Security Framework). NEW PROPOSED 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). Curtis
- [secdir] SECDIR review of draft-ietf-mpls-forward… Stephen Kent
- Re: [secdir] SECDIR review of draft-ietf-mpls-for… Curtis Villamizar
- Re: [secdir] SECDIR review of draft-ietf-mpls-for… Loa Andersson
- Re: [secdir] SECDIR review of draft-ietf-mpls-for… Stephen Kent
- Re: [secdir] SECDIR review of draft-ietf-mpls-for… Carlos Pignataro (cpignata)
- Re: [secdir] SECDIR review of draft-ietf-mpls-for… Curtis Villamizar
- Re: [secdir] SECDIR review of draft-ietf-mpls-for… Curtis Villamizar
- Re: [secdir] SECDIR review of draft-ietf-mpls-for… Stephen Kent
- [secdir] SECDIR review of draft-ietf-mpls-forward… Stephen Kent