Return-Path: X-Original-To: i2nsf@ietfa.amsl.com Delivered-To: i2nsf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8E81A9100 for ; Sat, 19 Dec 2015 11:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNyyAIMS3umz for ; Sat, 19 Dec 2015 11:30:41 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E8D1A90FF for ; Sat, 19 Dec 2015 11:30:41 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.177; From: "Susan Hares" To: "'Anil Kumar S N \(VRP Network BL\)'" , "'Linda Dunbar'" , References: <327562D94EA7BF428CD805F338C31EF06C07EC8B@nkgeml512-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F657DA6474@dfweml701-chm> <327562D94EA7BF428CD805F338C31EF06C07EFE5@nkgeml512-mbx.china.huawei.com> In-Reply-To: <327562D94EA7BF428CD805F338C31EF06C07EFE5@nkgeml512-mbx.china.huawei.com> Date: Sat, 19 Dec 2015 14:30:22 -0500 Message-ID: <000c01d13a93$b432d9d0$1c988d70$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01D13A69.CB6165B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKWPF/8Z7KcSyRLXKDKN5r6nGdP1wKVa8pQAhmmqwedIzUnsA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jayaraghavendran k' , i2nsf@ietf.org Subject: Re: [I2nsf] Comments on draft-dunbar-i2nsf-problem-statement-05 X-BeenThere: i2nsf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 19:30:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01D13A69.CB6165B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Anil, Linda and all: I've put in most of your changes into the combined problem statement and use case. However, I can no longer find a copy or reference to: [I2NSF-Mobile]. Would you point me to the current document? Thank you, Sue Hares From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Anil Kumar S N (VRP Network BL) Sent: Sunday, November 22, 2015 11:04 PM To: Linda Dunbar; draft-dunbar-i2nsf-problem-statement-05@ietf.org Cc: Jayaraghavendran k; i2nsf@ietf.org Subject: Re: [I2nsf] Comments on draft-dunbar-i2nsf-problem-statement-05 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); draft-dunbar-i2nsf-problem-statement-05@ietf.org Cc: Jayaraghavendran k; i2nsf@ietf.org 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: draft-dunbar-i2nsf-problem-statement-05@ietf.org Cc: Linda Dunbar; Jayaraghavendran k; i2nsf@ietf.org 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 ------=_NextPart_000_000D_01D13A69.CB6165B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Anil, Linda and all:

 

I’ve put in most = of your changes into the combined problem statement and use case.  = However, I can no longer find a copy or reference to: = [I2NSF-Mobile].

 

Would you point me to = the current document?

 

Thank = you,

 

Sue Hares =

 

From:= = I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Anil Kumar S N = (VRP Network BL)
Sent: Sunday, November 22, 2015 11:04 = PM
To: Linda Dunbar; = draft-dunbar-i2nsf-problem-statement-05@ietf.org
Cc: = Jayaraghavendran k; i2nsf@ietf.org
Subject: Re: [I2nsf] = Comments on = draft-dunbar-i2nsf-problem-statement-05

=

 

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); draft-du= nbar-i2nsf-problem-statement-05@ietf.org
Cc: = Jayaraghavendran k; i2nsf@ietf.org
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: draft-du= nbar-i2nsf-problem-statement-05@ietf.org
Cc: Linda Dunbar; = Jayaraghavendran k; i2nsf@ietf.org
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

------=_NextPart_000_000D_01D13A69.CB6165B0--