Verification of network functions in computer networks

Abstract

Disclosed herein is a method performed by a network function manager to support verification of a network function. The method includes obtaining a first hash that is digitally signed by the instance of the network function, wherein the first hash was generated based on applying a hash function to first information regarding a local execution environment of the instance of the network function, generating a second hash based on applying a hash function to second information regarding a control group associated with the instance of the network function, generating a certificate that is digitally signed by the network function manager based on combining the first hash and the second hash, and providing the certificate that is digitally signed to a signing server, wherein the signing server is to digitally sign the certificate and store the certificate in a verification database.

Description

SPECIFICATIONVERIFICATION OF NETWORK FUNCTIONS IN COMPUTER NETWORKSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of Greek Application No. 20230100913, filed November 3, 2023, which is hereby incorporated by reference.TECHNICAL FIELD

[0002] Embodiments of the invention relate to the field of computer networks, and more specifically, to verifying network functions in computer networks.BACKGROUND

[0003] Network functions virtualization (NFV) is a network architecture concept that leverages information technology (IT) virtualization technologies to virtualize entire classes of network node functions into building blocks that may be chained together to create and deliver communication services.

[0004] NFV relies upon traditional server-virtualization techniques such as those used in enterprise IT. A virtualized network function, or VNF, is implemented within one or more virtual machines or containers running different software and processes, on top of commercial off the shelf (COTS) high-volume servers, switches and storage devices, or even cloud computing infrastructure, instead of having custom dedicated hardware appliances for each network function, thereby avoiding vendor lock-in.

[0005] The radio access network (RAN) provides critical technology to connect users, including mobile phones or enterprises, to the mobile network over radio waves. RAN technology has traditionally been provided as a hardware and software integrated platform. Open RAN is an initiative to create a multi-supplier RAN solution that allows for the separation (or disaggregation) between hardware and software with open interfaces and virtualization, hosting software that controls and updates networks in the cloud. The promised benefits of this approach include supply chain diversity, solution flexibility, and new capabilities leading to increased competition and further innovation.

[0006] The zero-trust security model, also known as zero-trust architecture (ZTA), is an approach to designing and implementing IT systems. The motto of the zero-trust security model is "never trust, always verify," which means that users and devices should not be trusted bydefault, even if they are connected to a permissioned network and even if they were previously verified.

[0007] In a virtualized network environment, a consumer network function (NF) may send a request to a producer NF to perform a service / fiinction. The consumer NF may not know whether the producer NF is “good” for consumption. For example, the consumer NF may not know whether the underlying software of the producer NF is up-to-date and / or whether the underlying software has been modified (intentionally or unintentionally) after being deployed. Similarly, the producer NF may not know whether the underlying software of the consumer NF is up-to-date and has not been modified.

[0008] Although there exist mechanisms for verifying software before it is deployed (e.g., using MD5 (Message Digest Algorithm) checksums and vulnerability scanning tools), it is possible for malicious code to hijack the memory space allocated to a network function instance after the network function instance is deployed and running (i.e., during runtime). The malicious code may modify the behavior of the network function instance and thus compromise the network function instance, creating a security threat. Also, it is possible for the memory space allocated to the network function instance to be corrupted without malicious intent. Thus, there is a need for a mechanism that can verify that a network function instance has not been modified during runtime. The need for such a mechanism is increasing particularly in the field of mobile networks (e.g., Third Generation Partnership Project (3GPP) mobile networks), as their interfaces and functionality are being opened up to third parties as a consequence of cloud RAN initiatives such as Open RAN.SUMMARY

[0009] An embodiment is a method performed by a network device implementing a network function manager to support verification of a network function. The method includes obtaining a first hash that is digitally signed by an instance of the network function, wherein the first hash was generated based on applying a hash function to first information regarding a local execution environment of the instance of the network function, generating a second hash based on applying a hash function to second information regarding a control group associated with the instance of the network function, generating a certificate that is digitally signed by the network function manager based on combining the first hash and the second hash, and providing the certificate that is digitally signed to a signing server, wherein the signing server is to digitally sign the certificate and store the certificate in a verification database.

[0010] An embodiment is a machine-readable medium comprising computer program code, which when executed by a network device implementing a network function manager, causesthe network function manager to perform operations for supporting verification of a network function. The operations include obtaining a first hash that is digitally signed by an instance of the network function, wherein the first hash was generated based on applying a hash function to first information regarding a local execution environment of the instance of the network function, generating a second hash based on applying a hash function to second information regarding a control group associated with the instance of the network function, generating a certificate that is digitally signed by the network function manager based on combining the first hash and the second hash, and providing the certificate that is digitally signed to a signing server, wherein the signing server is to digitally sign the certificate and store the certificate in a verification database.

[0011] An embodiment is a network device to implement a network function manager configured to support verification of a network function. The network device includes a processor and a non-transitory machine-readable storage medium having instructions stored thereon, which when executed by the processor, causes the network function manager to perform operations for supporting verification of a network function. The operations include obtaining a first hash that is digitally signed by an instance of the network function, wherein the first hash was generated based on applying a hash function to first information regarding a local execution environment of the instance of the network function, generating a second hash based on applying a hash function to second information regarding a control group associated with the instance of the network function, generating a certificate that is digitally signed by the network function manager based on combining the first hash and the second hash, and providing the certificate that is digitally signed to a signing server, wherein the signing server is to digitally sign the certificate and store the certificate in a verification database.

[0012] An embodiment is a method performed by a network device implementing a verification server to verify a network function. The method includes receiving a request to verify an instance of the network function, wherein the request includes a first hash that is digitally signed by the instance of the network function, searching for a certificate that includes the first hash in a verification database, responsive to finding the certificate that includes the first hash in the verification database, extracting a second hash from the certificate, determining whether verification of the instance of the network function is successful based on the second hash, and providing a response corresponding to the request indicating whether the verification of the instance of the network function was successful.

[0013] An embodiment is a machine-readable medium comprising computer program code, which when executed by a network device implementing a verification server, causes the verification server to perform operations for verifying a network function. The operationsinclude receiving a request to verify an instance of the network function, wherein the request includes a first hash that is digitally signed by the instance of the network function, searching for a certificate that includes the first hash in a verification database, responsive to finding the certificate that includes the first hash in the verification database, extracting a second hash from the certificate, determining whether verification of the instance of the network function is successful based on the second hash, and providing a response corresponding to the request indicating whether the verification of the instance of the network function was successful..

[0014] An embodiment is a network device to implement a verification server configured to verify a network function. The network device includes a processor and a non-transitory machine -readable storage medium having instructions stored thereon, which when executed by the processor, causes the verification server to perform operations for verifying a network function. The operations include receiving a request to verify an instance of the network function, wherein the request includes a first hash that is digitally signed by the instance of the network function, searching for a certificate that includes the first hash in a verification database, responsive to finding the certificate that includes the first hash in the verification database, extracting a second hash from the certificate, determining whether verification of the instance of the network function is successful based on the second hash, and providing a response corresponding to the request indicating whether the verification of the instance of the network function was successful.

[0015] An embodiment is a method performed by a network device implementing a service communication proxy to facilitate verification of a consumer network function. The method includes sending a request to a verification server to verify an instance of the consumer network function, receiving a response from the verification server indicating whether verification of the instance of the consumer network function was successful, and responsive to determining that verification of the instance of the consumer network function was successful, forwarding requests received from the instance of the consumer network function to consume producer network functions without verifying the instance of the consumer network function with the verification server.

[0016] An embodiment is a machine-readable medium comprising computer program code, which when executed by a network device implementing a service communication proxy, causes the service communication proxy to perform operations for facilitating verification of a consumer network function. The operations include sending a request to a verification server to verify an instance of the consumer network function, receiving a response from the verification server indicating whether verification of the instance of the consumer network function was successful, and responsive to determining that verification of the instance of the consumernetwork function was successful, forwarding requests received from the instance of the consumer network function to consume producer network functions without verifying the instance of the consumer network function with the verification server.

