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
