Skip to main content

Early Review of draft-ietf-netconf-restconf-09
review-ietf-netconf-restconf-09-secdir-early-xia-2016-01-14-00

Request Review of draft-ietf-netconf-restconf
Requested revision No specific revision (document currently at 18)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2016-10-11
Requested 2015-12-22
Authors Andy Bierman , Martin Björklund , Kent Watsen
I-D last updated 2016-01-14
Completed reviews Genart Early review of -09 by Robert Sparks (diff)
Genart Last Call review of -15 by Robert Sparks (diff)
Genart Last Call review of -15 by Dale R. Worley (diff)
Genart Telechat review of -17 by Dale R. Worley (diff)
Secdir Early review of -09 by Liang Xia (diff)
Secdir Last Call review of -15 by Liang Xia (diff)
Opsdir Early review of -13 by Lionel Morand (diff)
Assignment Reviewer Liang Xia
State Completed
Request Early review on draft-ietf-netconf-restconf by Security Area Directorate Assigned
Reviewed revision 09 (document currently at 18)
Result Has issues
Completed 2016-01-14
review-ietf-netconf-restconf-09-secdir-early-xia-2016-01-14-00

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