Re: [I2nsf] Comments on draft-dunbar-i2nsf-problem-statement-05
"Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com> Mon, 23 November 2015 05:03 UTC
Return-Path: <anil.sn@huawei.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 1491A1B3638 for <i2nsf@ietfa.amsl.com>; Sun, 22 Nov 2015 21:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.785
X-Spam-Level:
X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
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 iKEhUMdhMQfc for <i2nsf@ietfa.amsl.com>; Sun, 22 Nov 2015 21:03:54 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730FE1B3615 for <i2nsf@ietf.org>; Sun, 22 Nov 2015 21:03:53 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAR14142; Mon, 23 Nov 2015 05:03:49 +0000 (GMT)
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 23 Nov 2015 05:03:46 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.181]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0235.001; Mon, 23 Nov 2015 13:03:35 +0800
From: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>
To: DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com>
Thread-Topic: [I2nsf] Comments on draft-dunbar-i2nsf-problem-statement-05
Thread-Index: AdEioAyIQfd93omoRVuyqnHeGuMT8AAmR5vwAEe5yYAAVOxPsA==
Date: Mon, 23 Nov 2015 05:03:35 +0000
Message-ID: <327562D94EA7BF428CD805F338C31EF06C07F012@nkgeml512-mbx.china.huawei.com>
References: <327562D94EA7BF428CD805F338C31EF06C07EC8B@nkgeml512-mbx.china.huawei.com> <C9100DC8-1CD1-49A4-AB60-D5BCC60499F3@telefonica.com>
In-Reply-To: <C9100DC8-1CD1-49A4-AB60-D5BCC60499F3@telefonica.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.213.92]
Content-Type: multipart/alternative; boundary="_000_327562D94EA7BF428CD805F338C31EF06C07F012nkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.56529E36.0029, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.181, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c9e5dc008c4f41a75904a489b1769490
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2nsf/LZK5SSexhwoQIeEwfkNkcztUsZw>
X-Mailman-Approved-At: Tue, 24 Nov 2015 08:02:05 -0800
Cc: Jayaraghavendran k <jayaraghavendran.k@huawei.com>, "i2nsf@ietf.org" <i2nsf@ietf.org>, "draft-dunbar-i2nsf-problem-statement-05@ietf.org" <draft-dunbar-i2nsf-problem-statement-05@ietf.org>, Linda Dunbar <linda.dunbar@huawei.com>
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: Mon, 23 Nov 2015 05:03:58 -0000
Hi Diego, Please see inline for response. Thanks & Regards Anil S N “Be liberal in what you accept, and conservative in what you send” - Jon Postel From: DIEGO LOPEZ GARCIA [mailto:diego.r.lopez@telefonica.com] Sent: 21 November 2015 20:28 To: Anil Kumar S N (VRP Network BL) Cc: draft-dunbar-i2nsf-problem-statement-05@ietf.org; Jayaraghavendran k; i2nsf@ietf.org; Linda Dunbar Subject: Re: [I2nsf] Comments on draft-dunbar-i2nsf-problem-statement-05 Hi, A couple of comments in line below… On 20 Nov 2015, at 03:22 , Anil Kumar S N (VRP Network BL) <anil.sn@huawei.com<mailto:anil.sn@huawei.com>> wrote: • 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… DRL> I disagree. Terms like IDS, AAA, ACL or CA are well defined elsewhere, have been of common usage for quite a while, and there is no advantage in redefining them in this document. For what is worth, we could need to define terms like “network” or “TCP”… There may be others like VNFpool that would need a definition because they are by no means widespread, though in those case we should first consider whether the term makes sense in the document, which I’d say it is not the case for “VNFpool” in particular. [[Anil >>]] Sorry my apologies Diego, I should have commented better, I meant to add these under abbreviation section. I didn’t mean to redefine it. • Adding new section : 3.1.9 Lack of mechanism for Key Management/Deterministic Generation and Provisioning for communicating protocols There is a need for a framework/data model for a key management protocol that may be used to create and manage session 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. In March 2006, the Internet Architecture Board (IAB) held a workshop on the topic of "Unwanted Internet Traffic". The report from that workshop is documented in RFC 4948 [RFC4948]. Section 8.1 of that document states that "A simple risk analysis would suggest that an ideal attack target of minimal cost but maximal disruption is the core routing infrastructure". Section 8.2 calls for "Tightening the security of the core routing infrastructure". One of the four main steps were identified for that tightening the security for the protocol packets on the wire. It is concerned with guidelines for describing issues and techniques for protecting the messages between directly communicating peers. Conceptually, when routing protocols send or receive messages, they might need to look up the key to use in this abstract key table. Conceptually, there must be an interface defined for a protocols to make requests of automated key management when it is being used; when keys become available, they might be made available in the key table. There might not be any requirement that this abstraction be used for implementation: 1) I2NSF need to design the key table abstraction, the interface between key management protocols and routing/other protocols, and possibly security protocols at other layers. 2) For each routing/other protocol, I2NSF need to define the mapping between how the protocol represents key material and the protocol- independent key table abstraction. When routing/other protocols share a common mechanism for authentication, such as the TCP Authentication Option, the same mapping is likely to be reused between protocols. An implementation may be able to move much of the keying logic into code related to this shared authentication primitive rather than code specific to routing/other protocols. 3) When designing automated key management for both symmetric keys and group keys, we will only need to use the abstractions designed based on point 1 above to communicate between automated key management and routing/other protocols. DRL> As Linda said, you should clarify what is the purpose for this. The intent of I2NSF is not to define new security functions, but to define an interface to them. And I’d say you are proposing the definition of a new key management service to be used by routing and other protocols. [[Anil >>]] Intention is not to define new security function, intension is to utilize I2NSF as interface/managing framework to utilize KDF for protocol. I have replied in detail to Linda’s mail. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com> Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
- [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