Re: [secdir] secdir review of draft-ietf-i2rs-pub-sub-requirements-06

["Eric Voit (evoit)" <[e-mail]>]

> From: Scott G. Kelly, April 27, 2016 9:09 PM
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by IESG.  These comments
> were written primarily for the benefit of security area directors.  Document
> editors and WG chairs should these comments just like any other last call
> comments.
> 
> Summary: not ready
> 
> From the abstract, this document provides requirements for a service that
> allows client applications to subscribe to updates of a YANG datastore.
> 
> I looked up YANG, and wikipedia says it is a data modeling language for the
> NETCONF network configuration protocol.
> 
> The introduction says
> 
>    Applications interacting with YANG datastores require capabilities
>    beyond the traditional client-server configuration of network
>    elements.  One class of such applications are service-assurance
>    applications which must maintain a continuous view of operational
>    data and state.  Another class of applications are security
>    applications which must continuously track changes made upon network
>    elements to ensure compliance to corporate policy.
> 
> So, this suggests that this pub/sub mechanism will sometimes be used for
> security-related monitoring.
> 
> When I read the document, I wondered where the requirements were coming
> from. There is a brief “Business Drivers” section that tells why a “push
> mechanism” (different name for pub/sub?) is useful, but other than this, the
> document does not describe use cases. This makes it very difficult to evaluate
> the subsequent requirements assertions.
> 
> I don’t know anything about I2RS, and I won’t comment on anything other than
> the security considerations.  That section lists various MUSTs and SHOULDs, but
> gives no rationale. It is not possible to evaluate this section without
> understanding *why* these requirements are what they are.
>
 > It is possible that the rationale exists in companion documents. If so, this should
> be called out. If not, I think it should be given here.

Hi Scott,

Section 2.1 provides multiple references to numbered requirements in three other i2rs documents:
- [i2rs-usecase] draft-ietf-i2rs-usecase-reqs-summary
- [i2rs-arch] draft-ietf-i2rs-architecture
- [i2rs-traceability] draft-ietf-i2rs-traceability
Some of these references are coupled to security uses.   Look to those referred documents for details.

It would have been possible to provide more references to those documents.  But we didn't what to overwhelm the reader with too large a volume of cross-references.  For example, all the individual items from [i2rs-usecase] in Section 13 Large Data Collection System could be referenced as subscribing to an extract of a datastore can be used for a variety of security verification reasons (such as ensuring ACLs in the router are actually what the NMS systems think they are).  

Beyond the existing references in section 2.1, we could have also included items like [i2rs-usecase]
L-Data-REQ-04 (IC): I2RS should support capability negotiation to  inform a subscriber of the options for publication of data.  The options include transport, security, and error handling.
L-Data-REQ-03 (IC): I2RS should use a pub-sub model which allows scaling plus push or pull of data.
Topo-Req-10 (NA): I2RS must provide a common and up-to-date normalized view of the topologies that that support security auditing, and IP/MPLS Provisioning (L2/L3) which includes...

Beyond the i2rs requirements, Section 2.2 includes references to [sacm-requirements].  As SACM is about security and continuous monitoring, this should be a relevant reference.   Also something which use to be in Section 2 was an i2rs security specific pub sub use case / requirements document -> camwinget-i2rs-pubsub-sec.  The reference to the camwinget draft was removed due to its expiration, and because the author then moved on the create the [sacm-requirements] document as a result.   

If these existing references are insufficient, we could also and bring in new use case references.  For example we could bring in draft-voit-netmod-yang-mount-requirements > Use Case 4.2. 

Please let me know if the explanation meets your needs, if some of the above references should be expanded, or if you have some other request.

Thanks,
Eric


> The intro suggests that this
> mechanism will be used for enterprise security monitoring operations. Those
> operations should be described (at a high level), along with associated threats.
> From those threats come associated mitigation measures, and from those
> measures come requirements. If you want to punt on the specifics (and address
> it in later work), then the requirements should at least describe what threats
> should be mitigated.
> 
> I think the ADs should take a look at this document.
> 
> --Scott
>