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

[Roman Danyliw <[e-mail]>]

Hi Young!

All of your proposed changes below address my concerns.  Thanks for the quick turn-around.

Cheers,
Roman

From: Leeyoung [mailto:[e-mail]]
Sent: Wednesday, June 13, 2018 5:05 PM
To: Roman Danyliw <[e-mail]>; [e-mail]; [e-mail]
Cc: BRUNGARD, DEBORAH A <[e-mail]>
Subject: RE: Secdir review of draft-ietf-teas-actn-info-model-08


Hi Roman,



Thanks for your review of the draft and providing good comments.



Please see inline for our responses to your comments. Please let us know if our responses are satisfactory to you; if not, please provide us your further comments.



Thanks & Best regards,

Young



-----Original Message-----
From: Roman Danyliw [mailto:[e-mail]]
Sent: Wednesday, June 13, 2018 2:26 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Secdir review of draft-ietf-teas-actn-info-model-08



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.



YL>> Your suggested text is very good. How about the new paragraph as follows:



[new]

   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 with proper authentication and authorization mechanisms.

  In addition, the data exchanged over the ACTN interfaces discussed in this

  document requires verification of data integrity. Backup or redundancies SHOULD

  also be available to restore the affected data to its correct state.



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



YL>> Thanks. I agree with your suggested text that will replace the original text.



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



YL>> Correct. I think the text in draft-ietf-teas-actn-framework-15 is relevant. So I will reference it. So the new text will look like:



[new text]

   The ACTN security discussion is further split into two specific

   interfaces:



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



See the detailed discussion of the CMI and MPI in Sections 9.1 and 9.2, respectively in [ACTN-Frame].





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



YL>> Thanks. I would drop 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?



YL>> for instance, encryption.



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.



YL>> Yes, actually "customer, application and network data" is a more descriptive version of "data in the information model". As such, I would take your text to replace the first sentence of Paragraph 5 (and move it to Paragraph 2). So Paragraph 2 will look like:



[new - Paragraph 2]

   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.

   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.



[new - Paragraph 5]

   The conclusion is that all data models and protocols used to realize

   the ACTN info model should have rich security features as discussed

   in this section. 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.



Regards,

Roman