[0017] An embodiment is a network device to implement a service communication proxy configured to facilitate verification of a consumer network function. The network device includes a processor and a non-transitory machine-readable storage medium having instructions stored thereon, which when executed by the processor, causes the service communication proxy to perform operations for facilitating verification of the consumer network function. The operations include sending a request to a verification server to verify an instance of the consumer network function, receiving a response from the verification server indicating whether verification of the instance of the consumer network function was successful, and responsive to determining that verification of the instance of the consumer network function was successful, forwarding requests received from the instance of the consumer network function to consume producer network functions without verifying the instance of the consumer network function with the verification server.

[0018] An embodiment is a method performed by a network device implementing a service communication proxy to facilitate verification of a producer network function. The method includes sending a request to a verification server to verify an instance of the producer network function, receiving a response from the verification server indicating whether verification of the instance of the producer network function was successful, and responsive to determining that verification of the instance of the producer network function was successful, forwarding requests received from instances of consumer network functions to the instance of the producer network function and forwarding responses received from the instance of the producer network function to the instances of the consumer network functions without verifying the instance of the producer network function with the verification server.

[0019] An embodiment is a machine-readable medium comprising computer program code, which when executed by a network device implementing a service communication proxy, causes the service communication proxy to perform operations for facilitating verification of a producer network function. The operations include sending a request to a verification server to verify an instance of the producer network function, receiving a response from the verification server indicating whether verification of the instance of the producer network function was successful, and responsive to determining that verification of the instance of the producer network function was successful, forwarding requests received from instances of consumer network functions to the instance of the producer network function and forwarding responses received from theinstance of the producer network function to the instances of the consumer network functions without verifying the instance of the producer network function with the verification server.

[0020] An embodiment is a network device to implement a service communication proxy configured to facilitate verification of a producer network function. The network device includes a processor and a non-transitory machine-readable storage medium having instructions stored thereon, which when executed by the processor, causes the service communication proxy to perform operations for facilitating verification of the producer network function. The operations include sending a request to a verification server to verify an instance of the producer network function, receiving a response from the verification server indicating whether verification of the instance of the producer network function was successful, and responsive to determining that verification of the instance of the producer network function was successful, forwarding requests received from instances of consumer network functions to the instance of the producer network function and forwarding responses received from the instance of the producer network function to the instances of the consumer network functions without verifying the instance of the producer network function with the verification server.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:

[0022] Figure 1 is a diagram showing an environment in which network functions can be verified, as well as operations performed therein to verify an instance of a consumer network function, according to some embodiments.

[0023] Figure 2 is a diagram showing operations performed in the example environment to verify an instance of a producer network function, according to some embodiments.

[0024] Figure 3 is a sequence diagram showing component interactions for generating a certificate for a network function instance and verifying the network function instance using the certificate, according to some embodiments.

[0025] Figure 4 is a flow diagram of a method for supporting verification of a network function, according to some embodiments. In an embodiment, the method may be performed by a network function manager.

[0026] Figure 5 is a flow diagram of a method for verifying a network function, according to some embodiments.

[0027] Figure 6 is a flow diagram of a method for facilitating verification of a consumer network function, according to some embodiments.

[0028] Figure 7 is a flow diagram of a method for facilitating verification of an instance of a producer network function, according to some embodiments.

[0029] Figure 8 is a diagram showing connectivity between network devices (NDs) within an exemplary network, as well as three example implementations of the NDs, according to some embodiments.DETAILED DESCRIPTION

[0030] The following description describes methods and apparatus for verifying network functions to ensure that they have not been modified during runtime. In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning / sharing / duplication implementations, types and interrelationships of system components, and logic partitioning / integration choices are set forth in order to provide a more thorough understanding of the present invention. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

[0031] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0032] Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dotdash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments of the invention. However, such notation should not be taken to mean that these are the only options or optional operations, and / or that blocks with solid borders are not optional in certain embodiments of the invention.

[0033] In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact witheach other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

[0034] An electronic device stores and transmits (internally and / or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and / or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e.g., wherein a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, other electronic circuitry, a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and / or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code / data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower nonvolatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set of one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and / or receive code and / or data using propagating signals) with other electronic devices. For example, the set of physical NIs (or the set of physical NI(s) in combination with the set of processors executing code) may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and / or a wireless connection. In some embodiments, a physical NI may comprise radio circuitry capable of receiving data from other electronic devices over a wireless connection and / or sending data out to other devices via a wireless connection. This radio circuitry may include transmitter(s), receiver(s), and / or transceiver(s) suitable for radiofrequency communication. The radio circuitry may convert digital data into a radio signal having the appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signal may then be transmitted via antennas to the appropriate recipient(s). In some embodiments, the set of physical NI(s) may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC(s) may facilitate in connecting the electronic device toother electronic devices allowing them to communicate via wire through plugging in a cable to a physical port connected to a NIC. One or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and / or hardware.

[0035] A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices). Some network devices are “multiple services network devices” that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and / or subscriber management), and / or provide support for multiple application services (e.g., data, voice, and video).

[0036] As mentioned above, there is a need for a mechanism that can verify that a network function has not been modified during runtime. Embodiments are described herein that can verify network functions to ensure that they have not been modified (intentionally or unintentionally) during runtime.

[0037] According to some embodiments, when a network function manager initially deploys an instance of a network function on a node, the instance of the network function generates a first hash based on applying a hash function to first information regarding a local execution environment of the instance of the network function. The first information may include information regarding a memory address space that the instance of the network function occupies and / or information regarding an operating system that the instance of the network function runs on. The instance of the network function may provide the first hash to the network function manager. The network function manager may generate a second hash based on applying a hash function to second information regarding a control group associated with the instance of the network function. A control group (sometimes referred to as “cgroup” or process containers) is a collection of processes that are bound by the same criteria and associated with a set of parameters or limits. The parameters or limits may relate to the allocation of resources such as the allocation of central processing unit (CPU) resources, memory resources and / or other types of resources such as network resources as represented by available handlers of the underlying operating system.

[0038] The second information may include an identifier that identifies the instance of the network function, information regarding a number of processes running inside the control group associated with the instance of the network function, information regarding memory usage of the control group associated with the instance of the network function, information regarding memory usage of swap memory allocated to the control group associated with the instance of the network function, information regarding a memory limit assigned to the control group associated with the instance of the network function, information regarding a current memory allocation forthe control group associated with the instance of the network function, information regarding a maximum memory allocation that has been observed for other control groups associated with other instances of the network function, information regarding network interfaces associated with the control group, and / or information regarding devices associated with the control group. The network function manager may then generate a certificate based on combining the first hash and the second hash and digitally sign the certificate. The certificate thus encodes both (1) first information regarding the local execution environment of the instance of the network function; and (2) second information regarding the control group associated with the instance of the network function. The network function manager may then provide the digitally signed certificate to a signing server. The signing server may digitally sign the certificate and store the certificate in a verification database. The certificate may be used to verify the running instance of the network function, as will be described in additional detail below.

