[secdir] Secdir (Re)review of draft-ietf-netconf-restconf-15:

"Xialiang (Frank)" <frank.xialiang@huawei.com> Fri, 15 July 2016 12:25 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 9A29812D1A9; Fri, 15 Jul 2016 05:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.507
X-Spam-Level:
X-Spam-Status: No, score=-5.507 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=-1.287, SPF_PASS=-0.001] autolearn=unavailable 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 qTcO-XlpQdg9; Fri, 15 Jul 2016 05:25:18 -0700 (PDT)
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 DF43D12D1A3; Fri, 15 Jul 2016 05:25:16 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CSP90061; Fri, 15 Jul 2016 12:25:13 +0000 (GMT)
Received: from SZXEMA415-HUB.china.huawei.com (10.82.72.33) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 15 Jul 2016 13:24:13 +0100
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.6]) by SZXEMA415-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0235.001; Fri, 15 Jul 2016 20:24:08 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: "'iesg@ietf.org'" <iesg@ietf.org>, "'secdir@ietf.org'" <secdir@ietf.org>, "draft-ietf-netconf-restconf.all@tools.ietf.org" <draft-ietf-netconf-restconf.all@tools.ietf.org>
Thread-Topic: Secdir (Re)review of draft-ietf-netconf-restconf-15:
Thread-Index: AdHek8af5RdqrPV4TzG3jaIi8o9bKQ==
Date: Fri, 15 Jul 2016 12:24:07 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12AF8A1E0@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.200.219.116]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AF8A1E0SZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5788D62A.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.6, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: abc42f9bb1abdf37b86b2026999a80db
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/74wN3OZD03BuuFfhnTEMHC3h30Q>
Subject: [secdir] Secdir (Re)review of draft-ietf-netconf-restconf-15:
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: Fri, 15 Jul 2016 12:25:20 -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 describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in NETCONF.

I have reviewed draft-ietf-netconf-restconf-09 as the Secdir before. My general thoughts about it is:

Firstly, the document appears in reasonably good shape.

Secondly, in general, the RESTCONF is an application protocol layered on the HTTP protocol. As mentioned in the document, just using the HTTPS (with TLS) can address most of the security issues such as confidentiality, integrity, authentication, etc. In other words, RESTCONF is designed inherently based on a good security base.


Now, after several rounds of update, this draft has became better in the aspect of security considerations. I don't see further security issues in addition to the description in the sections of "Transport Protocol Requirements" and "Security Considerations".

In summary, I think this draft is Ready!

Thanks!

B.R.
Frank