Customer Edge Switching: A Security Framework for 5G 205
the user‐generated data related to a host‐to‐host session is tunnelled across networks
using session tags agreed in the policy negotiation.
Under the premise of trust between networks, when a misbehaviour (or attack) is
observed in a host session, the misbehaving host could be reported to the remote net‑
work and cooperative firewalling will lead to its filtering close to the source network.
Naturally, the effectiveness of cooperative firewalling to filter the attacks will increase as
more and more networks adopt the CES firewall. If the remote CES node does not
cooperate, the CES node of the victim can send evidence to trust processing at GTO,
which can blacklist the remote CES everywhere for a time.
A possible result of deploying a CES node as gateway to the rest of the network blurs
the boundary between closed private networking and open style Internet networking.
In addition, for the case of closed and secure networking, all the logic resides at network
edge (additional logic may be executed at the end host), while the network core does not
need to be burdened with numerous virtual network routing tables as in the case of
BGP supported VPNs.
9.3.1 DNS to Initiate Communication
In an Internet where default gateways will be replaced largely by CES nodes, most hosts
will have just a private address, and the legacy interworking methods such as NATs and
RGW will grant connectivity to and from legacy hosts. The use of private addressing,
which could be assigned dynamically by DHCP servers, requires that a host also has a
rather stable globally unique identity. It is natural to resort to the use of Fully Qualified
Domain Names (FQDN) for identifying hosts, as well as the services running on
the hosts.
As a result, the CES architecture is tightly coupled with the use of Domain Name
System (DNS), such that hosts initiating the communication are required to issue DNS
queries for FQDN of the destination hosts. The use of DNS makes it possible for CES to
decouple the endpoint FQDN identifier from the advertised routing locator for
destination. Consequently, the CES system maintains a delegated DNS zone of author‑
ity with the records of the served hosts, that is, to respond to the DNS queries for the
served domains.
The DNS query for a host FQDN also triggers a phase of CETP service discovery,
which precedes the CES‐to‐CES policy negotiation. The service discovery process is
triggered by DNS query from an outbound CES (oCES) node, and determines whether
the destination is behind another CES and the proper course of action to reach it. The
procedure relies on the standard Naming Authority Pointer (NAPTR) [11] DNS queries
to ascertain the CETP service on the remote edge. An example of a valid NAPTR
response offered by an inbound CES (iCES) node is as follows:
b.nwb.ces. 40 IN NAPTR 20 6 “U” “CETP + cesid”
“!^(.*)$!cesid:1 = nwb.ces.?ip = 182.3.2.55?alias = GRX!”.
the user‐generated data related to a host‐to‐host session is tunnelled across networks
using session tags agreed in the policy negotiation.
Under the premise of trust between networks, when a misbehaviour (or attack) is
observed in a host session, the misbehaving host could be reported to the remote net‑
work and cooperative firewalling will lead to its filtering close to the source network.
Naturally, the effectiveness of cooperative firewalling to filter the attacks will increase as
more and more networks adopt the CES firewall. If the remote CES node does not
cooperate, the CES node of the victim can send evidence to trust processing at GTO,
which can blacklist the remote CES everywhere for a time.
A possible result of deploying a CES node as gateway to the rest of the network blurs
the boundary between closed private networking and open style Internet networking.
In addition, for the case of closed and secure networking, all the logic resides at network
edge (additional logic may be executed at the end host), while the network core does not
need to be burdened with numerous virtual network routing tables as in the case of
BGP supported VPNs.
9.3.1 DNS to Initiate Communication
In an Internet where default gateways will be replaced largely by CES nodes, most hosts
will have just a private address, and the legacy interworking methods such as NATs and
RGW will grant connectivity to and from legacy hosts. The use of private addressing,
which could be assigned dynamically by DHCP servers, requires that a host also has a
rather stable globally unique identity. It is natural to resort to the use of Fully Qualified
Domain Names (FQDN) for identifying hosts, as well as the services running on
the hosts.
As a result, the CES architecture is tightly coupled with the use of Domain Name
System (DNS), such that hosts initiating the communication are required to issue DNS
queries for FQDN of the destination hosts. The use of DNS makes it possible for CES to
decouple the endpoint FQDN identifier from the advertised routing locator for
destination. Consequently, the CES system maintains a delegated DNS zone of author‑
ity with the records of the served hosts, that is, to respond to the DNS queries for the
served domains.
The DNS query for a host FQDN also triggers a phase of CETP service discovery,
which precedes the CES‐to‐CES policy negotiation. The service discovery process is
triggered by DNS query from an outbound CES (oCES) node, and determines whether
the destination is behind another CES and the proper course of action to reach it. The
procedure relies on the standard Naming Authority Pointer (NAPTR) [11] DNS queries
to ascertain the CETP service on the remote edge. An example of a valid NAPTR
response offered by an inbound CES (iCES) node is as follows:
b.nwb.ces. 40 IN NAPTR 20 6 “U” “CETP + cesid”
“!^(.*)$!cesid:1 = nwb.ces.?ip = 182.3.2.55?alias = GRX!”.