[0039] An instance of a consumer network function that wishes to consume the network function (the network function being consumed may be referred to as the producer network function) may send a request to the instance of the producer network function to describe its local execution environment. In response to receiving the request, the instance of the producer network function may generate a third hash based on applying a hash function to third information regarding the local execution environment associated with the instance of the producer network function during runtime and provide the third hash to the consumer network function. The consumer network function may then send a request to a verification server to verify the instance of the producer network function. The consumer network function may include the third hash in the request. In response to receiving the request, the verification server may search the verification database for a certificate that includes the third hash. If no such hash is found in the verification database, then verification of the instance of the producer network function is unsuccessful (e.g., it means that the instance of the producer network function has been modified during runtime). If the verification server is able to find a certificate that includes the third hash in the verification database, the verification server may retrieve the certificate and extract a fourth hash from the certificate. The verification server may then send a request to the network function manager to verify control group information for the instance of the producer network function. The verification server may include the fourth hash in the request.Responsive to receiving the request, the network function manager may generate a fifth hash based on hashing information regarding the control group associated with the producer network function during runtime of the instance of the producer network function. The network function manager may then determine whether the fifth hash matches the fourth hash. If the fifth hash does not match the fourth hash, then verification of the control group information isunsuccessful (e.g., it means that the instance of the producer network function has been modified during runtime). Otherwise, if the fifth hash matches the fourth hash, then verification of the control group information is successful. The network function manager may send a response to the verification server indicating whether verification of the control group information was successful or not. The verification server may determine that verification of the instance of the producer network function is successful if the response from the network function manager indicates that verification of the control group information was successful. Otherwise, if the response from the network function manager indicates that verification of the control group information was unsuccessful, the verification server may determine that verification of the instance of the network function is unsuccessful. The verification server may send a response to the consumer network function (corresponding to the request by the consumer network function to verify the instance of the producer network function) indicating whether verification of the instance of the producer network function was successful or not. The consumer network function may consume the instance of the producer network function if verification is successful (since this indicates that the instance of the producer network function has not been modified during runtime and thus can be trusted). The consumer network function may decide not to consume the instance of the producer network function if verification is unsuccessful (since this indicates that the instance of the producer network function may have been modified during runtime and thus cannot be trusted).

[0040] Embodiments are able to verify that the local execution environment of a network function instance and the control group associated with the network function instance has not been changed after deployment. This ensures that the network function instance has not been modified (intentionally or unintentionally) during runtime and provides additional trust that the network function instance is “good” for consumption. Embodiments can be used in a zero-trust environment to verify network function instances before they are consumed and / or allowed to consume other network functions.

[0041] In some embodiments, a service communication proxy (SCP) facilitates the verification of network function instances. The SCP may be communicatively situated between a consumer network function and a producer network function. An instance of a consumer network function may send a request to consume the producer network function, along with a first hash, to the SCP. The first hash may have been generated by the instance of the consumer network function based on applying a hash function to information regarding its local execution environment. Responsive to receiving the request, the SCP may send a request to a verification server to verify the instance of the consumer network function. The request may include the first hash. The verification server may search a verification database for a certificate that includes the first hash.If such a certificate is found, the verification server may retrieve the certificate and extract a second hash from the certificate. The second hash may have been previously generated by a network function manager based on applying a hash function to control group information associated with the instance of the consumer network function at or near the time the instance of the consumer network function was deployed. The verification server may then send a request to the network function manager to verify control group information for the instance of the consumer network function. The request may include the second hash. Responsive to receiving the request, the network function manager may generate a third hash based on applying a hash function to information regarding the control group associated with the consumer network function during runtime of the instance of the consumer network function. The network function manager may then determine whether the third hash matches the second hash. If the third hash does not match the second hash, then verification of the control group information is unsuccessful (e.g., it means that the consumer network function has been modified during runtime). Otherwise, if the third hash matches the second hash, then verification of the control group information is successful. The network function manager may provide a response to the verification server indicating whether verification of the control group information was successful or not. The verification server may determine that verification of the instance of the consumer network function is successful if the response from the network function manager indicates that verification of the control group information was successful. Otherwise, if the response from the network function manager indicates that verification of the control group information was unsuccessful, the verification server may determine that verification of the instance of the consumer network function is unsuccessful. The verification server may send a response to the SCP indicating whether verification of the instance of the consumer network function was successful or not. If verification of the instance of the consumer network function was successful, then the SCP may forward the request to consume the provider network function (which the SCP received from the instance of the consumer network function) to an instance of the provider network function. However, if the verification of the instance of the consumer network function was unsuccessful, the SCP may prevent the request to consume the provider network function from being forwarded.

[0042] Responsive to receiving the request from the instance of the consumer network function to consume the producer network function, an instance of the producer network function may send a response to the request, along with a fourth hash, to the SCP. The fourth hash may have been generated by the instance of the producer network function based on applying a hash function to information regarding its local execution environment. Responsive to receiving the response, the SCP may send a request to a verification server to verify theinstance of the producer network function. The request may include the fourth hash. The verification server may search a verification database for a certificate that includes the fourth hash. If such a certificate is not found, then verification of instance of the producer network function is unsuccessful. Otherwise, if such a certificate is found, the verification server may retrieve the certificate and extract a fifth hash from the certificate. The fifth hash may have been previously generated by a network function manager based on applying a hash function to control group information associated with the instance of the producer network function at or near the time the instance of the producer network function was deployed. The verification server may then send a request to a network function manager to verify control group information for the instance of the producer network function. The request may include the fifth hash. Responsive to receiving the request, the network function manager may generate a sixth hash based on applying a hash function to information regarding the control group associated with the producer network function during runtime of the instance of the producer network function. The network function manager may then determine whether the sixth hash matches the fifth hash. If the sixth hash does not match the fifth hash, then verification of the control group information is unsuccessful (e.g., it means that the producer network function has been modified during runtime). Otherwise, if the sixth hash matches the fifth hash, then verification of the control group information is successful. The network function manager may provide a response to the verification server indicating whether verification of the control group information was successful or not. The verification server may determine that verification of the instance of the producer network function is successful if verification of the control group information was successful. Otherwise, if the verification of the control group information was unsuccessful, the verification server may determine that verification of the instance of the producer network function is unsuccessful. The verification server may send a response to the SCP indicating whether verification of the instance of the producer network function was successful or not. If the verification of the instance of the producer network function was successful, then the SCP may forward the response corresponding to the request to consume the provider network function to the instance of the consumer network function. However, if the verification of the instance of the producer network function was unsuccessful, the SCP may prevent the response from being forwarded to the instance of the consumer network function.

[0043] Embodiments allow the SCP to facilitate the verification of consumer network functions and producer network functions. In an embodiment, the SCP remembers the network function instances that have been verified and forwards requests / responses generated by those network function instances without having to reverify those network function instances with theverification server for each request / response, which helps reduce the signaling overhead involved with verification.

[0044] Embodiments are further described with reference to the accompanying figures.

[0045] Figure 1 is a diagram showing an environment in which network functions can be verified, as well as operations performed therein to verify an instance of a consumer network function, according to some embodiments.

[0046] As shown in the diagram, the environment includes a consumer network function (cNF) instance 110, a producer network function (pNF) instance 120, a service communication proxy (SCP) 160, a verification server 130, a verification database 140, and a network function manager 150.

[0047] The cNF instance 110 may be an instance of a consumer network function. A consumer network function may be a network function that consumes another network function. The pNF instance 120 may be an instance of a producer network function. A producer network function may be a network function that is consumed by another network function. It should be noted that a given network function may be a consumer network function for some interactions and be a producer network function in other interactions.

[0048] The network function manager 150 may be responsible for managing network functions in a network. The network function manager 150 may deploy network functions on nodes of a cloud computing infrastructure and allocate resources to the deployed network functions (e.g., compute, storage, and memory resources).

[0049] The verification server 130 may be responsible for verifying network functions. As will be described in additional detail herein, the verification server 130 may interact with the verification database 140 and the network function manager 150 to verify network functions.

[0050] The verification database 140 may be a database that stores certificates for network function instances. The verification database 140 may be any type of trusted data storage location. As will be described in additional detail herein, a certificate for a network function instance may include two hashes: (1) a hash that encodes information regarding the local execution environment of the network function instance; and (2) a hash that encodes information regarding the control group associated with the network function instance. As will be described in additional detail herein, the certificate for a network function instance can be used to verify the network function instance to ensure that the network function instance has not been modified during runtime. In an embodiment, the verification database 140 is a key-value database.However, it should be appreciated that the verification database 140 can be implemented in different ways (e.g., the verification database 140 may be a relational database in some embodiments).

