Scalable IPSec services

An Internet Key Exchange protocol message indicating a first Internet Protocol Security traffic flow is to be established via a first device is obtained at the first device. The Internet Key Exchange protocol message is forwarded from the first device to a second device. An encryption key used to transmit traffic via the first Internet Protocol Security Traffic flow is received at the first device from a key value store. The key value store is populated with the encryption key in response to the second device obtaining the Internet Key Exchange protocol message. A first data packet to be transmitted via the first Internet Protocol Security traffic flow is obtained at the first device. The first device provides the first data packet encrypted with the encryption key of the first Internet Protocol Security traffic flow.

TECHNICAL FIELD

The present disclosure relates to Internet Protocol Security implementations.

BACKGROUND

With the increasing move toward the cloud, service providers may seek to offer highly scalable and highly available, multi-tenant aware Internet Protocol Security (IPSec) gateways in cloud-native environments.

Cloud Native environments are often characterized by the utilization of ephemeral and short lived compute resources. Reliability and redundancy are often provided for in cloud environments by deploying multiple availability zones. Accordingly, scaling of such resources is often provided through horizontal scaling (e.g., providing additional host devices or additional virtual machines (VMs) to scale the resources).

Such environments may provide challenges as typical IPSec deployments are long-lived and rely on stable and reliable compute resources that are often scaled vertically (e.g., increasing the compute resource of a single host device or virtual machine). In other words, IPSec implementations may utilize compute resources in ways that differ from how such resources are often provided in cloud environments

Traditionally, highly available and highly reliable IPSec services were provided by building IPSec gateways in a High Available (HA) pair, with one active master and a standby slave node. Depending on the required reliability, it is not uncommon to deploy dedicated pairs for a tenant. Such implementations may result in waste or idle compute resources, as one half of the pair is held in reserve in case of a failure of the other half of the pair. Accordingly, such implementations may be costly to scale and operate.

Given the complexity of IPSec and its long-lived stateful nature, scaling IPSec gateways is typically implemented through vertical scaling, by deploying the IPSec gateways on more powerful VMs or compute nodes. When implementing a multi-tenant IPSec gateway servicing many tenants, the service is limited to compute resources of a single VM or compute node. Such implementations may make it difficult to scale a multi-tenant IPSec gateway. Furthermore, such gateways may be over-provisioned, making such implementations expensive in cost and resources. Such deployments may also suffer from a hard capacity maximum as determined by the number of CPU resources in a single compute resource.

Cloud native environments are by their nature very dynamic, and the underlying compute resources are typically less reliable than traditional dedicated IPSec gateways. Compute, Datacenter or Availability zone failures will affect the reachability of the IPSec gateway and will result in service outages for the IPSec service.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

Methods, an apparatus and computer readable media are provided which may be used to establish IPSec implementations that separate the IKE and ESP functionality. According to one such method, an Internet Key Exchange protocol message indicating a first Internet Protocol Security traffic flow is to be established via a first device is obtained at the first device. The Internet Key Exchange protocol message is forwarded from the first device to a second device. An encryption key used to transmit traffic via the first Internet Protocol Security Traffic flow is received at the first device from a key value store. The key value store is populated with the encryption key in response to the second device obtaining the first Internet Key Exchange protocol message. A first data packet to be transmitted via the Internet Protocol Security traffic flow is obtained at the first device. The first device provides the first data packet encrypted with the encryption key of the first Internet Protocol Security traffic flow.

Example Embodiments

With reference made toFIGS. 1A, 1B and 1C, depicted therein is a comparison of IPSec architectures105,110and115that may be used to send secure traffic between client106and Internet or cloud environment108. Architectures110and115implement the techniques of the present disclosure and may provide the following functionality:1. Separating the Internet Key Exchange (IKE) and Encapsulating Security Payload (ESP) functions of IPSec,2. Leveraging Anycast and Equal Cost Multipath (ECMP) routing for IPSec,3. Just in Time provisioning of ESP keys, and/or4. Just-in-Time handling of IKE traffic which is distributed using a key/value store.

