15.5.1 Technology Curve

Developing custom products for the telecom industry is a costly business. This cost shows up in the extraordinary long technology cycles. It is common for this process to take a decade or more from R&D to commonly-deployed services for customers. This cost also shows up in the proprietary systems such as gateways, switches, routers, and operating systems, middle-ware, and applications. The hardware is slower to upgrade because of this cost, which deprives the industry of the full benefits of Moore Law in silicon improvements. Its customized operating systems, tool chains, and middle-layer and application software do not fully take advantage of rapid software and methodology advancements, such as distributed system algorithms, distributed or NoSQL data bases, programmable APIs, Big Data, and machine learning, just to name a few. Other segments of the IT industry have taken leaps and bounds with these software technologies, which the telecom industry cannot readily adopt because of the proprietary approach it has taken. There are, of course, unique problems in the telecom industry, such as real-time constraints and high reliability needs. But the question is, can we achieve these based on standard COTS (common off-the-shelf) hardware and modern software technologies? The answer is not only yes, but that we must. NFV can help the telecom industry not only ride the technology curve but lead it.

15.5.2 Opportunity Cost and Competitive Landscape

Proprietary systems are not only costly to develop but also slow to adapt to new customer needs and too inflexible to compete with nimble new competitors. 5G’s success depends on satisfying new customer needs that we may not fully appreciate yet, and tapping into innovative ideas of many different types of partners. IoT, connected and driverless cars, mobile healthcare – these are entirely new markets different from the traditional mobile phone services. VR/AR, immersive video, intelligent agents – these are brand-new user experience and engagement models. To fully seize these new opportunities, agility and flexibility are a competitive advantage we must attain. New competitors, often referred to as OTTs (over the top), do not have the burden of legacy systems and can often outsmart telcos. Operators cannot justify the huge investment in 5G without a strategy to capture a large share of its promised bounty. NFV is part of that strategic toolset.

15.5.3 Horizontal Network Slicing

Networks are very expensive to build, maintain and operate. 5G envisions networks not only for mobile consumers on smart phones, but also for television, healthcare, automobiles, and vast swathes of other segments of the economy, as in IoT. Each of these networks has its own unique requirements. But we cannot build, maintain and operate entirely separate networks for each of them. It will be cost-prohibitive and extremely inefficient. What we need is a shared 5G mobile infrastructure that can be sliced end-to-end, or horizontally, into separate virtual networks that fit best for each market segment. This slicing applies to not only network access and topology but also to functions, such as security, provided by the slice. SDN and NFV together promise rapid provisioning and bringing up these slices on a shared and virtualized infrastructure.

15.5.4 Multi-Tenancy

Having different slices of networks is good, but we also need the virtual infrastructure to be able to support management and operations by different teams, by different functions in an organization, and by different partners and players in the industry in order to deliver sophisticated applications on shared infrastructure. NFV architecture is designed with multi-tenancy in mind as one of the major differences from traditional enterprise and telco systems.

15.5.5 Rapid Service Delivery

As we discussed earlier, the new competitive landscape demands business agility. But that is not all. Many types of requirements in 5G need the ability of rapid service delivery. For example, an “around the globe” service platform may require provisioning and tearing down of resources in a “follow the sun” pattern. Another example is the Continuous Integration/Continuous Deployment (CI/CD) model that requires applications to rapidly update live. Energy conservation is yet another example – being able to shut down part of the infrastructure when the work load is low, and then restart again when demands pick up. That also depends on the ability of rapid provisioning, and security, detecting attacks and rapidly provisioning resources to respond is a strategic arsenal in cyber defense.

15.5.6 XaaS Models

