Customer Edge Switching: A Security Framework for 5G 219
carries 25% FQDN and 75% SFQDN queries; and in Test‐4, 100% of the inbound queries
are SFQDN. We stress RGW with these traffic patterns from legitimate clients at a
constant rate of 4 requests per second. The connection load is distributed between the
private domains located in RGW.
In parallel to the client DNS queries, we trigger a network scan of 40 SYNs/sec from
the legacy hosts to CPPA addresses. The figure reveals that for Test1, FQDN initiations
only, nearly all the connections are hijacked. This is because the hacker is constantly
scanning the CPPA at a high rate and would overtake the allocation of a legitimate host
when its packet meets the end‐point independent state. However, as the share of
SFQDN grows and reaches 100% in total inbound DNS queries, the ratio of hijacked
connections starts declining to zero (for an all SFQDN traffic in Test‐4). This is because,
besides scanning for the allotted public IP addresses, the attacker also has to scan
through the whole port number space (2
16
) to compromise an allocation. As a result, the
hijacking of host allocations drops and legitimate users do not face disruptions or DoS.
We present our evaluation of the DNS query types and contribution of SFQDN on a
circular pool of 4 and 6 addresses, denoted by C4 and C6 in Figure 9.9. Note that this
result applies to the case where the hacker has no prior knowledge nor can the hacker
guess which port and protocol is being used. This may apply, for example, when one
admin can control both the legitimate client and the server.
Next, we evaluate the RGW security against the unwanted flows and network scans
that might originate from spoofed or non‐spoofed sources. RGW employs TCP‐Splice
to filter the risks from spoofed flows. Our testing revealed that spoofed flows (i.e. TCP
SYNs) failed to compromise an allocation of a valid client. This was due to the SYN
cookie mechanism, which admits a flow only after the spoofing is eliminated, in the
next inbound TCP ACK segment. In terms of performance, this limits the reusability of
the public IP address (and the port combination) by the same duration for the next
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
Connection percentage
0
C4.1
C4.2
RGW security vs (Network and port) scan attack
C4.3
Hijacked connections
Successful connections
C4.4
C6.1
C6.2
C6.3
C6.4
Circular pool Address space & Test Number (Cn. Tm)
Figure 9.9 Impact of inbound DNS query type (SFQDN) against versus network/ports scans.
carries 25% FQDN and 75% SFQDN queries; and in Test‐4, 100% of the inbound queries
are SFQDN. We stress RGW with these traffic patterns from legitimate clients at a
constant rate of 4 requests per second. The connection load is distributed between the
private domains located in RGW.
In parallel to the client DNS queries, we trigger a network scan of 40 SYNs/sec from
the legacy hosts to CPPA addresses. The figure reveals that for Test1, FQDN initiations
only, nearly all the connections are hijacked. This is because the hacker is constantly
scanning the CPPA at a high rate and would overtake the allocation of a legitimate host
when its packet meets the end‐point independent state. However, as the share of
SFQDN grows and reaches 100% in total inbound DNS queries, the ratio of hijacked
connections starts declining to zero (for an all SFQDN traffic in Test‐4). This is because,
besides scanning for the allotted public IP addresses, the attacker also has to scan
through the whole port number space (2
16
) to compromise an allocation. As a result, the
hijacking of host allocations drops and legitimate users do not face disruptions or DoS.
We present our evaluation of the DNS query types and contribution of SFQDN on a
circular pool of 4 and 6 addresses, denoted by C4 and C6 in Figure 9.9. Note that this
result applies to the case where the hacker has no prior knowledge nor can the hacker
guess which port and protocol is being used. This may apply, for example, when one
admin can control both the legitimate client and the server.
Next, we evaluate the RGW security against the unwanted flows and network scans
that might originate from spoofed or non‐spoofed sources. RGW employs TCP‐Splice
to filter the risks from spoofed flows. Our testing revealed that spoofed flows (i.e. TCP
SYNs) failed to compromise an allocation of a valid client. This was due to the SYN
cookie mechanism, which admits a flow only after the spoofing is eliminated, in the
next inbound TCP ACK segment. In terms of performance, this limits the reusability of
the public IP address (and the port combination) by the same duration for the next
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
Connection percentage
0
C4.1
C4.2
RGW security vs (Network and port) scan attack
C4.3
Hijacked connections
Successful connections
C4.4
C6.1
C6.2
C6.3
C6.4
Circular pool Address space & Test Number (Cn. Tm)
Figure 9.9 Impact of inbound DNS query type (SFQDN) against versus network/ports scans.