Through this functionality, example embodiments may provide globally scalable multi-tenant IPSec services with minimal downtime and massive scaling properties. Specifically, through the techniques disclosed herein, both of the IKE and ESP functionality of IPSec implementations may be scaled horizontally. Furthermore, the IKE and ESP functionality may be scaled independently from each other.

IPSec gateways, e.g., a gateway combining the IKE and ESP functionality, are challenging to scale, and typically operators will scale IPSec gateways vertically by increasing the compute resources of the device on which both of the IKE and ESP functionality are executing. Vertical scaling is utilized for IPSec gateways because IPSec sessions are long-lived (hours to days and possibly even weeks). The stateful nature of IPSec makes it difficult to deploy in a cloud-native environment where machines can go down with little notice, and the deployment needs to scale elastically.

The techniques of the present disclosure provide for horizontal scaling of IPSec gateways, and also provide for independent horizontal scaling of the IKE and ESP functionality. Accordingly, the techniques of the present disclosure provide elastic scaling of the IPSec dataplane, and may resolve the problems that often come with a multitenant setup implementing IPSec. Furthermore, the techniques of the present disclosure provide independent horizontal scaling of the IKE and ESP functionality while optimizing compute resources. For example, the techniques of the present disclosure may eliminate the need for (and the associated cost of) passive standby nodes that may be required in related art IPSec configurations. Finally, the techniques of the present disclosure may also provide for global IP mobility, allowing the IP addresses of the IPSec gateways to move globally between datacenters in a deterministic multi-stage approach.

IPSec is a suite of various protocols, most notably the control plane IKE protocol and the dataplane ESP protocol. As illustrated through IKE protocol packet150and pseudocode112ofFIGS. 1A-C, the IKE protocol serves as the control plane for IPSec via which encryption keys and key refresh rates for IPSec data transfers are determined. ESP is the protocol that is used to transfer the encrypted data packets152. Both protocols have separate operational challenges and different scaling properties.

Typical IPSec gateway deployments operate the IKE and ESP function on the same host as illustrated inFIG. 1A. This presents challenges for resolving the different and competing scaling properties of IKE and ESP. As illustrated in architecture105ofFIG. 1A, the IPSec gateway is embodied in a single compute node or virtual machine122. Specifically, the ESP module124, the IKE module126and the security associations database128all execute within the same compute node or virtual machine122. Accordingly, because the IKE module126and security associations database128reside in the same compute node or virtual machine122as the ESP module124, the ESP module124does not horizontally scale (i.e., increasing the number of ESP modules), and instead, ESP module124is scaled vertically (i.e., by increasing the compute resources of compute node or virtual machine122). The IKE module126is also scaled vertically as opposed to horizontally.

By separating the control plane IKE function from the dataplane ESP function, IPSec gateway scaling issues may be resolved separately. For example, as illustrated in IPSec architecture110ofFIG. 1B, IKE server136has been separated from the ESP data nodes134a-e. The horizontal scaling of the ESP modules134a-eis facilitated through key-value (KV) store138. KV store138includes all ESP session data, essentially replacing security associations database128ofFIG. 1A. By separating the IKE server136from the ESP dataplane, and providing the independent KV store138, the ESP dataplane may be scaled horizontally, resulting in a plurality of ESP hosts, embodied in IPSec architecture110as ESP data nodes134a-e.

ESP is well suited to scale horizontally and allows for node migration as it may leverage the IKE protocol to initiate rekeys after a node migration. Low cost, fast, stateless ECMP may be used to load balance ESP traffic to an elastic cluster of ESP nodes134a-eand ESP sessions may be moved between ESP nodes134a-eas needed. Specifically, ESP data packets152may be sent to any of ESP data nodes134a-e, as the IKE data associated with the ESP traffic is accessed via IKE server136and KV store138. If any one of ESP data nodes134a-efails, the remaining ESP data nodes still have access to the IKE data facilitated by IKE server136and KV store138.

