Patent Description:
A computer network is a collection of interconnected computing devices that can exchange data and share resources. Example computing devices include routers, switches, and other Layer <NUM> (L2) network devices that operate within Layer <NUM> of the Open Systems Interconnection (OSI) reference model, i.e., the data link layer, and Layer <NUM> (L3) network devices that operate within Layer <NUM> of the OSI reference model, i.e., the network layer. Network devices within computer networks often include a control unit that provides control plane functionality for the network device and forwarding components for routing or switching data units.

The computing devices may establish a "network session" (also referred to herein as "session") to enable communication between devices on a computer network. A session may be bidirectional in that the session includes packets traveling in both directions between a first device and a second device. For example, a session includes a forward packet flow originating from a first device and destinated for a second device and a reverse packet flow originating from the second device and destined for the first device. The forward and reverse packet flows of the session are related to one another in that the source address and source port of the forward packet flow is the same as the destination address and destination port of the reverse packet flow, and the destination address and destination port of the forward packet flow is the same as the source address and source port of the reverse packet flow.

Alternatively, a session may be unidirectional in that the session includes packets traveling in only one direction from a first device to a second device. For example, a session includes a forward packet flow originating from a first device and destinated for a second device. A different session may include a reverse packet flow originating from the second device and destined for the first device.

To establish a session, computing devices may use one or more communication session protocols including Transmission Control Protocol (TCP), Transport Layer Security (TLS), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), etc..

"<NPL> provides techniques for restricting keys to preauthorized uses and provides key management models for systems involving multiple domains or authorities. <CIT> provides a secure communication apparatus including a security module for generating an encrypted bitstream by encrypting at least a portion of data forming a bitstream and inserting at least a portion of key information used in the encryption into the bitstream and for decrypting encrypted data by acquiring at least a portion of key information for the decryption from a received encrypted bitstream, and a communication module for transmitting and receiving the encrypted bitstream.

In a traditional network system, a centralized security server may be used to distribute and update keys used by network devices to encrypt and decrypt network traffic. Such a server may attempt to update a key by providing a new key to each network device. However, if a network device is unavailable during an update, that network device would not have the proper key to decrypt traffic from other network devices as the other network devices may be using the updated key. Additionally, the other network devices may not be able to decrypt traffic from the network device that was unavailable, as the network device that was unavailable may be using an outdated key.

In some traditional network systems, the centralized security server may not have direct connections to each network device. In such cases, a network device may have to insert the key into the payload of a packet. That packet may traverse the network, being decrypted and reencrypted at each intervening router between the ingress router and egress router. Such an arrangement may involve a large amount of processing power due to all the encrypting and decrypting that is required.

In general, this disclosure describes techniques for providing a key inline without the need for a centralized security server. In one example, each path in a network between two network devices is associated with a path key which is used to encrypt and decrypt metadata associated with packets flowing between the two network devices. A first network device encrypts the payload of a packet using a payload key, which may be different than the path keys. The first network device may insert the payload key into metadata associated with the packet. The network device then encrypts the metadata using the path key. One or more intervening network devices each using their associated path keys may decrypt the metadata, determine that the packet is not destined for a client device coupled to the one or more intervening network devices based on the metadata, and re-encrypt the metadata using the path key associated with a path to the next network device. When the packet arrives at the network device that is coupled to the client device for which the packet is destined (the terminus or egress network device), the egress network device may decrypt the metadata using the path key associated with the path between the egress network device and the upstream next hop network device that sent the packet to the egress network device. The egress network device may determine that the packet is intended for the client device coupled to the egress network device based on the metadata. The egress network device may then obtain the payload key from the decrypted metadata and use the payload key to decrypt the payload of the packet. In some examples, one or more of the network devices may be session-based routers and the payload key may be associated with a session.

The techniques of the disclosure may provide specific improvements to the computer-related field of computer networking that have practical applications. For example, the techniques disclosed herein may provide for the distribution of payload keys in a point-to-point manner that does not require a centralized security server and which does not require each intervening network device to decrypt the payload of a packet and re-encrypt the payload, saving considerable processing power and network resources, particularly in the case where there are numerous intervening network devices.

In one example, this disclosure describes a network device including one or more processors and memory coupled to the one or more processors, the memory storing instructions that, upon execution, cause one or more processors to: obtain a first payload key; obtain a path key; encrypt a first payload of a first packet using the first payload key; insert the first payload key into first metadata of the first packet; encrypt the first metadata using the path key; and send the first packet to another network device.

In another example, this disclosure describes a network device including one or more processors and memory coupled to the one or more processors, the memory storing instructions that upon execution cause one or more processors to: obtain a path key; receive a first packet from another network device; decrypt first metadata of the first packet using the path key; obtain a first payload key from the first metadata of the first packet; and decrypt a first payload of the first packet using the first payload key.

In another example, this disclosure describes a method including: obtaining, by one or more processors of an ingress network device, a first payload key; obtaining, by one or more processors of the ingress network device, a first path key, the first path key being associated with one or more paths between the ingress network device and a first intervening network device of one or more intervening network devices; encrypting, by one or more processors of the ingress network device, a first payload of a first packet using the first payload key; inserting, by the one or more processors of the ingress network device, the first payload key into first metadata of the first packet; encrypting, by the one or more processors of the ingress network device, the first metadata using the first path key; and sending, by the one or more processors of the ingress network device, the first packet to the first intervening network device of the one or more intervening network devices, wherein the first packet is destined for an egress network device.

The details of one or more examples of the techniques of this disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the techniques will be apparent from the description and drawings, and from the claims.

<FIG> is a block diagram illustrating an example computer network system <NUM> in accordance with the techniques of the disclosure. In the example of <FIG>, computer network system <NUM> includes service provider networks 150A-150D (collectively, "service provider networks <NUM>") configured to provide Wide Area Network (WAN) connectivity to disparate customer networks 140A-140B (collectively, "customer networks <NUM>"). Routers 110A-110I (collectively, "routers <NUM>") of service provider networks <NUM> provide client devices 100A-100B (collectively, "client devices <NUM>") associated with customer networks <NUM> with access to service provider networks <NUM>. In some examples, customer networks <NUM> are enterprise networks. Customer network 140A is depicted as having a single client device 100A and customer network 140B is depicted as having a single client device 100B for ease of illustration, but each of customer networks <NUM> may include any number of client devices.

