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 > -----Original Message----- > From: Linda Dunbar > Sent: Thursday, June 16, 2016 4:15 PM > To: Tom Herbert; Xuxiaohu; [email protected] > Cc: Lou Berger; Liyizhou; NVO3; [email protected] > 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 > Security Policies exchanged over I2NSF service layer interface? > > 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 protected]] > Sent: Wednesday, June 15, 2016 11:28 PM > To: Xuxiaohu > Cc: Lou Berger; Linda Dunbar; Liyizhou; NVO3; [email protected] > 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 protected]> 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 protected]] 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 protected]'; BOUCADAIR Mohamed IMT/OLN > >> > *Cc:* [email protected] > >> > *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 protected] > >> > <mailto:[email protected]> > >> > [mailto:[email protected]] > >> > *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. > >> > > >> > > >> > > >> > > >> > > >> > cid:[email protected] > >> > > >> > > >> > > >> > */[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 protected] <mailto:[email protected]> 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 protected] > >> > https://www.ietf.org/mailman/listinfo/nvo3 > >> > >> > >> _______________________________________________ > >> nvo3 mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