Service providers are no strangers to providing functions as a service, of course. The problem is that the legacy service definitions are rigid, hard to change (regulated by governments), and narrowly targeted. Cloud computing providers such as Amazon Web Services (AWS) pioneered much more flexible service models with a programmable API. Whether the consumable functions are at the infrastructure level, Infrastructure-as-a-Service (IaaS), platform level (PaaS) or the software level (SaaS), or anything in between or in combinations, the flexibility and on-demand nature of these services open up a vibrant ecosystem of innovative partners who come up with a vast variety of ways to consume the shared infrastructure and create value. This type of ecosystem is a must for 5G network builders to fully leverage and monetize their expensive investment. Operators can also leverage each other’s investments and provide better services to their customers. Monetizing fully the operators’ (and vendors’, and partners’) collective investment is one of the most strategically important factors in the success of 5G.

15.5.7 One Cloud

We have talked about the telco cloud as powered by NFV and related technologies so far. But is there any fundamental reason that the telco cloud needs to be distinct from any IT cloud? If we look at the long horizon (or even if one looks back in history), the answer is no. Communication, as distinctive as it is, is closely intertwined with computing; future applications, as envisioned in 5G and in IT industries, predominantly require both computing and communication. Therefore, it is a fair question to ask: Is there a One Cloud into which we will eventually converge, regardless of IT or CT? It means that we are all competing towards the same technology foundation that will one day meet many, if not all, of our IT and CT needs. That day is already here in many market segments, and we may see the contour of what it looks like and make decisions to better prepare for the future. NFV is a major pillar in the foundation that will enable the networking industry to turn its expertise into advantages in the converged one cloud.

15.6.1 VNF Security Lifecycle and Trust

When a physical network device is introduced into an operational network, there is established trust of this device due to the fact that this device was installed and configured by a trusted employee, delivered to a secured location by a trusted courier, and developed and manufactured by a trusted vendor with a contract or a certification, and so on. For VNFs, this chain of trust relationships needs to be created and maintained in a NFV environment throughout its lifecycle.

A VNF’s lifecycle is illustrated in Figure 15.5.

A VNF has several important trust relationships, as shown in Figure 15.6.

In a private NFV environment, as in a private cloud – where NFV infrastructure, MANO and OSS/BSS are in the hands of one administrator and all VNFs are managed 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 will still need to perform the normal acceptance testing procedure. However, with VNFs, this testing procedure can be fully or largely automate. As security-related risks or bugs are identified, new releases can be quickly on-boarded and tested again through full automation in a Continuous Integration/Continuous Deployment (CI/CD) chain. Security verification is an important step in that tool chain. It also ensures that VNFs from different vendors follow the same rigorous process to achieve same level of security level and same security architecture standard. As early example of an automation security testing component in CI/CD is Amazon Web Service’s Inspector [7].

Once on-boarded, a VNF is ready for deployment. Deployment involves creation of an instance of the VNF, for example, one or more virtual machines or containers. It is given an identity and a private management IP address for communication, first with its VNF Manager (VNFM). The identity is usually provided as a service by the Virtual Infrastructure Manager (VIM). With the identity and management IP address, and the assistance of the Identity and Authentication/Authorization service, the VNF instance can now establish a trust relationship with VNFM, VIM and other MANO entities. While a VNF could be simple and contained within a single instance of VM or container, more often it is much more complex, with many VMs or containers collaborating to accomplish its functionalities. Each of these could have its own unique trusted identity, and the identity manager with the VIM facilitates trust establishment among them. It is also possible that a complex VNF or a legacy implementation may conduct the VNF internal trust management on its own. For example, a container manager or a vendor-specific PaaS layer may substitute for or complement the identity function.

The VNF Manager (VNFM) can be a common entity for many or all VNFs in a NFV environment. We can also see VNFM proprietary to a vendor and its VNFs. In either case, the VNF needs to locate the VNFM and then establish a trusted communication channel with the VNFM. Finding VNFM can be facilitated by the VIM’s or MANO’s instance creation phases via metadata to the VM (e.g. a model configuration), or by a common service discovery protocol. In a model-based approach, this VNFM identity can be one of the meta data in the descriptor that defines this VNF. There are efforts underway to standardize how a VNF should be formatted and described or modeled. Among other benefits, a model-based approach can ensure that security policies are uniformly expressed and enforced. Either way, the VNF establishes a trusted and secured management channel with the VNFM, and now it can be managed.

