Subject: [I2nsf] draft-ietf-i2nsf-framework-02.txt

From: Rakesh Kumar <[email-masked]>
Date: Sat, 9 Jul 2016 05:47:17 +0000

Dear authors,

From the title "Framework for Interface to Network Security Functions”, I assume the focus of this draft addresses the controller NSF facing interface. Based on that assumption, I have few comments and questions. I would appreciate any response or a sit down in Berlin to understand it better.

  1.  Section 3.2, (3) Rule Provisioning —> Do you mean Rules as defined in section 9.2?
  2.  Section 3.3 —> Registration Interface —> Does it mean the capabilities/functionality a particular instance of NSF/vNSF support? If it is true, then in the figure 1, why does this interface need to be treated different than other NSF facing interface. I don’t understand the need for mgmt system just for this interface.
  3.  Section 4 —> Are we talking about a need for RBAC model here in this section?
  4.  Section 5 —> This comment is in general though but since this section recommends that NSF facing interface must be based on  Flow/packet information, it begs a question whether we leave any big hole, that can not be covered and would require customer to deploy multiple solutions. This may not be the right place since I think, this is called out in the I2NSF charter. I wanted to bring it up though.
  5.  Section 6.1 —> I assume, we don’t want to state a particular authentication scheme but I think, it would be good to mention that I2NSF controller must support multi-tenant RBAC mechanism (something like this).
  6.  Section 6.2 —> There is some mention of authentication/authorization between controller and NSF but only in the open environment. Does it not make sense for NSF to operate in one mode (always authenticate)?
  7.  Section 6.3 —> In my opinion, whether it isa  vNSF or pNSF , we could have cluster or active/backup deployment in either scenario and security should not worry care about the implementation of NSF itself. The security controller should interact with the configuration entity on NSF and let it handle distributed nature of underlying NSF. This would be a cleaner approach in my opinion.
  8.  Section 7.1 —> It looks like user-intent based policy definition. Is my understanding correct?
  9.  Section 8 & 9 —> Are we saying that Capability is for Client side and Registration is for NSF side?  I am not able to understand the distinction between Capability and Registration interface. Can’t we achieve this with one interface (capability/discovery) ?

Thanks & Regards,
Rakesh