[0051] The SCP 160 may be a proxy that is communicatively situated between consumer network functions and producer network functions. The SCP 160 may mediate messages between consumer network functions and producer network functions (e.g., the SCP 160 may act as a load balancer that forwards requests from consumer network functions to different instances of producer network functions). As will be described in additional detail herein, the functionality of the SCP 160 may be extended to facilitate the verification of network functions.

[0052] While a certain arrangement of components is shown in the diagram, it should be appreciated that the arrangement is provided purely by way of example, and that other embodiments may use a different arrangement to achieve the same / similar functionality. For example, while the diagram shows the verification database 140 and the verification server 130 as being separate components, in some embodiments, the verification database 140 and the verification server 130 are integrated in a single component.

[0053] Operations for verifying the cNF instance 110 are now described with reference to the diagram to illustrate an embodiment.

[0054] At operation 1-1, the cNF instance 110 may send a request to consume the producer network function, along with a first hash, to the SCP 160. The cNF instance 110 may have generated the first hash based on applying a hash function to information regarding the local execution environment of the cNF instance 110. In an embodiment, the information regarding the local execution environment of the cNF instance 110 includes information regarding a memory address space that the cNF instance 110 occupies and information regarding an operating system that the cNF instance 110 runs on.

[0055] Responsive to receiving the request to consume the producer network function from the cNF instance 110, at operation 1-2, the SCP 160 may send a request to verify the cNF instance 110 to the verification server 130. The request may include the first hash.

[0056] Responsive to receiving the request to verify the cNF instance 110 from the SCP 160, at operation 1-3, the verification server 130 may search for a certificate that includes the first hash in the verification database 140, retrieve the certificate, and extract a second hash from the certificate.

[0057] At operation 1-4, the verification server 130 may verify control group (“cgroup”) information for the cNF instance 110 with the network function manager 150 using the second hash. In an embodiment, this involves the verification server 130 sending a request to verify control group information for the cNF instance 110 to the network function manager 150. The request may include the second hash. Responsive to receiving the request, the network function manager 150 may generate a hash based on applying a hash function to information regarding the control group associated with the cNF instance 110 during runtime of the cNF instance 110.The information regarding the control group associated with the cNF instance 110 may include an identifier that identifies the cNF instance 110, information regarding a number of processes running inside the control group associated with the cNF instance 110, information regarding memory usage of the control group, information regarding memory usage of swap memory allocated to the control group, information regarding a memory limit assigned to the control group, information regarding a current memory allocation for the control group, information regarding a maximum memory allocation that has been observed for other control groups associated with other instances of the same network function, information regarding network interfaces associated with the control group, and / or information regarding devices associated with the control group. Typically, information regarding the control group associated with a network function instance is available to the network function manager 150 but not available to the network function instance itself. The network function manager 150 may determine whether the generated hash matches the second hash. The network function manager 150 may determine that verification of control group information for the cNF instance 110 is successful if the hashes match and determine that verification of control group information for the cNF instance 110 is unsuccessful if the hashes do not match. The network function manager 150 may send a response indicating whether verification of the control group information for the cNF instance 110 was successful or not to the verification server 130. The verification server 130 may determine that verification of the cNF instance 110 is successful if verification of the control group information was successful and determine that verification of the cNF instance 110 is unsuccessful if verification of the control group information was unsuccessful. In an embodiment, the verification server 130 may perform additional checks (beyond checking the certificate) to verify the cNF instance 110. For example, the verification server 130 may check whether the request generated by the cNF instance 110 is anomalous (e.g., using a machine learning model that was trained using previous requests generated by instances of the cNF).

[0058] In this example, it is assumed that verification of the cNF instance 110 was successful (and thus it can be trusted that the cNF instance 110 has not been modified during runtime). Accordingly, at operation 1-5, the verification server 130 sends a response indicating that verification of the cNF instance 110 was successful to the SCP 160. Responsive to receiving the response, at operation 1-6, the SCP 160 forwards the request to consume the producer network function to the pNF instance 120.

[0059] The example shown in the diagram assumes that verification of the cNF instance 110 was successful. If verification of the cNF instance 110 was unsuccessful, then the SCP 160 may prevent the cNF instance’s request to consume the pNF from being forwarded to a pNF instance.

[0060] Figure 2 is a diagram showing operations performed in the example environment to verify an instance of a producer network function, according to some embodiments. The example shown in the diagram is a continuation of the example shown in Figure 1.

[0061] At operation 2-1, the pNF instance 120 may send a response (corresponding to the cNF instance’s 110 request to consume the producer network function), along with a third hash, to the SCP 160. The pNF instance 120 may have generated the third hash based on applying a hash function to information regarding the local execution environment of the pNF instance 120 (similar to how the cNF instance 110 generated the first hash).

[0062] Responsive to receiving the response from the pNF instance 120, at operation 2-2, the SCP 160 may send a request to verify the pNF instance 120 to the verification server 130. The request may include the third hash.

[0063] Responsive to receiving the request to verify the pNF instance 120 from the SCP 160, at operation 2-3, the verification server 130 may search for a certificate that includes the third hash in the verification database 140, retrieve the certificate, and extract a fourth hash from the certificate.

[0064] At operation 2-4, the verification server 130 may verify control group information for the pNF instance 120 with the network function manager 150 using the fourth hash. In an embodiment, this involves the verification server 130 sending a request to verify control group information for the pNF instance 120 to the network function manager 150. The request may include the fourth hash. Responsive to receiving the request, the network function manager 150 may generate a hash based on applying a hash function to information regarding the control group associated with the pNF instance 120 during runtime of the pNF instance 120. The network function manager 150 may determine whether the generated hash matches the fourth hash. The network function manager 150 may determine that verification of control group information for the pNF instance 120 is successful if the hashes match and determine that verification of control group information for the pNF instance 120 is unsuccessful if the hashes do not match. The network function manager 150 may send a response indicating whether verification of the control group information for the pNF instance 120 was successful or not to the verification server 130. The verification server 130 may determine that verification of the pNF instance 120 is successful if verification of the control group information was successful and determine that verification of the pNF instance 120 is unsuccessful if verification of the control group information was unsuccessful. In an embodiment, the verification server 130 may perform additional checks (beyond checking the certificate) to verify the pNF instance 120. For example, the verification server 130 may check whether the response generated by the pNFinstance 120 is anomalous (e.g., using a machine learning model that was trained using previous responses generated by instances of the pNF).

[0065] In this example, it is assumed that verification of the pNF instance 120 was successful (and thus it can be trusted that the pNF instance 120 has not been modified during runtime). Accordingly, at operation 2-5, the verification server 130 may send a response indicating that verification of the pNF instance 120 was successful to the SCP 160.

[0066] Responsive to receiving the response, at operation 2-6, the SCP 160 may forward the response (corresponding to the cNF instance’s 110 request to consume the producer network function) to the cNF instance 110.

[0067] The example shown in the diagram assumes that verification of the pNF instance 120 was successful. If verification of the pNF instance 120 was unsuccessful, then the SCP 160 may prevent the pNF instance’s 120 response from being forwarded to the cNF instance 110. In an embodiment, if verification of the pNF instance 120 was unsuccessful, the SCP 160 forwards the cNF instance’s 110 request to consume the pNF to a different instance of the pNF.

[0068] In an embodiment, the verification server’s 130 response (in operation 1-5 and / or operation 2-5) includes verification control information (VCI) for the network function instance being verified (or the set of network function instances being verified). The VCI may indicate whether the network function instance was successfully verified. In an embodiment, the VCI includes a timestamp indicating when the VCI for the network function instance was generated, a verification indicator indicating whether the network function instance was successfully verified, an identifier that identifies the network function instance, and a verification duration indicator indicating how long the network function instance can be considered as being verified.

