Re: [I2nsf] Comments on draft-dunbar-i2nsf-problem-statement-05

["Anil Kumar S N (VRP Network BL)" <[e-mail]>]

Hi Linda,

Reply is inline.

Thanks & Regards
Anil S N

"Be liberal in what you accept, and conservative in what you send" - Jon Postel


From: Linda Dunbar
Sent: 21 November 2015 06:07
To: Anil Kumar S N (VRP Network BL); [e-mail]
Cc: Jayaraghavendran k; [e-mail]
Subject: RE: Comments on draft-dunbar-i2nsf-problem-statement-05

Anil,

Thank you very much for the comments. Reply are inserted below:


From: Anil Kumar S N (VRP Network BL)
Sent: Thursday, November 19, 2015 8:23 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Linda Dunbar; Jayaraghavendran k; [e-mail]<mailto:[e-mail]>
Subject: Comments on draft-dunbar-i2nsf-problem-statement-05

Hi Authors,

          I was reading the draft for understanding and contributing towards I2NSF working group and found few comments :


*         Introduction section :  I think all these use cases are merged as "draft-pastor-i2nsf-merged-use-cases-00" request you to update the same


This document does not elaborate on specific use case. The reader
should refer to [I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile] for a
more in-depth discussion on the I2NSF use cases.

[Linda] you are correct. Actually all of them will be merged together with the problem statement.


*         Requirements Language, terms and acronyms section : We need to describe following abbreviations which are used in the documents as it the first document
to be referred by any newcomer into I2NSF WG

IPS, IDS, ACL, FWs, AAA, CA, VNFpool, Etc...

[Linda] Good point. Has been added.



*         3.1.1. Diverse types of Security Functions Section :  Below statement is contradicting each other, I2NSF wants to standardize the interface to control the behavior of NSF
but doesn't want to standardize the interface which carries the information of firewall filter and its application on specific flow. I Feel we could add more clarity on the scope of I2NSF with respect to
what is under its perview and what is not in this document if at all we want to talk about "what is needed" in this document.

     there is no need to standardize on how a
     firewall filters are created or applied. What is needed is having
     an interface to control and monitor the behavior of NSFs.
[Linda]  What in the I2NSF scope is "Rule Set" to those "Firewall filter".
How about this: "What is needed is having an interface to control and monitor the rule sets that NSFs use to treat packets traversing through."
[[Anil >>]] Sounds good


*         3.1.2.  Diverse Interface to monitor the behavior of NSFs :  Reparsed as below

You Can't Monitor What You Can't See. So enabling a security function

(e.g., firewall [I-D.ietf-opsawg-firewalls]) does not mean that a network is protected.

As such, it is necessary to have a mechanism to monitor and provide execution status of NSFs to

security and compliance management tools. There exist various network security monitoring vendor specific interfaces

for forensics and troubleshooting





*         Adding new section :

3.1.9 Lack of mechanism for Key Management/Deterministic Generation and Provisioning for communicating protocols



[Linda] Do you see it as challenge facing providers? Or the customers?  Do you mean  "Lack of Mechanism for security keys distribution to NSFs by different vendors"?





There is a need for a framework/data model for a key management protocol that may be used to create and manage session



[Linda] You need to provide more wording: Manage What Session? Is it IPSec session ? is VPN session?

What do you think of this

"There is a need for controller to distribute various keys to distributed NSFs."



[[Anil >>]] Agreed, Will rephrase; Idea is that there are many key management methods and KDF (key derivation function) exist

but there is a need for standardizing the interface to provision and manage it.  Here any two communicating protocols could use same KDF

to deterministically derive keys and  to communicate. The reference to session should have been two communicating entities.

Which will enhances the security by reducing life time of a key used and non repetitive of the keys for a very long time which is very much important for control plane packets.

Derived keys may be extended to IPsec/VPN  data packet.

Since the lack of such management framework/interface limited service providers to use keys with very longer lifetime or a key chain with a set of key which were repeated in a cycle.

We would like to address above issue with I2NSF framework. Please correct me if I am wrong.



keys for message authentication and integrity. As of now there is no much focus on an abstraction for keying information that describes the interface

between protocols, operators, and automated key management.



[[Anil >>]] How about below text :

3.1.9 Lack of framework/standard interface to provisioning the usage of Key Derivation Function (KDF) and managing KDF



A Key Derivation Function (KDF) or Key Derivation Algorithm is intended to be used in two ways:

(1) to derive a long-term Master Secret from a short-lived shared secret

(2) to derive secure channel session keys from a shared secret and a seed.



There is a need for a framework to ensure secure exchange of initial secrete between managing entity and managed entity (NSF).



There is a need for a framework/standard interface in provisioning two communicating protocols to use KDF as their key source for

Specific period of time or for a set of interaction.

There is also need for framework/standard interface in controlling and managing KDF used between two communicating protocols

The Provisioning and Managing framework could be extended to data plane too.



With Regards

Anil S N


"Be liberal in what you accept, and conservative in what you send" - Jon Postel