In some examples, customer networks <NUM> may be L2 computer networks, where reference to a layer followed by a number refers to a corresponding layer in the Open Systems Interconnection (OSI) model. L2 is also known as a "data link layer" in the OSI model and the term L2 may be used interchangeably with the phrase "data link layer" throughout this disclosure. Typically, customer networks <NUM> include many client devices <NUM>, each of which may communicate across service provider networks <NUM> with one another as described in more detail below. Communication links 16A-<NUM> (collectively, links "<NUM>") may be Ethernet, ATM or any other suitable network connections. In other examples, customer networks <NUM> may be L3 networks. Common L3 operations include those performed in accordance with L3 protocols, such as the Internet Protocol (IP). L3 is also known as a "network layer" in the OSI model and the term L3 may be used interchangeably with the phrase "network layer" throughout this disclosure.

Routers <NUM> are illustrated as routers in the example of <FIG>. However, techniques of the disclosure may be implemented using any network device, such as switches, routers, gateways, or other suitable network devices that may send and receive network traffic. Customer networks <NUM> may be networks for geographically separated sites of an enterprise, for example. Each of customer networks <NUM> may include additional customer equipment, such as, one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other routers not depicted in <FIG>. The configuration of computer network system <NUM> illustrated in <FIG> is merely an example. For example, computer network system <NUM> may include any number of customer networks <NUM>. Nonetheless, for ease of description, only customer networks 140A-140B are illustrated in <FIG>.

Service provider networks <NUM> represent one or more publicly accessible computer networks that are owned and operated by one or more service providers. Although computer network system <NUM> is illustrated in the example of <FIG> as including multiple interconnected service provider networks <NUM>, in other examples computer network system <NUM> may alternatively include a single service provider network that provides connectivity between customer networks <NUM>. A service provider is usually a large telecommunications entity or corporation. Each of service provider networks <NUM> is usually a large L3 computer network. Each service provider network <NUM> is an L3 network in the sense that it natively supports L3 operations as described in the OSI model.

Although not illustrated, each service provider network <NUM> may be coupled to one or more networks administered by other providers, and may thus form part of a large-scale public network infrastructure, e.g., the Internet. Consequently, customer networks <NUM> may be viewed as edge networks of the Internet. Each service provider network <NUM> may provide computing devices within customer networks <NUM>, such as client devices <NUM>, with access to the Internet, and may allow the computing devices within customer networks <NUM> to communicate with each other.

Although additional routers are not shown for ease of explanation, it should be understood that system <NUM> may comprise additional network and/or computing devices such as, for example, one or more additional switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other routers. Moreover, although the elements of system <NUM> are illustrated as being directly coupled, it should be understood that one or more additional network elements may be included along any of network links <NUM>, such that the network elements of system <NUM> are not directly coupled.

Each service provider network <NUM> typically provides a number of residential and business services for customer networks <NUM>, including residential and business class data services (which are often referred to as "Internet services" in that these data services permit access to the collection of publicly accessible networks referred to as the Internet), residential and business class telephone and/or voice services, and residential and business class television services.

In some examples, routers <NUM> may implement a stateful, session-based routing scheme that enables each of routers <NUM> to independently perform path selection and traffic engineering. The use of session-based routing may enable routers <NUM> to eschew the use of a centralized controller, such as a Software-Defined Networking (SDN) controller to perform path selection and traffic engineering. In this way, routers <NUM> may be more efficient and scalable for large networks where the use of an SDN controller would be infeasible. Furthermore, the use of session-based routing may enable routers <NUM> to eschew the use of tunnels, thereby saving considerable network resources by obviating the need to perform encapsulation and decapsulation at tunnel endpoints. In some examples, routers <NUM> implement session-based routing as Secure Vector Routing (SVR), provided by Juniper Networks, Inc. In some examples, routers <NUM> include Ethernet over SVR (EoSVR) routers.

In the example of <FIG>, client device 100A of system <NUM> establishes session <NUM> (shown with a dashed line) with client device 100B. Routers <NUM> facilitate establishment of session <NUM> by transporting network traffic between client device 100A and client device 100B. In some examples, client device 100A may be considered a "source" device in that client device 100A originates session <NUM> between client device 100A and client device 100B, e.g., client device 100A is the "source" of a packet of a forward flow of the session. Session <NUM> includes a forward packet flow originating from client device 100A and destined for client device 100B and a reverse packet flow originating from client device 100B and destined for client device 100A. A forward flow for session <NUM> traverses a first path including, e.g., client device 100A, routers 110A-110I, and client device 100B.

In some examples, routers <NUM> may extend session <NUM> as an L3 session across service provider networks <NUM> according to one or more L3 communication session protocols, including Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), etc. For example, to establish session <NUM> according to TCP such that data may be exchanged according to TCP, client device 100A and client device 100B perform a three-way handshake. Client device 100A sends a first packet comprising a "SYN" flag to client device 100B. Client device 100B acknowledges receipt of the first packet by responding to client device 100A with a second packet comprising a "SYN-ACK" flag. Client device 100A acknowledges receipt of the second packet by responding to client device 100B with a third packet comprising an "ACK" flag. After sending the third packet, session <NUM> is established according to TCP and client devices 100A, 100B may exchange data with one another via session <NUM>. Additional example information regarding TCP is described in "<NPL>.

UDP is a connectionless protocol in that client device 100A does not verify that client device 100B is capable of receiving data prior to transmitting data. To establish session <NUM> according to UDP, client device 100A transmits a first packet to client device 100B. Session <NUM> may be considered "established" according to UDP upon receipt by client device 100A of any packet from client device 100B, which implies that client device 100B successfully received the first packet from client device 100A, responded, and client device 100A was able to receive the response from client device 100B. Additional example information regarding UDP is described in "<NPL>.

In the example of <FIG>, when router 110A receives a packet for the forward packet flow originating from client device 100A and destined for client device 100B, router 110A determines whether the packet belongs to a new session (e.g., is the "first" packet or "lead" packet of session <NUM>). In some examples, router 110A determines whether a source address, source port, destination address, destination port, and protocol of the first packet matches an entry in a session table.

If no such entry exists, router 110A determines that the packet belongs to a new session and creates an entry in the session table. Furthermore, if the packet belongs to a new session, router 110A may generate a session identifier for session <NUM>. The session identifier may comprise, e.g., a source address and source port of client device 100A, a destination address and destination port of client device 100B, and a protocol used by the first packet. Router 110A may use the session identifier to identify subsequent packets as belonging to the same session.

In some examples, routers <NUM> perform stateful routing for session <NUM>. For example, routers <NUM> may forward each packet of the forward packet flow of session <NUM> sequentially and along the same forward network path. As described herein, the "same" forward path may mean the same routers <NUM> that form a segment or at least a portion of the path between a device originating the packet and a device to which the packet is destined (and not necessarily the entire network path between the device originating the packet and the device to which the packet is destined). Further, routers <NUM> forward each packet of the return flow of session <NUM> sequentially and along the same return network path. The forward network path for the forward packet flow of session <NUM> and the return network path of the return packet flow of session <NUM> may be the same path, or different paths. By ensuring that each packet of a flow is forwarded sequentially and along the same path, routers <NUM> maintain the state of the entire flow at each router <NUM>, thereby enabling the use of stateful packet services, such as Deep Packet Inspection (DPI).