[0069] As an example, the VCI for a network function instance may be as follows: 3gpp-new-NF: Timestamp: Tue, 06 Aug 2023 02:52:37 GMT; Valid:True; NF- Instance: 54856518-2313121-46sd3-95ad5c-afasfc631J953ed8; Validity-Period: 60s

[0070] In the above example VCI, the “Timestamp” parameter indicates the time when the VCI was generated, the “Valid” parameter indicates whether the network function instance was successfully verified or not, the “NF-Instance” parameter indicates an identifier of the network function instance, and the “Validity-Period” parameter indicates how long the network function instance can be considered as being verified.

[0071] In an embodiment, if the SCP 160 receives VCI for the cNF instance 110 indicating that the cNF instance 110 was successfully verified, the SCP 160 may forward requests (to consume a pNF) received from the cNF instance 110 to a pNF instance 120 without verifying the cNF instance 110 with the verification server 130 again, as long as the verification duration has not expired. Similarly, in an embodiment, if the SCP 160 receives VCI for the pNFinstance 120 indicating that the pNF instance 120 was successfully verified, the SCP 160 may forward responses (corresponding to requests to consume the pNF) received from the pNF instance 120 to the requesting cNF instances without verifying the pNF instance 120 with the verification server again, as long as the verification duration has not expired. This helps reduce the signaling overhead involved with verification (e.g., the pNF instance 120 only has to be verified once instead of having to verify the pNF instance 120 each time it is invoked by a cNF instance 110). In an embodiment, the SCP 160 proactively verifies a network function instance before the verification duration for the network function instance expires (e.g., to avoid any delays from having to perform the verification process after the verification duration expires). In some embodiments, the verification logic described above can be performed by a network function instead of a SCP.

[0072] The examples shown in Figures 1 and 2 assume that certificates for the network function instances (e.g., certificates for the cNF instance 110 and the pNF instance 120) have already been generated and stored in the verification database 140. Figure 3 shows component interactions for generating a certificate for a network function instance. As will be described in additional detail herein below, a certificate for a network function instance is generated to include a first hash and a second hash, where the first hash is generated based on applying a hash function to information regarding a local execution environment of the network function instance and the second hash is generated based on applying a hash function to information regarding the control group associated with the network function instance. Thus, the certificate for the network function instance may encode information regarding the local execution environment of the network function instance, as well as information regarding the control group associated with the network function instance.

[0073] Figure 3 is a sequence diagram showing component interactions for generating a certificate for a network function instance and verifying the network function instance using the certificate, according to some embodiments. The interactions shown in the diagram can be divided into a certification phase (during which the certification for a network function instance is generated) and a verification phase (during which the certificate is used to verify the network function instance).

[0074] As shown in the diagram, during the certification phase, the network function manager 150 may set up and deploy the pNF instance 120 on a node (e.g., a node of a cloud computing infrastructure). The network function manager 150 may deploy the pNF instance 120 using a container image (e.g., a Docker container image). Before deploying the pNF instance 120, the network function manager may verify the correctness of the container using existing techniques (e.g., using MD5 checksum).

[0075] The cNF instance 110 may send a request to the pNF instance 120 to provide a hash that encodes information regarding the local execution environment of the pNF instance 120. Responsive to receiving this request, the pNF instance 120 may generate a hash (“hash_NF”) based on applying a hash function to information regarding the local execution environment of the pNF instance (“Hash(pNF)”). The information regarding the local execution environment may include information regarding a memory address space that the instance of the network function occupies (e.g., the start and end of the memory segment) and / or information regarding an operating system that the instance of the network function runs on. In an embodiment, the hash function is a MD5 (Message Digest Algorithm) hash function, although other types of hash functions can be used. As an example, the information regarding the local execution environment (the input to the hash function) and the resulting hash (the output of the hash function) may be as follows:Input: Process: NFV_ID\nStart Memory: 00400000\nEnd Memory:00403000\nOS: Ubuntu 18.04.1 LTSOutput: t\xf3\xb4@D\xb5\xec\xe3y\xe2, '?z\xb9Z

[0076] As shown above, the input includes information regarding the start of the memory segment (“Start Memory” parameter), the end of the memory segment (“End Memory” parameter), and the operating system (“OS” parameter). The output is a hash.

[0077] The pNF instance 120 may digitally sign the “hash_NF” (“Sign(hash_NF)”) (e.g., using the pNF instance’s 120 private key of a public -private key pair) and send the signed “hash_NF” to the network function manager 150.

