[I2nsf] Key points of Case 2 of draft-abad-i2nsf-sdn-ipsec-flow-protection and going forward?

Linda Dunbar <linda.dunbar@huawei.com> Thu, 07 September 2017 22:40 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 E96D0132F64; Thu, 7 Sep 2017 15:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 O4c8bKJjThqo; Thu, 7 Sep 2017 15:40:23 -0700 (PDT)
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 AA59C132F56; Thu, 7 Sep 2017 15:40:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DOD73226; Thu, 07 Sep 2017 22:40:20 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 7 Sep 2017 23:40:19 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.148]) by SJCEML703-CHM.china.huawei.com ([169.254.5.62]) with mapi id 14.03.0301.000; Thu, 7 Sep 2017 15:40:14 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Gabriel Lopez <gabilm@um.es>, Rafa Marin-Lopez <rafa@um.es>, "i2nsf@ietf.org" <i2nsf@ietf.org>, IPsecME WG <ipsec@ietf.org>
Thread-Topic: Key points of Case 2 of draft-abad-i2nsf-sdn-ipsec-flow-protection and going forward?
Thread-Index: AdMoKhrSg5961fqcSuSmkATDTzC/MQ==
Date: Thu, 07 Sep 2017 22:40:13 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F65946FFB4@SJCEML702-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.78]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F65946FFB4SJCEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59B1CAD4.0087, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8d25f9a87488bd3b9f4ca0cff3b06e51
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/wZs828N8mU77jec3l0QCo7tfusQ>
Subject: [I2nsf] Key points of Case 2 of draft-abad-i2nsf-sdn-ipsec-flow-protection and going forward?
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.22
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, 07 Sep 2017 22:40:25 -0000

Tero, Gabriel, Rafa, Alejandro, and Interim meeting participants:

Thank you very much for presenting justification for Case 2 & Reasons against Case 2 at yesterday's I2NSF Interim. It is a very productive discussion.

In a nutshell:
Opponents believe Case 2 is technical feasible but very complex;

Proponents understand the technical difficulty but want to describe an approach for pushing the complexity to SDN Controller.

Question to Proponents: What is the advantages of Case 2?

Is the Case 2 for making the NSF simpler to not include an IKE daemon and its configuration files?
 Some people say that all platforms today include an IKE daemon: Windows, Mac, Linux (all distros), even all phones. Do all containers support IKE implementation? How about all VMs?

Question to Opponents:
If it is technical feasible, but have risks, can we document the risks associated with the method in the draft?


Thank you very much.

Linda