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

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 27 Apr 2016 18:09:04 -0700 (PDT)

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. 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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 28 Apr 2016 14:11:32 +0000

> 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.
> 
> 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.
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 29 Apr 2016 14:34:59 -0700 (PDT)

Hi Eric,

On Thursday, April 28, 2016 7:11am, "Eric Voit (evoit)" <[email-masked]> said:

<trimmed for readability...>
 
> Some of these references are coupled to security uses.   Look to those referred

Yes, you are right, those documents do provide related use cases and requirements rationale. Also of note: draft-ietf-i2rs-protocol-security-requirements.

Now I remember Sue Hares asking secdir for review help with this complex document set, and I can see why.

When I first looked at the protocol security requirements draft, I wondered if you should simply refer to that. I realize you are focusing only on YANG pub/sub requirements here, but maybe that is still worth considering.
 
If you choose to maintain security requirements in this document, I would suggest adopting a pattern similar that followed by draft-ietf-i2rs-protocol-security-requirements-03, and refer to the document(s)/numeric requirement(s) driving your MUSTs/SHOULDs. 

Thanks,

Scott