Abstract: Techniques and mechanisms for using a domain-specific language (DSL) to express overall network behaviors by describing what network-level behavior is desired. A compiler breaks down the DSL into portions of executable code that are to be run at different network devices and locations of the network architecture. In some instances, the executable code output from the compiler may be used to determine what network functions, network devices, and/or network topology is required to implement the overall network behavior that is desired. In other examples, an inventory and/or topology of available network devices may be fed into the compiler, and the compiler may compile the DSL into executable code that is able to be supported by the inventory and/or topology of available network devices. Thus, the DSL can be used to describe overall network behaviors to easily generate executable code that is used to implement a desired network-level behavior.

Abstract: Methods are provided for decentralized key negotiation. One method includes initiating, by a first Internet Key Exchange (IKE) node from among a plurality of IKE nodes, a rekeying process for an Internet Protocol Security (IPSec) communication session established with a client device and serviced by a second IKE node from among the plurality of IKE nodes, and in which a first encryption key is used to encrypt traffic. The method further includes obtaining, by the first IKE node from a key value store, information about the IPSec communication session and performing, by the first IKE node, at least a part of the rekeying process in which the first encryption key is replaced with a second encryption key for the IPSec communication session.

Abstract: Techniques for load balancing encrypted traffic based on security parameter index (SPI) values of packet headers and sets of 5-tuple values of the packet headers are described herein. Additionally, techniques for including quality of service (QoS)-type information in SPI value fields of packet headers are also described herein. The QoS-type information may indicate a particular traffic class according to which the packet is to be handled. Further, techniques for pre-configuring a backend host such that encrypted traffic may be migrated to the backend host from another backend host without causing temporary service disruptions are also described herein.

Abstract: Methods are provided for decentralized key negotiation. One method includes initiating, by a first Internet Key Exchange (IKE) node from among a plurality of IKE nodes, a rekeying process for an Internet Protocol Security (IPSec) communication session established with a client device and serviced by a second IKE node from among the plurality of IKE nodes, and in which a first encryption key is used to encrypt traffic. The method further includes obtaining, by the first IKE node from a key value store, information about the IPSec communication session and performing, by the first IKE node, at least a part of the rekeying process in which the first encryption key is replaced with a second encryption key for the IPSec communication session.

Abstract: Techniques for load balancing encrypted traffic based on security parameter index (SPI) values of packet headers and sets of 5-tuple values of the packet headers are described herein. Additionally, techniques for including quality of service (QoS)-type information in SPI value fields of packet headers are also described herein. The QoS-type information may indicate a particular traffic class according to which the packet is to be handled. Further, techniques for pre-configuring a backend host such that encrypted traffic may be migrated to the backend host from another backend host without causing temporary service disruptions are also described herein.

Abstract: Techniques for load balancing encrypted traffic based on security parameter index (SPI) values of packet headers and sets of 5-tuple values of the packet headers are described herein. Additionally, techniques for including quality of service (QoS)-type information in SPI value fields of packet headers are also described herein. The QoS-type information may indicate a particular traffic class according to which the packet is to be handled. Further, techniques for pre-configuring a backend host such that encrypted traffic may be migrated to the backend host from another backend host without causing temporary service disruptions are also described herein.

Abstract: 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.

Abstract: A method may include, with a controller of an AS, routing a data flow from a source device, through at least one front-end node to a plurality of back-end nodes, and balancing, by the controller, the data flow to the back-end nodes equally based at least in part on ECMP routing. A number of routes from the back-end nodes to endpoint devices may be determined based at least in part on a preference for a primary route from the back-end nodes to a corresponding one of the endpoint devices, and backup routes from the back-end nodes to the corresponding one of the endpoint devices. An indication of a failure of a first endpoint device is received, and the back-end nodes utilize a first backup route that is associated with a second endpoint device to rebalance the data flow from the first endpoint device to the second endpoint device.

Abstract: This disclosure describes techniques and mechanisms for using a domain-specific language (DSL) to express and compile serverless network functions, and optimizing the deployment location for the serverless network functions on network devices. In some examples, the serverless network functions may be expressed entirely in the DSL (e.g., via a text-based editor, a graphics-based editor, etc.), where the DSL is a computer language specialized to a particular domain, such as a network function domain. In additional examples, the serverless network functions may be expressed and compiled using a DSL in combination with a general-purpose language (GSL). Once the serverless network function have been expressed and/or compiled, the techniques of this disclosure further include determining an optimized network component on which the serverless network function is to execute, and deploying the serverless function to the optimized network component.

Abstract: This disclosure describes techniques and mechanisms for using a domain-specific language (DSL) to express and compile serverless network functions, and optimizing the deployment location for the serverless network functions on network devices. In some examples, the serverless network functions may be expressed entirely in the DSL (e.g., via a text-based editor, a graphics-based editor, etc.), where the DSL is a computer language specialized to a particular domain, such as a network function domain. In additional examples, the serverless network functions may be expressed and compiled using a DSL in combination with a general-purpose language (GSL). Once the serverless network function have been expressed and/or compiled, the techniques of this disclosure further include determining an optimized network component on which the serverless network function is to execute, and deploying the serverless function to the optimized network component.

