NFV and NFV-based Security Services 367
Policy‐based systems make declarations of what our goals are, without specifying
how to achieve those goals. Policy is therefore also called declarative, and it must then
rely on a system that can translate the declared goals and put them into practice or
enforcements. This sounds a lot like how some governments are supposed to function.
We can intuitively sense that this is easier said than done.
One problem with declarations is that they are often ambiguous. We therefore
must have a clear language that can express all kinds of policies we may wish
to impose. Another problem is that a group of declarations often contradict each
other; we will need a way to resolve internal conflicts and still maintain integrity
and consistency. But even with a clear and consistent policy specification, the question remains: how do you put the policy into force? Even with a correct procedure
implemented in a system that can enforce the said policy, we still do not know if it
is truly being enforced. You may say this is two sides of the same coin. If you are
mathematically inclined or trained in computer science theories, you know this is
indeed an unsolvable problem.
Because of these difficulties, policy‐based management of security, networks, and
other areas have been studied but not widely implemented on a large scale. With NFV,
we see a new possibility that we may come to achieve real deployment, and dramatically
simplify and enhance security at the same time. This optimism comes from the properties of NFV systems that we have been discussing throughout this chapter. To illustrate,
let us look at some of most recent open‐source solutions in this space.
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
3
gives a good illustration of the concept of groups and
NFV service chaining to enforce dynamic security policies in an NFV system.
3 Derived from image by Openstack Group Based Policy project, CC-BY-3.0 [43].
Policy‐based systems make declarations of what our goals are, without specifying
how to achieve those goals. Policy is therefore also called declarative, and it must then
rely on a system that can translate the declared goals and put them into practice or
enforcements. This sounds a lot like how some governments are supposed to function.
We can intuitively sense that this is easier said than done.
One problem with declarations is that they are often ambiguous. We therefore
must have a clear language that can express all kinds of policies we may wish
to impose. Another problem is that a group of declarations often contradict each
other; we will need a way to resolve internal conflicts and still maintain integrity
and consistency. But even with a clear and consistent policy specification, the question remains: how do you put the policy into force? Even with a correct procedure
implemented in a system that can enforce the said policy, we still do not know if it
is truly being enforced. You may say this is two sides of the same coin. If you are
mathematically inclined or trained in computer science theories, you know this is
indeed an unsolvable problem.
Because of these difficulties, policy‐based management of security, networks, and
other areas have been studied but not widely implemented on a large scale. With NFV,
we see a new possibility that we may come to achieve real deployment, and dramatically
simplify and enhance security at the same time. This optimism comes from the properties of NFV systems that we have been discussing throughout this chapter. To illustrate,
let us look at some of most recent open‐source solutions in this space.
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
3
gives a good illustration of the concept of groups and
NFV service chaining to enforce dynamic security policies in an NFV system.
3 Derived from image by Openstack Group Based Policy project, CC-BY-3.0 [43].