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