Last Call Review of draft-ietf-netmod-opstate-reqs-04
review-ietf-netmod-opstate-reqs-04-secdir-lc-kivinen-2016-02-11-00
Request | Review of | draft-ietf-netmod-opstate-reqs |
---|---|---|
Requested revision | No specific revision (document currently at 04) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2016-02-16 | |
Requested | 2016-02-04 | |
Authors | Kent Watsen , Thomas Nadeau | |
I-D last updated | 2016-02-11 | |
Completed reviews |
Genart Last Call review of -04
by Christer Holmberg
Secdir Last Call review of -04 by Tero Kivinen Opsdir Last Call review of -04 by Al Morton |
|
Assignment | Reviewer | Tero Kivinen |
State | Completed | |
Request | Last Call review on draft-ietf-netmod-opstate-reqs by Security Area Directorate Assigned | |
Reviewed revision | 04 | |
Result | Has nits | |
Completed | 2016-02-11 |
review-ietf-netmod-opstate-reqs-04-secdir-lc-kivinen-2016-02-11-00
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 is terminology and requirements document for handling operational state. As such the security considerations section cannot have very detailed problems, but it does properly point out that while configuration is being applied the device might be in inconsistent state, and that might cause security issues. It does not say anything about how the configuration requests needs to be secured, but I assume that is more in to the actual protocol RFC issue, than this document. It does not also comment anything about whether the different states (intended configuration, applied configuration and derivative state) should have different security policies to applied to them, i.e. it does say that it should be possible to retrieve only applied configuration or only derived state, but does not mention should there also be different security policies to do those operations. In some cases the derivative state might contain things like traffic keys negotiated during the protocol runs, or traffic information aabout flows passing the devices (privacy issues), so derivative state might be more sensitive than the actual applied configuration. Outside the security considerations section the requirement which says: A. A server MUST support only synchronous configuration operations, or only asynchronous configuration operations, or both synchronous and asynchronous configuration operations on a client-specified per-operation basis. is bit funny, as it effectively says that either syncronous or asyncronous MUST be supported and both may be supported, but I do not understand what the "client-specified per-operation basis" is meaning for the requirement for server. Client cannot really require server to change its IMPLEMENTATION on per-operation basis (i.e., client 1 requesting that server MUST support only asyncronous operations, and client 2 requesting that server MUST support only syncronous operations). Client can use either syncronous or asyncronous if both are supported by the server, and I assume this is trying to say that client can select syncronous/asyncronous operation per-operation basis, but when you are talking about that "A server MUST support ..." I do not think it is ok to requiring that on a client-specified way. I.e. proper way would be to say that if server supports both, it MUST allow client to select which method is used on per-operation basis. -- kivinen at iki.fi