In the example of <FIG>, a stateful routing session may be established from router 110A (which may be an ingress router) through intervening network devices, such as routers 110B-<NUM>, to router 110I (which may be an egress router). In this example, router 110A determines that the first packet is an unmodified packet and the first packet of new session <NUM>. Router 110A modifies the first packet to include metadata specifying the session identifier. The metadata may, in some examples, be inserted after the header of the modified first packet. The session identifier may include, e.g., the original source address, source port, destination address, destination port, protocol, service, and/or tenant. Router 110A replaces the header of the modified first packet to specify a source address that is an address of router 110A, a source port that is a port via which router 110A forwards the modified first packet toward client device 100B, a destination address that is an address of the next hop to which router 110A forwards the first packet (e.g., an address of router 110B), and a destination port that is a port of the next hop to which router 110A forwards the first packet (e.g., a port of router 110B).

Router 110A may further identify a network service associated with session <NUM>. For example, router 110A may compare one or more of a source address, source port, destination address, or destination port for the session to a table of service address and port information to identify a service associated with the session. Examples of network services include Hypertext Transfer Protocol (HTTP), a firewall service, a proxy service, packet monitoring or metrics services, etc. For example, router 110A may determine that the forward packet flow of session <NUM> specifies a destination address and destination port assigned to client device 100B. Router 110A may thereafter store an association between session <NUM> with the identified network service. As another example, if the source port and/or destination port for session <NUM> is <NUM>, router 110A may determine that session <NUM> is associated with an HTTP service. In other examples, router 110A may determine that one or more of a source address, source port, destination address, or destination port for session <NUM> belong to a block of address or ports indicative that a particular service is associated with session <NUM>.

In some examples, router 110A uses the determined network service for session <NUM> to select a forward path for forwarding the first packet and each subsequent packet of the forward packet flow of session <NUM> toward client device 100B. In this fashion, router 110A may perform service-specific path selection to select a network path that best suits the requirements of the service. In contrast to a network topology that uses an SDN controller to perform path selection, each of routers <NUM> performs path selection. Further, the use of session-based routing enables each of routers <NUM> to make routing decisions at the service- or application-level, in contrast to conventional routers that are only able to make routing decisions at the flow level.

According to the techniques of this disclosure, network devices, such as routers <NUM>, may provide inline payload key exchange. For example, router 110A may obtain a first payload key and obtain a path key. For example, this first payload key may be generated by router 110A or may be received by router 110A from, for example, a security server (not shown). In some examples, the first payload key is specific to a session. In some examples, the first payload key may be based on a service. For example, a voice service may have one associated payload key, while a video service may have another associated payload key.

In some examples, router 110A and router 110B may exchange path keys using transport layer security (TLS). In some examples, the same path key is used for all peer-to-peer paths between router 110A and router 110B. In response to obtaining the first payload key and path key, router 110A may insert the payload key into metadata associated with a packet. Router 110A may then encrypt the metadata and/or the packet header, using a path key that router 110A shares with router 110B.

Router 110A may forward the modified first packet to router 110B. Additionally, router 110A may store the session identifier for session <NUM> such that, upon receiving subsequent packets for session <NUM>, router 110A may identify the subsequent packets as belonging to the same session <NUM> and forward the subsequent packets along the same path as the first packet.

Intervening router 110B may receive the modified first packet and decrypt the metadata using the path key shared between router 110A and router 110B. Router 110B then may determine whether the modified first packet includes metadata specifying the session identifier. In response to determining that the modified first packet includes metadata specifying the session identifier, intervening router 110B may determine that router 110B is not an ingress device such that router 110B does not attach metadata specifying the session identifier.

As described above with respect to router 110A, router 110B determines whether the packet belongs to a new session (e.g., is the "first" packet or "lead" packet of the session) by determining whether a source address, source port, destination address, destination port, and protocol of the first packet matches an entry in a session table. If no such entry exists, router 110B may determine that the packet belongs to a new session and create an entry in the session table. Furthermore, if the packet belongs to a new session, router 110B may generate a session identifier for the session. The session identifier used by router 110B to identify the session for the first packet may be different from the session identifier used by router 110A to identify the same session for the first packet, because each router 110A, 110B uses the header source address, source port, destination address, and destination port of the first packet to generate the session identifier, and this header information may be modified by each preceding router of routers <NUM> as each of routers <NUM> forwards the first packet along the forward path. Furthermore, each of routers <NUM> may store this header information to identify a previous router of routers <NUM> (or "waypoint") and a next router of routers <NUM> (or "waypoint") such that each of routers <NUM> may reconstruct the same forward path and reverse path for each subsequent packet of the session.

Router 110B may replace the header of the modified first packet to specify a source address that is an address of router 110B, a source port that is a port via which router 110B forwards the modified first packet toward client device 100B, a destination address that is an address of the next hop to which router 110B may forward the first packet (e.g., an address of router 110C for session <NUM> along the first path), and a destination port that is a port of the next hop to which router 110B may forward the first packet (e.g., a port of router 110C). Router 110B may encrypt the metadata, including the payload key, using a path key router 110B shares with router 110C and forward the modified first packet to router 110C. Additionally, router 110B may store the session identifier for the session such that, upon receiving subsequent packets for the session, router 110B may identify subsequent packets as belonging to the same session and forward the subsequent packets along the same path as the first packet.

Subsequent intervening network devices, such as routers 110C-<NUM>, may process the modified first packet in a similar fashion as routers 110A and 110B such that routers <NUM> forward the subsequent packets of the session along the same path as the first packet. Further, each of routers <NUM> may store a session identifier for the session, which may include an identification of the previous router of routers <NUM> along the network path. Thus, each of routers <NUM> may use the session identifier to forward packets of the reverse packet flow for the session along the same network path back to client device 100A. As the packet is not destined for any client device coupled to any of the intervening network devices (e.g., routers 110B-<NUM>), none of the intervening network devices need to decrypt the payload using the payload key. Therefore, each of the intervening network devices (e.g., routers 110B-<NUM>) may refrain from decrypting the payload, thus saving network processing resources.