Let us first look at the simple case where the VNF is the only entity required for the example service. In this case, once the VNF can be securely managed and configured, it is now operational. There are a few things the VNF typically needs from the VIM to be fully operational, and they do have security implications. Common examples include publically addressable floating IP address, DNS service, and NTP time service. These services are usually provided by the VIM and NFVI, and therefore it is the responsibility of the operator to secure these services. DDoS attacks against DNS service have been widely reported in recent years, for example in [8]. The operator can also outsource some of these services, for example DNS, to professional DNS service providers. We will further discuss these XaaS scenarios in a later section.

The next step in a VNF’s lifecycle is updating its software image. Software upgrade is a major undertaking in physical network devices, including extensive testing and preparation. In the NFV methodology, the Continuous Integration and Continuous Deployment (CI/CD) [9] paradigm is a large part of changing the whole feature delivery pipeline to enable much more agile and flexible operation and business models. For the security domain, this is a great opportunity to create a threat intelligence pipeline, through which new threats are detected and analyzed, then new security patches or defenses are developed, tested and delivered through CI/CD routinely. The agility of this pipeline must beat the new threats in this game to maintain security in the future. NFV-based CI/CD is an enabler for this fundamental capability that future 5G systems must have.

The last stage of a VNF’s lifecycle is termination. Some of the tasks in a termination phase are the removal of cryptographic material from the image, orderly archival and removal of kept data records, etc.

Further discussions regarding the VNF’s lifecycle and security in each stage can be found in ETSI NFV ISG’s TST working group publications such as [10].

To summarize, in this simpler, private NFV environment, a VNF’s lifecycle is standardized by a model VNF Descriptor (VNFD) and automated through VIM, VNFM and service layer. This standardization and automation, coupled with rapid updating capability by CI/CD, will make security in NFV stronger than the manual system of today. We often hear that the most common security vulnerabilities are due to human error or human weakness exploitation. NFV-based automation will change the dynamics and allow operators to put their resources directly into defeating threats.

15.6.2 VNF Security in Operation

Managing a VNF’s lifecycle is only one aspect of VNF security. A VNF spends most of its time in the operational state. Several important factors determine a VNF’s security property.

First, let us remove one of the simplifications we made earlier: the assumption that a VNF is a single entity, for example, a virtual machine. More commonly, a VNF consists of a group of virtual machines with the same (a cluster) or different software images (VNF Components or VNFCs). In either case, each virtual machine has a unique identity and they are distributed to various computing units, not necessarily on the same physical servers.

These virtual machines will need a network over which they can: (i) coordinate their work by passing control messages among themselves, or (ii) pass around network packets (traffic) between them for distributed or pipeline processing. This is similar to a backplane in physical systems where control modules and line modules are interconnected, or there is an Ethernet-based network fabric in a data center. Inside a VNF, this interconnection is provided by a virtual network created dynamically. This virtual private network is provided on demand by virtual overlay such as VXLAN [11], a software abstraction supported by the hypervisor or by a virtual switch (vSwitch in layer 2) or a virtual router (vRouter in layer 3). Virtual networking or network slicing is a fundamental building block of the NFV infrastructure, and must support two basic requirements:

1. Topology isolation; and
2. Security rules.

Topology isolation means the virtual network is private, with its accessibility to the outside world fully controlled. Isolation alone is usually insufficient; security rules provide firewall-like security to the virtual machines that reside inside the virtual network. These software abstractions can be several magnitudes more scalable than physical firewalls such that security rules can be applied with very fine granularity. This is sometimes referred to as micro-segmentation [12].

