NFV and NFV-based Security Services 349
physical resources that can be shared and reallocated on demand. We will refer to the
appliances shown on the left side of Figure 15.1 as Physical Network Functions (PNF),
and the equivalent software implementation as Virtual Network Functions (VNF). From
a security perspective, the VNF’s role within a solution architecture stays the same as the
corresponding PNF, but its implementation environment has changed. For example, the
VNF’s developers can no longer use customized physical design features for security (e.g.
by limiting certain device management ports), nor can they do so to the common operating system or hypervisor or container environment in the virtualization layer. These
common systems represent both a potentially larger attack surface and a place where
fundamentally new security solutions can be delivered. It is critical that the virtualization
layer provides equivalent or stronger security features for the VNFs. The virtualization
layer is an intermediary that can potentially provide more unified, uniformly enforced,
and stronger security than an individual PNF developer can achieve on his/her own. In
addition, virtualization means that a VNF for security (e.g. a firewall or a DPI appliance)
can be deployed to anywhere in the virtual infrastructure almost instantaneously
with little overhead or cost. This also opens up new opportunities for stronger security
features that were not feasible before NFV.
Beyond virtualization of infrastructure and VNFs, NFV also integrates the management, orchestration and OSS/BSS to the architecture picture. In many aspects, the
management and orchestration layer may be more fundamental than virtualization
itself. The ETSI NFV ISG’s work in the NFV reference framework is the most widely
known example of the current thinking in this area. In Figure 15.2, three components
are introduced in the management and orchestration (MANO) area. The Virtual
Infrastructure Manager (VIM) constructs an abstract consumption model for the
virtualized infrastructure. The VNF Manager, whether it is a common instance for
many VNFs, or a specific instance (e.g. per vendor) for a given subset of VNFs, helps to
manage the lifecycle of the corresponding VNFs in a virtual infrastructure. The
Orchestrator (at least in ETSI’s naming convention) looks at the service‐level abstractions, such as the service catalog, and presents those abstractions to the broader users
of the overall system, such as OSS and BSS. While there are clearly alternative ways of
Traditional integrated custom-designed hardware
CDN
CG NAT
RAN
Server
Virtual
appliance
Virtual
appliance
Virtual
appliance
Storage
Network
Tester/QoE
monitor
WAN
Acceleration
BRAS
SBC
Firewall
PE Router
Message
Router
DPI
SGSN/
GGSN
Examples of Physical Network Functions
Standard off-the-shelf
hardware
Figure 15.1 A simple view of NFV.
physical resources that can be shared and reallocated on demand. We will refer to the
appliances shown on the left side of Figure 15.1 as Physical Network Functions (PNF),
and the equivalent software implementation as Virtual Network Functions (VNF). From
a security perspective, the VNF’s role within a solution architecture stays the same as the
corresponding PNF, but its implementation environment has changed. For example, the
VNF’s developers can no longer use customized physical design features for security (e.g.
by limiting certain device management ports), nor can they do so to the common operating system or hypervisor or container environment in the virtualization layer. These
common systems represent both a potentially larger attack surface and a place where
fundamentally new security solutions can be delivered. It is critical that the virtualization
layer provides equivalent or stronger security features for the VNFs. The virtualization
layer is an intermediary that can potentially provide more unified, uniformly enforced,
and stronger security than an individual PNF developer can achieve on his/her own. In
addition, virtualization means that a VNF for security (e.g. a firewall or a DPI appliance)
can be deployed to anywhere in the virtual infrastructure almost instantaneously
with little overhead or cost. This also opens up new opportunities for stronger security
features that were not feasible before NFV.
Beyond virtualization of infrastructure and VNFs, NFV also integrates the management, orchestration and OSS/BSS to the architecture picture. In many aspects, the
management and orchestration layer may be more fundamental than virtualization
itself. The ETSI NFV ISG’s work in the NFV reference framework is the most widely
known example of the current thinking in this area. In Figure 15.2, three components
are introduced in the management and orchestration (MANO) area. The Virtual
Infrastructure Manager (VIM) constructs an abstract consumption model for the
virtualized infrastructure. The VNF Manager, whether it is a common instance for
many VNFs, or a specific instance (e.g. per vendor) for a given subset of VNFs, helps to
manage the lifecycle of the corresponding VNFs in a virtual infrastructure. The
Orchestrator (at least in ETSI’s naming convention) looks at the service‐level abstractions, such as the service catalog, and presents those abstractions to the broader users
of the overall system, such as OSS and BSS. While there are clearly alternative ways of
Traditional integrated custom-designed hardware
CDN
CG NAT
RAN
Server
Virtual
appliance
Virtual
appliance
Virtual
appliance
Storage
Network
Tester/QoE
monitor
WAN
Acceleration
BRAS
SBC
Firewall
PE Router
Message
Router
DPI
SGSN/
GGSN
Examples of Physical Network Functions
Standard off-the-shelf
hardware
Figure 15.1 A simple view of NFV.