Securing end-to-end virtual machine traffic

A device may receive a packet from a first endpoint that is destined for a second endpoint. The first endpoint may be hosted on the device. The device may determine whether a secure session exists between the first endpoint and the second endpoint. The secure session may permit encrypted traffic to be exchanged between the first endpoint and the second endpoint. The device may process the packet using a set of rules after determining whether the secure session exists between the first endpoint and the second endpoint. The device may encrypt the packet using security information associated with the secure session after determining that the secure session exists, or establishing the secure session when the secure session does not exist. The device may provide the packet toward the second endpoint after encrypting the packet.

BACKGROUND

Cloud computing is a model for enabling access to shared pools of configurable resources. For example, the configurable resources can include computer networks, servers, storage, applications, services, and/or the like. The configurable resources can be rapidly provisioned with minimal management effort and/or over the Internet. Cloud computing may include the use of distributed devices (e.g., physically distributed devices) to provide the configurable resources.

SUMMARY

According to some possible implementations, a device may include one or more memories, and one or more processors, communicatively coupled to the one or more memories, to receive a packet from a first endpoint that is destined for a second endpoint. The first endpoint may be hosted on the device. The one or more processors may determine whether a secure session exists between the first endpoint and the second endpoint. The secure session may permit encrypted traffic to be exchanged between the first endpoint and the second endpoint. The one or more processors may process the packet using a set of rules after determining whether the secure session exists between the first endpoint and the second endpoint. The one or more processors may encrypt the packet using security information associated with the secure session after determining that the secure session exists, or establishing the secure session when the secure session does not exist. The one or more processors may provide the packet toward the second endpoint after encrypting the packet.

According to some possible implementations, a non-transitory computer-readable medium may store one or more instructions that, when executed by one or more processors, cause the one or more processors to receive a packet from a first endpoint that is destined for a second endpoint. The first endpoint may be local to a device. The second endpoint may be remote to the device. The one or more instructions, when executed by the one or more processors, may cause the one or more processors to determine whether a secure session exists between the first endpoint and the second endpoint. The secure session may be associated with security information that is to be used to encrypt the packet. The one or more instructions, when executed by the one or more processors, may cause the one or more processors to process the packet using a set of rules prior to encrypting the packet and after determining whether the secure session exists between the first endpoint and the second endpoint. The one or more instructions, when executed by the one or more processors, may cause the one or more processors to encrypt the packet using the security information associated with the secure session after processing the packet using the set of rules. The one or more instructions, when executed by the one or more processors, may cause the one or more processors to provide the packet toward the second endpoint after encrypting the packet. The packet may be provided toward the second endpoint via an underlying tunneling network between the device and another device hosting the second endpoint.

According to some possible implementations, a method may include receiving, by a device, a packet from a first endpoint that is destined for a second endpoint. The first endpoint may be hosted on the device. The second endpoint may be hosted on another device. The method may include determining, by the device, whether a secure session exists between the first endpoint and the second endpoint. The secure session may permit encrypted traffic to be exchanged between the first endpoint and the second endpoint. The method may include marking, by the device, the packet for encryption after determining whether the secure session exists between the first endpoint and the second endpoint. The packet may be encrypted using security information associated with the secure session. The method may include processing, by the device, the packet using a set of rules after marking the packet for encryption. The process may include encrypting, by the device, the packet using the security information associated with the secure session after processing the packet using the set of rules and after determining that the secure session exists, or establishing the secure session when the secure session does not exist. The method may include providing, by the device, the packet toward the second endpoint after encrypting the packet. The packet may be provided via an underlying tunneling network between the device and the other device.

DETAILED DESCRIPTION

A data center architecture may include various network devices (e.g., switches, routers, hypervisors, etc.). Traffic exchanged between network devices in a data center architecture may be susceptible to a man-in-the-middle attack or another type of attack if the traffic is unsecured. In addition, a data center may be implemented in a multi-tenant environment where virtual machines hosted on network devices are associated with different tenants. Traffic exchanged between virtual machines hosted on the network devices of one tenant may be read by virtual machines of another tenant if the traffic is unsecured. Network devices (e.g., hosts) in a multi-tenant environment may lack a technique for securing traffic between virtual machines hosted on the network devices (e.g., securing the traffic at layer 2 of the Open Systems Interconnection (OSI) model). For example, a first virtual machine hosted on a first network device may lack a technique for securing traffic destined for a second virtual machine hosted on a second network device, such that other virtual machines on the same or different network devices cannot read the traffic.

Some implementations, described herein, provide a network device (e.g., a host) that is capable of securing traffic between virtual machines on different network devices (e.g., at layer 2). In this way, the network device may provide end-to-end network security between virtual machines associated with the same tenant network or associated with a different tenant network. This improves security between virtual machines by permitting traffic to be secured as the traffic is exchanged between virtual machines. Further, this permits virtual machines associated with different tenants to be securely hosted on the same network device.

FIG. 1is a diagram of an overview of an example implementation100described herein. As shown inFIG. 1, example implementation100may include a service manager, and two network devices (e.g., shown as network device ND1and network device ND2). Further, each network device may include a set of virtual machines, a service node, and a packet forwarding component (PFC). AlthoughFIG. 1shows two network devices, in practice there may be tens, hundreds, thousands, etc. of network devices.