Virtual networks and security rules only protect a VNF from other virtual machines that are sharing the same infrastructure. VNFs must also connect with each other to collaboratively construct a network service. This is referred to as Service Function Chaining or SFC [13]. SFC can be realized by the same mechanism using virtual networks and security rules. It is not very efficient, however, because data packets must be in and out of processors repeatedly stressing the data path bottlenecks, and the common packet parsing and classification tasks have to be repeated in each stop of the pipeline where that information of a packet is needed. An active task in IETF [13] is defining a new encapsulation scheme for SFC to address some of these issues. SFC does not provide security protection between different VNFs, however. If security is needed, a virtual firewall VNF is inserted in the chain to work the same way as a physical firewall or security gateway.

Some of the VNFs that comprise the service must eventually connect with the outside world via physical network devices to backbone networks, access networks or devices that are geographically remote. The VNFs are gateways that must contain access to physical ports directly or indirectly. These edge VNFs must be protected from threats just like any other PNF in this case. They do have one advantage compared to the physical ones: they can scale up and down on demand, and that gives them better ability to deal with DDoS attacks.

Naturally, networking is the most important aspect of security for VNFs, but not the only one. Virtualization of computing and storage also exposes new attack surfaces to VNFs and adds new protection capabilities at the same time. Because VNFs share a server’s processors, memory and disk with other virtual machines, the isolation capability provided by the hypervisor is usually not as strong as physical isolation. These types of issues have been addressed, however, and more capabilities are being added to a processor’s architecture to strengthen protections. Other issues include the noisy neighbor problem, where a less-restrained virtual machine sharing the same physical processor resources could intentionally or inadvertently abuse them and cause performance degradation, or more severe issues. To properly address these types of issues, new generations of processors will add stronger isolation mechanisms, for example, Intel Xeon’s cache reservation [14]. VIM’s resource management software will develop schemes to allocate resources and place virtual machines more intelligently.

The virtualization layer, for example the hypervisor, provides a strong level of protection for the VNFs running on the top. Modern hypervisors all have built-in security features in addition to the protection provided by the operating systems. VNFs can also migrate, scaling up and down and in and out, and new security rules or security VNFs can be added on demand. All these functions substantially enhance the overall ability of the network services to withstand threats both old and new.

15.6.3 Multi-Tenancy and XaaS

So far we have assumed that the entire NFV system is private, that is administered by a single operator. NFV facilitates XaaS models in many different layers that can enable innovative business and operational approaches. For a given service, the provider must support multi-tenancy in the infrastructure, so that the same infrastructure can be provided to more than one consumer in a shared fashion. For the consumers, this is functionality provided to them as a service (XaaS). They can build higher-layer applications on top of the XaaS interface.

Let us take an example of IaaS (infrastructure as a service) where the provider operator offers its data center infrastructure to partners. The infrastructure is NFVI and VIM in NFV terminology and it supports multi-tenancy. The provider who may own the infrastructure and the operation of it offers the use of this infrastructure in a cloud fashion. NFVI consists of the virtualized assets being shared, and VIM provides the interface or API so that the partners can consume this service. Multi-tenancy means the provider allows the partner/consumer to slice a virtual pool of computing resources under the partner’s administrative control; the partner can virtually construct its own network services, composed of VNFs, within its slice of resources. Consumers of Amazon Web Services will be familiar with this consumption model; NFV extends this to telco services.

Multi-tenancy requires not only an efficient way of slicing the resources, but also security and privacy protections offered by the provider to its partners/consumers. Virtual private networks and their associated security rules, as described in the last section, are the basic foundation. But additional capabilities are required, including virtualization of supporting functions such as DNS, DHCP, identity, monitoring and reporting. Moreover, additional services are required for virtual gateway routing so that the virtual private network can securely connect with the Internet. We will often see that software originally developed for private use, even private cloud use, cannot adequately support these multi-tenancy requirements.