Abstract: Techniques and mechanisms to reduce double encryption of packets that are transmitted using encrypted tunnels. The techniques described herein include determining that portions of the packets are already encrypted, identifying portions of the packets that are unencrypted, and selectively encrypting the portions of the packets that are unencrypted prior to transmission through the encrypted tunnel. In this way, potentially private or sensitive data in the packets that is unencrypted, such as information in the packet headers, will be encrypted using the encryption protocol of the encrypted tunnel, but the data of the packets that is already encrypted, such as the payload, may avoid unnecessary double encryption. By reducing (or eliminating) the amount of data in data packets that is double encrypted, the amount of time taken by computing devices, and computing resources consumed, to encrypted traffic for encrypted tunnels may be reduced.

Abstract: A system receives a first request from a first instance of a network function associated with a first address. The system may determine the first address and, based at least in part on the first address, may identify a second address with which to respond to the first request. The system may then send, to the first instance of the network function, a response to the first request specifying the second address. The system may also receive a second request from a second instance of the network function associated with a third address. The system may determine a fourth address with which to respond to the second request, and may thereafter send a response to the second request to the second instance of the network function, with the response specifying the fourth address.

Abstract: 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.

Abstract: A VM receives a first ARP request from a first instance of a virtualized network function (VNF) associated with a first MAC address. The VM may determine the first MAC address and, based at least in part on the first MAC address, may a second MAC address with which to respond to the first ARP request. The VM may then send, to the first instance of the VNF, a response to the first ARP request specifying the second MAC address. The VM may also receive a second ARP request from a second instance of the VNF associated with a third MAC address. The VM may determine a fourth MAC address with which to respond to the second ARP request, and may thereafter send a response to the second ARP request to the second instance of the VNF, with the response specifying the fourth MAC address.

Abstract: Techniques for detecting inactive peers of a tunneled communication session, while allowing for a scalable tunneled protocol that includes split control plane nodes and data plane nodes are described herein. A method according to a technique described herein may include establishing a communication session between a first node and a second node in a network such that control plane traffic of the communication session flows through one or more control nodes and data plane traffic of the communication session flows through one or more data nodes different than the one or more control nodes. The method may also include receiving, at a control node, an indication from a data node that a probe message is to be generated. The probe message may be configured to determine data plane connectivity in the communication session. Additionally, the control node may generate the probe message and send it to the first node.

Abstract: This disclosure describes techniques and mechanisms for using a domain-specific language (DSL) to express and compile serverless network functions, and optimizing the deployment location for the serverless network functions on network devices. In some examples, the serverless network functions may be expressed entirely in the DSL (e.g., via a text-based editor, a graphics-based editor, etc.), where the DSL is a computer language specialized to a particular domain, such as a network function domain. In additional examples, the serverless network functions may be expressed and compiled using a DSL in combination with a general-purpose language (GSL). Once the serverless network function have been expressed and/or compiled, the techniques of this disclosure further include determining an optimized network component on which the serverless network function is to execute, and deploying the serverless function to the optimized network component.

Abstract: A VM receives a first ARP request from a first instance of a virtualized network function (VNF) associated with a first MAC address. The VM may determine the first MAC address and, based at least in part on the first MAC address, may a second MAC address with which to respond to the first ARP request. The VM may then send, to the first instance of the VNF, a response to the first ARP request specifying the second MAC address. The VM may also receive a second ARP request from a second instance of the VNF associated with a third MAC address. The VM may determine a fourth MAC address with which to respond to the second ARP request, and may thereafter send a response to the second ARP request to the second instance of the VNF, with the response specifying the fourth MAC address.

Abstract: Presented herein are techniques for establishing VPN services. According to example embodiments, an initial VPN message configured to establish a VPN session between the initiating device and a responding device is received at a VPN node. The initial VPN message is received from an initiating device. Data indicative of the initiating device and data indicative of the responding device is extracted from the initial VPN message. A VPN namespace is established to facilitate the VPN session between the initiating device and the responding device based on the data indicative of the initiating device and the data indicative of the responding device. One or more messages comprising data indicative of the VPN session are transmitted to a database.

Abstract: Methods are provided for decentralized key negotiation. One method includes initiating, by a first Internet Key Exchange (IKE) node from among a plurality of IKE nodes, a rekeying process for an Internet Protocol Security (IPSec) communication session established with a client device and serviced by a second IKE node from among the plurality of IKE nodes, and in which a first encryption key is used to encrypt traffic. The method further includes obtaining, by the first IKE node from a key value store, information about the IPSec communication session and performing, by the first IKE node, at least a part of the rekeying process in which the first encryption key is replaced with a second encryption key for the IPSec communication session.

Abstract: 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.