As further shown inFIG. 1, and by reference numbers105-1and105-2, a service manager may provide topology information to the service nodes associated with network devices ND1and ND2. For example, the topology information may identify network devices that are associated with a network and/or that are available, virtual machines associated with network devices on a network, service nodes associated with network devices on a network, and/or the like.

As further shown inFIG. 1, and by reference number110, a first virtual machine (e.g., a virtual machine that is local to network device ND1) may provide a packet toward a first service node associated with network device ND1. In some implementations, the first virtual machine may provide the packet toward the service node via a virtual network interface card (VNIC) associated with the first virtual machine. Additionally, or alternatively, the first virtual machine may provide the packet toward the PFC, which may provide the packet to the first service node via a virtual port associated with the first service node. The service node may include multiple virtual ports. For example, the service node for a network device may include a virtual port for each virtual machine associated with the network device to permit the service node to exchange traffic with each virtual machine.

As further shown inFIG. 1, and by reference number115, a first service node (e.g., a service node that is local to network device ND1) may receive a packet from a first virtual machine that is destined for a second virtual machine. For example, the first service node may receive a packet from the first virtual machine destined for a second virtual machine. In example implementation100, assume that the second virtual machine is remote to network device ND1(e.g., that is hosted on network device ND2).

As further shown inFIG. 1, and by reference number120, the first service node may determine whether a secure session exists between the first virtual machine and the second virtual machine, and may encrypt the packet. For example, the first service node may determine whether a media access control (MAC) security (MACsec) key agreement (MKA) session has been established between the first virtual machine and the second virtual machine. In some implementations, the first service node may determine whether a secure session exists by performing a lookup of information that indicates whether a secure session exists between the first virtual machine and the second virtual machine using information that identifies a source MAC address for the packet (e.g., a MAC address of the first virtual machine), a destination MAC address for the packet (e.g., a MAC address of the second virtual machine), and/or the like. Although implementations are described herein with respect to MAC addresses, some implementations may use other types of information, such as an Internet protocol (IP) address of a source and/or destination of the packet.

If the first service node determines that the secure session exists, the first service node may perform an action related to providing the packet toward the second virtual machine. For example, if the first service node determines that an MKA session exists between the first virtual machine and the second virtual machine, the first service node may identify a corresponding encryption key (e.g., an encryption key derived from a pre-shared key (PSK)) associated with the MKA session and may encrypt the packet using the encryption key derived from the PSK and other information related to the packet (e.g., a source MAC address, a destination MAC address, etc.).

Conversely, if the first service node determines that the secure session does not exist, the first service node may perform an action related to establishing the secure session. For example, if the first service node determines that an MKA session does not exist between the first virtual machine and the second virtual machine, the first service node may block the first virtual machine from providing additional packets. Additionally, or alternatively, the first service node may establish an MKA session by using, for example, extensible authentication protocol over local area network (EAPoL) to exchange information with a second service node associated with network device ND2(e.g., the network device that is hosting the destination virtual machine for the packet). In this case, after establishing the MKA session, the first service node may store information identifying the encryption key (and/or decryption key) derived from the PSK associated with the MKA session between the first virtual machine and the second virtual machine and the first service node may use the encryption key and other information related to the packet (e.g., a source MAC address, a destination MAC address, etc.) to encrypt the packet.

As further shown inFIG. 1, and by reference number125, the first service node may provide the packet toward the second virtual machine (e.g., after encrypting the packet using the encryption key and the other information related to the packet). For example, the first service node may provide the packet via a network interface card (NIC) associated with the first service node, a NIC port associated with network device ND1, and an underlying tunneling network between network device ND1and network device ND2.

As further shown inFIG. 1, and by reference number130, a second service node (e.g., a service node that is local to network device ND2) may receive a packet from the first virtual machine that is destined for the second virtual machine. For example, the second service node may receive the packet from the first virtual machine (e.g., a virtual machine that is remote to network device ND2) via a NIC port associated with network device ND1and a NIC associated with the second service node. Continuing with the previous example, the packet may be destined for the second virtual machine (e.g., a virtual machine that is local to network device ND2and remote to network device ND1).

As further shown inFIG. 1, and by reference number135, the second service node may decrypt the packet using security information associated with the secure session between the first virtual machine and the second virtual machine. For example, the second service node may decrypt the packet using a decryption key derived from a PSK associated an MKA session between the first virtual machine and the second virtual machine and other information related to the packet (e.g., a source MAC address, a destination MAC address, etc.). In some implementations, the second service node may identify the security information by performing a lookup. For example, the second service node may perform a lookup of a decryption key using information identifying a destination and source MAC address associated with the packet, layer 2 information related to a source and/or destination of a packet, and/or the like.

As further shown inFIG. 1, and by reference number140, the second service node may provide the packet toward the second virtual machine (e.g., a virtual machine that is local to network device ND2and remote to network device ND1). In some implementations, the second service node may provide the packet via a virtual port of the second service node to a PFC associated with network device ND2. In this case, the PFC may provide the packet to the second virtual machine via a VNIC associated with the second virtual machine.