The provider may optionally support more features for its partners or consumers. These can be common tools that are needed to develop or deploy VNFs, such as performance monitoring and reporting, logging, data analytics, enhanced security services, databases, high availability, scaling and billing. These are often referred to as either Platform as a Service (PaaS) or Software as a Services (SaaS), depending on how we classify them into middle-ware or application categories. All these services will also need to support multi-tenancy.

With 5G networks and applications, this concept of resource-sharing and multi-tenancy are being pushed to new levels to include network-sharing. For instance, a new class of end-user devices (say, IoT or healthcare or automobiles) can be supported with a virtual slice of wireless access. Associated with each class is a slice of access network infrastructure (virtual networks), and a slice of virtual computing infrastructure and service applications (NFV data centers and VNFs). Each such class of services can have its own capacity, its own security policy, its own SLA, billing and support models, and so on.

15.6.4 OPNFV and Openstack: Open Source Projects for NFV

Why open source? Open source may seem like an off-topic subject for 5G, security or NFV, but it is not – for two very important reasons.

First, as we alluded to earlier, open source has been increasingly seen as an indispensable component in the development of NFV. The traditional standardization processes made tremendous accomplishments in getting mobile networks to where we are today. 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.

In addition to the hypervisor/container, NFV requires special functions to support the network data plane. Open vSwitch (OVS) [19] is an open-source implementation of software-based switching capabilities based on SDN and is the most commonly deployed virtual switching implementation, according to Openstack user surveys. FD.io [20] is an alternative way of supporting a high-performance network data plane.

The networking data plane puts an extreme demand on packet movement (I/O) and processing to the underlying servers. The kernel TCP/IP stacks (and drivers) known to many software developers are often inadequate due to performance and other limitations. DPDK [21] is an open-source SDK that can improve, dramatically in some use cases, the data-packet movement and processing performance by taking advantage of special features in the processors. DPDK is developed by Intel® for Xeon processors. Similarly, ODP [22] (Open Data Plane) is an open-source project aiming to provide a cross-platform data plane SDK for SoCs and servers. The performance improvement levels of DPDK and ODP are particularly pronounced when we look at smaller packet sizes or packet-per-second measurements [23]. These smaller packets can be common in telecommunications networks for voice, media and others, as compared to IT and database applications in enterprises. In addition, packet-process latency or latency variation (jitter) can also be important considerations. More importantly, we also start to see that the narrow focus on SDK for performance may not be sufficient. A system’s approach, where we develop a general framework that takes into account cluster management, reliability, programmability, and other system level issues, may hold more promise [24].

The data plane is the fundamental component of the fabric, for security or any networking functionality. One prominent feature of NFV is virtual network on demand. This network level isolation, in topology by layer 2 or layer 3 means, in virtual addressing, NAT, and security rules applied to the virtual network domains lay the bedrock for NFV security.

The counterpart of network data plane is its control plane. In Openstack, Neutron is the default virtual networking API, and we use an SDN controller to achieve many challenging goals such as scaling, flexibility and reliability. OPNFV integrated several well-developed options for the SDN controller. OpenDaylight (ODL) [25] is a sister Linux Foundation project focused on developing an open-source SDN controller. ODL is backed by many networking industry major corporations. The Open Network Operating Systems (ONOS) [26] is another open-source project spearheaded by ON.lab and other members, which has also become a Linux Foundation project. ONOS closely collaborates with the AT&T CORD (Central Office Re-architected as Data center) [27] project. As we have discussed, the SDN controller is the back end to deliver a certain networking area function abstraction. In Openstack, Neutron is the abstraction that comes natively by default. Let us take Open vSwitch (OVS) as an example of the data plane, and ODL as an example of the controller. Users make a Neutron API call to create an on-demand virtual network. This request passes to and is implemented by ODL, which in turn interacts with OVS via OpenFlow. There is much more complexity in the steps taken to realize the simple virtual network abstraction, of course, but Neutron abstraction itself is quite simple.

