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 <[email protected]> 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:[email protected]] > 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 <[email protected]> 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 > [email protected] > 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: [email protected] ------------------------------------------------------- _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
