Kabir, Kantola, and Llorente Santos
222
Figure 9.12 shows security of SFQDN allocations against an advanced hacker. It is per‑
tinent to mention that in our testing, no state allocation is compromised by spoofed flows.
However, before a non‑spoofed flood is mitigated, some of its packets can beat a legiti‑
mate host in claiming the allocated state, causing DoS to the actual client. Thus the
security of RGW can exhibit false negatives during attack. However, these false nega‑
tives reduce as the attack progresses, since the active bots will be filtered upon exceed‑
ing the Bot‑detection threshold. The ratio of false negatives can further reduce by:
1) proper dimensioning of the network that presents more opportunities for a hacker
to meet the detection threshold; or
2) by building and employing reputation of the source addresses.
Though our testing identified few false negatives, RGW did not exhibit any false
positives, that is, classifying a valid client as attacker. We argue that in the RGW
networks, a false negative is not as severe as a false positive; since a client that suffers
hijacks can always re‐attempt to access the service hosted in the private realm.
The use of TCP‐Splice together with the Bot‐detection method aims to protect RGW
against abuses from spoofed and non‐spoofed sources, respectively, and hence ensure
that only a valid client is admitted to the private network. A new version of our proto‑
type is to consider replacing TCP‐Splicing with the SYN proxy for improved perfor‑
mance of the prototype. Table 9.3 presents an overview of the implemented mechanisms
for securing RGW against typical Internet abuses, their contribution to security and
impact on the RGW performance.
9.5 Deployment in 5G Networks
The principle is that each network administrator, mobile operator or ISP makes inde‑
pendent CES deployment decisions. The deployment of CES can take place one stub
network at a time, since it supports the RGW functions for interoperability with the
legacy networks.
Table 9.3 Security mechanisms and their performance.
Security threats
Mechanisms
Cost of Security
Outcome
Source address
spoofing
TCP‐Splice
Extends duration of
assigning the half‐state
Spoofing eliminated
Bot‐controlled
flows
Bot‐detection
Processing delay
Possible False
Negatives
Malformed ACK
segments
SYN cookie verification
Verification cost
(<0.01 ms)
Malformed ACKs
filtered
Spoofed DNS
requests
DNS/TCP, DNS Relay
and Ingress filtering
Slow first DNS
resolution due to TCP
connection
Spoofing eliminated
DNS‐floods
Address allocation model
Rate limitations
Server reputation
Server tracking
Less trusted servers
face congestion,
under load
222
Figure 9.12 shows security of SFQDN allocations against an advanced hacker. It is per‑
tinent to mention that in our testing, no state allocation is compromised by spoofed flows.
However, before a non‑spoofed flood is mitigated, some of its packets can beat a legiti‑
mate host in claiming the allocated state, causing DoS to the actual client. Thus the
security of RGW can exhibit false negatives during attack. However, these false nega‑
tives reduce as the attack progresses, since the active bots will be filtered upon exceed‑
ing the Bot‑detection threshold. The ratio of false negatives can further reduce by:
1) proper dimensioning of the network that presents more opportunities for a hacker
to meet the detection threshold; or
2) by building and employing reputation of the source addresses.
Though our testing identified few false negatives, RGW did not exhibit any false
positives, that is, classifying a valid client as attacker. We argue that in the RGW
networks, a false negative is not as severe as a false positive; since a client that suffers
hijacks can always re‐attempt to access the service hosted in the private realm.
The use of TCP‐Splice together with the Bot‐detection method aims to protect RGW
against abuses from spoofed and non‐spoofed sources, respectively, and hence ensure
that only a valid client is admitted to the private network. A new version of our proto‑
type is to consider replacing TCP‐Splicing with the SYN proxy for improved perfor‑
mance of the prototype. Table 9.3 presents an overview of the implemented mechanisms
for securing RGW against typical Internet abuses, their contribution to security and
impact on the RGW performance.
9.5 Deployment in 5G Networks
The principle is that each network administrator, mobile operator or ISP makes inde‑
pendent CES deployment decisions. The deployment of CES can take place one stub
network at a time, since it supports the RGW functions for interoperability with the
legacy networks.
Table 9.3 Security mechanisms and their performance.
Security threats
Mechanisms
Cost of Security
Outcome
Source address
spoofing
TCP‐Splice
Extends duration of
assigning the half‐state
Spoofing eliminated
Bot‐controlled
flows
Bot‐detection
Processing delay
Possible False
Negatives
Malformed ACK
segments
SYN cookie verification
Verification cost
(<0.01 ms)
Malformed ACKs
filtered
Spoofed DNS
requests
DNS/TCP, DNS Relay
and Ingress filtering
Slow first DNS
resolution due to TCP
connection
Spoofing eliminated
DNS‐floods
Address allocation model
Rate limitations
Server reputation
Server tracking
Less trusted servers
face congestion,
under load