Subject: [I2nsf] Can Overlay nodes see any difference on how ECMP is used by the underlay in building the IPSec tunnels for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface?

From: Linda Dunbar <[email-masked]>
Date: Thu, 16 Jun 2016 08:15:21 +0000

Xiao Hu and Tom, 

Do you think that Overlay nodes will see any difference on How ECMP is used by the underlay to build the IPSec tunnel between Ingress/Egress nodes for the overlay network nodes? 

If yes, how can Overlay controller specify its specific requests to the underlay? Is "needing ECMP" or "Don't care ECMP" be good enough? 

Thanks, Linda

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, June 15, 2016 11:28 PM
To: Xuxiaohu
Cc: Lou Berger; Linda Dunbar; Liyizhou; NVO3; [email-masked]
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:03 PM, Xuxiaohu <[email-masked]> wrote:
> Hi Lou,
>
> If IPsec tunnels are used within data centers, the security need is well satisfied. However, the ECMP capability built on the UDP tunnels is lost at all. So, how about encapsulating IPsec ESP over UDP tunnels for load-balancing improvement purpose? Note that this ESP-over-UDP encapsulation is different from the ESP-over-UDP encapsulation as described in RFC3948: the former uses the UDP tunnel for load-balancing improvement purpose and therefore the source port is used as an entropy field, in contrast, the latter uses the UDP tunnel for NAT traversal purpose and therefore the source port is set to a constant value (i.e.,4500).
>
> By the way, I had wrote a draft about this ESP-over-UDP approach (w/o submission) three years ago when considering how to use UDP tunnels to transport MPLS and IP traffic. If there is enough interest on this ESP-over-UDP approach, I can update it and then submit it for further discussion.
>
Using the flow label for ECMP (RFC6438) solves this problem without requiring the additional overhead of a UDP header.

Tom

> Best regards,
> Xiaohu
>
>> -----Original Message-----
>> From: nvo3 [mailto:[email-masked]] On Behalf Of Lou Berger
>> Sent: Wednesday, June 15, 2016 11:00 PM
>> 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:* [email-masked]'; BOUCADAIR Mohamed IMT/OLN
>> > *Cc:* [email-masked]
>> > *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:[email-masked]
>> > <mailto:[email-masked]>
>> > [mailto:[email-masked]]
>> > *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.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > */[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 [email-masked] <mailto:[email-masked]> 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
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/nvo3
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nvo3
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 16 Jun 2016 08:07:20 +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:[email-masked]] 
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?

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:
> 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.
>
>  
>
> 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 ).
>
>  
>
> 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).
>
>  
>
> 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
>
>  
>
> *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.
>
>  
>
>  
>
>
>  
>
> 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 
> [email-masked] <mailto:[email-masked]> 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.
>
>  
>
> ______________________________________________________________________
> 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.
>  
> 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.
>
>

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 16 Jun 2016 08:54:35 +0000

Linda,

To maximize the bandwidth utilization within data center networks, it's much desirable to transport traffic between two NVE/PE nodes across ECMPs of the underlay. It has nothing to do with overlay nodes and overlay controllers.

Best regards,
Xiaohu