In this way, a network device may provide end-to-end network security between virtual machines associated with the same tenant network or associated with different tenant networks. This improves security between virtual machines by permitting traffic to be secured as the traffic is exchanged between the virtual machines. Further, this permits virtual machines associated with different tenants to be securely hosted on the same network device.

FIG. 2is a diagram of an example environment200in which systems and/or methods, described herein, may be implemented. As shown inFIG. 2, environment200may include a set of client devices210and one or more network devices220-1through220-N (N≥1) (hereinafter referred to collectively as “network devices220,” and individually as “network device220”). Devices of environment200may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

Client device210includes one or more devices capable of receiving, generating, storing, processing, and/or providing information associated with a packet exchanged among virtual machines. For example, client device210may include a mobile phone (e.g., a smart phone, a radiotelephone, etc.), a laptop computer, a desktop computer, a tablet computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart wristwatch, a pair of smart eyeglasses, etc.), or a similar type of device. In some implementations, client device210may receive a report generated by network device220related to a packet exchanged among virtual machines, as described in more detail elsewhere herein.

Network device220includes one or more devices (e.g., one or more traffic transfer devices) capable of receiving, providing, storing, generating, and/or processing information related to a packet exchanged among virtual machines. For example, network device220may include a firewall, a router, a gateway, a switch, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server), a security device, an intrusion detection device, a load balancer, or a similar device. In some implementations, network device220may determine whether a secure session exists between two or more virtual machines exchanging a packet, as described in more detail elsewhere herein. Additionally, or alternatively, network device220may encrypt or decrypt the packet using security information related to the secure session between the two or more virtual machines exchanging the packet, as described in more detail elsewhere herein. In some implementations, network device220may be a physical device implemented within a housing, such as a chassis. In some implementations, network device220may be a virtual device implemented by one or more computer devices of a cloud computing environment or a data center.

The number and arrangement of devices and networks shown inFIG. 2are provided as an example. In practice, there may be additional devices, fewer devices, different devices, or differently arranged devices than those shown inFIG. 2. Furthermore, two or more devices shown inFIG. 2may be implemented within a single device, or a single device shown inFIG. 2may be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment200may perform one or more functions described as being performed by another set of devices of environment200.

FIG. 3is a diagram of example components of a device300. Device300may correspond to client device210and/or network device220. In some implementations, client device210and/or network device220may include one or more devices300and/or one or more components of device300. As shown inFIG. 3, device300may include one or more input components305-1through305-B (B≥1) (hereinafter referred to collectively as “input components305,” and individually as “input component305”), a switching component310, one or more output components315-1through315-C (C≥1) (hereinafter referred to collectively as “output components315,” and individually as “output component315”), and a controller320.

Input component305may be points of attachment for physical links and may be points of entry for incoming traffic, such as packets. Input component305may process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, input component305may send and/or receive packets. In some implementations, input component305may include an input line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more interface cards (IFCs), packet forwarding components, line card controller components, input ports, processors, memories, and/or input queues. In some implementations, device300may include one or more input components305.

Switching component310may interconnect input components305with output components315. In some implementations, switching component310may be implemented via one or more crossbars, via busses, and/or with shared memories. The shared memories may act as temporary buffers to store packets from input components305before the packets are eventually scheduled for delivery to output components315. In some implementations, switching component310may enable input components305, output components315, and/or controller320to communicate.

Output component315may store packets and may schedule packets for transmission on output physical links. Output component315may support data link layer encapsulation or decapsulation, and/or a variety of higher-level protocols. In some implementations, output component315may send packets and/or receive packets. In some implementations, output component315may include an output line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and/or output queues. In some implementations, device300may include one or more output components315. In some implementations, input component305and output component315may be implemented by the same set of components (e.g., an input/output component may be a combination of input component305and output component315).

Controller320includes a processor in the form of, for example, a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and/or another type of processor. The processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, controller320may include one or more processors that can be programmed to perform a function.

In some implementations, controller320may include a random access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, an optical memory, etc.) that stores information and/or instructions for use by controller320.

In some implementations, controller320may communicate with other devices, networks, and/or systems connected to device300to exchange information regarding network topology. Controller320may create routing tables based on the network topology information, create forwarding tables based on the routing tables, and forward the forwarding tables to input components305and/or output components315. Input components305and/or output components315may use the forwarding tables to perform route lookups for incoming and/or outgoing packets.

Controller320may perform one or more processes described herein. Controller320may perform these processes based on executing software instructions stored by a non-transitory computer-readable medium. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.

FIG. 4is a flow chart of an example process400for exchanging encrypted traffic between endpoints using an underlying tunneling network. Specifically,FIG. 4shows an example relating to processing and/or providing a packet from a local virtual machine toward a remote virtual machine. In some implementations, one or more process blocks ofFIG. 4may be performed by network device220. In some implementations, one or more process blocks ofFIG. 4may be performed by another device or a group of devices separate from or including network device220, such as client device210.

As shown inFIG. 4, process400may include receiving a packet from a local virtual machine that is destined for a remote virtual machine (block410). For example, network device220may receive a packet from a local virtual machine (e.g., that network device220hosts) that is destined for a remote virtual machine (e.g., that another network device220hosts). In some implementations, network device220may receive a packet periodically, according to a schedule, based on a local virtual machine providing the packet toward a remote virtual machine, such as via a VNIC associated with the first virtual machine, based on requesting the packet, and/or the like.