For NFV, Neutron’s simple abstraction is often not enough, because it has to have the ability to represent many different networking technologies and use cases. For instances, virtualization of broadband access networks (vCPE: virtual Customer Premises Equipment) and VPN based on BGP/MPLS [28] for core networks will not fit into the simple Neutron model neatly. If we consider 5G use cases such as IoT, automobile, healthcare and other industries outside of traditional telco, this situation is even more complex. We have several ways to solve this problem. We could extend Neutron, but this option can make Neutron very complex and be a burden on enterprise applications that may not need or want that complexity. We could develop a separate service that specifically addresses telco networking needs (e.g. the Openstack Gluon project) [29]. Or, we could implement those networking abstractions outside of Openstack altogether by deploying SDN controller as a separate instance of VIM (Figure 15.4).

There are several abstractions in Openstack to capture different storage needs. Glance is an image service for all application software images; Swift is an API for object store; and Cinder is an API for block storage. OPNFV currently integrates a Ceph open-source project [30] to implement virtual storage from various storage hardware, for example, economical local hard drives in the servers. Other storage back ends exist and can be more common in deployments.

In Openstack, Keystone implements Openstack’s identity API, supporting API client authentication, service discovery, and distributed multi-tenant authorization services for the entire Openstack deployment. A client asks Keystone for an authentication token by providing its valid credentials. This token is then used in the REST API to access an Openstack service, such as the X-Auth-Token request header. Keystone also supports integration with existing LDAP directories for authentication and authorization.

Finally, in the Danube release cycle, OPNFV is integrating two MANO (Management and Orchestration) open-source projects. OPEN-O [31] is a Linux Foundation-backed project “that enables telecommunications and cable operators to effectively deliver end-to-end services across Network Functions Virtualization (NFV) Infrastructure.” The Open Baton project [32] is supported by TU Berlin, Fraunhofer FOKUS, and the 5G-Berlin program in Germany, and it “is a ETSI NFV compliant MANO framework. It enables virtual Network Services deployments on top of heterogeneous NFV Infrastructures.” While these MANO projects are still new at the time of writing, they complete the OPNFV stack so that an end-to-end NFV deployment reference platform is now possible in open-source through OPNFV.¹

Figure 15.8² illustrates an end-to-end use case for an operator to deploy residential vCPE service with OPNFV integrated with OPEN-O VNF Manager and Orchestrator. This end-to-end network service slicing capability allows a common 5G network infrastructure to efficiently support multiple partners, multiple market segments, and use cases.

15.7.1 NFV-based Network Security

Network security services are typically provided by a gateway device. They are ubiquitous today in our computing and networking infrastructures in the forms of firewalls, DPI (deep packet inspection), IDS/IPS (intrusion detection systems or intrusion prevention systems), and many more. They can be stand-alone appliances or can be embedded into other network devices. These gateways are inline devices, meaning that they must be inserted into the network data path and handle the full load of traffic in order to be most effective. They are therefore prime candidates for virtualization. We look at different ways in an NFV system in which this can be achieved, and their benefits.

15.7.2.1 Group-based Policy

Network engineers have been configuring access control lists (ACL) or firewall rules for years. These rules may be clear but they are extremely brittle and fragile, hard to maintain because they are specific to the details of each system, and difficult to prove correct. They are also primitive and not very effective.

Group-Based Policy (GBP) is a high-level abstraction to solve some of these challenges. A group is an abstraction of a collection of network endpoints and description of their properties. In NFV, this can be a group of VNFs. A VNF can instantly inherit security and other policies by becoming a member of a group. In GBP, the actual rules are separated out of the devices with an abstract rule set describing the desired behavior. These abstract rules can therefore be “reused” by attaching to many groups. The reusable nature of the rule set allows operators to develop mature policies that comply with known regulations, such as PCI and those developed to meet IoT, healthcare or autonomous cars in the future. These rules include not only common ones that we know in firewalls or ACLs, but also NFV-powered service chaining rules and rerouting rules. For example, you can write rules to reroute “dirty” traffic through a firewall virus-scan or IDS. This redirection capability allows GBP to describe a NFV Forwarding Graph. GBP also allows rules to come from different sources, for example, VNF’s developers specifying the rules for the application, and data center operators specifying rules for operations and administration.

