Elastic enforcement layer for cloud security using SDN

• US 9,304,801 B2
• Filed: 06/12/2012
• Issued: 04/05/2016
• Est. Priority Date: 06/12/2012
• Status: Active Grant

• Current Assignee: Telefonaktiebolaget LM Ericsson
• Original Assignee: Telefonaktiebolaget LM Ericsson
• Inventors: Koorevaar, Tommy, Pourzandi, Makan, Zhang, Ying
• Primary Examiner(s): Smith, Marcus R
• Assistant Examiner(s): Clark, Rose
• Application Number:
  US13/494,637
• Publication Number:
  US 20130332983A1
• Time in Patent Office: 1,393 Days
• Field of Search: 718/1, 370/392, 370/389, 370/401, 709/223, 709/238, 709/220, 709/225, 726/1, 726/13, 726/11, 726/14, 726/12, 726/15, 726/2, 726/22, 726/23, 726/24, 726/3, 726/4, 726/7, 726/9
• US Class Current: 1/1
• CPC Class Codes: G06F 2009/4557 Distribution of virtual machine instances; Migration and load balancing
• CPC Class Codes: G06F 2009/45595 Network integration; Enabling network access in virtual machine instances
• CPC Class Codes: G06F 9/45558 Hypervisor-specific management and integration aspects
• CPC Class Codes: H04L 45/306 Route determination based on the nature of the carried application
• CPC Class Codes: H04L 63/20 for managing network security; network security policies in general filtering policies H04L63/0227

Abstract

An efficient elastic enforcement layer (EEL) for realizing security policies is deployed in a cloud computing environment based on a split architecture framework. The split architecture network includes a controller coupled to switches. When the controller receives a packet originating from a source VM, it extracts an application identifier from the received packet that identifies an application running on the source VM. Based on the application identifier, the controller determines a chain of middlebox types. The controller further determines middlebox instances based on current availability of resources. The controller then adds a set of rules to the switches to cause the switches to forward the packet toward the destination VM via the middlebox instances.

Claims

1. A method performed by a controller in a split architecture network to control network connectivity for a cloud computing environment, the split architecture network including a plurality of switches coupled to the controller, wherein the controller manages a control plane for the plurality of switches and policy enforcement for network security for a plurality of virtual machines (VMs) including a source VM and a destination VM that execute applications in the cloud computing environment and exchange data via the split architecture network, the method comprising the steps of:

receiving by the controller a packet from the plurality of switches, the packet originating from the source VM, where the controller manages the control plane for the plurality of switches and the plurality of switches implement the data plane of the split architecture network;

extracting by the controller an application identifier from the received packet, the application identifier identifying an application running on the source VM;

determining by the controller a chain of middlebox types based on the application identifier;

mapping by the controller one or more of the middlebox types in the chain to corresponding one or more middlebox instances based on current availability of resources in the cloud computing environment, wherein one or more of the middlebox instances perform network security operations on the packet and the one or more middlebox instances are in communication with one or more of the plurality of switches; and

sending by the controller a set of rules to the plurality of switches, the set of rules to add a set of tags to the packet to cause the plurality of switches to forward the packet toward the destination VM via the one or more middlebox instances to thereby enforce network security in the cloud computing environment.

2. The method of claim 1, wherein both the source VM and the destination VM are controlled by the controller, the step of determining further comprising the steps of:

mapping the chain of middlebox types to a chain of middlebox instances; and

adding the set of rules to the plurality of switches to cause the plurality of switches to forward the packet to the destination VM via the chain of middlebox instances.

3. The method of claim 1, wherein the source VM is in a first area controlled by the controller and the destination VM is in a second area controlled by a second controller, the step of mapping further comprising the steps of:

mapping by the controller a subset of middlebox types in the chain of middlebox types to a subset of middlebox instances; and

deferring mapping of remaining middlebox types in the chain of middlebox types to the second controller.

4. The method of claim 1, wherein the step of adding further comprises the step of adding a single rule to a given one of the plurality of switches to cause the given switch to route packets toward a same middlebox instance according to the single rule, wherein the packet have different application identifiers, originating from different VMs, or destined for different VMs.

5. The method of claim 1, further comprising the steps of:

receiving a second packet originating from the source VM that has migrated from a first physical server to a second physical server;

extracting an application identifier from the second packet, the application identifier being the same as before migration of the source VM; and

