Customer Edge Switching: A Security Framework for 5G 217
9.4.1.2 Outcomes of the Security Testing
The security testing shows that the CES security mechanisms can:
● eliminate risks from spoofed sources, due to possibility of exchanging CETP signal‑
ling on the underlying spoofing‐free protocols, i.e. TCP, TLS/TCP, IPSec;
● use of X.509 certificate allows authenticating a signalling source at network‐level
using CES‐level policy negotiation for trust establishment. This can happen both at
the level of underlying protocols or exclusively in CETP signalling;
● proof‐of‐work mechanism in CES pushes the burden of establishing trust to the
sender, and prevents CETP level floods towards CES at the signalling level;
● the elimination of spoofing and source authentication allows attributing the misbehav‑
ior at signalling or data‐connection level to the ID of the remote network and its host;
● the performance penalty (i.e. delay), introduced by security mechanisms to the
connection setup is minimal, and the mechanisms do not exhibit any false positives
or negatives.
Our implementation is in Python, and is open to further optimizations at the archi‑
tecture level, which could further reduce the session‐setup delay at processing level.
9.4.2 Evaluation of RGW Security
This section presents an evaluation of the RGW security mechanisms in tackling the
inherent Internet weaknesses. For this, we implemented the RGW security mechanisms
in our prototype, and subjected it to a set of Internet abuses, such as source address
spoofing, network/port scans and DNS floods from legacy Internet, to determine the
bounds of the RGW security.
We utilize Scapy [19] to craft malicious packets and to launch attacks on RGW. For
our testing, this enables legacy nodes in the testbed to initiate: i) spoofed traffic; or ii)
network floods from multiple sources (i.e. botnets). The legacy nodes use virtual net‑
work interfaces to provide an illustration of many hosts participating in the attack. The
attack load is measured in flows per second, whereas the network delay between the
nodes is artificially induced. The outcome of the testing reveals the effectiveness and
cost of the RGW security, in terms of the ratio of hijacked connections and processing
delay introduced in the prototype, respectively.
Figure 9.5 shows how legacy hosts can initiate connections towards RGW. As
described in Section 9.3.6, RGW can be susceptible to the abuse of DNS, address spoof‑
ing and connection hijacks. The goal of RGW security is to neutralize these abuses that
can otherwise force CPPA into a blocking state or launch DoS by hijacking connections
of legitimate clients.
First, we analysed the impact of DNS floods and the arrival of different DNS queries
on RGW. For this, we pre‐configure the whitelist servers in RGW, and submit it to a
DNS flood from multiple greylist sources. Figure 9.8 shows that without security, the
DNS flood could reserve all the CPPA resources and force RGW into blocking state. In
contrast, the address allocation model notes that the DNS source is greylisted and limits
the resource allocations for greylist servers to a portion of the circular pool. In this
manner, the allocation model prevents the exhaustion of CPPA under DNS floods, and
ensures that whitelist servers can access RGW, even under load/attack conditions.
Moreover, the rate limitation enforced by the address allocation model makes it difficult
to launch DoS by flooding through a single server.
9.4.1.2 Outcomes of the Security Testing
The security testing shows that the CES security mechanisms can:
● eliminate risks from spoofed sources, due to possibility of exchanging CETP signal‑
ling on the underlying spoofing‐free protocols, i.e. TCP, TLS/TCP, IPSec;
● use of X.509 certificate allows authenticating a signalling source at network‐level
using CES‐level policy negotiation for trust establishment. This can happen both at
the level of underlying protocols or exclusively in CETP signalling;
● proof‐of‐work mechanism in CES pushes the burden of establishing trust to the
sender, and prevents CETP level floods towards CES at the signalling level;
● the elimination of spoofing and source authentication allows attributing the misbehav‑
ior at signalling or data‐connection level to the ID of the remote network and its host;
● the performance penalty (i.e. delay), introduced by security mechanisms to the
connection setup is minimal, and the mechanisms do not exhibit any false positives
or negatives.
Our implementation is in Python, and is open to further optimizations at the archi‑
tecture level, which could further reduce the session‐setup delay at processing level.
9.4.2 Evaluation of RGW Security
This section presents an evaluation of the RGW security mechanisms in tackling the
inherent Internet weaknesses. For this, we implemented the RGW security mechanisms
in our prototype, and subjected it to a set of Internet abuses, such as source address
spoofing, network/port scans and DNS floods from legacy Internet, to determine the
bounds of the RGW security.
We utilize Scapy [19] to craft malicious packets and to launch attacks on RGW. For
our testing, this enables legacy nodes in the testbed to initiate: i) spoofed traffic; or ii)
network floods from multiple sources (i.e. botnets). The legacy nodes use virtual net‑
work interfaces to provide an illustration of many hosts participating in the attack. The
attack load is measured in flows per second, whereas the network delay between the
nodes is artificially induced. The outcome of the testing reveals the effectiveness and
cost of the RGW security, in terms of the ratio of hijacked connections and processing
delay introduced in the prototype, respectively.
Figure 9.5 shows how legacy hosts can initiate connections towards RGW. As
described in Section 9.3.6, RGW can be susceptible to the abuse of DNS, address spoof‑
ing and connection hijacks. The goal of RGW security is to neutralize these abuses that
can otherwise force CPPA into a blocking state or launch DoS by hijacking connections
of legitimate clients.
First, we analysed the impact of DNS floods and the arrival of different DNS queries
on RGW. For this, we pre‐configure the whitelist servers in RGW, and submit it to a
DNS flood from multiple greylist sources. Figure 9.8 shows that without security, the
DNS flood could reserve all the CPPA resources and force RGW into blocking state. In
contrast, the address allocation model notes that the DNS source is greylisted and limits
the resource allocations for greylist servers to a portion of the circular pool. In this
manner, the allocation model prevents the exhaustion of CPPA under DNS floods, and
ensures that whitelist servers can access RGW, even under load/attack conditions.
Moreover, the rate limitation enforced by the address allocation model makes it difficult
to launch DoS by flooding through a single server.