A router of routers <NUM> that may forward packets for a forward packet flow of the session to a destination for the packet flow may be called an egress, or "terminus" router. In the foregoing example, router 110I is a terminus router because router 110I may forward packets to client device 100B. Router 110I receives the modified first packet that comprises the metadata specifying the session identifier (e.g., the original source address, source port, destination address, and destination port) and the metadata including the payload key. Router 110I decrypts the metadata using a path key router 110I shares with router <NUM>, identifies the modified first packet as destined for a service terminating at router 110I by determining that the destination source address and destination source port specified in the metadata of the modified lead packet corresponds to a destination reachable by router 110I (e.g., client device 100B). Router 110I recovers the original first packet by removing the metadata from the modified first packet, decrypting the payload using the payload key from the metadata, and using the metadata to modify the header of the first packet to specify the original source address, source port, destination address, and destination port. Router 110I forwards the recovered first packet to client device 100B. The use of session-based routing may therefore form a series of waypoints (e.g., routers <NUM>) interconnected by path "segments" (e.g., end-to-end route vectors between each waypoint) that provide inline payload key exchange.

Router 110A may determine when to update the payload key. For example, router 110A may update the payload key on a periodic basis, e.g., every <NUM> minutes, every <NUM> minutes, or some (e.g., routers <NUM>) interconnected by path "segments" (e.g., end-to-end route vectors between each waypoint) that provide inline payload key exchange.

Router 110A may determine when to update the payload key. For example, router 110A may update the payload key on a periodic basis, e.g., every <NUM> minutes, every <NUM> minutes, or some other amount of time. In these examples, router 110A may update the payload key and distribute the updated payload key using the techniques described above.

<FIG> is a block diagram illustrating an example computing device <NUM> in accordance with the techniques of the disclosure. In general, computing device <NUM> may be an example implementation of one of routers <NUM> of <FIG>. <FIG> illustrates a particular example of a server or other computing device <NUM> that includes processing circuitry <NUM> for executing any one or more of applications <NUM>, routing component <NUM>, or any other computing device described herein. Other examples of computing device <NUM> may be used in other instances.

Although shown in <FIG> as a stand-alone computing device <NUM> for purposes of example, a computing device that operates in accordance with the techniques of this disclosure may be any component or system that includes one or more processors or other suitable computing environment for executing software instructions and, for example, need not necessarily include one or more elements shown in <FIG> (e.g., communication units <NUM>; and in some examples, components such as storage device(s) <NUM> may not be co-located or in the same chassis as other components). In some examples, computing device <NUM> may be implemented as a virtualized network function (VNF). In some examples, one or more aspects of computing device <NUM> can be run as one or more containers or as one or more applications within virtual machines of a Network Functions Virtualization (NFV) platform using, e.g., VirtIO and SRIOV network virtualization technologies, or on bare-metal servers. In some examples, computing device <NUM> is a physical network device, such as a switch, router, gateway, or other device that sends and receives network traffic.

As shown in the example of <FIG>, computing device <NUM> includes processing circuitry <NUM>, one or more input device(s) <NUM>, one or more communication unit(s) <NUM>, one or more output device(s) <NUM>, one or more storage device(s) <NUM>, and one or more user interface (UI) device(s) <NUM>. Computing device <NUM>, in one example, further includes one or more application(s) <NUM> and operating system <NUM> that are executable by computing device <NUM>. Each data structure, or any other method for communicating data. As one example, components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be coupled by one or more communication channels <NUM>.

Processing circuitry <NUM>, in one example, is configured to implement functionality and/or process instructions for execution within computing device <NUM>. In some examples, processing circuitry <NUM> comprises one or more hardware-based processors. For example, processing circuitry <NUM> may be capable of processing instructions stored in storage device <NUM>. Examples of processing circuitry <NUM> may include, any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry.

One or more storage device(s) <NUM> may be configured to store information within computing device <NUM> during operation. Storage device(s) <NUM>, in some examples, is described as a computer-readable storage medium. In some examples, storage device(s) <NUM> include a temporary memory, meaning that a primary purpose of storage device <NUM> is not long-term storage. Storage device(s) <NUM>, in some examples, include a volatile memory, meaning that storage device(s) <NUM> does not maintain stored contents when the computer is turned off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories. In some examples, storage device(s) <NUM> stores program instructions for execution by processing circuitry <NUM>. Storage device(s) <NUM>, in one example, are used by software or applications running on computing device <NUM> to temporarily store information during program execution.

Storage device(s) <NUM>, in some examples, also include one or more computer-readable storage media. Storage device(s) <NUM> may be configured to store larger amounts of information than volatile memory. Storage device(s) <NUM> may further be configured for long-term storage of information. In some examples, storage device(s) <NUM> include non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.

Computing device <NUM>, in some examples, also includes one or more communication unit(s) <NUM>. Computing device <NUM>, in one example, utilizes communication unit(s) <NUM> to communicate with external devices via one or more networks, such as one or more wired/wireless/mobile networks. Communication unit(s) <NUM> may include a network interface, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that can send and receive information. Other examples of such network interfaces may include <NUM> and WiFi radios. In some examples, communication unit(s) <NUM> may include a plurality of high-speed network interface cards. In some examples, computing device <NUM> uses communication unit(s) <NUM> to communicate with an external device. For example, computing device <NUM> uses communication unit(s) <NUM> to communicate with other routers <NUM> and/or client devices <NUM> of <FIG> via links <NUM> of <FIG> with which communication unit(s) <NUM> are connected.

Computing device <NUM>, in one example, also includes one or more user interface device(s) <NUM>. User interface devices <NUM>, in some examples, are configured to receive input from a user through tactile, audio, or video feedback. Examples of user interface devices(s) <NUM> include a presence-sensitive display, a mouse, a keyboard, a voice responsive system, video camera, microphone or any other type of device for detecting a command from a user. In some examples, a presence-sensitive display includes a touch-sensitive screen. In some examples, a user such as an administrator of service provider networks <NUM> may enter configuration data for computing device <NUM>.

One or more output device(s) <NUM> may also be included in computing device <NUM>. Output device(s) <NUM>, in some examples, is configured to provide output to a user using tactile, audio, or video stimuli. Output device(s) <NUM>, in one example, includes a presence-sensitive display, a sound card, a video graphics adapter card, or any other type of device for converting a signal into an appropriate form understandable to humans or machines. Additional examples of output device(s) <NUM> include a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device that can generate intelligible output to a user.

Computing device <NUM> may include operating system <NUM>. Operating system <NUM>, in some examples, controls the operation of components of computing device <NUM>. For example, operating system <NUM>, in one example, facilitates the communication of one or more applications <NUM> with processing circuitry <NUM>, communication unit(s) <NUM>, storage device(s) <NUM>, input device(s) <NUM>, user interface device(s) <NUM>, and output device(s) <NUM>. Applications <NUM> may also include program instructions and/or data that are executable by computing device <NUM>.