With reference made toFIG. 2, depicted therein is a process flow for IPSec traffic in an environment like architecture110ofFIG. 1B. When IPSec traffic205of a new dataflow is received at ESP data nodes134aor134bfrom a client106a-e, the traffic is initially sent to IKE node136via IKE traffic210aor210bto establish the necessary ESP session keys, which are stored in KV store138. The ESP data node134aor134bthat received the first ESP packet of a data flow will locally story the session keys and ESP state and policies for the data flow. These keys may be used to transmit secure ESP traffic via, for example, virtual extensible local area networks (VXLANs)215aand215b, to the Internet or cloud environment108. If packets for the same session are subsequently received at a different one of ESP data nodes134aor134b, the receiving ESP data node134aor134bmay retrieve the appropriate session keys and ESP state from KV store138. In other words, because an alternate ESP data node134aor134bmay receive session keys and ESP state from KV store138, the ESP protocol functionality of IPSec may be scaled horizontally in an environment like that illustrated inFIG. 2or as illustrated in architecture110ofFIG. 1B.

Traffic may be sent to either of ESP data node134aor134bthrough the use of Anycast and/or ECMP routing. For example, ECMP routing may be used to appropriately load balance traffic between ESP data nodes134aand134b. Similarly, if one of data nodes134aor134bcrashes or is otherwise unable provide ESP services, ECMP routing may be used to direct traffic to the other of data nodes134aand134bin a manner that is completely transparent to clients106a-e.

IKE may also be scaled horizontally according to the techniques of the present disclosure. For example, as illustrated in IPSec architecture115ofFIG. 1C, the use of KV store148allows for the separation of ESP data nodes144a-efrom IKE servers146aand146b, and for the horizontal scaling of IKE servers146aand146b. Specifically, KV store148is maintained separately from all of IKE servers146aand146bwhile all of IKE servers146aand146bhave access to the IKE data contained in KV store148. If either one of IKE servers146aor146bgoes down, the remaining IKE server(s) may access the data contained in KV store148to continue servicing the IPSec gateway, and thus allowing for seamless IKE session migration between nodes. ECMP may be used to reroute traffic to an operating IKE server146aor146bin the event the previously utilized IKE server is taken out of operation.

According to one specific example embodiment, as illustrated inFIG. 3, IKE functionality may be implemented on each of IKE servers146a-cthrough an IKE plugin305a-c. Specific example embodiments of IKE plugins305a-cinclude plugins implementing the StrongSwan Open Source IPsec-based Virtual Private Network (VPN) solution for Linux and other UNIX based operating systems. According to some example embodiments, IKE plugins305a-cspeak with a High Availability (HA) Application Programming Interface (API)310a-c(also referred to herein as a Just-in-Time IKE Agent (JITIKE Agent)) and the KV store148through, for example, a Charon Security Associations manager, on one side, and to KV store148on the other side. According to other example embodiments, the HA APIs310a-bmay not be required. In such example embodiments, the IKE plugins305a-coperate independently to handle IKE sessions “just in time” without ever interacting with each other. In these embodiments without the HA APIs310a-c, the IKE plugins305a-cmay be treated as “cattle” (i.e., if a one of the plugins experiences errors or fails, it is killed and replaced with another instance of the plugin).

The separate communication between IKE servers146a-cand KV store148allows for storing all IKE session data in the KV store148, meaning failover of IKE sessions may be implemented across many different nodes, and scaling of the IKE servers may be done horizontally. In other words, if one or more of IKE servers146a-cfails or is otherwise taken out of service, the remaining operating IKE servers146a-cmay continue to service IPSec traffic, including existing traffic flows, as all IKE session data is stored in KV store148, not stored at individual ones of IKE servers146a-c. ECMP may be utilized to ensure that traffic being sent from data nodes (such as data nodes134a-eofFIG. 1B, data nodes144a-eofFIG. 1Cand/or data nodes134aand134bofFIG. 2) to IKE servers146a-cis routed to an operating IKE server146a-c. By communicating with KV store148, the operational IKE servers146a-cmay retrieve the state, security associations, and other data necessary for IKE servers146a-cto continue servicing existing and new IPSec traffic flows.