In some implementations, a packet may refer to a communication structure for communicating information, such as a protocol data unit (PDU), a network packet, a datagram, a segment, a message, a block, a cell, a frame, a subframe, a slot, a symbol, a portion of any of the above, and/or another type of formatted or unformatted unit of data capable of being transmitted via network230. In some implementations, traffic may refer to a set of packets. In some implementations, a packet may include information that identifies a MAC address of a source of the packet (e.g., a local virtual machine), a MAC address of a destination of the packet (e.g., a remote virtual machine), and/or the like.

In some implementations, network device220may receive the packet using a service node associated with network device220. For example, network device220may receive the packet via a virtual port associated with the service node. In some implementations, network device220may receive the packet via a packet forwarding component (PFC) of network device220. For example, a PFC associated with network device220may receive a packet from a local virtual machine and the PFC may provide the packet to a service node associated with network device220.

In some implementations, network device220may receive information from a service manager. For example, network device220may receive topology information that identifies network devices220connected to network230, virtual machines hosted by network devices220on network230, service nodes associated with network devices220on network230, and/or the like. In some implementations, network device220may receive the information from a service manager periodically, according to a schedule, when the service manager detects that network devices220and/or virtual machines hosted by network devices220become available or become unavailable, and/or the like. In some implementations, a service node associated with network device220may receive the information from the service manager.

In this way, network device220may receive a packet from a local virtual machine destined for a remote virtual machine prior to determining whether a secure session exists between the local virtual machine and the remote virtual machine.

As further shown inFIG. 4, process400may include determining whether a secure session exists between the local virtual machine and the remote virtual machine (block420). For example, network device220may determine whether a secure session exists between the local virtual machine and the remote virtual machine. In some implementations, network device220may determine whether a secure session exists prior to providing the packet from the local virtual machine toward the remote virtual machine.

In some implementations, a secure session may include a connection that permits a source and destination virtual machine to exchange encrypted packets such that other virtual machines on the same network devices220that are hosting the source and destination virtual machines cannot read the packets. For example, the secure session may include an MKA session between source and destination virtual machines that is associated with an encryption key and/or decryption key that can be used to secure packets between the source and destination virtual machines.

In some implementations, when determining whether a secure session exists between the local virtual machine and the remote virtual machine, network device220may perform a lookup of information that identifies whether a secure session exists between a source virtual machine for the packet and a destination virtual machine for the packet. For example, network device220may perform a lookup using information identifying MAC addresses of the source and destination virtual machines. Continuing with the previous example, network device220may perform a lookup to determine whether an MKA session exists between a local virtual machine associated with network device220and a remote virtual machine associated with another network device220. In some implementations, network device220may determine whether a secure session exists based on a result of performing the lookup (e.g., based on whether a result of performing the lookup indicates a match).

In some implementations, when network device220determines that a secure session does not exist, network device220may perform an action related to establishing the secure session. For example, if network device220determines that an MKA session does not exist between the first virtual machine and the second virtual machine, the service node of network device220may block the first virtual machine from providing additional packets. Continuing with the previous example, network device220may establish an MKA session by using EAPoL to exchange information with another network device220related to the local virtual machine and the remote virtual machine. Continuing still with the previous example, after establishing the MKA session, network device220may store information identifying a key (e.g., an encryption key and/or a decryption key) derived from a PSK associated with the MKA session and the service node associated with network device220may use the key to encrypt the packet, as described in more detail herein.

In some implementations, prior to determining whether a secure session exists between the local virtual machine and the remote virtual machine, network device220may perform a lookup of MAC addresses associated with the packet using a source IP address associated with the packet, a destination IP address associated with the packet, and/or the like. For example, network device220may perform the lookup to identify a service node associated with a destination and/or source virtual machine of the packet. Continuing with the previous example, network device220may perform the lookup to identify a next hop for the packet.

In this way, network device220may determine whether a secure session exists between a local virtual machine and remote virtual machine prior to encrypting a packet from the local virtual machine to the remote virtual machine.

As further shown inFIG. 4, process400may include encrypting the packet using security information associated with the secure session after determining that the secure session exists or after establishing the secure session when the secure session does not exist (block430). For example, network device220may encrypt the packet using security information. In some implementations, network device220may encrypt the packet after determining that the secure session exists or after establishing the secure session when the secure session does not exist.

In some implementations, security information may include information that can be used to encrypt a packet sent from a first virtual machine (e.g., a local virtual machine) to a second virtual machine (e.g., a remote virtual machine) such that other virtual machines cannot read the packet. For example, security information may include an encryption and/or decryption key, a token, and/or the like associated with an MKA session associated with the first and second virtual machines. In some implementations, network device220may encrypt the packet using information associated with the packet (e.g., in addition to using the security information to encrypt the packet). For example, network device220may encrypt the packet using information that identifies a MAC address of a source virtual machine (e.g., a local virtual machine) and/or a destination virtual machine (e.g., a remote virtual machine) of the packet.

This permits a packet to be encrypted at a layer 2 level (e.g., at a virtual machine level). This increases a security of the packet by preventing other network devices220on a path of the packet and/or service nodes associated with the other network devices220, from reading the packet.

