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

Rafa Marin-Lopez <rafa@um.es> Wed, 28 November 2018 11:06 UTC

Return-Path: <rafa@um.es>
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 B01D3130F70; Wed, 28 Nov 2018 03:06:23 -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 8KAWTTV8ZH8d; Wed, 28 Nov 2018 03:06:21 -0800 (PST)
Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9D05C130E27; Wed, 28 Nov 2018 03:06:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id CD0E31FF97; Wed, 28 Nov 2018 12:06:18 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon44.um.es
Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HBtQgBqbhkgw; Wed, 28 Nov 2018 12:06:18 +0100 (CET)
Received: from [155.54.12.16] (unknown [155.54.12.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id C94581FE9E; Wed, 28 Nov 2018 12:06:16 +0100 (CET)
From: Rafa Marin-Lopez <rafa@um.es>
Message-Id: <6036A6CE-A851-4FEB-AB05-6375CE4B1D66@um.es>
Content-Type: multipart/alternative; boundary="Apple-Mail=_49E2A981-B6FA-4649-AF43-E72A2AA0EEE3"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 28 Nov 2018 12:06:16 +0100
In-Reply-To: <37F4E2D9-47C3-450C-B1E8-649FC901DA82@gmail.com>
Cc: Rafa Marin-Lopez <rafa@um.es>, Gabriel Lopez <gabilm@um.es>, Paul Wouters <paul@nohats.ca>, i2nsf@ietf.org, "ipsec@ietf.org WG" <ipsec@ietf.org>
To: Yoav Nir <ynir.ietf@gmail.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>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/jvc_NSZTdBvKAlmXf7lwv3BcyrI>
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, 28 Nov 2018 11:06:24 -0000

Hi Yoav:

> El 27 nov 2018, a las 23:38, Yoav Nir <ynir.ietf@gmail.com> escribió:
> 
> 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”.

The IKE case and IKE-less seems to show clearly both cases. It does not mean your proposal does not but I guess I got used to IKE and IKEless cases now :) apart from the fact the IKE-less reflects clearly that IKE is not shipped in the NSF.

> 
> 
> 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.

It can definitely part of this effort. In fact it was part of this effort. Our earlier version of the I-D (before becoming a WG document) has this case: https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-01#page-18. At some point, and due to our discussions during the presentations of our I-D we decided to get rid of this one and focus on host-to-host and gw-to-gw. However we believe the person you talked to and you are giving good reasons to recover it. 

Having said that, I would like to comment something we noticed when we thought about this case:

In the real case with road-warrior configuration (let us know if we are mistaken) the host would be out of the radar of the Security Controller (let’s think, for example, a mobile phone or a laptop). 

Therefore, with IKE case, the SC could install IKE configuration but no specific to any particular host (which is fine).  

The IKE-less case is more complicated in the sense that if the host cannot be configured by the SC, the host will use IKE but the VPN concentrator won’t have IKE. So the IKE negotiation would have to happen between the host and the SC. If we analyze this and it is posible, we could go for also IKE less. 

If we consider a case where the host can be also configured by the SC, then it is both IKE and IKE-less cases are plausible. 

Most probably we should start to analyzing the simple (and perhaps more realistic) case: road warrior with IKE case where the SC does not configure the host. 

Best Regards.

> 
> Yoav

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------