According to the example embodiments that implement HA APIs310a-c, the HA APIs310a-cmay act as passive slave agents. The IKE plugins305a-csync with the HA APIs310a-cusing a User Datagram Protocol (UDP) HA protocol. Though, such processing is unnecessary in example embodiments in which the IKE Plugins305a-care configured to communicate directly with KV store148. The IKE traffic transmitted between the HA APIs310a-c, or directly from the IKE plugins305a-c, and KV store148may be encrypted.

Accordingly, the techniques of the present disclosure may be used to successfully separate the IKE and ESP functions of IPSec. Furthermore, the techniques of the present disclosure may leverage the separation of the IKE and ESP functions. For example, an IPSec client will send traffic to a single IPSec server Internet Protocol (IP) address, but the client is actually sending traffic via the IP address for a globally anycasted ESP cluster. For example, returning toFIGS. 1B and 1C, when client106sends ESP traffic, the traffic will all be addressed the same, regardless of which of ESP nodes134a-eor144a-eis servicing the traffic flow. Similarly, the ESP cluster comprised of ESP nodes134a-eor144a-emay forward the IKE traffic to the IKE cluster (comprised of IKE node136inFIG. 1Bor IKE nodes146aand a46bofFIG. 1C) using a single address.

The techniques of the present disclosure also allow for Just-in-Time provisioning of IPSec keys. For example, once an IPSec session is established by the IKE protocol, subsequent ESP packets will reach one of the many ESP nodes in a global cluster. The ESP node will do a lookup by using a signaling service that retrieves the required ESP keys and traffic selector policies. The ESP keys and traffic selector policies will then be installed on the receiving ESP node in a Just-In-Time manner. Said differently, even if an IPSec traffic flow is established at a first of a cluster of ESP data nodes, such as data nodes134a-eor144a-eofFIG. 1B or 1C, any one of the other ESP data nodes in the cluster may service the ESP traffic by retrieving the necessary security associations from the KV store, such as KV stores138and148ofFIGS. 1B and 1C, respectively.

The techniques of the present disclosure also allow for the leveraging of Anycast and ECMP for IPSec. Specifically, using the techniques of the present disclosure, ESP nodes may be taken in and out of a cluster. If an ESP node disappears out of the available pool, Anycast and ECMP will automatically and in a stateless manner map the ESP packet to the next available ESP node, either in the same datacenter, or even in a next available datacenter, providing global failover functionality. When ESP traffic for locally unknown ESP security associations arrives on an ESP node, the ESP node will do a Just-in-Time lookup in the independent KV store, retrieving the session properties such as ESP keys and traffic selectors as described above. Accordingly, the techniques of the present disclosure may provide for global ESP session migration and massive horizontal scaling opportunities without interruption to the IPSec client session.

An example embodiment of leveraging a multi-stage anycast setup to allow for inter-datacenter failover, providing global load balancing and redundancy, is illustrated inFIG. 4. Specifically, an IPSec client106connects to the IPSec gateways with a destination IP address of 146.112.52.50. The Border Gateway Protocol (BGP) prefix for the IPSec gateway 146.112.52.50 is announced to the Internet using BGP as 146.112.52.0/24 out of datacenter305, which in the example ofFIG. 4is located in New York City. The supernet prefix 146.112.52.0/23 (which also contains the IP for the IPSec gateway 146.112.52.50), is announced out of datacenter310, which is located in Chicago. This means that when datacenter305becomes unavailable, traffic for the IPSec gateway with IP address 146.112.52.50 is automatically rerouted to datacenter310where it can be serviced by the IPSec gateway there. Specifically, if datacenter310has access to KV store348aof datacenter305, it can migrate the ESP sessions from datacenter305to datacenter310and into KV store348b. This model of providing datacenter failover scales out further to additional locations that announce, for example, the supernet prefix 146.112.52.0/22 and the supernet prefix 146.112.52.0/21, respectively. Since BGP follows the most specific prefix, traffic will route to the next active datacenter. Should that datacenter become unavailable, the IP address for the IPSec gateway prefix will automatically be available in the next datacenter, with the KV store data migrating between datacenters. The example above is an example of a 4-stage failover (i.e., utilizing supernet prefixes 146.112.52.0/21, 146.112.52.0/22, 146.112.52.0/23 and 146.112.52.0/24), but this model may scale as far as needed (e.g., by using additional supernet prefixes) and is only limited by the IP addresses available.