In this way, network device220may encrypt the packet prior to providing the packet toward the remote virtual machine.

As further shown inFIG. 4, process400may include providing the packet toward the remote virtual machine (block440). For example, network device220may provide the packet. In some implementations, network device220may provide the packet toward the remote virtual machine (e.g., hosted on another network device220). In some implementations, network device220may provide thousands, millions, billions, etc. of packets toward a remote virtual machine.

In some implementations, network device220may provide the packet via an underlying tunneling network. For example, network device220may provide the packet via an underlying tunneling network as a MACsec secured frame or a tunneled MACsec frame. In some implementations, network device220may provide the packet via a component of network device220. For example, a service node associated with network device220may provide the packet via a NIC associated with the service node and a NIC port associated with network device220.

In some implementations, network device220may perform another action. For example, network device220may send a message indicating that the secure session has been established and that the packet has been provided toward the remote virtual machine (e.g., may provide a message to client device210). In some implementations, network device220may record metrics related to the packet. For example, network device220may record metrics related to a size of the packet, or a set of packets, provided toward the remote virtual machine (e.g., whether a size of the packet satisfies a threshold). Additionally, or alternatively, and as another example, network device220may record metrics related to a quantity of packets provided toward the remote virtual machine (e.g., whether a quantity of packets satisfies a threshold). In some implementations, network device220may generate a report related to packets provided toward a virtual machine (e.g., that includes information identifying metrics related to the packets).

In this way, network device220may provide the packet toward the remote virtual machine.

FIG. 5is a flow chart of an example process500for securing end-to-end virtual machine traffic. Specifically,FIG. 5shows an example related to processing and/or providing a packet from a remote virtual machine toward a local virtual machine. For example, where process400related to a first network device220providing a packet to a second network device220, process500relates to the second network device220receiving the packet from the first network device220. In some implementations, one or more process blocks ofFIG. 5may be performed by network device220. In some implementations, one or more process blocks ofFIG. 5may be performed by another device or a group of devices separate from or including network device220, such as client device210.

As shown inFIG. 5, process500may include receiving a packet from a remote virtual machine that is destined for a local virtual machine (block510). For example, network device220may receive a packet. In some implementations, network device220may receive a packet from a remote virtual machine (e.g., hosted by another network device220) that is destined for a local virtual machine (e.g., hosted by network device220). In some implementations, network device220may receive the packet periodically, according to a schedule, when another network device220provides the packet, and/or the like. In practice, network device220may receive thousands, millions, billions, etc. of packets from another network device220.

In some implementations, network device220may receive a packet via an underlying tunneling network between network device220and another network device220(e.g., between service nodes of network device220and the other network device220). For example, network device220may receive the packet as a MACsec secured frame via an underlying tunneling network between network device220and another network device220. In some implementations, network device220may receive the packet via a component, or element, of network device220. For example, network device220may receive the packet via a NIC port of network device220, a service node of network device220, and/or a NIC of the service node.

In this way, network device220may receive a packet from a remote virtual machine prior to decrypting the packet.

As further shown inFIG. 5, process500may include decrypting the packet using security information associated with a secure session between the remote virtual machine and the local virtual machine (block520). For example, network device220may decrypt the packet. In some implementations, network device220may decrypt the packet using security information associated with a secure session between the remote virtual machine and the local virtual machine. In some implementations, network device220may decrypt thousands, millions, billions, etc. of packets. In this way, network device220may process a set of packets that cannot be processed manually or objectively by a human actor.

In some implementations, network device220may perform a lookup to identify security information. For example, network device220may perform a lookup of MAC addresses for destination and source virtual machines of the packet using information included in a header of the packet. Continuing with the previous example, network device220may identify a decryption key derived from a PSK to be used to decrypt the packet when a result of performing the lookup indicates a match.

In this way, network device220may decrypt the packet prior to providing the packet toward the local virtual machine.

As further shown inFIG. 5, process500may include providing the packet toward the local virtual machine (block530). For example, network device220may provide the packet. In some implementations, network device220may provide the packet toward the local virtual machine. In some implementations, network device220may provide thousands, millions, billions, etc. of packets.

In some implementations, a service node associated with network device220may provide the packet to a PFC associated with network device220via a virtual port of the service node. For example, the PFC may provide the packet to the local virtual machine via a VNIC of the local virtual machine.

In some implementations, network device220may perform another action. For example, network device220may process the packet and/or provide information associated with the packet for display (e.g., via client device210). Additionally, or alternatively, and as another example, network device220may generate a report indicating that the packet was received. Additionally, or alternatively, and as another example, network device220may send a message to another network device220from which the packet was received to indicate that the packet was received (e.g., the local virtual machine may send a message to the remote virtual machine).

In this way, network device220may provide the packet toward the local virtual machine.

FIG. 6is a diagram of an example implementation600relating to example process400shown inFIG. 4and/or example process500shown inFIG. 5.FIG. 6shows an example system architecture for securing end-to-end virtual machine traffic. As shown inFIG. 6, implementation600includes a set of network devices220(e.g., a set of hosts), shown as network devices220-1and220-2.

