Chu
356
by one operator – trust relationships can be simplified. In this section, we focus on this
simpler case. We will look at multi‐tenancy and XaaS in a later section.
In the development phase, a VNF vendor must design the VNF for operation in
an NFV environment. For physical devices, a lot of trust is often assumed. Even when
a simple password mechanism is implemented, it is common that the password has a
publically‐known or easy‐to‐guess default value. The default password, or private
cryptographic key, is often stored in the image itself. All these practices must be
thoroughly eliminated in order for the VNF to operate in a much more open and less‐
trusty environment. Comprehensive public key authentication with an identity
management infrastructure must be designed into software products, and backdoors
eliminated. Software integrity must be strictly maintained at every step of the lifecycle
with cryptographic signing using a traceable certificate from a Certificate Authority
(CA) established or recognized by the operator.
In the on‐boarding phase, the operator must be able to assure the VNF’s authenticity
and integrity by validating the vendor signature with an authorized CA. The operator
VNF in
development
VNF onboarded
VNF instance
created
VNF instance
in operation
VNF instance
termination
VNF instance
hibernation,
migration ...
VNF instance
upgrade
VNF image
deleted
Figure 15.5 A VNFs lifecycle.
OSS/BSS
NFV orchestrator
VNF
VNF’s EMS
VNF manager
NFV virtual
infrastructure
VIM
Figure 15.6 A VNF’s trust relationship.