Because the techniques of the present disclosure separate out IKE and ESP into different nodes, the techniques rely on a KV store to handle state. This allows for the scaling of the KV store independently, and the scaling of a KV store is a problem already solved in related art that is outside the scope of the present disclosure.

With reference now made toFIG. 5, depicted therein is a flowchart500illustrating a process according to the techniques presented herein. The process beings in operation505in which an IKE protocol message is obtained at a first device. The IKE protocol message indicates that a first IPSec traffic flow is to be established by the first device. For example, the first device may be embodied as an ESP node, such as ESP data nodes134a-eofFIG. 1B, ESP data nodes144a-eofFIG. 1C, and/or ESP data nodes134aand134bofFIG. 2.

In operation510, the IKE protocol message is forwarded from the first device to a second device. For example, the second device may be embodied as an IKE node, such as IKE control node136ofFIG. 1B, IKE control nodes146aand146bofFIG. 1C, and/or IKE control nodes146a-cofFIG. 3.

In operation515an encryption key used to transmit traffic via the first IPSec traffic flow is received at the first device from a KV store. The KV store is populated in response to the second device obtaining the IKE protocol message. For example, the KV store may be embodied as a KV store as discussed above with reference toFIGS. 1B, 1C and 2-4.

In operation520, a first data packet is obtained at the first device to be transmitted via the first IPSec traffic flow. Finally, in operation525, the first data packet is provided to the first IPSec traffic flow using encryption provided by the encryption key.

One specific example embodiment of the process of flowchart500may take the form of the following call flow:An IKE packet is obtained at an ESP data node from a client device.The IKE packet is provided to the IKE server/control node.The IKE server/control node handles IKE packet, establishing the IPSec session.The IKE server/control node stores IKE session information in KV store.A first ESP packet arrives on the ESP data node.ESP data node reads key information from KV store and programs the data node for the ESP session.The first ESP packet is transmitted or provided from the ESP data node as part of the ESP session.

Embodiments of the process of flowchart500may also include the following additional operations. Specifically, when an ESP data node with an active session goes down (i.e., fails or is otherwise removed from service), the following operations may commence:ECMP routing redirects ESP data traffic to a new ESP data node.The new ESP data node that receives the ESP data traffic does not have the encryption key associated with the ESP data.The ESP data node requests the IKE server to rekey the ESP keys.The ESP data node obtains from the KV store the new ESP information, and installs the ESP information, such as the rekeyed encryption key, into the kernel of the ESP data node.The new ESP data node assumes servicing of the ESP session.

When an IKE server/control node fails or is otherwise removed from operation, example embodiments of the process of flowchart500may include the following operations:The IKE server/control node receives IKE traffic for an unknown session.The IKE server/control node performs a look-up in the KV store for session data associated within the unknown sessionIf the data associated with the unknown session is found in the KV store, data is obtained at the IKE server/control node where it is installed locally.The IKE server/control node assumes servicing of the previously unknown IKE session.

Accordingly, provided for herein are distributed IPSec implementations using KV stores which separate the IKE and ESP hosts, allowing each type of host to scale separately and horizontally.

The techniques presented herein specifically separate out IKE and ESP, resulting in different nodes handling IKE and ESP. A tunnel is installed on the node where IPSec traffic arrives, thereby having that node take over the tunnel. Any node can handle any session at any time, making this a fully elastic IPSec VPN service. Moreover, the IKE and ESP nodes may be completely stateless. The KV store may store all the states for the ESP and IKE sessions, thus allowing failure or migration of both IKE and ESP sessions across a variety of nodes. While the KV store will maintain state for IKE and ESP sessions, IKE control nodes and ESP data nodes may maintain local copies of the session states. Furthermore, on IKE control nodes, the techniques of the present disclosure detect when a given IKE session is not handled locally. The IKE session information is obtained from the KV store, and the session is programmed locally, all without interrupting the client side. Likewise, an existing ESP session can be detected on an ESP node, the session data obtained from the KV store, and programmed locally in the ESP node, with only a rekey involved.