As shown inFIG. 6, and by reference number605, implementation600may include a service manager (e.g., a controller, a software defined network (SDN) controller, etc.). In some implementations, the service manager may receive, provide, store, generate, and/or process information related to a network topology. For example, the service manager may determine network devices220, virtual machines hosted on network devices220, service nodes of network devices220, and/or the like that are available for communication. In some implementations, the service manager may provide information to a service node of network device220to update a network topology of network230as network devices220and/or virtual machines become available or unavailable for communication.

As shown by reference numbers610, network devices220-1and220-2may include a service node. In some implementations, the service node may perform various functions related to traffic to and/or from a corresponding network device220(e.g., the service node may function like a gateway, a firewall, an intrusion detection device, and/or the like). As shown by reference numbers615, network devices220-1and220-2may include a management component (e.g., a management interface, a management daemon, etc.). In some implementations, the management component may receive topology information from the service manager. Additionally, or alternatively, the management component may push information to the key manager/PSK cache (shown by reference number620) (e.g., information related to a secure session).

As shown by reference numbers620, network devices220-1and220-2may include a key manager/PSK cache. For example, the key manager/PSK cache may store security information related to a secure session between a local virtual machine and a remote virtual machine. As shown by reference numbers625, network devices220-1and220-2may include a cryptography component. For example, the cryptography component may encrypt traffic provided by network device220and/or may decrypt traffic received by network device220(e.g., using security information associated with a secure session).

As shown by reference numbers630, network devices220-1and220-2may include a virtual port. For example, the service node associated with network device220may include a virtual port to provide/receive traffic to/from a set of virtual machines hosted on network device220. As shown by reference numbers635, network devices220-1and220-2may include a NIC. For example, the service node of network device220may include a NIC to provide/receive traffic to/from a NIC port of network device220.

As shown by reference numbers640, network devices220-1and220-2may include a set of virtual machines (e.g., may host a set of virtual machines). As shown by reference numbers645, a virtual machine hosted on network device220may include a virtual NIC (VNIC) that permits the virtual machine to provide and/or receive traffic. As shown by reference numbers650, network devices220-1and220-2may include a packet forwarding component (PFC). For example, the PFC may provide an outgoing packet from a virtual machine to the service node and/or may provide an incoming packet from the service node to a virtual machine.

As shown by reference numbers655, network devices220-1and220-2may include a NIC port. For example, the NIC port may be used by network device220to provide and/or receive traffic. As shown by reference number660, network devices220-1and220-2may communicate using a tunneled MACsec frame (e.g., exchanged through an underlying tunneling network as a MACsec secured frame). As shown by reference number665, the tunneled MACsec frame may include various layers of encapsulation, headers, and/or the like. For example, the tunneled frame may include an outer MAC header, an outer IP header, a user datagram protocol (UDP) header, a virtual extensible LAN (VXLAN) header, a layer 2 (L2) header, and/or an encrypted frame (e.g., encrypted using security information associated with a secure session).

As shown by reference numbers670, the service node may include a MACsec driver that exchanges traffic with various ports of the services node. For example, the MACsec driver may communicate with one or more virtual ports of the service node and/or a NIC of the service node. Additionally, or alternatively, the MACsec driver may determine whether a secure session exists between a local virtual machine and a remote virtual machine. Additionally, or alternatively, the MACsec driver may communicate with a cryptography component (shown by reference number625) to decrypt and/or encrypt a packet.

As indicated above,FIG. 6is provided merely as an example. Other examples are possible and may differ from what was described with regard toFIG. 6.

FIG. 7is a call flow of an example implementation700relating to example process400shown inFIG. 4and/or example process500shown inFIG. 5.FIG. 7shows an example of creating a VXLAN interface to permit tunneling of traffic between virtual machines hosted on network devices220.

As shown inFIG. 7, and by reference number710, a service manager may provide a topology update to a management daemon (e.g., associated with a service node of network device220). For example, the service manager may provide a message to the management daemon that includes information indicating that a service node on another network device220has been added to the network topology. As shown by reference number720, the management daemon may provide an indication to a VXLAN daemon to cause the VXLAN daemon to create a VXLAN interface to the service node that was added to the network topology. As shown by reference number730, the VXLAN daemon may create the VXLAN interface to the added service node and may provide a route update to a kernel of network device220and/or a PFC of network device220. For example, a route update may include information that permits traffic to be routed to the added service node via the created VXLAN interface.

In this way, network device220may create a VXLAN interface to permit communication with a virtual machine, a service node, and/or network device220that is added to a network topology.

As indicated above,FIG. 7is provided merely as an example. Other examples are possible and may differ from what was described with regard toFIG. 7.

FIG. 8is a call flow of an example implementation800relating to example process400shown inFIG. 4and/or example process500shown inFIG. 5.FIG. 8shows an example of processing a packet that originates from a local virtual machine (VM) and is destined for a remote virtual machine and establishing a secure session between the local virtual machine and the remote virtual machine.

As shown by reference number810, the first packet from a local virtual machine to a remote virtual machine may be provided from a virtual port driver of network device220to a MACsec driver of network device220. For example, the virtual port driver may be associated with a VNIC of a virtual machine hosted on network device220and the MACsec driver may be associated with a service node of network device220. As shown by reference number820, the MACsec driver may access a MACsec lookup table (e.g., a data structure) to determine whether a session (e.g., a secure session, an MKA session, etc.) exists between the local virtual machine and the remote virtual machine. For example, the MACsec driver may perform the lookup using information identifying a source MAC address of the packet, a destination MAC address of the packet, and/or the like. In some implementations, the MACsec lookup table may include information that identifies existing secure sessions and corresponding local and remote virtual machines associated with the secure sessions.

