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
- [I2nsf] Comments on draft-dunbar-i2nsf-problem-st… Anil Kumar S N (VRP Network BL)
- Re: [I2nsf] Comments on draft-dunbar-i2nsf-proble… Linda Dunbar
- Re: [I2nsf] Comments on draft-dunbar-i2nsf-proble… DIEGO LOPEZ GARCIA
- Re: [I2nsf] Comments on draft-dunbar-i2nsf-proble… Sumandra Majee
- Re: [I2nsf] Comments on draft-dunbar-i2nsf-proble… Anil Kumar S N (VRP Network BL)
- Re: [I2nsf] Comments on draft-dunbar-i2nsf-proble… Anil Kumar S N (VRP Network BL)
- Re: [I2nsf] Comments on draft-dunbar-i2nsf-proble… Susan Hares