> From: Linda Dunbar
> Sent: Thursday, June 16, 2016 4:15 PM
> To: Tom Herbert; Xuxiaohu; [email-masked]
> Cc: Lou Berger; Liyizhou; NVO3; [email-masked]
> Subject: Can Overlay nodes see any difference on how ECMP is used by the
> underlay in building the IPSec tunnels for a specific time span? (was : Flow
> Do you think that Overlay nodes will see any difference on How ECMP is used by
> the underlay to build the IPSec tunnel between Ingress/Egress nodes for the
> overlay network nodes?
> 
> If yes, how can Overlay controller specify its specific requests to the underlay? Is
> "needing ECMP" or "Don't care ECMP" be good enough?
> 
> Thanks, Linda
> 
> Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting IPSec
> connection from the Underlay for a specific time span? (was : Flow Security
> > If IPsec tunnels are used within data centers, the security need is well satisfied.
> However, the ECMP capability built on the UDP tunnels is lost at all. So, how
> about encapsulating IPsec ESP over UDP tunnels for load-balancing
> improvement purpose? Note that this ESP-over-UDP encapsulation is different
> from the ESP-over-UDP encapsulation as described in RFC3948: the former uses
> the UDP tunnel for load-balancing improvement purpose and therefore the
> source port is used as an entropy field, in contrast, the latter uses the UDP
> tunnel for NAT traversal purpose and therefore the source port is set to a
> constant value (i.e.,4500).
> >
> > By the way, I had wrote a draft about this ESP-over-UDP approach (w/o
> submission) three years ago when considering how to use UDP tunnels to
> transport MPLS and IP traffic. If there is enough interest on this ESP-over-UDP
> approach, I can update it and then submit it for further discussion.
> >
> >> > consistency of the (flow-based security policies enforced by both parties,
> and which should be derived from the customer's requirements (if any).
> >> >

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 17 Jun 2016 08:43:56 +0000

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-masked]]
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-masked]<mailto:[email-masked]>> 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).

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 17 Jun 2016 14:43:02 +0200

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-masked]> escribió:
> 
> Sowmini, 
>  
> You said:
> On Wed, Jun 15, 2016 at 8:55 AM, Linda Dunbar <[email-masked]> wrote:
> >
> > NVO3 Participants,
> >
> >
> >
> I2nsf mailing list
> [email-masked]
> 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-masked]
-------------------------------------------------------

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 17 Jun 2016 20:50:47 +0000

Rafa,

Quickly reading through your draft, I have a few questions:

- Do you mean that the (SDN) controller will be responsible for distributing the needed information to the end nodes of the IPSec tunnel When you say "SDN controller takes the role of the Internet Key Exchange (IKE) entity in the IPsec architecture"?

- Section 8.1: Page 11: Bullet 1:
      You stated that the node sends the first packet to Controller for the controller to determine if the traffic needs to go through IPSec tunnel.

      Shouldn't the controller get flow protection policy from clients (north bound interface) and inform the needed end nodes on what traffic/flows need to go through the IPSec tunnel?

- Section 8.1: Page 12: Bullet 3:
      The controller can't really enforce the rule. but instead requesting the "End Node" to encapsulate the IPSec tunnel around the flows that need to be through the IPSec tunnel. correct?

- Section 6, Page 7, Second paragraph after the Figure 2:
      The Controller should send the IPSec tunnel request to the end points of the desired IPSec tunnel. Also the controller should send query to the end point to check if they have the needed resource to establish the desired IPSec tunnel.

- Section 8.2:
      Second paragraph: When the two end points of the needed IPSec tunnel are in two different ISPs (say ISP-A and ISP-B), your draft states that the ISP-A controller has to negotiate with ISP-B controller on the Flow Security policy rules. What information will be carried by those Policy Rules? Since I2NSF is to specify the data models for those rules, it would be very helpful to identify the information exchanged first.

      Page 13: bullet 2: before the negotiation between the two controllers on the SPD policies and IKE credentials, don't you think that they need to inquire each other if the other party has the needed resource for the needed IPsec tunnel?

Thanks, Linda

-----Original Message-----
From: Rafa Marin Lopez [mailto:[email-masked]]
Sent: Friday, June 17, 2016 7:43 AM
To: Linda Dunbar
Cc: Rafa Marin Lopez; Sowmini Varadhan; [email-masked]; Sowmini Varadhan; NVO3; Liyizhou
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?

Dear all:

Best Regards.

-------------------------------------------------------
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-masked]
-------------------------------------------------------

---

From: Sowmini Varadhan <[email-masked]>
Date: Fri, 17 Jun 2016 17:21:39 -0400

On (06/17/16 08:43), Linda Dunbar wrote:
>    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?

there are 2 aspects to this

- for the underlay network, as nodes/NVEs appear, the controller 
  needs to update the relevant nodes, because, as you pointed out,
  ipsec SAs are between 2 end-points, so all the needed pair-wise
  associations need to be set up. 

- overlay -> underlay communication- overlay network needs some way
  to tell the underlay which flows need to the ipsec transforms
  (and what ipsec config params to use for those transforms). At the 
  moment we have a simplistic model for achieving this, but
  this obviously needs to scale. One way would be by orchestrating this
  via some management connection to the controller.

--Sowmini

---

