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>
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/wgRLwRzZVAezquFN_nGMZm0LXdY>
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: [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?
Precedence: list

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=C3=B3:
>=20
> Sowmini,=20
> =20
> You said:
> =E2=80=9CHowever, applying IPsec to specific flows (e.g., those =
defined by a src or dst port on which the service listens) is =
important.=E2=80=9D
> =20
> What is the current operation procedure for Overlay network to inform =
the underlay network on which flows to go through IPSec channel?=20
> =20
> You said:=20
> =E2=80=9C..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.=E2=80=9D
> =20
> =20
> 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?=20
> =20
> =20
> Thanks,=20
> Linda
> =20
> =20
> -----Original Message-----
> From: Sowmini Varadhan [mailto:sowmini05@gmail.com]=20
> 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?
> =20
> 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. =E2=80=9Cunderlay =
network=E2=80=9D).  The flow policy rules are intended to filter out =
unwanted traffic from underlay network so that various attack traffic =
won=E2=80=99t 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?
> =20
> Yes, this is a valid use case, and one that we  are looking at as =
well.
> =20
> > IPSec is supposed to be between two end nodes. Here we assume that =
the Overlay nodes don=E2=80=99t have the resource or capability for =
IPsec, but expect IPsec between flow=E2=80=99s ingress and egress nodes =
(i.e. NVE).
> > Any opinion is appreciated.
> =20
> =20
> >
> > 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?
> =20
> 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.
> =20
> However, applying IPsec to specific flows (e.g., those defined by a =
src or dst port on which the service listens) is important.
> =20
> 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.
> =20
> Like [CJ], I too have to read the draft in greater detail to comment =
further.
> =20
> --Sowmini
> =20
> _______________________________________________
> 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
-------------------------------------------------------