IETF Logo Mail Archive

[I2nsf] One comment on draft-ietf-i2nsf-sdn-ipsec-flow-protection-02:

"Xialiang (Frank, Network Integration Technology Research Dept)" <frank.xialiang@huawei.com> Thu, 12 July 2018 01:13 UTC

Return-Path: <frank.xialiang@huawei.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FEB130DD8; Wed, 11 Jul 2018 18:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UlV3Zs1IJVk0; Wed, 11 Jul 2018 18:13:05 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 029E812F1A2; Wed, 11 Jul 2018 18:13:05 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 35B8863CDC86E; Thu, 12 Jul 2018 02:13:00 +0100 (IST)
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 12 Jul 2018 02:13:01 +0100
Received: from DGGEML522-MBX.china.huawei.com ([169.254.7.143]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0382.000; Thu, 12 Jul 2018 09:12:56 +0800
From: "Xialiang (Frank, Network Integration Technology Research Dept)" <frank.xialiang@huawei.com>
To: "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" <draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org>
CC: "i2nsf@ietf.org" <i2nsf@ietf.org>
Thread-Topic: One comment on draft-ietf-i2nsf-sdn-ipsec-flow-protection-02:
Thread-Index: AdQZfVBmSmNC/oFwQjO5wfbxXoT30w==
Date: Thu, 12 Jul 2018 01:12:55 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F12BE354B7@DGGEML522-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.159.76]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BE354B7DGGEML522MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/-M1uX7w8_aUNmOfl-YsCYjbpsN4>
Subject: [I2nsf] One comment on draft-ietf-i2nsf-sdn-ipsec-flow-protection-02:
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 12 Jul 2018 01:13:07 -0000

Hi authors,
In Section 5.2.1, to avoid exposure of other nodes once one node is compromised, key materials for each pair must be different and irreversible, this may cause performance issue with controller with large network during initial setup and rekey.

So, to distribute some of the SA key calculation to each device while still avoiding negotiation latency, the other options is that controller can send common key material to all NSFs, then NSF calculates actual SA key using the common key and known local, peer info. This way, both peers can generate Tx SA and Rx SA without negotiating with each other, also, the keys will be unique for each tunnel.

Will you consider this option?

Thanks!

B.R.
Frank

v2.23.0 | Report a Bug | By Email