mapping the application identifier to a same chain of middlebox types as before the migration of the source VM.

6. The method of claim 5, wherein a same middlebox type is mapped to different middlebox instances before and after the migration of the source VM.

7. The method of claim 1, wherein the application identifier carried by packets emitted by the source VM stays the same after the source VM migrates to a different physical server.

8. The method of claim 1, wherein one of the rules specifies that an ingress switch of a given one of the middlebox instances is to pop a tag carried by the packet, the tag having a value pointing to the given middlebox instance.

9. The method of claim 1, wherein one of the rules specifies that an egress switch of a given one of the middlebox instances is to push a tag carried by the packet, the tag having a value pointing to a next middlebox instance toward which the packet is to be sent by the egress switch.

10. The method of claim 1, further comprising the steps of:

mapping a middlebox type in the chain to a set of middlebox instances;

choosing a middlebox instance from the set; and

identifying an Internal Protocol (IP) address of the middlebox instances being chosen.

11. A network node functioning as a controller in a split architecture network to control network connectivity for a cloud computing environment, the split architecture network including a plurality of switches coupled to the controller, wherein the controller manages a control plane of the plurality of switches and policy enforcement for network security for a plurality of virtual machines (VMs) including a source VM and a destination VM that execute applications in the cloud computing environment and exchange data via the split architecture network, the controller comprising:

receiver circuitry configured to receive a packet from one of the plurality of switches, the packet originating from the source VM, where the controller manages the control plane for the plurality of switches and the plurality of switches implement the data plane of the split architecture network; and

a processor coupled to the receiver circuitry and a memory, the processor configured to execute an elastic enforcement module, which is configured to

extract an application identifier from the received packet, the application identifier identifying an application running on the source VM;

determine a chain of middlebox types based on the application identifier; and

map one or more of the middlebox types in the chain to corresponding one or more middlebox instances based on current availability of resources in the cloud computing environment, wherein one or more of the middlebox instances perform network security operations on the packet and the one or more middlebox instances are in communication with one or more of the plurality of switches; and

transmitter circuitry coupled to the processor, the transmitter circuitry configured to send a set of rules to the plurality of switches to add a set of tags to the packet to cause the plurality of switches to forward the packet toward the destination VM via the one or more middlebox instances to thereby enforce network security in the cloud computing environment.

12. The network node of claim 11, wherein both the source VM and the destination VM are controlled by the controller, and wherein the controller is further configured to map the chain of middlebox types to a chain of middlebox instances, and to add the set of rules to the plurality of switches to cause the plurality of switches to forward the packet to the destination VM via the chain of middlebox instances.

13. The network node of claim 11, wherein the source VM is in a first area controlled by the controller and the destination VM is in a second area controlled by a second controller, and wherein the controller is further configured to map a subset of middlebox types in the chain of middlebox types to a subset of middlebox instances, and to defer mapping of remaining middlebox types in the chain of middlebox types to the second controller.

14. The network node of claim 11, wherein the controller is further configured to add a single rule to a given one of the plurality of switches to cause the given switch to route packets toward a same middlebox instance according to the single rule, wherein the packet have different applications identifiers, originating from different VMs, or destined for different VMs.

15. The network node of claim 11, wherein the controller is further configured to receive a second packet originating from the source VM that has migrated from a first physical server to a second physical server, extract the application identifier from the second packet, the application identifier being the same as before migration of the source VM, and map the application identifier to a same chain of middlebox types as before the migration of the source VM.

16. The network node of claim 14, wherein a same middlebox type is mapped to different middlebox instances before and after the migration of the source VM.

17. The network node of claim 11, wherein the application identifier carried by packets emitted by the source VM stays the same after the source VM migrates to a different physical server.

18. The network node of claim 11, wherein one of the rules specifies that an ingress switch of a given one of the middlebox instances is to pop a tag carried by the packet, the tag having a value pointing to the given middlebox instance.

19. The network node of claim 11, wherein one of the rules specifies that an egress switch of a given one of the middlebox instances is to push a tag carried by the packet, the tag having a value pointing to a next middlebox instance toward which the packet is to be sent by the egress switch.

20. The network node of claim 11, wherein the controller is further configured to map a middlebox type in the chain to a set of middlebox instances, choose a middlebox instance from the set, and identify an Internal Protocol (IP) address of the middlebox instances being chosen.