NFV and NFV-based Security Services 361
That being said, we see shortcomings too, such as long and slow processes from ideas to
products and services, and difficulty to adopt those kinds of processes to the software
domain. Open‐source projects such as Linux and Openstack have emerged as de facto
standards within certain domains and can be just as effective in achieving many of the
goals, like interoperability and rich ecosystems, which standards try to achieve. In the
security realm, the prominence of open‐source components like OpenSSL is a good
example. Premium standard organizations such as ETSI, 3GPP and IETF recognize this
trend and see the important role open‐source is likely to play for NFV, IoT, and many
other areas of 5G. OPNFV (Open Platform for NFV) [15] is one such project launched
in September 2014 to accelerate the adoption of NFV by integrating an open‐source
reference platform for NFV.
Second, as more and more people come to realize, open‐source cloud computing
software based on commodity off‐the‐shelf hardware have made incredible progress in
delivering unparalleled economic computing power in the last decade. One may venture to say that this is the main reason why we started the NFV initiative in the first
place. Taking advantage of the open‐source technology base to accelerate NFV seems a
natural and obvious thing to do. Why re‐invent the wheel when we can stand on the
success that open‐source already created for IT, web and cloud computing industries?
That is why, in about two years after ETSI’s launch of the NFV program, the Open
Platform for NFV (OPNFV) project was created – with leading operators, network
vendors, IT vendors, and open‐source software developers joining together for the first
time in industry history. It became a Linux Foundation project in September 2014
with a mission to “create a reference NFV platform to accelerate the transformation of
enterprise and service provider networks”.
If we take a high‐level framework like that of Figure 15.2, how do we then use open‐
source components to build a platform together to satisfy operators’ needs? That is
essentially what OPNFV set out to do (Figure 15.7). The OPNFV reference platform is
the one example of NFV design that we can closely examine – and, for those of us who
are so inclined, run it in a lab to experience it. The following diagram is a rendition of
the OPNFV reference platform by the author. Many will readily admit that there is not
one single reference platform but several different ways we can compose the platform
together. Not all technical questions have been settled yet, as is often the case in the
open‐source world, but we can still benefit from studying their most recent release still
in development at the time of writing, code‐named Danube.
As shown in Figure 15.7, the centerpiece of the OPNFV reference platform is
Openstack [16] as the VIM (virtual infrastructure manager). Openstack provides
abstracted services as APIs.
Nova is Openstack’s virtual computing API. For the NFV data plane, we first need a
hypervisor, such as KVM [17] or LXD [18]. There are other choices for either hypervisor
or container. Well‐recognized examples include ESX® from VMWare and Docker®. For
simplicity, we only show the components that have been actively integrated within the
OPNFV at the time of writing (during the Danube release cycle). The same applies to all
the discussions in this section.
The hypervisor is critical in providing security to VNFs in this environment.
Hardening KVM is mandatory to prevent common vulnerabilities such as guest execution escape, guest‐triggered DOS, and information leaks to guest. Modern hypervisors
are safe for most common‐use cases.
That being said, we see shortcomings too, such as long and slow processes from ideas to
products and services, and difficulty to adopt those kinds of processes to the software
domain. Open‐source projects such as Linux and Openstack have emerged as de facto
standards within certain domains and can be just as effective in achieving many of the
goals, like interoperability and rich ecosystems, which standards try to achieve. In the
security realm, the prominence of open‐source components like OpenSSL is a good
example. Premium standard organizations such as ETSI, 3GPP and IETF recognize this
trend and see the important role open‐source is likely to play for NFV, IoT, and many
other areas of 5G. OPNFV (Open Platform for NFV) [15] is one such project launched
in September 2014 to accelerate the adoption of NFV by integrating an open‐source
reference platform for NFV.
Second, as more and more people come to realize, open‐source cloud computing
software based on commodity off‐the‐shelf hardware have made incredible progress in
delivering unparalleled economic computing power in the last decade. One may venture to say that this is the main reason why we started the NFV initiative in the first
place. Taking advantage of the open‐source technology base to accelerate NFV seems a
natural and obvious thing to do. Why re‐invent the wheel when we can stand on the
success that open‐source already created for IT, web and cloud computing industries?
That is why, in about two years after ETSI’s launch of the NFV program, the Open
Platform for NFV (OPNFV) project was created – with leading operators, network
vendors, IT vendors, and open‐source software developers joining together for the first
time in industry history. It became a Linux Foundation project in September 2014
with a mission to “create a reference NFV platform to accelerate the transformation of
enterprise and service provider networks”.
If we take a high‐level framework like that of Figure 15.2, how do we then use open‐
source components to build a platform together to satisfy operators’ needs? That is
essentially what OPNFV set out to do (Figure 15.7). The OPNFV reference platform is
the one example of NFV design that we can closely examine – and, for those of us who
are so inclined, run it in a lab to experience it. The following diagram is a rendition of
the OPNFV reference platform by the author. Many will readily admit that there is not
one single reference platform but several different ways we can compose the platform
together. Not all technical questions have been settled yet, as is often the case in the
open‐source world, but we can still benefit from studying their most recent release still
in development at the time of writing, code‐named Danube.
As shown in Figure 15.7, the centerpiece of the OPNFV reference platform is
Openstack [16] as the VIM (virtual infrastructure manager). Openstack provides
abstracted services as APIs.
Nova is Openstack’s virtual computing API. For the NFV data plane, we first need a
hypervisor, such as KVM [17] or LXD [18]. There are other choices for either hypervisor
or container. Well‐recognized examples include ESX® from VMWare and Docker®. For
simplicity, we only show the components that have been actively integrated within the
OPNFV at the time of writing (during the Danube release cycle). The same applies to all
the discussions in this section.
The hypervisor is critical in providing security to VNFs in this environment.
Hardening KVM is mandatory to prevent common vulnerabilities such as guest execution escape, guest‐triggered DOS, and information leaks to guest. Modern hypervisors
are safe for most common‐use cases.