Customer Edge Switching: A Security Framework for 5G 213
9.3.6.2 Preventing DNS Abuse
Remote DNS servers can also connect to the RGW via a TCP connection, which pro‑
vides a spoofing‐free channel. The mechanism can be employed as a part of whitelisting
a DNS server. Together with DNS extensions or additional records that identify the
source of DNS query, it is possible to trace an aggressive host and rate‐limit it.
The deployment of RGW in hierarchal fashion with the serving‐ISP also provides an
opportunity to protect the DNS leaf node against attacks. This is possible due to a DNS
Relay function that acts as a front end and prevents RGW from direct exposure to the
inbound DNS queries. The relay function allows a separation of concerns and makes
possible to delegate the security against DNS abuses to a dedicated entity that
can independently leverage best practices in tackling the DNS abuse, and thus only
forwards legitimate traffic to RGW.
9.3.6.3 Bot‐Detection Algorithm
The arrival of the first packet of a flow, that is, TCP SYN that does not correspond to con‑
nection state is monitored for hacking activity. Once such mismatching packets exceed a
threshold in an observed duration, Bot‐detection can process the subsequent mismatch‑
ing packets to determine if the sender is not spoofed. A non‐spoofing check together with
the history of misbehavior leads to blacklisting of the sender in RGW, where it undergoes
a time penalty during which its connection initiations, that is, TCP SYNs, are dropped.
9.3.6.4 TCP‐Splice
To tackle the problem of spoofing in Internet originated connections, RGW may chal‑
lenge the sender of TCP SYN with a cookie embedded in the Initial Sequence Number
(ISN) [17] of the SYN/ACK segment. If the TCP handshake completes, we ascertain
authenticity of the sender as non‐spoofed and accept the connection. The subsequent
data packets are forwarded in compliance with TCP‐splicing technique. However,
a packet from a blacklisted source is dropped to prevent the connection hijacking.
A source can be blacklisted following the Bot‐detection algorithm. The Bot‐detection
method together with the TCP‐Splice aims to filter unwanted traffic from both the
spoofed and non‐spoofed sources.
CES provides these mechanisms as policy‐controlled features for network administrators.
The mechanisms contribute to establish safer connections from the legacy Internet towards
the private network. They protect RGW from hazardous effects of the most common
Internet weaknesses and facilitate the deployment of RGW in Internet networks.
9.4 Evaluation of CES Security
This section introduces the prototype network developed as CES proof‐of‐concept. We
define the key performance indicators (KPIs) for evaluating the CES prototype, and present
the performance evaluation as well as the results from security testing. Figure 9.6 presents
our CES testbed, which is implemented in the Linux environment and simulates the network
nodes using Linux containers, connected via standard Linux networking capabilities. The
architecture employs Ryu [18] as the SDN Controller, realizing the control plane, whereas
the data plane is implemented with OpenvSwitch, which enforces the rules generated by the
controller. The communication protocol between the planes is OpenFlow v1.3.
9.3.6.2 Preventing DNS Abuse
Remote DNS servers can also connect to the RGW via a TCP connection, which pro‑
vides a spoofing‐free channel. The mechanism can be employed as a part of whitelisting
a DNS server. Together with DNS extensions or additional records that identify the
source of DNS query, it is possible to trace an aggressive host and rate‐limit it.
The deployment of RGW in hierarchal fashion with the serving‐ISP also provides an
opportunity to protect the DNS leaf node against attacks. This is possible due to a DNS
Relay function that acts as a front end and prevents RGW from direct exposure to the
inbound DNS queries. The relay function allows a separation of concerns and makes
possible to delegate the security against DNS abuses to a dedicated entity that
can independently leverage best practices in tackling the DNS abuse, and thus only
forwards legitimate traffic to RGW.
9.3.6.3 Bot‐Detection Algorithm
The arrival of the first packet of a flow, that is, TCP SYN that does not correspond to con‑
nection state is monitored for hacking activity. Once such mismatching packets exceed a
threshold in an observed duration, Bot‐detection can process the subsequent mismatch‑
ing packets to determine if the sender is not spoofed. A non‐spoofing check together with
the history of misbehavior leads to blacklisting of the sender in RGW, where it undergoes
a time penalty during which its connection initiations, that is, TCP SYNs, are dropped.
9.3.6.4 TCP‐Splice
To tackle the problem of spoofing in Internet originated connections, RGW may chal‑
lenge the sender of TCP SYN with a cookie embedded in the Initial Sequence Number
(ISN) [17] of the SYN/ACK segment. If the TCP handshake completes, we ascertain
authenticity of the sender as non‐spoofed and accept the connection. The subsequent
data packets are forwarded in compliance with TCP‐splicing technique. However,
a packet from a blacklisted source is dropped to prevent the connection hijacking.
A source can be blacklisted following the Bot‐detection algorithm. The Bot‐detection
method together with the TCP‐Splice aims to filter unwanted traffic from both the
spoofed and non‐spoofed sources.
CES provides these mechanisms as policy‐controlled features for network administrators.
The mechanisms contribute to establish safer connections from the legacy Internet towards
the private network. They protect RGW from hazardous effects of the most common
Internet weaknesses and facilitate the deployment of RGW in Internet networks.
9.4 Evaluation of CES Security
This section introduces the prototype network developed as CES proof‐of‐concept. We
define the key performance indicators (KPIs) for evaluating the CES prototype, and present
the performance evaluation as well as the results from security testing. Figure 9.6 presents
our CES testbed, which is implemented in the Linux environment and simulates the network
nodes using Linux containers, connected via standard Linux networking capabilities. The
architecture employs Ryu [18] as the SDN Controller, realizing the control plane, whereas
the data plane is implemented with OpenvSwitch, which enforces the rules generated by the
controller. The communication protocol between the planes is OpenFlow v1.3.