From: Sowmini Varadhan <[email-masked]>
Date: Fri, 17 Jun 2016 17:26:48 -0400

On (06/17/16 20:50), Linda Dunbar wrote:
>    You stated that the node sends the first packet to Controller for the
>    controller to determine if the traffic needs to go through IPSec tunnel.
>     

I had a related question Section 8.2, #2 as well: is the first
data packet in the clear or not?  If it is not in the clear, how
can you determine the flow in the general case? If it is in 
the clear, what is the scope of the security consideration?

--Sowmini

---

From: Rafa Marin Lopez <[email-masked]>
Date: Sun, 19 Jun 2016 20:06:17 +0200

Dear Linda:

Thank you for reviewing our I-D. Please see my comments inline.

> El 17 jun 2016, a las 22:50, Linda Dunbar <[email-masked]> escribió:
> 
> Rafa, 
>  
> - Do you mean that the (SDN) controller will be responsible for distributing the needed information to the end nodes of the IPSec tunnel When you say "SDN controller takes the role of the Internet Key Exchange (IKE) entity in the IPsec architecture”?

[Rafa] Correct. That is the general idea in this I-D. SDN controller can also send IKE credentials to the network resources if they implement IKE (besides IPsec stack of course)

> Shouldn't the controller get flow protection policy from clients (north bound interface) and inform the needed end nodes on what traffic/flows need to go through the IPSec tunnel?

[Rafa] Actually, there are two options. The one shown in the I-D is reactive, that is,  very similar as it would happen with the OpenFlow PacketIn message and then PacketOut. The other option, of course, it is to create the rules in the network resource even when traffic has not been observed yet (proactive). Both options are completely possible. We can clarify this in the next version.

> The controller can't really enforce the rule. but instead requesting the "End Node" to encapsulate the IPSec tunnel around the flows that need to be through the IPSec tunnel. correct?

[Rafa] Not sure why you think the controller can’t enforce the rule. Basically the step 3 says the controller is filling a SAD entry without the need of running IKE between network resources.

> The Controller should send the IPSec tunnel request to the end points of the desired IPSec tunnel. Also the controller should send query to the end point to check if they have the needed resource t…

[Rafa] What do you mean with “IPsec tunnel request”? By sending the information related with the IPsec tunnel (e.g. a SAD entry) to build it should be enough, I guess that is what you mean by that , right?.

The controller can of course verify if the end points of the IPsec SA have the information to establish an IPsec tunnel according to the information that the controller keeps. If the state is not there or is going to be outdated it can enforce the information again. Alternatively, the end points could also inform when something is required to the controller (reactive) so the controller can act accordingly.

> Second paragraph: When the two end points of the needed IPSec tunnel are in two different ISPs (say ISP-A and ISP-B), your draft states that the ISP-A controller has to negotiate with ISP-B control…

[Rafa] We can specify better what information in the following draft. But basically we have two models explained in the draft when 1) IKE is implemented in the network resource or when IKE is not implemented in the network resource.  

In 1) parameters to run an IKE SA between GW1 and GW2 must be negotiated (IKE credential, cryptographic suite, etc…) and the different SPD entries of the SPD that apply. An SPD entry has parameters such as Remote IP Address, Local IP Address, Next Layer Protocol, Name, Local and Remote Ports.

In 2) apart from SPD entries you need to configure SAD entries. This information implies Security Parameter Index, Sequence Number, AH information (keys , key lifetime) , ESP information… etc.

We can detail what information is required.

> Page 13: bullet 2: before the negotiation between the two controllers on the SPD policies and IKE credentials, don't you think that they need to inquire each other if the other party has the needed…

[Rafa] But for that, what kind of parameters do you send to ask the question? I can imagine you could ask : do you have an end point with this IP address, IKE support, AH or ESP support… etc…? Is that what you have in mind?

In any case, if they do not have that support trying the negotiation between the two controllers would fail so that you would notice that the needed resource is not available as well, right?

Best Regards.
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Rafa Marin Lopez <[email-masked]>
Date: Sun, 19 Jun 2016 20:06:48 +0200

Dear Sowmini:

Thanks for asking about our I-D.

> El 17 jun 2016, a las 23:26, Sowmini Varadhan <[email-masked]> escribió:
> 
> can you determine the flow in the general case? 

