Subject: [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?

From: Linda Dunbar <[email-masked]>
Date: Wed, 15 Jun 2016 12:55:15 +0000

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

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 Jun 2016 10:59:33 -0400

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).
>
>  
>
> *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-mitigation-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
>
>  
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: Lucy yong <[email-masked]>
Date: Wed, 15 Jun 2016 15:12:42 +0000

Nov3 use case draft describes this use case  https://datatracker.ietf.org/doc/draft-ietf-nvo3-use-case/

Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Wednesday, June 15, 2016 7:55 AM
To: Liyizhou; NVO3
Subject: [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?

NVO3 Participants,

From: Linda Dunbar
Sent: Tuesday, June 14, 2016 4:03 PM
To: [email-masked]'; BOUCADAIR Mohamed IMT/OLN
Cc: [email-masked]<mailto:[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,

Linda

[snip]

Cheers,

Christian.

Thanks, Linda

Thank you.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 16 Jun 2016 03:03:39 +0000

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. 

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
> 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
> 
> > provided by other network operators (a.k.a. "underlay network").  The
> > underlay network so that various attack traffic won't saturated 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).
> >
> >
> >
> > provided by other network operators (a.k.a. "underlay network").  Very
> > network nodes, and to avoid the overlay nodes' CPU/Storage/Port
> > example of "Overlay Video Communication network" exchange Flow
> > controller uses AH, the network controller doesn't), thereby leading
> > should be derived from the customer's requirements (if any).
> >
> > 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).
> > but this may take a couple of weeks as I'm pretty busy for the time being.
> >
> >
> >
> _____________________________________________________________
> _________
> > ___________________________________________________
> >
> > 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.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 15 Jun 2016 21:28:12 -0700

> 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 intere…
Using the flow label for ECMP (RFC6438) solves this problem without
requiring the additional overhead of a UDP header.

Tom

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 16 Jun 2016 06:31:13 +0000

> From: Tom Herbert [mailto:[email-masked]]
> Sent: Thursday, June 16, 2016 12:28 PM
> To: Xuxiaohu
> Cc: Lou Berger; Linda Dunbar; Liyizhou; NVO3; [email-masked]
> > 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.

In IPv6 underlay networks, the above argument seems true. However, in IPv4 underlay networks, there is no such FL field.

Best regards,
Xiaohu

> >> 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?
> >>
> >>
> >> points) motivated our work on RFC5566 and we built supported for it
> >> (as well as other tunnel technologies) in a quagga based NVO3 controller.
> >> > 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
> >> > 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,
> >> > 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: 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?

> 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 intere…
Using the flow label for ECMP (RFC6438) solves this problem without requiring the additional overhead of a UDP header.

Tom

>> > "Overlay Video Communication network" exchange Flow Policies to the Underlay network.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > consistency of the (flow-based security policies enforced by both parties, and which should be derived from the customer's requirements (if any).
>> >
>> > accordingly, but this may take a couple of weeks as I'm pretty busy for the time being.
>> >
>> >
>> >

---

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:
> ______________________________________________________________________
> 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.

---

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

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

---

From: Lucy yong <[email-masked]>
Date: Thu, 16 Jun 2016 14:18:53 +0000

FYI.

draft-hy-nov3-gue-4-secure-transport specifies ESP-over-UDP that provides the benefits mentioned below.

Lucy

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Wednesday, June 15, 2016 10:04 PM
To: Lou Berger; Linda Dunbar; Liyizhou; NVO3
Cc: [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?

Hi Lou,

Best regards,
Xiaohu

> > 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.
> >
> >
> >
> > 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 ).
> >
> >
> >
> > 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.
> >
> >
> >
> >
> >
> >
> >
> >
> > 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).
> >
> > https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-m
> > it igation-api/ is just the starting point. (needs more work to 
> > improve the clarity).

---

From: Sowmini Varadhan <[email-masked]>
Date: Thu, 16 Jun 2016 11:57:24 -0400

On Wed, Jun 15, 2016 at 8:55 AM, Linda Dunbar <[email-masked]> 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.
>
>
>

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

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.

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