The combination of the above described techniques allows to the implementation of an anycast-based VPN service, permitting failover of IKE and ESP sessions across datacenters and regions as required, bringing a truly cloud-native VPN service to life.

With reference now made toFIG. 6, depicted therein is an apparatus configured to implement the techniques of the present disclosure. Specifically, illustrated inFIG. 6is an apparatus that may be configured to implement any of the functions described above with regard to an ESP data node/server, an IKE server/control node, and/or a KV store as described above with reference toFIGS. 1-5, as well as datacenter elements as described with reference toFIG. 4.FIG. 6illustrates a computer system601upon which the embodiments presented may be implemented. The computer system601may be programmed to implement a computer based device. The computer system601includes a bus602or other communication mechanism for communicating information, and a processor603coupled with the bus602for processing the information. While the figure shows a single block for a processor, it should be understood that the processors603represent a plurality of processing cores, each of which can perform separate processing. The computer system601also includes a main memory604, such as a random access memory (RAM) or other dynamic storage device (e.g., dynamic RAM (DRAM), static RAM (SRAM), and synchronous DRAM (SD RAM)), coupled to the bus602for storing information and instructions to be executed by processor603. In addition, the main memory604may be used for storing temporary variables or other intermediate information during the execution of instructions by the processor603.

The computer system601further includes a read only memory (ROM)605or other static storage device (e.g., programmable ROM (PROM), erasable PROM (EPROM), and electrically erasable PROM (EEPROM)) coupled to the bus602for storing static information and instructions for the processor603.

The computer system601also includes a disk controller606coupled to the bus602to control one or more storage devices for storing information and instructions, such as a magnetic hard disk or solid state drive607, and a removable media drive608(e.g., floppy disk drive, read-only compact disc drive, read/write compact disc drive, removable magneto-optical drive and optical storage drive). The storage devices may be added to the computer system601using an appropriate device interface (e.g., small computer system interface (SCSI), integrated device electronics (IDE), enhanced-IDE (E-IDE), direct memory access (DMA), or ultra-DMA), or any other technologies now known or hereinafter developed.

The computer system601may also include special purpose logic devices (e.g., application specific integrated circuits (ASICs)) or configurable logic devices (e.g., simple programmable logic devices (SPLDs), complex programmable logic devices (CPLDs), and field programmable gate arrays (FPGAs)), that, in addition to microprocessors and digital signal processors may individually, or collectively, are types of processing circuitry. The processing circuitry may be located in one device or distributed across multiple devices.

The computer system601may also include a display controller609coupled to the bus602to control a display610, such as a Liquid Crystal Display (LCD), Light Emitting Diode (LED) display, or other now known or hereinafter developed display technologies, for displaying information to a computer user. The computer system601includes input devices, such as a keyboard611and a pointing device612, for interacting with a computer user and providing information to the processor603. The pointing device612, for example, may be a mouse, a trackball, a pointing stick or a touch-pad, for communicating direction information and command selections to the processor603and for controlling cursor movement on the display610. The display610may be a touch-screen display.

The computer system601performs a portion or all of the processing steps of the process in response to the processor603executing one or more sequences of one or more instructions contained in a memory, such as the main memory604. Such instructions may be read into the main memory604from another computer readable medium, such as a hard disk or solid state drive607or a removable media drive608. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory604. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

Stored on any one or on a combination of non-transitory computer readable storage media, embodiments presented herein include software for controlling the computer system601, for driving a device or devices for implementing the process, and for enabling the computer system601to interact with a human user (e.g., print production personnel). Such software may include, but is not limited to, device drivers, operating systems, development tools, and applications software. Such computer readable storage media further includes a computer program product for performing all or a portion (if processing is distributed) of the processing presented herein.

The computer code devices may be any interpretable or executable code mechanism, including but not limited to scripts, interpretable programs, dynamic link libraries (DLLs), Java classes, and complete executable programs. Moreover, parts of the processing may be distributed for better performance, reliability, and/or cost.

