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

[Linda Dunbar <[e-mail]>]

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:[e-mail]]
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 <[e-mail]<mailto:[e-mail]>> 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