[secdir] SECDIR Review of draft-ietf-teas-actn-framework-13

[Catherine Meadows <[e-mail]>]

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.

This draft describes a framework for abstraction and control of traffic engineered networks (ACTN).
According to the abstract, a traffic engineered network is a network that  
uses any connection-oriented technology under the control of a distributed or
centralized control plane to support dynamic provisioning of end-to-end connectivity.
Abstraction in this context is a technique can be applied across a single or multiply domains
to create a single virtualized network under the control of a network operator or owner.
This is thus a very broad topic, and the ID is informational only. The most important part
is probably the description of the ACTN base architecture.  It describes three components: the Customer Network Controller (CNC) responsible
for communicating the customer’s requirements to the network provider , the 
Multi-Domain Servicing Coordinator (MDSC), responsible for implementing ACTN functions, and the Provisioning Network Controller (PNC),
responsible for configuration and topology management. It also describes as the interfaces between them.  The document also gives
a description of some more advanced ACTN architectures,
a description of  several topology abstraction methods, and an example of an advanced ACTN application: a multi-destination servers.
  

The security considerations section, while it lists some general considerations that would
hold for any kind of network, mainly concentrates on the two interfaces between the components: the CNC-MDSC (CMI) and the MDSC-PNC (MPI) interfaces.
It gives a good overview of the types of security risks that might arise with respect to the two interfaces,
and the means for mitigating them.  For the rest, it defers security considerations to the specific applications, which
I assume would be handled by other working groups.  I believe that this is reasonable for an informational document
that is providing a general framework. 

A nit:

I couldn’t parse the last sentence of Section 9.3:

 
   Which MDSC the PNC exports topology information to, and the level of
   detail (full or abstracted) should also be authenticated and
   specific access restrictions and topology views, should be
   configurable and/or policy-based.

I think it may be the commas are misplaced, and what you really want to say is this:

 
   Which MDSC the PNC exports topology information to, and the level of
   detail (full or abstracted), should also be authenticated, and
   specific access restrictions and topology views should be
   configurable and/or policy-based.



Cathy Meadows
 
Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: [phone]
fax: [phone]
email: [e-mail] <mailto:[e-mail]>