In some examples, processing circuitry <NUM> executes routing component <NUM>, which determines routes of received packets and forwards the packets accordingly. Routing component <NUM> may communicate with other routers, e.g., such as routers <NUM> of <FIG>, to establish and maintain a computer network, such as computer network system <NUM> of <FIG>, for transporting network traffic between one or more customer devices. Routing protocol daemon (RPD) <NUM> of routing component <NUM> may execute software instructions to implement one or more control plane networking protocols <NUM>. For example, protocols <NUM> may include one or more routing protocols, such as Internet Group Management Protocol (IGMP) <NUM> and/or Border Gateway Protocol (BGP) <NUM>, for exchanging routing information with other routing devices and for updating routing information base (RIB) <NUM>, Multiprotocol Label Switching (MPLS) protocol <NUM>, and other routing protocols. Protocols <NUM> may further include one or more communication session protocols, such as TCP, UDP, TLS, or ICMP.

Routing information <NUM> may describe a topology of the computer network in which computing device <NUM> resides, and may also include routes through the shared trees in the computer network. Routing information <NUM> may describe various routes within the computer network, and the appropriate next hops for each route, e.g., the neighboring routing devices along each of the routes. Routing information <NUM> may be programmed into dedicated forwarding chips, a series of tables, a complex database, a link list, a radix tree, a database, a flat file, or various other data structures.

Session information <NUM> stores information for identifying sessions. In some examples, session information <NUM> is in the form of a session table. For example, services information <NUM> comprises one or more entries that specify a session identifier. In some examples, the session identifier comprises one or more of a source address, source port, destination address, destination port, or protocol associated with a forward packet flow and/or a reverse packet flow of the session. As described above, when routing component <NUM> receives a packet for a forward packet flow originating from client device 100A and destined for client device 100B of <FIG>, routing component <NUM> determines whether the packet belongs to a new session (e.g., is the "first" packet or "lead" packet of session <NUM>). To determine whether the packet belongs to a new session, routing component <NUM> determines whether session information <NUM> includes an entry corresponding to a source address, source port, destination address, destination port, and protocol of the first packet. If an entry exists, then the session is not a new session. If no entry exists, then the session is new and routing component <NUM> generates a session identifier for the session and stores the session identifier in session information <NUM>. Routing component <NUM> may thereafter use the session identifier stored in session information <NUM> for the session to identify subsequent packets as belonging to the same session.

Services information <NUM> stores information that routing component <NUM> may use to identify a service associated with a session. In some examples, services information <NUM> is in the form of a services table. For example, services information <NUM> comprises one or more entries that specify a service identifier and one or more of a source address, source port, destination address, destination port, or protocol associated the service. In some examples, routing component <NUM> may query services information <NUM> with one or more of a source address, source port, destination address, destination port, or protocol of a session for a received packet to determine a service associated with a session. For example, routing component <NUM> may determine a service identifier based on a correspondence of a source address, source port, destination address, destination port, or protocol in services information <NUM> to a source address, source port, destination address, destination port, or protocol specified by a session identifier. Routing component <NUM> retrieves, based on the service associated with the packet, one or more service policies <NUM> corresponding to the identified service. The service policies may include, e.g., a path failover policy, a Dynamic Host Configuration Protocol (DHCP) marking policy, a traffic engineering policy, a priority for network traffic associated with the session, etc. Routing component <NUM> applies, to the packet, the one or more service policies <NUM> that correspond to the service associated with the packet.

In accordance with the techniques of the disclosure, computing device <NUM> performs inline payload key distribution. Computing device <NUM> may operate as any of routers <NUM> of <FIG>. With reference to <FIG>, in the following example, computing device <NUM> operates as router 110A. Computing device <NUM> receives, via communication unit(s) <NUM>, a packet from client device 100A destined for client device 100B. In response to receiving the packet, computing device <NUM> generates an L3 packet comprising an L3 header, a first portion of metadata comprising a source IP address and a source port of client device 100A and a destination IP address and a destination port of client device 100B. In some examples, computing device <NUM> generates the first portion of metadata specifying the session identifier and a second portion of the metadata comprising a payload key.

In some examples, the first portion of metadata comprises a session identifier. The session identifier is a unique identifier for a session comprising a first packet flow originating from a first client device (e.g., client device 100A) and destined for a second client device (e.g., client device 100B) and a second packet flow originating from the second client device and destined for the first client device. Typically, the session identifier comprises a <NUM>-tuple, e.g., the source IP address and the source port of the first client device, the destination IP address and the destination port of the second client device, and a network protocol used by the session.

In some examples, a second portion of the metadata comprises a payload key. In some examples, computing device <NUM> may generate the payload key. In other examples, computing device <NUM> may receive the payload key from another network device, such as a security server.

In this example, the packet is a first packet of a plurality of packets for the session. In response to receiving the first packet, computing device <NUM> may generate a session identifier for the session between client device 100A and client device 100B and store the session identifier in session information <NUM> (e.g., so as to store the first portion of metadata of the L3 packet). Computing device <NUM> may generate, based on the first packet, the L3 packet comprising the L3 header, first portion of metadata, and the second portion of metadata, as described above. Computing device <NUM> may use a path key associated with the path between router 110A and router 110B to encrypt the metadata. Computing device <NUM> may also encrypt the payload of the packet with the payload key and then forward, via communication unit(s) <NUM>, the L3 packet toward the next-hop router, router 110B.

For subsequent packets, computing device <NUM> may determine, based on information of the subsequent packets (e.g., <NUM>-tuple), that the subsequent packets belong to the same session as the first packet. For example, in response to receiving a second packet for the session, computing device <NUM> may perform a lookup of session information <NUM> and determine, based on the source address, source port, destination address, destination port, and/or protocol specified by the second packet, that the second packet belongs to a session having a corresponding entry within session information <NUM>.

