SONATA: Securely Publishing NFV-based Network Services

SONATA published its latest blog post.

We hope the subject is of your interest and you enjoy reading it!

The softwarization and virtualization of networks and network functions have elevated the complexity of securing networks by another notch. The security of the complete lifecycle of NFV based network services has to be revised and accounted for in order to address their basic security needs and, as a consequence, ensure their functioning.

A Network Service (NS) lifecycle includes Development, Publication, Deployment, Management and Termination. Usually, a validation stage is also considered between Development and Publication and between Publication and Deployment. The former validation is conducted by the developer and the latter one by the platform where the NS is published. The aim of the validation stage is to perform a syntax wise sanity check. This blog post discusses the very basic security aspects related to the publication of NSes.

There are usually two approaches towards NS development, standalone SDK and built-in tools in service platforms. SONATA is an example of the former whereas T-NOVA and OSM are examples of the latter. Using the SDK, a developer can write his/her own NS consisting of all the required descriptors including NS, VNFs, etc. [Quick Reminder: An NS consists of one or more Virtual Network Functions (VNFs)].

The NS may be published as a package/bundle of all the constituent descriptors but in order to maintain the integrity of the NS, the NS package must be digitally signed by the developer using public key cryptography principles. [Quick Reminder: Public key cryptography (a.k.a asymmetric key cryptography) revolves around usage of a pair of keys, Public key and Private Key, which are mathematically unique to each other. The Public key is disseminated publically whereas the Private Key is kept secret]. Digitally signing the package allows the receiving party to verify, without doubt, that the NS package received was actually written by the original developer, hence avoiding Man-in-the-Middle attacks. To achieve this, the developer encrypts the hash of the NS package with its private key. In order to publish it securely, the developer includes the original NS package, encrypted hash, and his/her public key certificate. The public key certificate is an essential requirement as it validates the authenticity of public key of the developer. The receiving party, in this case, a service platform or NS catalogue, verifies the integrity (authenticity) of the NS package in three steps: i) compute hash of the NS package using the same hash function, ii) validates the public key certificate and then decrypts the received signed hash, and iii) compares the decrypted hash with locally produced hash. If the hash values are identical then the NS package is considered authentic otherwise not.

The process of computing digital signatures on the developer side and the verification of these signatures by the service platform or catalogues, may seem cumbersome but it is essential to reusability of the NSes. That is, a developer must ensure the authenticity of an existing NS before it reuses it to create another NS. If the authenticity of existing NSes are not established then proper functioning of the NSes will be impossible to guarantee. In order to make existing NSes available to 3rd party developers, NS catalogues or service platforms, have to store the encrypted hash received from the original developers and optionally along with their public key certificates as well. This encrypted hash along with public key certificate [Note: If the public key certificate is not tagged along, then the requested developer has to acquire it on its own] has to be send along with the NS package to the requesting 3rd party developer so that he/she his/herself can also verify it.

Another interesting point to consider is what if the reusability of existing NSes is at the VNF level. That is, a developer does not reuses the entire NS but only reuses one or more constituent VNFs. In this case, NS package level signatures will not suffice and each VNF descriptor has to be individually signed and verified to ensure secure re-usage of existing VNFs.