[secdir] Secdir review of draft-ietf-teas-actn-info-model-08

[Roman Danyliw <[e-mail]>]

Reviewer: Roman Danyliw
Review result: Ready with nits

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.

The summary of the review is Ready with nits.

My feedback is as follows:

(1) Section 9, Security Considerations, Page 21, Paragraph 1

[original text]
   The ACTN information model described in this document defines key
   interfaces for managed traffic engineered networks.  Securing the
   request and control of resources, confidentiality of the
   information, and availability of function, should all be critical
   security considerations when deploying and operating ACTN platforms.

[feedback]

This section (Section 9) reads to me as if it is describing more than just the information model.  The text appears to be identical to the security considerations in draft-ietf-teas-actn-framework-15.  IMO, the text here would benefit from tighter scoping.  Perhaps something like:

"The ACTN information model does not directly introduce security issues.  Rather, it defines a set of interfaces for traffic engineered networks.  The underlying protocols, procedures, and implementations used to exchange the information model described in this draft will need to secure the request and control of resources ...:

Furthermore, I assumed that "securing the request and control of resources" was implying the need for authentication and authorization of requests.  However, there is no discussion of that in the subsequent text.  There is also no subsequent discussion of the significance of availability despite it being referenced in this paragraph.

(2) Section 9, Security Considerations, Page 21, Paragraph 2

[original text]
   Several distributed ACTN functional components are required, and
   implementations should consider encrypting data that flows between
   components, especially when they are implemented at remote nodes,
   regardless of these data flows are on external or internal network
   interfaces.

[feedback]

Editorial -- This paragraph was a dense read for me.  Perhaps something like the following would be more approachable:

"Implementations of the ACTN framework will have distributed functional components that will exchange this information model.  Implementations SHOULD encrypt data that flows between them, especially when they are implemented at remote nodes and irrespective of whether these data flows are on external or internal network interfaces."

(3) Section 9, Security Considerations, Page 21, Paragraph 3

[original text]
   The ACTN security discussion is further split into two specific
   categories described in the following sub-sections:

   - Interface between the Customer Network Controller and Multi Domain
     Service Coordinator (MDSC), CNC-MDSC Interface (CMI)

   - Interface between the Multi Domain Service Coordinator and
     Provisioning Network Controller (PNC), MDSC-PNC Interface (MPI)

[feedback]

This sentence references additional sub-sections that don't appear to exist -- Section 9 has no sub-sections.  draft-ietf-teas-actn-framework-15 which has identical text does have these sub-sections (Sections 9.1 and 9.2).  Without additional text, this paragraph doesn't add anything.  If the text in draft-ietf-teas-actn-framework-15 is relevant, I would recommend simply referencing it.

(4) Section 9, Security Considerations, Page 21, Paragraph 4

[original text]
   From a security and reliability perspective, ACTN may encounter many
   risks such as malicious attack and rogue elements attempting to
   connect to various ACTN components.  Furthermore, some ACTN
   components represent a single point of failure and threat vector,
   and must also manage policy conflicts, and eavesdropping of
   communication between different ACTN components.

[feedback]

This text identifies some of the potential threats.  What mitigations should be applied?  Furthermore, these threats aren't scoped within the bounds of the information model.  I recommend revising this threat discussion to be around the information being exchange or dropping the paragraph.

(5) Section 9, Security Considerations, Page 22, Paragraph 5

[original text]
   The conclusion is that all data models and protocols used to realize
   the ACTN info model should have rich security features, and
   customer, application and network data should be stored in encrypted
   data stores.  Additional security risks may still exist.  Therefore,
   discussion and applicability of specific security functions and
   protocols will be better described in documents that are use case
   and environment specific.

[feedback]

Per "The conclusion is that ... should have rich security features".  What does "rich security" mean?

Per "... and customer, application and network data should be stored ...", this is a good point about encryption at rest.  Is the "customer, application and network data" a more descriptive version of "data in the information model"?  If no, then it's out of scope.  If yes, then I would recommend explicitly stating that "The information model may contain customer, application and network data that for business or privacy reasons may be considered sensitive.  It SHOULD be stored only in an encrypted data store".  As data in motion is discussed in paragraph 2, it might make sense to move this text there.

Regards,
Roman