[Rafa] Please be aware that, if ESP (AH does not encrypt the packet) has been applied to the packet before reaching the GW1 the IP header of that packet is still visible (it is not encrypted). And based on that information there would be SPD entries so that the IPsec implementation would act based on that visible information. Thus, adding the controller does not change that behavior. So I am not sure the issue/problem you may have in mind.

> If it is in 

[Rafa] Not sure about what do you mean? Are you referring to section 9 or other aspect?

---

From: Sowmini Varadhan <[email-masked]>
Date: Sun, 19 Jun 2016 17:45:43 -0400

On (06/19/16 20:06), Rafa Marin Lopez wrote:
> [Rafa] Please be aware that, if ESP (AH does not encrypt the packet)
> has been applied to the packet before reaching the GW1 the IP header of
> that packet is still visible (it is not encrypted). And based on that
> information there would be SPD entries so that the IPsec implementation
> would act based on that visible information. Thus, adding the controller
> does not change that behavior. So I am not sure the issue/problem you
> may have in mind.

if the first packet is using AH, then the sender has alredy made
some assumption about the auth key. How is the receiver going to
know that key (assuming that AH has been added for a reason)? 
And what is the point of  the following (quoted from Section 8.2)
if the sender is already making some assumptions about the AH
parameters for the first packet?

   "2.  The SDN Controller looks for security policies in its SPD table
       and decides that the flow MUST be protected, for example, with
       IPsec ESP in tunnel mode.

   3.  The SDN controller derives keys for the IPsec tunnel and enforces
       them, along with other information required, such as IPsec mode
       (ESP or AH), into both gateways' IPsec Security Association
       Database (SAD)."

To put this in another way, isnt this a chicken-and-egg problem:
receiver is supposed to use the first data packet figure out the
sadb/spd configuration (which may or may not include both AH and ESP),
but the first packet itself has some AH  (with no ESP) based on <what
negotiation?>?

> [Rafa] Not sure about what do you mean? Are you referring to section

Is the IPsec SA/SPD negotiated in Section 8.1 applicable/different
for the first packet compared  to the rest of the flow?

--Sowmini

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 20 Jun 2016 01:29:12 +0200

Dear Sowmini:

> El 19 jun 2016, a las 23:45, Sowmini Varadhan <[email-masked]> escribió:
> 

[Rafa] The quick answer would be the controller have to install what is required in both end points. However, from your questions, we have to clarify first what is the use case we are discussing, which is the following:

host1-—gw1——IPsec——gw2—-host2. 

That is, a typical GW-to-GW scenario for IPsec tunnel.

Imagine that host1 sends a IP packet to host2. The gw1 will get the IP packet and it has to determine what to do. The gw1 contacts the controller and the controller installs what it is required in both gw1 and gw2 (e.g. IPsec tunnel in ESP mode, and the key material). With that information the gw1 can tunnel the IP packet coming from host1 to host2 inside a IPsec tunnel whose endpoints are gw1 and gw2. Thus, IPsec SA is between gw1 and gw2 and the controller configures both.

That would be the reactive case because everything is triggered in the first packet arriving the gw1. I agree that gw1 must have something like a default behavior saying “go to the controller when you do not know what to do” (which is similar to packetin in openflow).

Another approach is to just sending the SPD/SAD entries to gw1 and gw2 (the controller knows that from the policies obtained from the northbound api) even when either gw1 or gw2 have not observed any traffic with those features. That is what I called proactive.   

>       Database (SAD).”

[Rafa] As you can see, this text applies to the example I just mentioned. Do you want to consider IPsec between host1 to host2 in an end-to-end fashion (transport mode)? If the answer is yes, that should be fairly similar. We can add also that use case to the next version of the I-D.  
> To put this in another way, isnt this a chicken-and-egg problem:

[Rafa] I do not think so.
> but the first packet itself has some AH  (with no ESP) based on <what

[Rafa] I mentioned AH just to show that packets may be still in clear. In any case, to your question and considering our example, if the first packet coming from host1 to host2 through gw1 has AH, it does not matter for gw1.  

It would mean that there is some an IPsec SA AH in transport mode between host1 and host2. The behavior in the gw1 will be same as described above because they are different IPsec SA between different end-points (host1-host2 and gw1-gw2).

