Last Call Review of draft-ietf-teas-actn-info-model-08
review-ietf-teas-actn-info-model-08-secdir-lc-danyliw-2018-06-13-00

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