Customer Edge Switching: A Security Framework for 5G 209
In case a prior trust does not exist between the CES nodes, a CES‐to‐CES level nego‑
tiation of policies precedes the host‐to‐host policy negotiation in step‐2. The aim of
CES policies is to negotiate network‐layer capabilities, and to achieve the trust between
networks. This includes elimination of the classical internet weaknesses, such as source
address spoofing, and hence establishing grounds for putting blame on the remote net‑
work or its hosts, in case a misbehaviour is detected or reported. We discuss these CES
policies and corresponding security mechanisms briefly in Section 9.3.4.
9.3.3 Policy Architecture
All aspects of communication in CES are governed by policy. For example, CES‐level
policy defined by a network administrator is concerned with establishing trust between
CES networks, besides guiding other aspects of CES‐to‐CES signalling, such as coop‑
erative firewalling and reputation handling. Similarly, all the host, service or application‐
level communications are governed by the corresponding policies defined by the end
users or its subscriptions within constraints agreed with the corporate network admin,
the eyeball ISP or the mobile operator.
The policy creation can be based on business contracts or software licenses. Examples
of such business contracts include subscription to ISP or mobile operator; purchase of
mobile network packages and services; or outsourcing contracts between firms or
between the firms and the consumers. In order to produce executable policies for a CES
node, there is a need to leverage information in different data repositories, such as
mobile application stores, trusted electronic contracting services, security vendor data‑
bases and company level security policy databases, at both the CES and host level. In
addition, the CES nodes need to leverage the black, grey and white lists dynamically
maintained by the trust domain.
To use policy architecture in the context of mobile networks, CES would, for example,
use a Diameter client that can query HSS for mobile issued identities. The storage and
management of policies for hosts and applications can be delegated to the current 3GPP
architecture, where the controller can also configure and update PCRF with a set of its
security policies. The policies can be retrieved by the CES node, cached and reused
when needed. The principle of allowing a subscriber to modify its policy within a given
contract or license will be that it can always make policies of its users, hosts or services
more restrictive. For example, the subscriber could limit the access to a “Payroll” server
only to a set of devices that can provide an identity defined in the policy.
The idea is that by executing the flow level policies in the control plane of a CES node,
residing in the cloud, we can provide per‐host or per‐service firewalling. In the context
of cellular networks, the security policy management can be seen as an extension of the
3GPP policy management architecture, which has so far focused on the Quality of
Service policies.
9.3.4 CES Security Mechanisms
CES provides several policy‐controlled mechanisms for establishing flow legitimacy,
such as negotiation of a variety of ID types, return‐routability checks, proof‐of‐work
mechanisms and the use of secure locators. The mechanisms enable CES to identify the
sender and its network on a required level of assurance. For this, CES eliminates
In case a prior trust does not exist between the CES nodes, a CES‐to‐CES level nego‑
tiation of policies precedes the host‐to‐host policy negotiation in step‐2. The aim of
CES policies is to negotiate network‐layer capabilities, and to achieve the trust between
networks. This includes elimination of the classical internet weaknesses, such as source
address spoofing, and hence establishing grounds for putting blame on the remote net‑
work or its hosts, in case a misbehaviour is detected or reported. We discuss these CES
policies and corresponding security mechanisms briefly in Section 9.3.4.
9.3.3 Policy Architecture
All aspects of communication in CES are governed by policy. For example, CES‐level
policy defined by a network administrator is concerned with establishing trust between
CES networks, besides guiding other aspects of CES‐to‐CES signalling, such as coop‑
erative firewalling and reputation handling. Similarly, all the host, service or application‐
level communications are governed by the corresponding policies defined by the end
users or its subscriptions within constraints agreed with the corporate network admin,
the eyeball ISP or the mobile operator.
The policy creation can be based on business contracts or software licenses. Examples
of such business contracts include subscription to ISP or mobile operator; purchase of
mobile network packages and services; or outsourcing contracts between firms or
between the firms and the consumers. In order to produce executable policies for a CES
node, there is a need to leverage information in different data repositories, such as
mobile application stores, trusted electronic contracting services, security vendor data‑
bases and company level security policy databases, at both the CES and host level. In
addition, the CES nodes need to leverage the black, grey and white lists dynamically
maintained by the trust domain.
To use policy architecture in the context of mobile networks, CES would, for example,
use a Diameter client that can query HSS for mobile issued identities. The storage and
management of policies for hosts and applications can be delegated to the current 3GPP
architecture, where the controller can also configure and update PCRF with a set of its
security policies. The policies can be retrieved by the CES node, cached and reused
when needed. The principle of allowing a subscriber to modify its policy within a given
contract or license will be that it can always make policies of its users, hosts or services
more restrictive. For example, the subscriber could limit the access to a “Payroll” server
only to a set of devices that can provide an identity defined in the policy.
The idea is that by executing the flow level policies in the control plane of a CES node,
residing in the cloud, we can provide per‐host or per‐service firewalling. In the context
of cellular networks, the security policy management can be seen as an extension of the
3GPP policy management architecture, which has so far focused on the Quality of
Service policies.
9.3.4 CES Security Mechanisms
CES provides several policy‐controlled mechanisms for establishing flow legitimacy,
such as negotiation of a variety of ID types, return‐routability checks, proof‐of‐work
mechanisms and the use of secure locators. The mechanisms enable CES to identify the
sender and its network on a required level of assurance. For this, CES eliminates