Now, you may ask: how does host1 know that the IP packet to host2 must be protected with AH. If we follow the approach of using a controller, the controller should have installed IPsec policies in both host1 and host2.

> for the first packet compared  to the rest of the flow?

No, it isn’t. This first packet that triggers everything (in the reactive case) will be protected in the same way that the rest of the flow.

Although perhaps you question is related to what I have just mentioned about the behavior regarding the first packet: "go to the controller when you do not know what to do”. This is a new behavior... I agree (it is something like OpenFlow does) that we should definitely describe for the reactive case. In the proactive case, no need for that. 

Best Regards.

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 20 Jun 2016 13:41:48 +0000

Rafa,

I see that your draft has identified multiple cases of SDN controlled IPSec tunnel.

As I2NSF focus on specifying the data models for the Flow Security Policies, the controller "Proactively" setting up the IPSec polices/keys to network elements are within the I2NSF scope.

The "reactive option, that is,  very similar as it would happen with the OpenFlow PacketIn message and then PacketOut" is not in the I2NSF scope. However, the specifying the data model for the policy to the controller on which flows to be protected by IPSec tunnel should be in the I2NSF scope.

Other comments are inserted below

-----Original Message-----
From: Rafa Marin Lopez [mailto:[email-masked]]
Sent: Sunday, June 19, 2016 1:06 PM
To: Linda Dunbar
Cc: Rafa Marin Lopez; [email-masked]; [email-masked]; Sowmini Varadhan; Sowmini Varadhan
Subject: Re: [IPsec] [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?

<snip>

[Linda] so the I2NSF should only focus on specifying the protocols and data models for the “Protective” methods. Maybe part of your draft can be further developed in I2NSF WG.

[Linda] Are you assuming that data packets actually traversing the “Controller”? If yes, the I2NSF focus on the flow policy north bound to the controller.

[Linda] Yes.

[Linda] above is what I call “query”. Need to flush out the detailed data model for your IPSec case in I2NSF WG.

[Linda] that will be useful. Can you write this detailed information exchange for I2NSF?

[Linda] correct.

Thanks, Linda

Best Regards.
> Cc: Rafa Marin Lopez; Sowmini Varadhan; [email-masked]<mailto:[email-masked]>; Sowmini
> Varadhan; NVO3; Liyizhou
> > El 17 jun 2016, a las 10:43, Linda Dunbar <[email-masked]<mailto:[email-masked]>> escribió:
> >
> > Sowmini,
> >
> > You said:
> > [email-masked]<mailto:[email-masked]>
> Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

-------------------------------------------------------
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-masked]<mailto:[email-masked]>
-------------------------------------------------------

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 22 Jun 2016 17:13:15 +0200

Hi Linda:

> El 20 jun 2016, a las 15:41, Linda Dunbar <[email-masked]> escribió:
> 
> Rafa, 
>  

I see.

> The "reactive option, that is,  very similar as it would happen with the OpenFlow PacketIn message and then PacketOut" is not in the I2NSF scope. However, the specifying the data model for the poli…

Please be aware that some reactive (upon an event) behavior may be required even when the controller sets up the IPsec policies/keys proactively. For example, the PF_KEY interface (RFC 2367) in the kernel has an “event”

"The SADB_EXPIRE message is sent from the kernel to key management
   applications when the "soft lifetime" or "hard lifetime" of a
   Security Association has expired.  Key management applications should
   use receipt of a soft lifetime SADB_EXPIRE message as a hint to
   negotiate a replacement SA so the replacement SA will be ready and in
   the kernel before it is needed.”

This is a kind of asynchronous event, which is important because it allows the controller to react and update the SAs. Is this kind of event in the I2NSF scope? 

In any case we are going to modify the I-D to show all these aspects.

> [Linda] Are you assuming that data packets actually traversing the “Controller”? If yes, the I2NSF focus on the flow policy north bound to the controller. 

[Rafa] It is not traverse but it is to check the first data packet in a flow to see there is need for security or not. But certainly that belongs to southbound interface.

> [Linda] that will be useful. Can you write this detailed information exchange for I2NSF? 

[Rafa] We think so yes.

Best Regards.

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 23 Jun 2016 21:13:00 +0000

Rafa, 