[0078] The network function manager 150 may generate a hash (“hash_cgroup”) based on applying a hash function to information regarding the control group associated with the pNF instance 120 (”Hash(c group)"). The network function manager 150 may then generate a certificate (“cert”) based on combining “hash_NF” and “hash_cgroup.” In an embodiment, the hashes are combined by appending the hashes to each other. It should be appreciated, however, that the hashes can be combined in other ways. The network function manager 150 may digitally sign the “cert” (“Sign(cert)”) (e.g., using the network function manager’s 150 private key of a public-private key pair) and send the signed “cert” to a signing server 310. The signing server 310 may be a server that is trusted by the underlying architecture. The signing server 310 may digitally sign the certificate (“Sign(cert)”) (e.g., using the signing server’s 310 private key of a public-private key pair) and store the signed “cert” in the verification database 140. The “cert” stored in the verification database 140 may include both the “hash_NF” and “hash_cgroup.”

[0079] As shown in the diagram, during the verification phase, the cNF instance 110 may send a request to the pNF instance 120 to provide a hash that encodes information regarding the local execution environment of the pNF instance 120. Responsive to receiving this request, the pNF instance 120 may generate a hash (“hash_NF”) based on applying a hash function to information regarding the pNF instance’s local execution environment during runtime. The pNF instance 120 may digitally sign the “hash_NF” (e.g., using the pNF instance’s 120 private key of a public -private key pair) and send the signed “hash_NF” to the cNF instance 110. It is noted that the signed “hash_NF” encodes information regarding the local execution environment of the pNF instance 120 but it does not encode information regarding the control group associated with the pNF instance 120 (since this information is typically not available to the network function instance). However, information regarding the control group associated with the pNF instance 120 is encoded in the signed “cert” stored in the verification database 140.Embodiments use digital signatures in various places as a way to provide authentication. For example, a participant may digitally sign a message using its private key and another participant may authenticate the message using the public key corresponding to the private key. In an embodiment, a trusted key authority issues public-private key pairs to the different participants that digitally sign messages.

[0080] In this example, it is assumed that when the pNF instance 120 is asked to provide the hash, it will generate the hash using valid information and not fabricate it. In some embodiments, if the pNF instance 120 cannot be trusted, an additional node / entity can be provided that provides the information regarding the local execution environment of the pNF instance 120 instead of assuming that the pNF instance 120 is trusted.

[0081] The cNF instance 110 may then send a request to the verification server 130 to verify the pNF instance 120. The request may include the signed “hash_NF.” Responsive to receiving this request, the verification server 130 may search for and retrieve the “cert” that includes the “hash_NF” from the verification database 140. The verification server 130 may extract another hash from the “cert” (“hash_cgroup <- Get_cgroup(cert)”). The verification server 130 may send a request to the network function manager 150 to verify control group information for the pNF instance 120. The request may include the “hash_cgroup.”

[0082] Responsive to receiving the request from the verification server 130, the network function manager 150 may verify the control group information for the pNF instance 120 using the “hash_cgroup” (“Verify_cgroup(hash_cgroup)”). The network function manager 150 may verify the control group information by generating a hash based on applying a hash function to information regarding the control group associated with the pNF instance 120 during runtime and determining whether this generated hash matches the “hash_cgroup.” The network functionmanager 150 may determine that verification of the control group information is successful if the hashes match and determine that the verification of the control group information is unsuccessful if the hashes do not match. The network function manager 150 may send a response indicating whether verification of the control group information was successful or not (“cgroup verification response”) to the verification server 130. The verification server 130 may determine that verification of the pNF instance 120 is successful if verification of the control group information for the pNF instance 120 was successful and determine that verification of the pNF instance 120 is unsuccessful if verification of the control group information for the pNF instance 120 was unsuccessful. The verification server 130 may then send a response indicating whether verification of the pNF instance 120 was successful or not (“pNF verification response”) to the cNF instance 110.

[0083] In an embodiment, the signed “cert” expires after a predetermined period of time. In an embodiment, the verification server 130 causes the “cert” to be revoked in response to determining that the “cert” has expired (e.g., the “cert” is deleted from the verification database 140 or marked as being revoked).

[0084] If the pNF instance 120 is terminated or moved to a different node (e.g., due to lack of resources at the current node), the “cert” may no longer be valid (since the local execution environment of the pNF instance 120 and / or the control group associated with the pNF instance 120 will be different). Thus, in an embodiment, if the network function manager 150 determines that the pNF instance has been terminated or placed on a different node, the network function manager 150 causes the “cert” to be revoked (e.g., the “cert” is deleted from the verification database 140 or marked as being revoked). If the pNF instance 120 is placed on a different node, a new certificate may be generated using the techniques described herein above (e.g., using updated information regarding the local execution environment of the pNF instance 120 and updated information regarding the control group associated with the pNF instance 120).

[0085] Embodiments are able to verify that the local execution environment of a network function instance and the control group associated with the network function instance has not been changed after deployment. This ensures that the network function instance has not been modified (intentionally or unintentionally) during runtime and provides additional trust that the network function instance is “good” for consumption. Embodiments can be used in a zero-trust environment to verify network function instances before they are used.

[0086] Figure 4 is a flow diagram of a method for supporting verification of a network function, according to some embodiments. In an embodiment, the method may be performed bya network function manager. The network function manager may be implemented by one or more computing devices.

[0087] The operations in the flow diagrams will be described with reference to the example embodiments of the other figures. However, it should be understood that the operations of the flow diagrams can be performed by embodiments other than those discussed with reference to the other figures, and the embodiments discussed with reference to these other figures can perform operations different than those discussed with reference to the flow diagrams.

[0088] At operation 410, the network function manager obtains a first hash that is digitally signed by an instance of the network function, wherein the first hash is generated based on applying a hash function to first information regarding a local execution environment of the instance of the network function. In an embodiment, the first information regarding the local execution environment of the instance of the network function includes one or more of: information regarding a memory address space that the instance of the network function occupies and information regarding an operating system that the instance of the network function runs on.

[0089] At operation 420, the network function manager generates a second hash based on applying a hash function to second information regarding a control group associated with the instance of the network function. In an embodiment, the second information regarding the control group associated with the instance of the network function includes one or more of: an identifier that identifies the instance of the network function, information regarding a number of processes running inside the control group associated with the instance of the network function, information regarding memory usage of the control group associated with the instance of the network function, information regarding memory usage of swap memory allocated to the control group associated with the instance of the network function, information regarding a memory limit assigned to the control group associated with the instance of the network function, information regarding a current memory allocation for the control group associated with the instance of the network function, information regarding a maximum memory allocation that has been observed for other control groups associated with other instances of the network function, information regarding network interfaces associated with the control group, and information regarding devices associated with the control group.

[0090] At operation 430, the network function manager generates a certificate that is digitally signed by the network function manager based on combining the first hash and the second hash.

[0091] At operation 440, the network function manager provides the certificate that is digitally signed to a signing server, wherein the signing server is to digitally sign the certificate and store the certificate in a verification database.

[0092] In an embodiment, at operation 450, the network function manager receives a request to verify control group information for the instance of the network function, wherein the request includes the second hash.

[0093] In an embodiment, responsive to receiving the request, at operation 460, the network function manager generates a third hash based on applying a hash function to information regarding a control group associated with the instance of the network function during runtime of the instance of the network function.

[0094] In an embodiment, at operation 470, the network function manager determines whether verification of the control group information for the instance of the network function is successful based on determining whether the third hash matches the second hash.

[0095] At operation 480, the network function manager provides a response corresponding to the request indicating whether the verification of the instance of the network function was successful.

[0096] In an embodiment, the network function manager causes the certificate to be revoked in response to determining that the instance of the network function has been terminated or placed on a different node.

[0097] Figure 5 is a flow diagram of a method for verifying a network function, according to some embodiments. In an embodiment, the method may be performed by a verification server. The verification server may be implemented by one or more computing devices.

[0098] At operation 510, the verification server receives a request to verify an instance of the network function, wherein the request includes a first hash that is digitally signed by the instance of the network function.

[0099] At operation 520, the verification server searches for a certificate that includes the first hash in a verification database. If the verification server does not find a certificate that includes the first hash in the verification database, then verification of the instance of the network function is unsuccessful and the flow moves to operation 550.

[0100] Responsive to finding the certificate that includes the first hash in the verification database, at operation 530, the verification server extracts a second hash from the certificate.

[0101] At operation 540, the verification server determines whether verification of the instance of the network function is successful based on the second hash (e.g., by verifying control group information for the instance of the network function with the network function manager, as described herein above). In an embodiment, determining whether verification of the instance of the network function is successful based on the second hash comprises sending, to a network function manager, a second request to verify control group information for the instance of the network function, wherein the second request includes the second hash andreceiving, from the network function manager, a second response corresponding to the second request indicating whether the verification of the control group information for the instance of the network function was successful.

[0102] At operation 550, the verification server provides a response corresponding to the request indicating whether the verification of the instance of the network function was successful. In an embodiment, the response corresponding to the request includes VCI for the instance of the network function, wherein the VCI for the instance of the network function includes a time stamp indicating when the VCI for the instance of the network function was generated, a verification indicator indicating whether the instance of the network function was successfully verified, an identifier that identifies the instance of the network function, and a verification duration indicator indicating how long the instance of the network function can be considered as being verified.

[0103] In an embodiment, the verification server causes the certificate to be revoked in response to determining that the certificate has expired.

[0104] In an embodiment, the request is received from a service communication proxy that functions as a proxy between a consumer network function and the network function, and wherein the response corresponding to the request is provided to the service communication proxy. In an embodiment, the request is received from an instance of a consumer network function that is to consume the network function, and wherein the response corresponding to the request is provided to the instance of the consumer network function.

[0105] Figure 6 is a flow diagram of a method for facilitating verification of a consumer network function, according to some embodiments. In an embodiment, the method is performed by a SCP. The SCP may be implemented by one or more computing devices.

[0106] At operation 610, the SCP sends a request to a verification server to verify an instance of a consumer network function.

[0107] At operation 620, the SCP receives a response from the verification server indicating whether verification of the instance of the consumer network function was successful. If the instance of the consumer network function was successfully verified, the response may include a verification duration indicator indicating how long the SCP can consider the instance of the consumer network function as being verified.

[0108] At operation 630, the SCP determines whether verification was successful (based on the response received from the verification server). If verification of the instance of the consumer network function was successful, at operation 640, the service communication proxy forwards requests received from the instance of the consumer network function to consume producer network functions without verifying the instance of the consumer network functionwith the verification server again (while verification duration has not expired). Otherwise, if verification of the instance of the consumer network function was unsuccessful, at operation 650, the SCP does not forward requests received from the instance of the consume network function.

[0109] Figure 7 is a flow diagram of a method for facilitating verification of an instance of a producer network function, according to some embodiments. In an embodiment, the method is performed by a SCP. The SCP may be implemented by one or more computing devices.

[0110] At operation 710, the SCP sends a request to a verification server to verify an instance of a producer network function.

[0111] At operation 720, the SCP receives a response from the verification server indicating whether verification of the instance of the producer network function was successful. If the instance of the producer network function was successfully verified, the response may include a verification duration indicator indicating how long the SCP can consider the instance of the producer network function as being verified.

[0112] At operation 730, the service communication proxy determines whether verification was successful (based on the response received from the verification server). If verification of the instance of the producer network function was successful, at operation 740, the SCP forwards requests received from instances of consumer network functions to the instance of the producer network function (while verification duration has not expired). Also, at operation 750, the service communication proxy forwards responses received from the instance of the producer network function to the instances of the consumer network functions without verifying the instance of the producer network function with the verification server (while verification duration has not expired).

[0113] Returning to operation 730, if verification of the instance of the producer network function was unsuccessful, at operation 760, the service communication proxy does not forward requests to the instance of the producer network function or responses received from the instance of the producer network function.

[0114] Figure 8 illustrates connectivity between network devices (NDs) within an example network, as well as three exemplary implementations of the NDs, according to some embodiments. Figure 8 shows NDs 800A-H, and their connectivity by way of lines between 800A-800B, 800B-800C, 800C-800D, 800D-800E, 800E-800F, 800F-800G, and 800A- 800G, as well as between 800H and each of 800A, 800C, 800D, and 800G. These NDs are physical devices, and the connectivity between these NDs can be wireless or wired (often referred to as a link). An additional line extending from NDs 800A, 800E, and 800F illustratesthat these NDs act as ingress and egress points for the network (and thus, these NDs are sometimes referred to as edge NDs; while the other NDs may be called core NDs).

[0115] Two of the exemplary ND implementations in Figure 8 are: 1) a special -purpose network device 802 that uses custom application-specific integrated-circuits (ASICs) and a special-purpose operating system (OS); and 2) a general purpose network device 804 that uses common off-the-shelf (COTS) processors and a standard OS.

