IETF Logo Mail Archive

Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

Linda Dunbar <linda.dunbar@huawei.com> Wed, 05 December 2018 21:29 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D982812D4E7; Wed, 5 Dec 2018 13:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xUf6_dIdqyVh; Wed, 5 Dec 2018 13:29:37 -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 71E30130E95; Wed, 5 Dec 2018 13:29:36 -0800 (PST)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7DEF7E86E6890; Wed, 5 Dec 2018 21:29:31 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 5 Dec 2018 21:29:32 +0000
Received: from SJCEML521-MBB.china.huawei.com ([169.254.6.33]) by SJCEML701-CHM.china.huawei.com ([169.254.3.198]) with mapi id 14.03.0415.000; Wed, 5 Dec 2018 13:29:26 -0800
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Yoav Nir <ynir.ietf@gmail.com>, Gabriel Lopez <gabilm@um.es>
CC: "i2nsf@ietf.org" <i2nsf@ietf.org>, "ipsec@ietf.org WG" <ipsec@ietf.org>, Paul Wouters <paul@nohats.ca>, Rafa Marin Lopez <rafa@um.es>
Thread-Topic: [I2nsf] [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)
Thread-Index: AQHUhnHCQWI/aI09rEKRAvt+rExe0aVkvROAgAv4zeA=
Date: Wed, 05 Dec 2018 21:29:26 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B1F6237@SJCEML521-MBB.china.huawei.com>
References: <A881C135-9BF7-4E93-BB7A-75EB3D1FF605@gmail.com> <6839D47C-4074-486F-9350-8EB7B378036C@um.es> <DAE14995-8504-4134-B021-93D56A4994FB@gmail.com> <alpine.LRH.2.21.1811180149220.25604@bofh.nohats.ca> <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> <alpine.LRH.2.21.1811270826430.2053@bofh.nohats.ca> <B47EE67E-1B50-44BB-9821-AB439CA2C2F1@um.es> <37F4E2D9-47C3-450C-B1E8-649FC901DA82@gmail.com>
In-Reply-To: <37F4E2D9-47C3-450C-B1E8-649FC901DA82@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.11.90]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B1F6237SJCEML521MBBchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/-gHqdGm7gK3PHvJxhG9z38ZxQDY>
Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Dec 2018 21:29:40 -0000

I like the title of  “distributed keying” (case 1) vs “centralized keying” (Case 2).

Linda

From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Tuesday, November 27, 2018 4:39 PM
To: Gabriel Lopez <gabilm@um.es>
Cc: i2nsf@ietf.org; ipsec@ietf.org WG <ipsec@ietf.org>; Paul Wouters <paul@nohats.ca>; Rafa Marin Lopez <rafa@um.es>
Subject: Re: [I2nsf] [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)

A couple of remarks (with no hats)

If we’re bikeshedding the names, I think the difference is that in one case the two NSFs generate traffic keys between themselves, and in the other it is the controller that generates the keys for them.  So how about “distributed keying” vs “centralized keying”, or perhaps “automatic keying” vs “SDN keying”.


Also, I have been asked by someone not on this list whether our work covers the road warrior use case. I said it didn’t and wondered why. So I got these points:

  *   Road warriors are numerous and not where the administrator can configure them manually.
  *   Additionally, the configuration of what networks, gateways (NSFs), and resources a road warrior may access (in IPsec terms, the SPD and PAD) change often.
  *   Because of the above, some automatic method of configuring SPD and PAD is needed.
  *   There is also the issue of multiple VPN gateways covering similar domains, and VPN gateways being overloaded or down for maintenance, as well as malfunctions in the network behind those VPN gateways. So the decision on which gateway a road warrior should use to access a particular resource is also a natural question to ask an SDN controller.

Since I used to work for a VPN vendor, I can tell you what our product did:

  *   The current configuration was formatted (automatically by a management function) as a text file that the road warrior downloaded through the VPN gateway (the gateway doubled as a server serving this one file)
  *   The proper gateway to connect to was determined by pinging all gateways that were possible according to the configuration file.
  *   This did not account for any internal networking issues.

I don’t know if this should be part of *this* effort, but there is a use case for road warrior SDN.

Yoav

v2.23.0 | Report a Bug | By Email