In response to determining that the subsequent packets belong to the same session as the first packet, computing device <NUM> may generate, for the subsequent packets, subsequent L3 packets that include the L3 header but do not include the first portion of metadata or the second portion of the metadata (as the payload key may be associated with a given session and router 110I (<FIG>) may already possess the payload key from decrypting the header associated with the first packet.

In some examples, when the ingress router, e.g., computing device <NUM> acting as router 110A, updates the payload key (e.g., by generating a new payload key), router 110A may include the second portion of metadata including the new payload key in the packet and encrypt the second portion of metadata using the path key router 110A shares with router 110B.

Computing device <NUM> may forward the subsequent L3 packets toward the same next-hop router 110B. Intervening network devices (e.g., routers 110B-<NUM>) may receive the subsequent L3 packets and identify, from the L3 header of the subsequent L3 packets, the session associated with the subsequent L3 packets, and use the stored first portion of metadata to perform session-based routing of the subsequent L3 packets. In this fashion, computing device <NUM> may only modify the first L3 packet of the plurality of L3 packets generated for the session to include the first portion of metadata, and the second portion of metadata (unless router 110A is updating the payload key), thereby avoiding including the first and second portions of metadata within every packet of the plurality of L3 packets generated for the session while still ensuring that each L3 packet of the plurality of L3 packets is forwarded along the same path (e.g., to the same next-hop router <NUM>) and that the original packet may be recovered from the L3 packet and decrypted by an egress router, such as router 110I.

With reference to <FIG>, in the following example, computing device <NUM> operates as router 110I and receives an L3 packet modified as described above from router <NUM>. For example, computing device <NUM> receives, via communication unit(s) <NUM>, the L3 packet comprising the L3 header, first portion of metadata, and second portion of metadata. Computing device <NUM> uses a path key associated with the path between router <NUM> and router 110I to decrypt the metadata. Computing device <NUM> then obtains the payload key from the second portion of the metadata. Computing device <NUM> may store the payload key in keys <NUM> or in session information <NUM>, in the case where the payload key is associated with a session.

If the L3 packet is a first L3 packet of a plurality of L3 packets for the session, computing device <NUM> may use the first portion of metadata to generate a session identifier for the session between client device 100A and client device 100B and store the session identifier in session information <NUM> (e.g., so as to store the first portion of metadata of the L3 packet). In response to determining the packet is destined for a client device coupled to router 110I, computing device <NUM> may use the first portion of metadata of the L3 packet to recover the original packet. For example, computing device <NUM> may use the first portion of metadata to modify the header of the packet to specify the original source address, source port, destination address, and destination port. Computing device <NUM> may also use the payload key to decrypt the payload. Computing device <NUM> then forwards the recovered packet to client device 100B.

Computing device <NUM> may further receive subsequent L3 packets of the plurality of L3 packets that do not include the first portion of metadata or the second portion of metadata. For these subsequent L3 packets, computing device <NUM> may retrieve the path key associated with the path between router 110I and router <NUM> from keys <NUM> (or session information <NUM>) and decrypt the L3 header and metadata. Computing device <NUM> may determine, based on the decrypted L3 header (e.g., the source IP address and source port of a previous-hop router and the destination IP address and destination port of router 110I), the subsequent L3 packets belong to the same session as the first L3 packet. Computing device <NUM> may retrieve from keys <NUM>, or from session information <NUM>, the payload key and decrypt the payload. Computing device <NUM> may determine the original destination port and destination address of the packet from the stored first portion of metadata for the first L3 packet. Computing device <NUM> may forward, via communication unit(s) <NUM>, the subsequent packets to client device 100A. In this fashion, computing device <NUM> may receive only a first L3 packet that specifies the first portion of metadata and a second portion of metadata, while subsequent L3 packets do not include such information. Thereby, routers <NUM> as described herein may avoid including the first and second portions of metadata within every packet of the plurality of L3 packets generated for the session while still ensuring that each L3 packet of the plurality of L3 packets is forwarded along the same path (e.g., to the same next-hop router <NUM>) and that the appropriate routers may have the correct payload key.

<FIG> is a block diagram illustrating an example data structure for an L3 packet in accordance with the techniques of the disclosure. L3 packet <NUM> includes L3 header <NUM>, a first portion of metadata <NUM>, a second portion of metadata <NUM>, and data payload <NUM>. While the example of <FIG> describes first portion of metadata <NUM> and second portions of metadata <NUM> in a modified packet, in some examples, the metadata includes second portion of metadata <NUM> (e.g., payload key <NUM>) but not first portion of metadata <NUM>, such as when a router is updating the payload key.

L3 header <NUM> specifies source router IP address <NUM> indicative of a device originating L3 packet <NUM>, source port <NUM> indicative of a port of the originating device from which L3 packet <NUM> egresses, destination router IP address <NUM> indicative of a device to which L3 packet <NUM> is destined, destination port <NUM> indicative of a port of destination device to which L3 packet <NUM> is destined, and router IP protocol <NUM>, which specifies a protocol used by L3 packet <NUM>. In some examples, router IP protocol <NUM> specifies one of TCP or UDP.

First portion of metadata <NUM> specifies source client IP address <NUM>, source client port <NUM>, destination client IP address <NUM>, destination client port <NUM>, and client IP protocol <NUM>. Source client IP address <NUM> and source client port <NUM> together comprise L3 address information corresponding to source MAC address of client device 100A. Destination client IP address <NUM> and destination client port <NUM> together comprise L3 address information corresponding to the MAC address of the client device 100B. Client IP protocol <NUM> specifies a protocol used by source client IP address <NUM>, source client port <NUM>, destination client IP address <NUM>, and destination client port <NUM>. In some examples, client IP protocol <NUM> specifies one of TCP or UDP.

Second portion of metadata <NUM> includes payload key <NUM> which may be used by router 110A to encrypt payload <NUM> and by router 110I to decrypt payload <NUM>. Intervening network devices (e.g., routers 110B-<NUM>) do not need to use payload key <NUM>, as payload <NUM> is not intended for a client coupled to any of intervening network devices. Rather the intervening network devices (e.g., routers 110B-<NUM>) may decrypt first portion of metadata <NUM>, and/or second portion of metadata <NUM>, using a path key shared by the upstream next hop router that forwarded the L3 packet <NUM> to the router. For example, router 110A may forward L3 packet <NUM> to an intervening network device (e.g., router 110B) which may use a path key shared between router 110A and 110B. Intervening network devices (e.g., routers 110B-<NUM>) may determine that L3 packet <NUM> is not intended for a client device coupled to the intervening network devices based on the metadata as described herein. The intervening network devices (e.g., routers 110B-<NUM>) may re-encrypt first portion of metadata <NUM>, and/or second portion of metadata <NUM> using a path key shared with a next hop neighboring network device. The intervening network devices (e.g., routers 110B-<NUM>) may then forward L3 packet <NUM> to the neighboring next hop network device. For example, router 110B may forward the packet to router 110C.

As described above with reference to <FIG>, source router IP address <NUM> and source port <NUM> specify an IP address of router 110A and port used by router 110A to forward L3 packet <NUM>, respectively. Destination router IP address <NUM> and destination port <NUM> specify an IP address and port of router 110B to which L3 packet <NUM> is destined, respectively.

Additionally, source client IP address <NUM> and source client port <NUM> of first portion of metadata <NUM> specify L3 address information corresponding to the MAC address of client device 100A. Destination client IP address <NUM> and destination client port <NUM> of first portion of metadata <NUM> specify L3 address information corresponding to the MAC address of client device 100B. As described above, routers <NUM> of <FIG> may use first portion of metadata <NUM> as a session identifier to identify a session associated with L3 packet <NUM> so as to perform session-based routing of L3 packet <NUM>.

<FIG> is a flow diagram illustrating an example operation in accordance with the techniques of the disclosure. <FIG> is described with respect to <FIG> for convenience. Router 110A (<FIG>) may obtain a first payload key (<NUM>). For example, router 110A may generate the first payload key or receive the first payload key from another network device, such as a security server. Router 110A may obtain a first path key (<NUM>), the first path key being associated with one or more paths between the ingress network device (e.g., router 110A) and a first intervening network device (e.g., router 110B) of one or more intervening network devices (e.g., routers 110B-<NUM>). For example, router 110A may exchange path keys with router 110B to obtain the first path key.

Router 110A may encrypt a first payload of a first packet using the first payload key (<NUM>). Router 110A may insert the first payload key into first metadata of the first packet (<NUM>). For example, router 110A may insert payload key <NUM> into second portion of metadata <NUM> (both of <FIG>). Router 110A may encrypt the first metadata using the first path key (<NUM>). For example, router 110A may use the first path key associated with one or more paths between router 110A and router <NUM>10B to encrypt the first metadata. Router 110A may send the first packet to the first intervening network device of the one or more intervening network devices (e.g., routers 110B-<NUM>) (<NUM>), wherein the first packet is destined for an egress network device (e.g., router 110I).

In some examples, router 110I may obtain a second path key, the second path key being associated with one or more paths between the egress network device (e.g., router 110I) and a last intervening network device (e.g., router <NUM>) of the one or more intervening network devices (e.g., routers 110B-<NUM>). In some examples, router 110I may receive the first packet from the last intervening network device of the one more intervening network devices (e.g., from router <NUM>). In some examples, router 110I may decrypt the first metadata of the first packet using the second path key. In some examples, router 110I may obtain the first payload key from the first metadata of the first packet. In some examples, router 110I may decrypt the first payload of the first packet using the first payload key.

In some examples, one or more intervening network devices (e.g., routers 110B-<NUM>) may receive the first packet from the ingress network device (e.g., router 110A). In some examples, the one or more intervening network devices may decrypt the first metadata associated with the first packet using the first path key. For example, router 110B may decrypt the first metadata associated with the first packet using the first path key. In some examples, one or more of intervening network devices may determine that the first packet is not destined for a client device coupled to the one or more intervening network devices. In some examples, the one or more intervening network devices may encrypt the first metadata associated with the first packet using the second path key. For example, router <NUM> may encrypt the first metadata associated with the first packet using the second path key. In some examples, the one or more intervening network devices may send the first packet to the egress network device (e.g., router 110I).

In some examples, router 110A may encrypt a second payload of a second packet using the first payload key and send the second packet to the one or more intervening network devices (e.g., routers 110B-<NUM>). In some examples, router 110I may receive the second packet from the one or more intervening network devices and decrypt the second payload of the second packet using the first payload key.

In some examples, router 110A may determine to update the first payload key. In some examples, router 110A may obtain a second payload key. For example, router 110A may generate the second payload key or receive the second payload key from another network device, such as a security server. In some examples, router 110A may encrypt a second payload of a second packet using the second payload key. In some examples, router 110A may insert the second payload key into second metadata of the second packet. In some examples, router 110A may encrypt the second metadata using the first path key. In some examples, router 110A may send the second packet to the one or more intervening network devices (e.g., routers 110B-<NUM>).

In some examples, router 110I may receive the second packet from the one or more intervening network devices (e.g., routers 110B-<NUM>). In some examples, router 110I may decrypt the second metadata of the second packet using the second path key. In some examples, router 110I may obtain the second payload key from the second metadata of the second packet. In some examples, router 110I may decrypt the second payload of the second packet using the second payload key.

In some examples, router 110A may obtain a first payload key and obtain a path key. In some examples, router 110A may encrypt a first payload of a first packet using the first payload key and insert the first payload key into first metadata of the first packet. In some examples, router 110A may encrypt the first metadata using the path key and send the first packet to another network device (e.g., router 110B).

In some examples, router 110A may obtain the first payload key by generating the first payload key or by receiving the first payload key. In some examples, router 110A may encrypt a second payload of a second packet using the first payload key and send the second packet to the another network device (e.g., router 110B).

In some examples, router 110A may determine to update the first payload key. In some examples, router 110A may obtain a second payload key. In some examples, router 110A may encrypt a second payload of a second packet using the second payload key and insert the second payload key into second metadata of the second packet. In some examples, router 110A may encrypt the second metadata using the path key and send the second packet to the another network device (e.g., router 110B). In some examples, router 110A is a session-based router.

In some examples, the first payload key is associated with a first session. In some examples, router 110A may obtain a second payload key associated with a second session. In some examples, router 110A may encrypt a second payload of a second packet associated with the second session using the second payload key and insert the second payload key into second metadata of the second packet. In some examples, router 110A may encrypt the second metadata using the path key and send the second packet to the another network device.

In some examples, the first payload key is associated with a first type of service. In some examples, router 110A obtain a second payload key associated with a second type of service. In some examples, router 110A may encrypt a second payload of a second packet associated with the second type of service using the second payload key and insert the second payload key into second metadata of the second packet. In some examples, router 110A may encrypt the second metadata using the path key and send the second packet to the another network device.

In some examples, router 110I may obtain a path key. In some examples, router 110I may receive a first packet from another network device (e.g., router <NUM>). In some examples, router 110I may decrypt first metadata of the first packet using the path key. In some examples, router 110I may obtain a first payload key from the first metadata of the first packet and decrypt a first payload of the first packet using the first payload key.

In some examples, router 110I may receive a second packet from the another network device and decrypt a second payload of the second packet using the first payload key.

In some examples, router 110I may receive a second packet from the another network device and decrypt second metadata of the second packet using the path key. In some examples, router 110I may obtain a second payload key from the second metadata of the second packet and decrypt a second payload of the second packet using the second payload key. In some examples, router 110I is a session-based router.

In some examples, the first payload key is associated with a first session. In some examples, router 110I may receive a second packet from the another network device (e.g., router <NUM>), the second packet being associated with a second session. In some examples, router 110I may decrypt second metadata of the second packet using the path key. In some examples, router 110I may obtain a second payload key from the second metadata of the second packet, the second payload key being associated with the second session, and decrypt a second payload of the second packet using the second payload key.

In some examples, the first payload key is associated with a first type of service. In some examples, router 110I may receive a second packet from the another network device (e.g., router <NUM>), the second packet being associated with a second type of service. In some examples, router 110I may decrypt second metadata of the second packet using the path key. In some examples, router 110I may obtain a second payload key from the second metadata of the second packet, the second payload key being associated with the second type of service, and decrypt a second payload of the second packet using the second payload key.

The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium or computer-readable transmission medium, comprising instructions. Instructions embedded in, encoded in and/or conveyed by a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer readable storage media may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic media, optical media, or other computer readable media. Computer-readable transmission media may include carrier waves, transmission signals or the like, and may occur between components of an individual computer system and/or between plural separate computer systems. A computer-readable medium comprising instructions may also be referred to as a computer program product.

Therefore, from one perspective, there have been described techniques are for inline security key exchanges between network devices. An example network device includes one or more processors and memory coupled to the one or more processors. The memory stores instructions that, upon execution, cause one or more processors to obtain a first payload key and obtain a path key. The instructions cause the one or more processors to encrypt a first payload of a first packet using the first payload key and insert the first payload key into first metadata of the first packet. The instructions cause the one or more processors to encrypt the first metadata using the path key and send the first packet to another network device.

Clause <NUM>. A network device comprising: one or more processors; and memory coupled to the one or more processors, the memory storing instructions that upon execution cause one or more processors to: obtain a path key; receive a first packet from another network device; decrypt first metadata of the first packet using the path key; obtain a first payload key from the first metadata of the first packet; and decrypt a first payload of the first packet using the first payload key.

Clause <NUM>. The network device of clause <NUM>, wherein the instructions further cause the one or more processors to: receive a second packet from the another network device; and decrypt a second payload of the second packet using the first payload key.

Clause <NUM>. The network device of clause <NUM> or <NUM>, wherein the instructions further cause the one or more processors to: receive a second packet from the another network device; decrypt second metadata of the second packet using the path key; obtain a second payload key from the second metadata of the second packet; and decrypt a second payload of the second packet using the second payload key.

Clause <NUM>. The network device of clause <NUM>, <NUM> or <NUM>, wherein the network device comprises a session-based router.

Clause <NUM>. The network device of any of clauses <NUM> to <NUM>, wherein the first payload key is associated with a first session and wherein the instructions further cause the one or more processors to: receive a second packet from the another network device, the second packet being associated with a second session; decrypt second metadata of the second packet using the path key; obtain a second payload key from the second metadata of the second packet, the second payload key being associated with the second session; and decrypt a second payload of the second packet using the second payload key.

Clause <NUM>. The network device of any of clauses <NUM> to <NUM>, wherein the first payload key is associated with a first type of service and wherein the instructions further cause the one or more processors to: receive a second packet from the another network device, the second packet being associated with a second type of service; decrypt second metadata of the second packet using the path key; obtain a second payload key from the second metadata of the second packet, the second payload key being associated with the second type of service; and decrypt a second payload of the second packet using the second payload key.

Clause <NUM>. A method comprising: obtaining, by one or more processors of an ingress network device, a first payload key; obtaining, by one or more processors of the ingress network device, a first path key, the first path key being associated with one or more paths between the ingress network device and a first intervening network device of one or more intervening network devices; encrypting, by one or more processors of the ingress network device, a first payload of a first packet using the first payload key; inserting, by the one or more processors of the ingress network device, the first payload key into first metadata of the first packet; encrypting, by the one or more processors of the ingress network device, the first metadata using the first path key; and sending, by the one or more processors of the ingress network device, the first packet to the first intervening network device of the one or more intervening network devices, wherein the first packet is destined for an egress network device.

Clause <NUM>. The method of clause <NUM>, further comprising: obtaining, by one or more processors of the egress network device, a second path key, the second path key being associated with one or more paths between the egress network device and a last intervening network device of the one or more intervening network devices; receiving, by one or more processors of the egress network device, the first packet from the last intervening network device of the one more intervening network devices; decrypting, by the one or more processors of the egress network device, the first metadata of the first packet using the second path key; obtaining, by the one or more processors of the egress network device, the first payload key from the first metadata of the first packet; and decrypting, by the one or more processors of the egress network device, the first payload of the first packet using the first payload key.

Clause <NUM>. The method of clause <NUM>, further comprising: receiving, by the one or more processors of the one or more intervening network devices, the first packet from the ingress network device; decrypting, by the one or more processors of the one or more intervening network devices, the first metadata associated with the first packet using the first path key; determining, by the one or more processors of the one or more intervening network devices, that the first packet is not destined for a client device coupled to the one or more intervening network devices; encrypting, by the one or more processors of the one or more intervening network devices, the first metadata associated with the first packet using the second path key; and sending, by the one or more processors of the one or more intervening network devices, the first packet to the egress network device.

Clause <NUM>. The method of clause <NUM> or <NUM>, further comprising: encrypting, by the one or more processors of the ingress network device, a second payload of a second packet using the first payload key; and sending, by the one or more processors of the ingress network device, the second packet to the one or more intervening network devices.

Clause <NUM>. The method of clause <NUM>, further comprising: receiving, by the one or more processors of the egress network device, the second packet from the one or more intervening network devices; and decrypting, by the one or more processors of the egress network device, the second payload of the second packet using the first payload key.

Clause <NUM>. The method of any of clauses <NUM> to <NUM>, further comprising: determining, by the one or more processors of the ingress network device, to update the first payload key; obtaining, by the one or more processors of the ingress network device, a second payload key; encrypting, by the one or more processors of the ingress network device, a second payload of a second packet using the second payload key; inserting, by the one or more processors of the ingress network device, the second payload key into second metadata of the second packet; encrypting, by the one or more processors of the ingress network device, the second metadata using the first path key; and sending, by the one or more processors of the ingress network device, the second packet to the one or more intervening network devices.

Clause <NUM>. The method of clause <NUM>, further comprising: receiving, by the one or more processors of the egress network device, the second packet from the one or more intervening network devices; decrypting, by the one or more processors of the egress network device, the second metadata of the second packet using the second path key; obtaining, by the one or more processors of the egress network device, the second payload key from the second metadata of the second packet; and decrypting, by the one or more processors of the egress network device, the second payload of the second packet using the second payload key.

Claim 1:
A network device comprising:
one or more processors; and
memory coupled to the one or more processors, the memory storing instructions that, upon execution, cause one or more processors to:
obtain (<NUM>) a first payload key;
obtain (<NUM>) a path key, wherein the path key is associated with a path between the network device and another network device, and wherein the path key is a symmetric key;
encrypt (<NUM>) a first payload of a first packet using the first payload key;
insert (<NUM>) the first payload key into first metadata of the first packet;
encrypt (<NUM>) the first metadata using the path key; and
send (<NUM>) the first packet to the other network device.