-----Original Message-----
From: Rafa Marin Lopez [mailto:[email-masked]] 
Sent: Wednesday, June 22, 2016 10:13 AM
To: Linda Dunbar

<snip>

[Linda]I see. Those "events" definitely need to be addressed by the data model between controller and end points. It is helpful to describe the information model. 

In any case we are going to modify the I-D to show all these aspects.
[Linda] Thanks. Are you going to take the relevant portion in the I-D for I2NSF WG? Or are you going to keep in the SDNrg? 

[Rafa] We think so yes.

Best Regards.

> > https://tools.ietf.org/html/draft-abad-sdnrg-sdn-ipsec-flow-protecti
> > on
> > -01
> >  
> > Best Regards.
> >  
> >

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 27 Jun 2016 12:14:36 +0200

Hi Linda:

> El 23 jun 2016, a las 23:13, Linda Dunbar <[email-masked]> escribió:
> 
> Rafa, 
> 
> 
> 
> 

[Rafa] Good to know.

> [Linda] Thanks. Are you going to take the relevant portion in the I-D for I2NSF WG? Or are you going to keep in the SDNrg?

[Rafa] We will bring these modifications to I2NSF WG.

Best Regards

---

From: Sowmini Varadhan <[email-masked]>
Date: Thu, 30 Jun 2016 12:26:15 -0400

Hi, sorry for the delay in response, needed some time to go over
the draft carefully. Here are some comments.

> 1.  Introduction
            :
>    .. In this sense, it will provision the required
>    parameters to create valid entries in the Security Association
>    Database (SAD), which we assumed to be in the data plane.  

That definition was a bit unusual (at least from a network-stack perspective)
and threw me off.  The SAD is security assoction database, thus it is not
"data plane" as such, but rather, a database configured by the
control-plane that is looked up by the network stack's dataplane.
(In the same way, the SPD is also just a security policy database,
so the decision to call one "control plane", while the other as "data plane"
is also quite confusing).

>    Therefore,
>    the data plane will have only support for IPsec while SPD and IKE
>    functionality is moved to the control plane.  In both cases, to carry
>    out this provisioning, an interface/protocol will be required between
>    the SDN controller and the data plane to send: the policies to be

Again, perhaps my notion of "data plane" does not match the intention,
but the SDN controller has to interface with the control 
plane (i.e, the IKE implementation in the network resource) in case 1. 

Seems to me like case-1 vs case-2 is basically a split-IKE
model (where IKE is split between the network-resource and the controller)
and a model where the network resource implements IPsec only, with
IKE exclusively managed by the controller.

> 5.  Case 1: IKE/IPsec in the network resource
     :
>    Advantages: It is simple since network resources typically have and
>    IKE/IPsec implementations.
> 
>    Disadvantages: 1) IKE implementations needs to renegotiate IPsec SAs
>    upon SPD entries changes without restarting IKE daemon. 2) Data plane
>    more complex.

How does the data-plane become any more complex than a non-SDN env
where there would be no controller? The only change introduced
by the controller is that the IKE/IPsec SAs and policies are now
orchestrated via the controller.

I do agree that this results in a split-IKE model, which may
need to be thought through.

> 6.  Case 2: IKE and SPD in the SDN Controller
   :
>    Advantages: 1) There is clear separation of data plane (IPsec
>    protection per flow) and control plane (IKE and SPD policies).
>    Hence, it allows less complex data planes. 2) IKE does not need to be
>    run in gateway-to-gateway scenario with a single controller (see
>    Section 8.1).

Moving IKE into the controller will result in a fairly complex 
controller implementation, making the control plane extremely complex
(we need to now worry about interop, compat with config options
supported by existing IKE impelementations etc)

Section 8.1 underlines this somewhat- essentially the controller is now
doing everything that a standard IKE implementation would do. Trying
to get this to work with a stock TCP/IP stack implmentation would be
quite complex (whereas stock TCP/IP stack implementations already 
deal correctly with stock IPsec/IKE implementations).

There may also be other complications, if the IKE-enabled-controller
has to negotiate IKE on behalf of some other entity (network resource)
with a peer that thinks it is negotiating iwth the network-resource
itself. I dont know if the current IKE specs would have some issues
with that.

--Sowmini