Re: [secdir] Secdir review of draft-ietf-netmod-opstate-reqs-04

[Benoit Claise <[e-mail]>]

Tom, Kent, WG,

Can you please engage with Tero.
I would like to put this document on the telechat in 2 weeks from now.

Regards, Benoit
> 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.