[secdir] Secdir review of draft-ietf-netconf-restconf-09

"Xialiang (Frank)" <frank.xialiang@huawei.com> Tue, 12 January 2016 08:28 UTC

Return-Path: <frank.xialiang@huawei.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 90D9B1A1EF1; Tue, 12 Jan 2016 00:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 e4bOb4v_irRX; Tue, 12 Jan 2016 00:28:15 -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 094D81A1C06; Tue, 12 Jan 2016 00:28:13 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGS10806; Tue, 12 Jan 2016 08:28:10 +0000 (GMT)
Received: from LHREML705-CAH.china.huawei.com (10.201.5.168) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Jan 2016 08:28:09 +0000
Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Jan 2016 08:28:10 +0000
Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.185]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Tue, 12 Jan 2016 16:27:53 +0800
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
To: "draft-ietf-netconf-restconf.all@tools.ietf.org" <draft-ietf-netconf-restconf.all@tools.ietf.org>
Thread-Topic: Secdir review of draft-ietf-netconf-restconf-09
Thread-Index: AdFNEv/v0fWtOVGbSBOdzSCBJKdg7g==
Date: Tue, 12 Jan 2016 08:27:53 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12AED7F4D@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_C02846B1344F344EB4FAA6FA7AF481F12AED7F4DSZXEMA502MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5694B91B.006D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.185, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8d0c2bc30af141861b8c9a8af925691f
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/q-Seaw5jgIx9I1G9tXpKnfHE_Qc>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: [secdir] Secdir review of draft-ietf-netconf-restconf-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 12 Jan 2016 08:28: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 describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF.





The document appears in reasonably good shape.



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, etc. In other words, RESTCONF is designed inherently based on a good security foundation.



But there are still several security issues (TBDs) missing in the document that need to be addressed before publication.





Below is a series of my comments, questions for your consideration.





Discussion: Section 2

Since this section is all about the security requirements to the RESTCONF transport protocol, is it appropriate to combine it into the security consideration section directly?





Questions:

Section 4.3

What is the error handling if GET method is used to retrieve the operational resources?



Section 4.5

What is the error handing if PUT method does not include the message body?



Generally, the similar problems like the above two appear several times in the document, please double check them.





Comments: Section 12

In the security considerations section, there are still some serious security issues not mentioned:

1. DDoS attack: One RESTCONF client is possible to communicate with a lot of RESTCONF servers, which potentially leads to the situation of DDoS attack to itself or its link. How to avoid or mitigate it?

2. Replay attack: the attacker records a sequence of messages off the wire and plays them back to the RESTCONF server/client. To protect against it, the common methods include using timestamp or sequence id.





Questions: Section 12

1. "Security considerations for the content manipulated by RESTCONF can be found in the documents defining data models.": which documents are mentioned in this sentence for defining data models?

2. nits: "Implementors SHOULD provide a comprehensive authorization scheme with...". Here, should "authorization" be "authentication"?





Thank you.



B.R.

Frank