[0116] The special-purpose network device 802 includes networking hardware 810 comprising a set of one or more processor(s) 812, forwarding resource(s) 814 (which typically include one or more ASICs and / or network processors), and physical network interfaces (NIs) 816 (through which network connections are made, such as those shown by the connectivity between NDs 800A-H), as well as non-transitory machine readable storage media 818 having stored therein networking software 820. During operation, the networking software 820 may be executed by the networking hardware 810 to instantiate a set of one or more networking software instance(s) 822. Each of the networking software instance(s) 822, and that part of the networking hardware 810 that executes that network software instance (be it hardware dedicated to that networking software instance and / or time slices of hardware temporally shared by that networking software instance with others of the networking software instance(s) 822), form a separate virtual network element 830A-R. Each of the virtual network element(s) (VNEs) 830A-R includes a control communication and configuration module 832A- R (sometimes referred to as a local control module or control communication module) and forwarding table(s) 834A-R, such that a given virtual network element (e.g., 830A) includes the control communication and configuration module (e.g., 832A), a set of one or more forwarding table(s) (e.g., 834A), and that portion of the networking hardware 810 that executes the virtual network element (e.g., 830A).

[0117] The special-purpose network device 802 is often physically and / or logically considered to include: 1) a ND control plane 824 (sometimes referred to as a control plane) comprising the processor(s) 812 that execute the control communication and configuration module(s) 832A-R; and 2) a ND forwarding plane 826 (sometimes referred to as a forwarding plane, a data plane, or a media plane) comprising the forwarding resource(s) 814 that utilize the forwarding table(s) 834A-R and the physical NIs 816. By way of example, where the ND is a router (or is implementing routing functionality), the ND control plane 824 (the processor(s) 812 executing the control communication and configuration module(s) 832A-R) is typically responsible for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) and storing that routing information in the forwarding table(s) 834A-R, and the ND forwarding plane 826 is responsible for receivingthat data on the physical NIs 816 and forwarding that data out the appropriate ones of the physical NIs 816 based on the forwarding table(s) 834A-R.

[0118] In an embodiment, software 820 includes code such as network function verification component 823, which when executed by networking hardware 810, causes the special-purpose network device 802 to perform operations of one or more embodiments disclosed herein as part of networking software instances 822 (e.g., operations to verify instances of network functions to ensure they have not been modified during runtime).

[0119] As shown in Figure 8, the general purpose network device 804 includes hardware 840 comprising a set of one or more processor(s) 842 (which are often COTS processors) and physical NIs 846, as well as non-transitory machine readable storage media 848 having stored therein software 850. During operation, the processor(s) 842 execute the software 850 to instantiate one or more sets of one or more applications 864A-R. While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in one such alternative embodiment the virtualization layer 854 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 862A-R called software containers that may each be used to execute one (or more) of the sets of applications 864A-R; where the multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space) that are separate from each other and separate from the kernel space in which the operating system is run; and where the set of applications running in a given user space, unless explicitly allowed, cannot access the memory of the other processes. In another such alternative embodiment the virtualization layer 854 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications 864A-R is run on top of a guest operating system within an instance 862A-R called a virtual machine (which may in some cases be considered a tightly isolated form of software container) that is run on top of the hypervisor - the guest operating system and application may not know they are running on a virtual machine as opposed to running on a “bare metal” host electronic device, or through para-virtualization the operating system and / or application may be aware of the presence of virtualization for optimization purposes. In yet other alternative embodiments, one, some or all of the applications are implemented as unikemel(s), which can be generated by compiling directly with an application only a limited set of libraries (e.g., from a library operating system (LibOS) including drivers / libraries of OS services) that provide the particular OS services needed by the application. As a unikemel can be implemented to run directly on hardware 840, directly on a hypervisor (in which case the unikemel is sometimes described as running within a LibOSvirtual machine), or in a software container, embodiments can be implemented fully with unikemels running directly on a hypervisor represented by virtualization layer 854, unikemels running within software containers represented by instances 862A-R, or as a combination of unikemels and the above-described techniques (e.g., unikemels and virtual machines both mn directly on a hypervisor, unikemels and sets of applications that are run in different software containers).

[0120] The instantiation of the one or more sets of one or more applications 864A-R, as well as virtualization if implemented, are collectively referred to as software instance(s) 852. Each set of applications 864A-R, corresponding virtualization construct (e.g., instance 862A-R) if implemented, and that part of the hardware 840 that executes them (be it hardware dedicated to that execution and / or time slices of hardware temporally shared), forms a separate virtual network element(s) 860A-R.

[0121] The virtual network element(s) 860A-R perform similar functionality to the virtual network element(s) 830A-R - e.g., similar to the control communication and configuration module(s) 832A and forwarding table(s) 834A (this virtualization of the hardware 840 is sometimes referred to as network function virtualization (NFV)). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which could be located in Data centers, NDs, and customer premise equipment (CPE). While embodiments are illustrated with each instance 862A-R corresponding to one VNE 860A-R, alternative embodiments may implement this correspondence at a finer level granularity (e.g., line card virtual machines virtualize line cards, control card virtual machine virtualize control cards, etc.); it should be understood that the techniques described herein with reference to a correspondence of instances 862A-Rto VNEs also apply to embodiments where such a finer level of granularity and / or unikemels are used.

[0122] In certain embodiments, the virtualization layer 854 includes a virtual switch that provides similar forwarding services as a physical Ethernet switch. Specifically, this virtual switch forwards traffic between instances 862A-R and the physical NI(s) 846, as well as optionally between the instances 862A-R; in addition, this virtual switch may enforce network isolation between the VNEs 860A-Rthat by policy are not permitted to communicate with each other (e.g., by honoring virtual local area networks (VLANs)).

[0123] In an embodiment, software 850 includes code such as network function verification component 863, which when executed by processor(s) 842, causes the general purpose network device 804 to perform operations of one or more embodiments described herein as part of software instances 862A-R (e.g., operations to verify instances of network functions to ensure they have not been modified during runtime).