In some implementations, prior to determining whether a secure session exists between the local virtual machine and the remote virtual machine, network device220may perform a lookup of MAC addresses associated with the packet using a source IP address associated with the packet, a destination IP address associated with the packet, and/or the like. For example, network device220may perform the lookup to identify a service node associated with a destination and/or source virtual machine of the packet. Continuing with the previous example, network device220may perform the lookup to identify a next hop for the packet.

As shown by reference number830, the MACsec driver may determine that a secure session does not exist between the local virtual machine and the remote virtual machine (e.g., based on a result of the lookup failing to indicate a match). As shown by reference number840, the MACsec driver may start a secure session between the local virtual machine and the remote virtual machine. For example, the MACsec driver may cause a MACsec daemon to start the secure session (e.g., by providing a set of instructions to the MACsec daemon). As shown by reference number850, the MACsec daemon may receive MACsec configuration information (e.g., a PSK, MACsec parameters, etc.) from a virtual machine (VM) data structure. For example, the virtual machine data structure may include MACsec configuration information that identifies a MAC address of the local and/or remote virtual machines that is to be used to establish a secure session between the local and remote virtual machines.

Although a secure session may be described herein as being between virtual machines, a secure session may be described as being between, or associated with, MAC addresses. For example, the secure session may be between service nodes and/or network devices220that are functioning on behalf of virtual machines exchanging packets. Continuing with the previous example, the service nodes and/or network devices220may use MAC addresses associated with virtual machines hosted by network devices220on behalf of the hosted virtual machines to permit an exchange of packets between the virtual machines.

As shown by reference number860, the MACsec daemon may establish a MACsec session with a remote virtual machine by sending information to a VXLAN interface associated with network device220(e.g., information related to an MKA EAPoL). As shown by reference number870, the MACsec daemon may update the lookup table with information identifying a successful (e.g., existing) session state. In this way, network device220may establish a secure session between a local virtual machine and a remote virtual machine.

As indicated above,FIG. 8is provided merely as an example. Other examples are possible and may differ from what was described with regard toFIG. 8.

FIG. 9is a call flow of an example implementation900relating to example process400shown inFIG. 4and/or example process500shown inFIG. 5.FIG. 9shows an example of network device220processing a packet received from a remote virtual machine (e.g., hosted by another network device220) that is destined for a local virtual machine hosted by network device220.

As shown by reference number910, a VXLAN interface of network device220may provide an un-encapsulated packet from a remote virtual machine to a MACsec driver of network device220. As shown by reference number920, the MACsec driver may identify secure session information related to a secure session between the remote virtual machine that provided the packet and the local virtual machine to which the packet is destined. For example, the MACsec driver may identify information identifying a session key for the secure session from a MACsec lookup table that includes information identifying session keys, a corresponding secure session, and virtual machines associated with the secure session. In some implementations, the MACsec driver may identify the secure session information by performing a lookup in the MACsec lookup table of information that identifies a secure session between the remote virtual machine and a local virtual machine, information that identifies the remote virtual machine and/or the local virtual machine, and/or the like and may identify the secure session information where a result of the lookup indicates a match.

As shown by reference number930, the MACsec driver may receive secure session information from the MACsec lookup table. For example, the MACsec driver may receive the information based on a result of a lookup to identify the secure session information indicating a match. In some implementations, the MACsec driver may decrypt the packet using the secure session information (e.g., a session key). As shown by reference number940, the MACsec driver may provide the decrypted packet to a security flow stack (e.g., a set of components, elements, processes, security layers, and/or the like) for processing. For example, the security flow stack may process the decrypted packet using a set of firewall rules, policies, and/or the like.

In this way, network device220may process a packet received from another network device220(e.g., a packet received from a remote virtual machine that is destined for a local virtual machine).

As indicated above,FIG. 9is provided merely as an example. Other examples are possible and may differ from what was described with regard toFIG. 9.

FIG. 10is a call flow of an example implementation1000relating to example process400shown inFIG. 4and/or example process500shown inFIG. 5.FIG. 10shows an example of processing a packet from a local virtual machine that is destined for a remote virtual machine.

As shown by reference number1010, a virtual port driver associated with network device220may provide a packet from a local virtual machine to a MACsec driver associated with network device220. For example, the packet may be destined for a remote virtual machine hosted by another network device220. As shown by reference number1020, the MACsec driver may determine whether a secure session exists between the local virtual machine from which the packet originated and the remote virtual machine to which the packet is destined. For example, the MACsec driver may perform a lookup of information related to the packet (e.g., a source/destination MAC address) using a MACsec lookup table to determine whether an MKA session exists between the local virtual machine and the remote virtual machine (e.g., where a result of the lookup indicates a match between the information related to the packet and information included in the MACsec lookup table).