The computer system601also includes a communication interface613coupled to the bus602. The communication interface613provides a two-way data communication coupling to a network link614that is connected to, for example, a local area network (LAN)615, or to another communications network616such as the Internet. For example, the communication interface613may be a wired or wireless network interface card to attach to any packet switched (wired or wireless) LAN. As another example, the communication interface613may be an asymmetrical digital subscriber line (ADSL) card, an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of communications line. Wireless links may also be implemented. In any such implementation, the communication interface613sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

The network link614typically provides data communication through one or more networks to other data devices. For example, the network link614may provide a connection to another computer through a local area network615(e.g., a LAN) or through equipment operated by a service provider, which provides communication services through a communications network616. The local network614and the communications network616use, for example, electrical, electromagnetic, or optical signals that carry digital data streams, and the associated physical layer (e.g., CAT 5 cable, coaxial cable, optical fiber, etc.). The signals through the various networks and the signals on the network link614and through the communication interface613, which carry the digital data to and from the computer system601maybe implemented in baseband signals, or carrier wave based signals. The baseband signals convey the digital data as unmodulated electrical pulses that are descriptive of a stream of digital data bits, where the term “bits” is to be construed broadly to mean symbol, where each symbol conveys at least one or more information bits. The digital data may also be used to modulate a carrier wave, such as with amplitude, phase and/or frequency shift keyed signals that are propagated over a conductive media, or transmitted as electromagnetic waves through a propagation medium. Thus, the digital data may be sent as unmodulated baseband data through a “wired” communication channel and/or sent within a predetermined frequency band, different than baseband, by modulating a carrier wave. The computer system601can transmit and receive data, including program code, through the network(s)615and616, the network link614and the communication interface613. Moreover, the network link614may provide a connection through a LAN615to a mobile device617such as a personal digital assistant (PDA) laptop computer, or cellular telephone.

In summary, provided for herein are methods that comprise: obtaining, at a first device, an Internet Key Exchange protocol message indicating a first Internet Protocol Security traffic flow is to be established via the first device; forwarding, from the first device, the Internet Key Exchange protocol message to a second device; obtaining, at the first device from a key value store, an encryption key used to transmit traffic via the first Internet Protocol Security Traffic flow, wherein the key value store is populated with the encryption key in response to the second device obtaining the Internet Key Exchange protocol message; obtaining, at the first device, a first data packet to be transmitted via the first Internet Protocol Security traffic flow; and providing, from the first device, the first data packet encrypted with the encryption key of the first Internet Protocol Security traffic flow.

Also provided for herein is an apparatus that includes one or more processors and one or more network interfaces configured to communicate over a network. The one or more processors are configured to: obtain, via the one or more network interfaces, an Internet Key Exchange protocol message indicating a first Internet Protocol Security traffic flow is to be established via the apparatus; forward, via the one or more network interfaces, the Internet Key Exchange protocol message to a first device; obtain, at the apparatus from a key value store via the one or more network interfaces, an encryption key used to transmit traffic via the first Internet Protocol Security Traffic flow, wherein the key value store is populated with the encryption key in response to the first device obtaining the first Internet Key Exchange protocol message; obtain, via the one or more network interfaces, a first data packet to be transmitted via the Internet Protocol Security traffic flow; and provide, from the apparatus via the one or more network interfaces, the first data packet encrypted with the encryption key of the first Internet Protocol Security traffic flow.

Also according to the techniques of the present disclosure are non-transitory computer readable media encoded with instructions. When the instructions are executed by a processor, the instructions are operable to: obtain, at a first device, an Internet Key Exchange protocol message indicating a first Internet Protocol Security traffic flow is to be established via the first device; forward, from the first device, the Internet Key Exchange protocol message to a second device; obtain, at the first device from a key value store, an encryption key used to transmit traffic via the first Internet Protocol Security Traffic flow, wherein the key value store is populated with the encryption key in response to the second device obtaining the Internet Key Exchange protocol message; obtain, at the first device, a first data packet to be transmitted via the first Internet Protocol Security traffic flow; and provide, from the first device, the first data packet encrypted with the encryption key of the first Internet Protocol Security traffic flow.

Through the techniques of the present application, a distributed IPSec implementation may be established using a key/value store that also separates IKE and ESP, allowing each to scale separately.