Re: [nvo3] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface?

Rafa Marin Lopez <rafa@um.es> Fri, 17 June 2016 12:49 UTC

Return-Path: <rafa@um.es>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5FB12D0CC; Fri, 17 Jun 2016 05:49:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=unavailable 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 G0a9pnQObMag; Fri, 17 Jun 2016 05:49:22 -0700 (PDT)
Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id EAC7912D5FF; Fri, 17 Jun 2016 05:43:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 70CC264A0; Fri, 17 Jun 2016 14:43:07 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon22.um.es
Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G1-U6OyKEO8v; Fri, 17 Jun 2016 14:43:07 +0200 (CEST)
Received: from eduroam_um-7-168.inf.um.es (eduroam_um-7-168.inf.um.es [155.54.7.168]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon22.um.es (Postfix) with ESMTPSA id 35A9FCE5; Fri, 17 Jun 2016 14:43:03 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb>
Date: Fri, 17 Jun 2016 14:43:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es>
References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <CACP96tSfp4XEU9mKzRD=Dm5hMDGN7uGiM6Eje5-_udiDXWLwsA@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb>
To: Linda Dunbar <linda.dunbar@huawei.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/FiuC9LimW99guWFadgwu3s0E2tE>
Cc: "I2NSF@ietf.org" <I2NSF@ietf.org>, Sowmini Varadhan <sowmini.varadhan@oracle.com>, NVO3 <nvo3@ietf.org>, Rafa Marin Lopez <rafa@um.es>, Sowmini Varadhan <sowmini05@gmail.com>, Liyizhou <liyizhou@huawei.com>
Subject: Re: [nvo3] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface?
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2016 12:49:24 -0000

Dear all:

Maybe this I-D might be interesting and related with this discussion regarding IPsec/IKE management. We hope to have an updated version soon and a proof-of-concept implementation of some of the scenarios.

https://tools.ietf.org/html/draft-abad-sdnrg-sdn-ipsec-flow-protection-01

Best Regards.


> El 17 jun 2016, a las 10:43, Linda Dunbar <linda.dunbar@huawei.com> escribió:
> 
> Sowmini, 
>  
> You said:
> “However, applying IPsec to specific flows (e.g., those defined by a src or dst port on which the service listens) is important.”
>  
> What is the current operation procedure for Overlay network to inform the underlay network on which flows to go through IPSec channel? 
>  
> You said: 
> “..But that also made me wonder about the interaction between IPsec/IKE and the proposed BGP FS (IPsec is frequently used between end-systems that do not want to run a BGP daemon). Since the config information that needs to be distributed are things like keys, algorithms etc to populate the sadb/spd, IKE looks more appropriate in most cases.”
>  
>  
> Does the underlay network controller get some information (or hint from the Overlay network controller) on how the keys are configured for the IPSec tunnel for the specific flows among the Overlay nodes? 
>  
>  
> Thanks, 
> Linda
>  
>  
> -----Original Message-----
> From: Sowmini Varadhan [mailto:sowmini05@gmail.com] 
> Sent: Thursday, June 16, 2016 10:57 AM
> To: Linda Dunbar
> Cc: Liyizhou; NVO3; Sowmini Varadhan
> Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting IPSec connection from the Underlay for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface?
>  
> On Wed, Jun 15, 2016 at 8:55 AM, Linda Dunbar <linda.dunbar@huawei.com> wrote:
> >
> > NVO3 Participants,
> >
> >
> >
> > I2NSF (Interface to Network Security function) has a work item in defining the flow security policy between domains (which includes inquiry of the capability from one domain to another and the actual flow policy rules from one domain to another).
> >
> > Very often, the paths (or links) among nodes of a overlay network are provided by other network operators (a.k.a. “underlay network”).  The flow policy rules are intended to filter out unwanted traffic from underlay network so that various attack traffic won’t saturated the access links to the overlay nodes.
> >
> >
> >
> > One interesting scenario brought up is Overlay nodes may need to request some traffic to be traversing IPsec channel. To achieve this goal, it is necessary for Overlay Network controller to inquire if the needed IPsec resource are even available before send the request (may even involve AAA process between controllers of each corresponding domain ).
> >
> >
> >
> > Want to have a survey if people see the use case of Overlay Network needing portion of traffic to be through IPSec channel?
>  
> Yes, this is a valid use case, and one that we  are looking at as well.
>  
> > IPSec is supposed to be between two end nodes. Here we assume that the Overlay nodes don’t have the resource or capability for IPsec, but expect IPsec between flow’s ingress and egress nodes (i.e. NVE).
> > Any opinion is appreciated.
>  
>  
> >
> > Are there any use cases of overlay network needing IPSec among their nodes only for a specific time span? i.e. Time based IPSec connection?
>  
> Time based IPsec connection is not a use-case we have encountered.
> People usually use IKE for periodic key-rollover, if that is the goal.
>  
> However, applying IPsec to specific flows (e.g., those defined by a src or dst port on which the service listens) is important.
>  
> But that also made me wonder about the interaction between IPsec/IKE and the proposed BGP FS (IPsec is frequently used between end-systems that do not want to run a BGP daemon). Since the config information that needs to be distributed are things like keys, algorithms etc to populate the sadb/spd, IKE looks more appropriate in most cases.
>  
> Like [CJ], I too have to read the draft in greater detail to comment further.
>  
> --Sowmini
>  
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf

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