[secdir] Security review of draft-ietf-mpls-tp-psc-itu-02.txt
"Hilarie Orman" <ho@alum.mit.edu> Mon, 24 February 2014 00:35 UTC
Return-Path: <hilarie@purplestreak.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 6EA251A0785; Sun, 23 Feb 2014 16:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2
X-Spam-Level: **
X-Spam-Status: No, score=2 tagged_above=-999 required=5 tests=[BAYES_80=2, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 zHH0pKT6D7L4; Sun, 23 Feb 2014 16:35:36 -0800 (PST)
Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id 64B361A0784; Sun, 23 Feb 2014 16:35:36 -0800 (PST)
Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1WHjWA-0005cz-7q; Sun, 23 Feb 2014 17:35:34 -0700
Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from <hilarie@purplestreak.com>) id 1WHjW8-0001Lr-3s; Sun, 23 Feb 2014 17:35:34 -0700
Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id s1O0ZRsJ014993; Sun, 23 Feb 2014 17:35:27 -0700
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id s1O0ZRJl014980; Sun, 23 Feb 2014 17:35:27 -0700
Date: Sun, 23 Feb 2014 17:35:27 -0700
Message-Id: <201402240035.s1O0ZRJl014980@sylvester.rhmr.com>
From: Hilarie Orman <ho@alum.mit.edu>
To: iesg@ietf.org, secdir@ietf.org
X-XM-AID: U2FsdGVkX19BxKouGYizest/AWLqsSbk
X-SA-Exim-Connect-IP: 72.250.219.84
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: **;iesg@ietf.org, secdir@ietf.org
X-Spam-Relay-Country:
X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/UXAjlOIAsRSoLM7nla9sZjSLZmI
Cc: draft-ietf-mpls-tp-psc-itu@tools.ietf.org
Subject: [secdir] Security review of draft-ietf-mpls-tp-psc-itu-02.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
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: Mon, 24 Feb 2014 00:35:37 -0000
Security review of draft-ietf-mpls-tp-psc-itu-02.txt MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of SDH, OTN and Ethernet Transport Network Operators Do not be alarmed. 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. The abstract for this document states: This document describes alternate mechanisms to perform some of the sub-functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks. The security considerations are the timeworn statement that No specific security issue is raised in addition to those ones already documented in RFC 6378 [RFC6378] In RFC 6378 we find: MPLS networks make the assumption that it is very hard to inject traffic into a network and equally hard to cause traffic to be directed outside the network. The control-plane protocols utilize hop-by-hop security and assume a "chain-of-trust" model such that end-to-end control-plane security is not used. For more information on the generic aspects of MPLS security, see [RFC5920]. To my great astonishment I found that "RFC5920 Security Framework for MPLS and GMPLS Networks" is an excellent document, and it is my suggestion that the current draft reference it directly in section 13 "Security Considerations". Barring any surprises in the extensive state diagrams, I otherwise am inclined to accept the "no new issues" handwave. Hilarie
- [secdir] Security review of draft-ietf-mpls-tp-ps… Hilarie Orman
- Re: [secdir] Security review of draft-ietf-mpls-t… Hilarie Orman
- Re: [secdir] Security review of draft-ietf-mpls-t… Adrian Farrel
- Re: [secdir] Security review of draft-ietf-mpls-t… Ryoo, Jeong-dong
- Re: [secdir] Security review of draft-ietf-mpls-t… Ryoo, Jeong-dong