As shown by reference number1030, if the MACsec driver determines that a secure session exists between the local virtual machine and the remote virtual machine, the MACsec driver may mark the packet for egress encryption. For example, the MACsec driver may mark the packet to be encrypted using security information related to the existing MKA session (e.g., by updating information in a data structure, including information in a header of the packet, etc.). As shown by reference number1040, the MACsec driver may provide the packet to a security flow stack for processing. For example, the security flow stack may process the packet using a set of firewall rules, a set of policies, and/or the like, such as to determine whether to filter the packet, to drop the packet, to log the packet, and/or the like. As shown by reference number1050, the security flow stack may provide the packet to the MACsec driver after processing the packet.

As shown by reference number1060, the MACsec driver may provide the packet toward the remote virtual machine by providing the packet to a VXLAN interface. In some implementations, if the packet is marked for encryption, the MACsec driver may obtain security information related to the secure session between the local virtual machine and the remote virtual machine and may encrypt the packet using the security information. In this way, network device220may encrypt a packet destined for a remote virtual machine using security information related to a secure session between a local virtual machine and the remote virtual machine.

As indicated above,FIG. 10is provided merely as an example. Other examples are possible and may differ from what was described with regard toFIG. 10.

FIG. 11is a diagram of an example implementation1100relating to example process400shown inFIG. 4and/or example process500shown inFIG. 5.FIG. 11shows an example of processing an ingress packet from a remote virtual machine (e.g., destined for a local virtual machine) and processing an egress packet from a local virtual machine (e.g., destined for a remote virtual machine).

As shown by reference number1105, network device220may receive a packet via a VXLAN interface driver (e.g., from a NIC associated with a service node of network device220). For example, the packet may be received from a remote virtual machine (e.g., hosted on another network device220) and may be destined for a local virtual machine (e.g., hosted on network device220). In some implementations, the VXLAN interface driver may provide the packet to a MACsec driver associated with network device220. As shown by reference number1110, the MACsec driver may process the packet. For example, the MACsec driver may decrypt an encrypted packet received from the remote virtual machine (e.g., using security information associated with a secure session between the remote virtual machine and the local virtual machine).

In some implementations, after processing the packet, the MACsec driver may provide the packet to a security flow stack for further processing. As shown by reference number1115, the security flow stack may process the packet. For example, the security flow stack may process the packet using a set of rules (e.g., firewall rules, policies, etc.). For example, the security flow stack may filter the packet, determine a route for the packet, drop the packet, log the packet, and/or the like based on processing the packet.

As shown by reference number1120, the security flow stack may provide the processed packet to the MACsec driver. As shown by reference number1125, the MACsec driver may provide the packet to a virtual port driver associated with network device220. As shown by reference number1130, the virtual port driver may provide the packet (e.g., a decrypted packet) toward the local virtual machine (e.g., via a virtual port of a service node that corresponds to a VNIC of the local virtual machine).

As shown by reference number1135, the virtual port driver may receive a packet from the local virtual machine (e.g., an un-encrypted packet destined for a remote virtual machine). In some implementations, the virtual port driver may provide the packet to the MACsec driver. As shown by reference number1140, the MACsec driver may process the packet. For example, the MACsec driver may determine whether an MKA session exists between the local virtual machine that provided the packet and the remote virtual machine to which the packet is destined. In some implementations, the MACsec driver may establish a secure session (e.g., an MKA session) between the local virtual machine and the remote virtual machine if one does not exist. Additionally, or alternatively, the MACsec driver may mark the packet for encryption (e.g., based on identifying an existing MKA session between the local virtual machine and the remote virtual machine or based on establishing an MKA session). In some implementations, the MACsec driver may provide the packet to the security flow stack for processing after marking the packet for encryption.

As shown by reference number1145, the security flow stack may process the packet. For example, the security flow stack may process the packet using a set of firewall rules, a set of policies, and/or the like. In some implementations, the security flow stack may filter the packet, drop the packet, log the packet, and/or the like based on processing the packet. As shown by reference number1150, the security flow stack may provide the packet to the MACsec driver. In some implementations, the MACsec driver may encrypt the packet after receiving the packet. For example, the MACsec driver may encrypt the packet using security information associated with a secure session (e.g., an MKA session) between the local virtual machine and the remote virtual machine.

As shown by reference number1155, the MACsec driver may provide the packet (e.g., an encrypted packet) to the VXLAN interface driver. As shown by reference number1160, the VXLAN interface driver may provide the packet toward the remote virtual machine after receiving the packet from the MACsec driver (e.g., via a NIC of a service node associated with network device220).

In this way, network device220may process a packet from a local virtual machine that is destined for a remote virtual machine.

As indicated above,FIG. 11is provided merely as an example. Other examples are possible and may differ from what was described with regard toFIG. 11.

Some implementations, described herein, provide a network device (e.g., a host) that is capable of securing traffic between virtual machines on different network devices (e.g., at layer 2). In this way, the network device may provide end-to-end network security between virtual machines associated with the same tenant network or associated with different tenant networks. This improves security between virtual machines by permitting traffic to be secured as the traffic is exchanged between virtual machines. Further, this permits virtual machines associated with different tenants to be securely hosted on the same network device.

Although some implementations were described with respect to a virtual machine, the implementations apply equally to other types of endpoints that can exchange traffic. For example, the implementations apply equally to a container, an application, a service, a computing resource, a cloud endpoint, and/or the like.