[secdir] SecDir review of draft-ietf-teas-gmpls-resource-sharing-proc-08

"Xialiang (Frank)" <frank.xialiang@huawei.com> Mon, 06 February 2017 02:41 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018E71294AD; Sun, 5 Feb 2017 18:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yhChqKqjPe7R; Sun, 5 Feb 2017 18:41:17 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13FE129A8A; Sun, 5 Feb 2017 18:41:16 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFV86559; Mon, 06 Feb 2017 02:41:15 +0000 (GMT)
Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 6 Feb 2017 02:41:14 +0000
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.53]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Mon, 6 Feb 2017 10:41:10 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-teas-gmpls-resource-sharing-proc.all@tools.ietf.org" <draft-ietf-teas-gmpls-resource-sharing-proc.all@tools.ietf.org>
Thread-Topic: [secdir] SecDir review of draft-ietf-teas-gmpls-resource-sharing-proc-08
Thread-Index: AdKAInfEqvyGbZ+IQNGuIrUZF9s6BA==
Date: Mon, 6 Feb 2017 02:41:09 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12B0B1B24@SZXEMA502-MBS.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.135.43.91]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12B0B1B24SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5897E24B.0125, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.53, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 5cdc91b6fe8cb36b252624efcb6d0029
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/cQQhW-oU06TkUN2l3fALR29SpTY>
Subject: [secdir] SecDir review of draft-ietf-teas-gmpls-resource-sharing-proc-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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, 06 Feb 2017 02:41:19 -0000

Hello,
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.

This document reviews how the LSP association is to be provided using Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down.  In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures.

Firstly, no new signaling extensions are defined by this document, and it is strictly informative in nature. So, no new security issues arise in this document. Secondly, the security considerations in [RFC3209] [RFC4872] [RFC4873] and [RFC6689] are included in the security consideration section of this draft, nothing more is missed. In consequence, I have no more security issues.

Summary: this document appears in reasonably good shape, and no more security issues. I think it is ready.

Thanks!

B.R.
Frank