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

"Susan Hares" <shares@ndzh.com> Sat, 19 December 2015 19:30 UTC

Return-Path: <shares@ndzh.com>
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 <i2nsf@ietfa.amsl.com>; 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 <i2nsf@ietfa.amsl.com>; 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 <i2nsf@ietf.org>; 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 <shares@ndzh.com>
To: "'Anil Kumar S N (VRP Network BL)'" <anil.sn@huawei.com>, 'Linda Dunbar' <linda.dunbar@huawei.com>, draft-dunbar-i2nsf-problem-statement-05@ietf.org
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: <http://mailarchive.ietf.org/arch/msg/i2nsf/JZVxSGm1wLOPLrlDT_eCvCey6ik>
Cc: 'Jayaraghavendran k' <jayaraghavendran.k@huawei.com>, 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*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Dec 2015 19:30:46 -0000

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