[0124] The third exemplary ND implementation in Figure 8 is a hybrid network device 806, which includes both custom ASICs / special-purpose OS and COTS processors / standard OS in a single ND or a single card within an ND. In certain embodiments of such a hybrid network device, a platform VM (i.e., a VM that that implements the functionality of the special-purpose network device 802) could provide for para-virtualization to the networking hardware present in the hybrid network device 806.

[0125] Regardless of the above exemplary implementations of an ND, when a single one of multiple VNEs implemented by an ND is being considered (e.g., only one of the VNEs is part of a given virtual network) or where only a single VNE is currently being implemented by an ND, the shortened term network element (NE) is sometimes used to refer to that VNE. Also in all of the above example implementations, each of the VNEs (e.g., VNE(s) 830A-R, VNEs 860A-R, and those in the hybrid network device 806) receives data on the physical NIs (e.g., 816, 846) and forwards that data out the appropriate ones of the physical NIs (e.g., 816, 846). For example, a VNE implementing IP router functionality forwards IP packets on the basis of some of the IP header information in the IP packet; where IP header information includes source IP address, destination IP address, source port, destination port (where “source port” and “destination port” refer herein to protocol ports, as opposed to physical ports of a ND), transport protocol (e.g., user datagram protocol (UDP), Transmission Control Protocol (TCP), and differentiated services code point (DSCP) values.

[0126] A network interface (NI) may be physical or virtual; and in the context of IP, an interface address is an IP address assigned to a NI, be it a physical NI or virtual NI. A virtual NI may be associated with a physical NI, with another virtual interface, or stand on its own (e.g., a loopback interface, a point-to-point protocol interface). A NI (physical or virtual) may be numbered (a NI with an IP address) or unnumbered (a NI without an IP address). A loopback interface (and its loopback address) is a specific type of virtual NI (and IP address) of a NE / VNE (physical or virtual) often used for management purposes; where such an IP address is referred to as the nodal loopback address. The IP address(es) assigned to the NI(s) of a ND are referred to as IP addresses of that ND; at a more granular level, the IP address(es) assigned to NI(s) assigned to a NE / VNE implemented on a ND can be referred to as IP addresses of that NE / VNE.

[0127] Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of transactions on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of transactionsleading to a desired result. The transactions are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0128] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0129] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method transactions. The required structure for a variety of these systems will appear from the description above. In addition, embodiments are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of embodiments as described herein.

[0130] An embodiment may be an article of manufacture in which a non-transitory machine- readable storage medium (such as microelectronic memory) has stored thereon instructions (e.g., computer code) which program one or more data processing components (generically referred to here as a “processor”) to perform the operations described above. In other embodiments, some of these operations might be performed by specific hardware components that contain hardwired logic (e.g., dedicated digital filter blocks and state machines). Those operations might alternatively be performed by any combination of programmed data processing components and fixed hardwired circuit components.

[0131] Throughout the description, embodiments have been presented through flow diagrams. It will be appreciated that the order of transactions and transactions described in these flow diagrams are only intended for illustrative purposes and not intended as a limitation of the present invention. One having ordinary skill in the art would recognize that variations can bemade to the flow diagrams without departing from the broader spirit and scope of the invention as set forth in the following claims.

[0132] In the foregoing specification, embodiments have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

CLAIMSWhat is claimed is:

1. A method performed by a network device implementing a network function manager to support verification of a network function, the method comprising: obtaining (410) a first hash that is digitally signed by an instance of the network function, wherein the first hash was generated based on applying a hash function to first information regarding a local execution environment of the instance of the network function; generating (420) a second hash based on applying a hash function to second information regarding a control group associated with the instance of the network function; generating (430) a certificate that is digitally signed by the network function manager based on combining the first hash and the second hash; and providing (440) the certificate that is digitally signed to a signing server, wherein the signing server is to digitally sign the certificate and store the certificate in a verification database.

2. The method of claim 1, further comprising: receiving (450) a request to verify control group information for the instance of the network function, wherein the request includes the second hash; responsive to receiving the request, generating (460) a third hash based on applying a hash function to information regarding a control group associated with the instance of the network function during runtime of the instance of the network function; determining (470) whether verification of the control group information for the instance of the network function is successful based on determining whether the third hash matches the second hash; and providing (480) a response corresponding to the request indicating whether the verification of the instance of the network function was successful.

3. The method of claim 1, further comprising: causing the certificate to be revoked in response to determining that the instance of the network function has been terminated or placed on a different node.

4. The method of claim 1, wherein the second information regarding the control group associated with the instance of the network function includes one or more of: an identifier thatidentifies the instance of the network function, information regarding a number of processes running inside the control group associated with the instance of the network function, information regarding memory usage of the control group associated with the instance of the network function, information regarding memory usage of swap memory allocated to the control group associated with the instance of the network function, information regarding a memory limit assigned to the control group associated with the instance of the network function, information regarding a current memory allocation for the control group associated with the instance of the network function, information regarding a maximum memory allocation that has been observed for other control groups associated with other instances of the network function, information regarding network interfaces associated with the control group, and information regarding devices associated with the control group.

5. The method of claim 1, wherein the first information regarding the local execution environment of the instance of the network function includes one or more of: information regarding a memory address space that the instance of the network function occupies and information regarding an operating system that the instance of the network function runs on.

6. A method performed by a network device implementing a verification server to verify a network function, the method comprising: receiving (510) a request to verify an instance of the network function, wherein the request includes a first hash that is digitally signed by the instance of the network function; searching (520) for a certificate that includes the first hash in a verification database; responsive to finding the certificate that includes the first hash in the verification database, extracting (530) a second hash from the certificate; determining (540) whether verification of the instance of the network function is successful based on the second hash; and providing (550) a response corresponding to the request indicating whether the verification of the instance of the network function was successful.

7. The method of claim 6, wherein the determining whether verification of the instance of the network function is successful based on the second hash comprises: sending, to a network function manager, a second request to verify control group information for the instance of the network function, wherein the second request includes the second hash; andreceiving, from the network function manager, a second response corresponding to the second request indicating whether the verification of the control group information for the instance of the network function was successful.

8. The method of claim 6, further comprising: causing the certificate to be revoked in response to determining that the certificate has expired.

9. The method of claim 6, wherein the response corresponding to the request includes verification control information (VCI) for the instance of the network function, wherein the VCI for the instance of the network function includes a timestamp indicating when the VCI for the instance of the network function was generated, a verification indicator indicating whether the instance of the network function was successfully verified, an identifier that identifies the instance of the network function, and a verification duration indicator indicating how long the instance of the network function can be considered as being verified.

10. The method of claim 6, wherein the request is received from a service communication proxy that functions as a proxy between a consumer network function and the network function, and wherein the response corresponding to the request is provided to the service communication proxy.

11. The method of claim 6, wherein the request is received from an instance of a consumer network function that is to consume the network function, and wherein the response corresponding to the request is provided to the instance of the consumer network function.

12. A machine -readable medium comprising computer program code, which when executed by a network device implementing a network function manager, causes the network function manager to carry out the method steps of any one of claims 1-5.

13. A machine -readable medium comprising computer program code, which when executed by a network device implementing a verification server, causes the verification server to carry out the method steps of any one of claims 6-11.

14. A network device (804) to implement a network function manager, comprising: a processor (842); and a non-transitory machine-readable storage medium (848) having instructions stored thereon, which when executed by the processor, causes the network function manager to carry out the method steps of any one of claims 1-5.

5. A network device (804) to implement a verification server, comprising: a processor (842); and a non-transitory machine-readable storage medium (848) having instructions stored thereon, which when executed by the processor, causes the verification server to carry out the method steps of any one of claims 6-11.

Images