The example in Figure 15.9³ gives a good illustration of the concept of groups and NFV service chaining to enforce dynamic security policies in an NFV system.

GBP is a policy framework specifically focused on networking and network-based security services. It is otherwise general and has been utilized in Openstack on top of Neutron [34], and in OpenDaylight [35], in addition to commercial products from several networking vendors.

Next, let us look at an example of a policy framework that is more general-purpose by design, beyond just networking.

dmz_server(x) :-
      nova:servers(id = x,status = 'ACTIVE'),
      neutronv2:ports(id, device_id, status = 'ACTIVE'),
      neutronv2:security_group_port_bindings(id, sg),
      neutronv2:security_groups(sg,name = 'dmz')

dmz_placement_error(id) :-
      nova:servers(id,name,hostId,status,tenant_id,user_id,image,flavor,az,hh),
      not glancev2:tags(image,'dmz'),
      dmz_server(id)

execute[nova:servers.pause(id)] :-
      dmz_placement_error(id),
      nova:servers(id,status = 'ACTIVE')

15.7.3 Machine Learning for NFV-based Security Services

Policy-based approaches tend to favor deductive reasoning by building models of reality and analyzing the models based on logical rules. As we know, this approach has its limits and does not work well in complex, dynamic and large systems by itself. An alternative way is to find truth from observation data and inductive reasoning.

Machine learning (ML) and Big Data have made rapid advancements and have had a huge impact on many problems that IT and CT industries face. It is not new that ML has played a large part in security – both on the positive side in protecting business systems and user privacy, and on the negative side as in hacking or unwanted surveillance. It is out of the scope of this short discussion to go into the general picture of ML applications in security and many of the envisioned 5G use cases. We will briefly touch upon several promising areas where ML can help NFV-based systems to better perform and protect [38,39].

• Autonomous Operations

Within an abstracted and service API-oriented system, ML can use collected real-time data to fine-tune optimization parameters of the overall resource management scheme. It is also promising that the ML system will be able to adapt to load spikes (e.g. during a DDoS attack) with autonomous responses by learning from long-term operational data collected from human expert operators. As we have reviewed throughout this chapter, NFV has made the system highly automatable and also made consistent real-time data readily available. In [38], we call such a highly autonomous system a Sentient Network.

• Self-Defense

There exists a large body of literature now about ML algorithm for anomaly detection and learning latent structures or patterns from network activities. Discovery of invariants in functional, operational, causal and other relationships are crucial in many complex cyber-physical systems such as a smart grid [40]. The telco physical infrastructure itself is such a system. ML can go beyond what traditional data analytics can deliver by discovering deep non-linear, distributed, and time-shifted relationships. Detection of these kinds of complex relationships, and anomalies within them, is a huge step towards creating a large self-defending NFV infrastructure and future applications that will run on it.

• Artificially-Intelligent Customer Service

Beyond the wonders of Photo Captioning, Natural Language Processing (NLP) systems and chat bots, AI and ML can also make the modeling of user needs much more intelligent. NFV allows these systems to have access to data far beyond just the Call Records and mobile device tracking, for example, into end-to-end customer services. Examples include seamless mobility between heterogeneous networks and voice or video emotion detection of quality problem detections. NFV’s flexibility allows the system to address the problem before a customer’s experience deteriorates. Security is a crucial part of this customer experience. Static systems often put security vs. privacy, or security vs. convenience into a zero-sum game. ML can help us differentiate and make choices to optimize the overall experience – without the hassle of making explicit trade-offs every time we face such a choice.