[I2nsf] Let's try to draw closure for sdn-ipsec-flow-protection ( RE: Reviewing sdn-ipsec-flow-protection

Linda Dunbar <linda.dunbar@huawei.com> Wed, 27 February 2019 20:36 UTC

Return-Path: <linda.dunbar@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 0EB02131127 for <i2nsf@ietfa.amsl.com>; Wed, 27 Feb 2019 12:36:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 AwcRY_6_oKHr for <i2nsf@ietfa.amsl.com>; Wed, 27 Feb 2019 12:36:08 -0800 (PST)
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 6F369131123 for <i2nsf@ietf.org>; Wed, 27 Feb 2019 12:36:07 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 04D0E64C7B98C980358C for <i2nsf@ietf.org>; Wed, 27 Feb 2019 20:36:05 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 27 Feb 2019 20:36:03 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.241]) by SJCEML703-CHM.china.huawei.com ([169.254.5.8]) with mapi id 14.03.0415.000; Wed, 27 Feb 2019 12:35:57 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Gabriel Lopez <gabilm@um.es>, Rafa Marin Lopez <rafa@um.es>
CC: "i2nsf@ietf.org" <i2nsf@ietf.org>, =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= <fernando.pereniguez@cud.upct.es>, Yoav Nir <ynir.ietf@gmail.com>
Thread-Topic: Let's try to draw closure for sdn-ipsec-flow-protection ( RE: [I2nsf] Reviewing sdn-ipsec-flow-protection
Thread-Index: AdTO2InvAHwIIG4YQkqS2/M7/lwALg==
Date: Wed, 27 Feb 2019 20:35:56 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B2C71AA@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.84]
Content-Type: multipart/mixed; boundary="_004_4A95BA014132FF49AE685FAB4B9F17F66B2C71AAsjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/M8eAVVu0M27CSI9WZJMjSmwITuk>
Subject: [I2nsf] Let's try to draw closure for sdn-ipsec-flow-protection ( RE: Reviewing sdn-ipsec-flow-protection
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 27 Feb 2019 20:36:12 -0000

Gabriel and Rafa,

What you suggested in this email are all valid options:

·        NSF could provide them by itself during the NSF’s registration process into the controller.

·        the controller receives the capabilities for a set of NSFs from an external entity.

·        IPsec-based NSFs can consider the usage of the capabilities model to inform the security controller about IPsec capabilities.

Can you update the draft before IETF104 (March 11)? So we can start the WG LC during IETF104.
During IETF103, authors of draft-carrel-ipsecme-controller-ike stated that 3rd case (Controller-IKE) should be added to the document. SDWAN depends on the Controller based IKE to scale.
Since draft-carrel-ipsecme-controller-ike has detailed description for Controll-IKE, you only need to simply add a brief description as presented by David and refer to their draft for details.
Something like:

Case 3: Controller-IKE
Controller-IKE is DH based key exchange done through the controller with following characteristics:

¾    All peers send their DH public value to the controller

¾    Controller sends the list of all public values to all peers

¾    All peers calculate a unique pairwise secret for each other peer

¾    No peer-to-peer messages.

Re-keys mechanism is further described in draft-carrel-ipsecme-controller-ike

-----
Because of SDWAN getting more importance for enterprises to reach cloud DCs, scaling IPsec becomes very critical.
Recently, there are multiple initiatives in Routing Area for SD-WAN, all of them need IPsec:
draft-sajassi-bess-secure-evpn
draft-rosen-bess-secure-l3vpn
draft-ietf-rtgwg-net2cloud-problem-statement
draft-ietf-rtgwg-net2cloud-gap-analysis
It will be better if we can smooth out the IPsec scaling solution, and telling routing area not to re-invent the wheel.


Please let us know if you need help in editing the draft to bring it to WGLC.

Linda & Yoav


From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Gabriel Lopez
Sent: Thursday, January 24, 2019 8:24 AM
To: Rafa Marin Lopez <rafa@um.es>;
Cc: i2nsf@ietf.org; Fernando Pereñíguez García <fernando.pereniguez@cud.upct.es>;; Gabriel Lopez <gabilm@um.es>;; Yoav Nir <ynir.ietf@gmail.com>;
Subject: Re: [I2nsf] Reviewing sdn-ipsec-flow-protection

Hi all.


El 14 nov 2018, a las 10:30, Rafa Marin-Lopez <rafa@um.es<mailto:rafa@um.es>> escribió:

Hi Yoav:


El 8 nov 2018, a las 17:11, Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>> escribió:

Hi, all





  *   The interaction between Controller and NSF

     *   There’s no way for the controller to retrieve NSF capabilities. What if the NSF does not implement rc5?  It’s fine if we say that the Controller knows in advance what the capabilities of each NSF are, but it should be stated.

Agree. Nevertheless, I would say that the most correct way is when the controller asks the NSF about capabilities after NSF and controller connect.


Regarding this question, we wonder how the controller knows about the capabilities provided by each IPsec NSF. As Rafa pointed out, one way is that the NSF could provide them by itself during the NSF’s registration process into the controller. Another way is that the controller receives the capabilities for a set of NSFs from an external entity. Following the I2NSF Reference Model in RFC 8329, it is assumed this role is assigned to the “Developer’s Management System”.

In our concrete example where a NSF provides IPsec-based security functions, our understanding of that IPsec capabilities refer the set of features a IPsec NSF node is able to support. A (non-exhaustive) list is:
-           IKE support
-           IKEless support
-           For IKE case: authentication and encryption algorithms, dh_groups, authentication method, NAT traversal support, etc.
-           For IKEless case: authentication, integrity and encryption algorithms, AH support, etc.

We would like to draw attention to IPsec-based NSFs and suggest authors of these drafts to consider the usage of the capabilities model to inform the security controller about IPsec capabilities.

Thanks in advance and best regards, Gabi.




_______________________________________________
I2nsf mailing list
I2nsf@ietf.org<mailto:I2nsf@ietf.org>
https://www.ietf.org/mailman/listinfo/i2nsf

-----------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: gabilm@um.es<mailto:gabilm@um.es>