Re: [nvo3] : 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?

Linda Dunbar <linda.dunbar@huawei.com> Thu, 16 June 2016 08:17 UTC

Return-Path: <linda.dunbar@huawei.com>
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 B968B12B015; Thu, 16 Jun 2016 01:17:21 -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 A953l7s2SdB8; Thu, 16 Jun 2016 01:17:20 -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 96B3C12B027; Thu, 16 Jun 2016 01:07:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQX12941; Thu, 16 Jun 2016 08:07:33 +0000 (GMT)
Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 16 Jun 2016 09:07:32 +0100
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 01:07:21 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Lou Berger <lberger@labn.net>, Liyizhou <liyizhou@huawei.com>, NVO3 <nvo3@ietf.org>
Thread-Topic: : 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?
Thread-Index: AQHRx6YbXT5qJk0N50+rgdw7Em/z2g==
Date: Thu, 16 Jun 2016 08:07:20 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657EB5155@dfweml501-mbb>
References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <d47517f0-b1b7-950d-ac81-04f16af591b8@labn.net>
In-Reply-To: <d47517f0-b1b7-950d-ac81-04f16af591b8@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.220.134.143]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.57625E46.0082, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 89c24c6a5d6000a8c48646f30678f5ea
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/SyzyuruJpoScB6cGuMkejh6wawE>
Cc: "I2NSF@ietf.org" <I2NSF@ietf.org>
Subject: Re: [nvo3] : 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?
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: Thu, 16 Jun 2016 08:17:22 -0000

Lou, 

Thanks for the confirmation of the use case. 

Two questions related to Overlay IPSec tunnel being provided by Underlay network: 

1) Are there any cases when overlay network nodes don't normally need IPSec tunnel among their nodes for normal traffic. Only for some special occasions needing the IPSec tunnels for a portion of the traffic among subset of overlay nodes? 

2) If the answer to the above question is YES, then are there any cases that Overlay nodes don't have the resource or capability to establish IPSec Tunnels among themselves for the special traffic that need IPSec, therefore, would like to request the underlay network to establish IPSec tunnel between the directly attached NVE nodes?  

For examples,  the Virtual Switch embedded in servers may not have the needed IPSec capability as majority of its traffic don't need to be over IPSec channels.

If Overlay network nodes need the underlay network to establish IPsec tunnels for some specific traffic, should the request come from the Overlay network controller (or management system) because the request needs to consume resources and may need extra billing involved? In addition, the Overlay network needs to query if the underlay network can provide the needed Tunnel, correct? 

I2NSF Service Layer interface specifies the Flow Security Policy North bound to controller, which can be used by Overlay network controller to inquire the capability provided by the underlay and to set the actual Flow Policy to the underlay (via the controller).

Thanks, Linda

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Wednesday, June 15, 2016 10:00 AM
To: Linda Dunbar; Liyizhou; NVO3
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?


Yes -- this is a real use case.

This use case (overlays interconnected over IPsec tunnels with NVE end
points) motivated our work on RFC5566 and we built supported for it (as well as other tunnel technologies) in a quagga based NVO3 controller. 
This code is publicly available, but is not yet part of a standard quagga release.

Lou

On 6/15/2016 8:55 AM, Linda Dunbar 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?
>
> 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.
>
> Thanks,
>
> Linda
>
>  
>
> *From:*Linda Dunbar
> *Sent:* Tuesday, June 14, 2016 4:03 PM
> *To:* 'christian.jacquenet@orange.com'; BOUCADAIR Mohamed IMT/OLN
> *Cc:* I2NSF@ietf.org
> *Subject:* 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?
>
>  
>
> Christian,
>
>  
>
> Your feedback seems to suggest that Overlay network Controller may 
> send request to the underlay network controller requesting IPsec 
> connections among overlay nodes. Do I understand you correctly?
>
>  
>
> 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?
>
>  
>
> Linda
>
>  
>
> *From:*christian.jacquenet@orange.com
> <mailto:christian.jacquenet@orange.com>
> [mailto:christian.jacquenet@orange.com]
> *Sent:* Monday, June 13, 2016 11:23 AM
> *To:* Linda Dunbar; BOUCADAIR Mohamed IMT/OLN
> *Subject:* RE: Any feedback on the Protocol Independent Flow Security 
> Policies exchanged over I2NSF service layer interface?
>
>  
>
>  
>
> *[snip]*
>
>  
>
>  
>
>  
>
> Very often, the paths (or links) among nodes of a overlay network are 
> provided by other network operators (a.k.a. "underlay network").  Very 
> much like traditional networks placing FW (Firewall) or IPS (Intrusion 
> Prevention System) on the wire to enforce the flow security rules, 
> I2NSF *_Protocol Independent Flow Security Policies_* can be used by 
> overlay networks to request certain flow based security rules to be 
> enforced by its underlay networks, to prevent the unwanted attacks 
> traffic from occupying the physical links and ports to the overlay 
> network nodes, and to avoid the overlay nodes' CPU/Storage/Port 
> utilization being consumed down by the various attacks.  Here is one 
> example of "Overlay Video Communication network" exchange Flow 
> Policies to the Underlay network.
>
>  
>
>  
>
> cid:image001.png@01D1B516.7F74E410
>
>  
>
> */[CJ] /*The above example clearly shows the necessary interaction 
> between the two PDPs/controllers, to make sure that decisions made by 
> the network controller accommodate the needs of the video customer as 
> possibly expressed towards the video controller: for example, customer 
> demands that the confidentiality of the videoconference needs to be 
> preserved, thereby suggesting the use of the IPsec protocol suite. The 
> video controller may enforce an IPsec design based upon the transport 
> mode, whereas the network controller is solicited to allocate IPsec 
> resources (read for example no AH, ESP in NULL mode) accordingly. This 
> may possibly raise conflicting configuration tasks (the video 
> controller uses AH, the network controller doesn't), thereby leading 
> to inconsistency that may jeopardize the service. Whether BGP FS is 
> used to carry security policy information between the two controllers 
> is hardly the point, imho: what matters is the consistency of the 
> (flow-based security policies enforced by both parties, and which 
> should be derived from the customer's requirements (if any).
>
> The goal of I2NSF is to specify the common information model and data 
> model for the *_ Protocol Independent Flow Security Policies _*which 
> can be queried and set between domains.
>
> [CJ] OK.
>
> * *
>
> https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mit
> igation-api/ is just the starting point. (needs more work to improve 
> the clarity).
> We are asking if people to express their opinion on this work to the 
> I2NSF@ietf.org <mailto:I2NSF@ietf.org> list.
>
> [CJ] I need to read this draft and will get back to you accordingly, 
> but this may take a couple of weeks as I'm pretty busy for the time being.
>
>  
>
> I'll let Med further comment as appropriate.
>
>  
>
> Cheers,
>
>  
>
> Christian.
>
>  
>
> Thanks, Linda
>
>  
>
> ______________________________________________________________________
> ___________________________________________________
>  
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>  
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3