[I2nsf] draft-dunbar-i2nsf-problem-statement

[Kathleen Moriarty <[e-mail]>]

Hello,


In reviewing draft-dunbar-i2nsf-problem-statement, I see that this draft
also covers use cases.  Having 4 different drafts with use cases is
problematic as the scope seems unwieldy.  There is plenty of overlap
between drafts, but I recommend the group narrows down the number of drafts
to better focus the efforts.  Having them within the framework may make
sense.  It's also fine to have use cases in either a separate draft that
may not get published or on a wiki to maintain as the work definition
evolves.  In many cases, the use cases don't need to be published, so the
wiki model could work to consolidate the numerous efforts put forth by list
members.


This draft also uses the word "cloud", it would be more clear if the draft
instead stated the scope so the reader would understand if it's a managed
data center or the data center crosses administrative domains, etc.

The scope stated in the following section is quite broad:



There are two aspects of the I2NSF work:

     - Service Layer, which is for clients to express, monitor, or
        manage their desired security policies for their designated
        traffic.

        This layer will leverage the existing protocols in RESTconf,
        AAA, SACM, and security policy expression using Role Based
        Access Control (RBAC), Mandatory Access Control (MAC), or
        Attribute based access control (ABAC).

     - Functional layer, which is to specify the proper interface to
        the individual security functions or function instances when
        overall policies are enforced by a collection of security
        functions located in multiple premises.


Although it is good to leverage existing work, how much of this work could
be done in the mentioned working groups?  SACM is starting to look at
information models, could some of that be proposed in drafts to that WG?
I'd like to understand more on the access control statements as it is not
clear where that fits in from the current materials and if it changes with
the flow-based discussions (I'm not sure if that was agreed upon or not
yet).  If that doesn't meet the need of the BoF proponents, we need to hear
that on list as well.

Section 3, for the pinhole example, I think you can fit this into service
definitions where the ports would already be defined and it may get opened
for a user or set of to/from addresses.  I think this would help you get
around the vendor agnostic issues as your service definitions might reside
at the service provider and include specific requirements for the
particular firewall in question.

I need to dig into PCP and Midcom a bit more, so if what I am describing
has been done, the existing work should be leveraged.

Discussion of VPN clients in this section needs to be further distinguished
from SUPA, which should be easy enough to do as this applies to tenants, or
it should be removed if it is now out-of-scope.

Summary:

I think this work is progressing and will be valuable once the scope is
clear not only in a charter, but also in the supporting drafts. I'll need
to know if that scope is agreed to by those on list: is the scope allowing
for policy configuration of a few devices such as firewall and IPS or will
it switch to flow-based?

Could the team continue to work on the scope, then update and consolidate
the drafts to reflect the more clearly defined scope (once it is agreed
upon)?  Understanding how you might achieve the vendor agnostic policy
management in either scope will be important to understating if this effort
can be successful.  I did provide an option that I think could work in my
feedback if the WG chooses the firewall/IPS direction or maybe others on
list have thought through this more and have methods that would be better.

Thank you.
-- 

Best regards,
Kathleen