Kabir, Kantola, and Llorente Santos
218
Besides admitting connections based on FQDN queries of the served hosts, RGW
also allows connections towards a service running on the end host, using a service‐
FQDN (SFQDN). The use of SFQDN allows CPPA to make a more specific address
allocation that binds the port number and protocol of the service to the allocated IP
address. This makes it possible to reuse a public IP address from the pool for any com‑
bination of the port (2
16
) and transport protocol (i.e. UDP and TCP). As a result, the
scalability of CPPA improves and it becomes more difficult to enforce the blocking state
on CPPA. In this case, the CPPA intermediate state is port‐ and protocol‐dependent but
endpoint agnostic. In practice, the upper bound of CPPA scalability is determined
by the most popular service that leads to the allocation of a new circular pool address
for the already reserved port and protocol combination. Our work in [20] further dis‑
cusses the scalability due to use of SFQDN.
Our testing shows that a resource depletion attack using SFQDN is more challenging.
This is because it now requires a high‐rate DNS flood to constantly force CPPA into a
blocking state, where the CPPA would be reserved for all the combination of its public IP
addresses, ports and protocols. Such a high rate of flood makes it easier to detect the attack
and to grey‐ or blacklist the server that is constantly serving the DNS flood. Moreover, the
rate limits on simultaneous domain queries from a DNS server also hinders the attacker’s
ability to launch floods from a few named servers or open resolvers, for long durations.
The more specific address allocation due to SFQDN also hardens RGW against
malicious flows from spoofed and non‐spoofed addresses, which aim to hijack the
valid user connections. This is because besides the public address, a hacker also has to
target the correct port and protocol to compromise the state allocated to a user. This
is in contrast to general‐purpose FQDN query where IP address allocation is not
restricted to a port or transport protocol, and thus applies end‐point independent
filtering relative to the client.
For the purpose of testing, we forward different concentrations of DNS queries that
include both FQDN and SFQDN towards RGW. Traffic patterns: Test‐1 carries 100%
FQDN traffic towards RGW; Test‐2 carries 50% FQDN and 50% SFQDN queries; Test‐3,
100
90
80
70
60
50
40
30
20
10
0
0.5
1
1.5
2
2.5
Time (in seconds)
3.5
4
3
0
Load (in % of circular pool addresses)
Result of ratelimiting greylist DNS traffic
Greylist DNS traffic before allocation model
Figure 9.8 Tackling DNS flood towards RGW.
218
Besides admitting connections based on FQDN queries of the served hosts, RGW
also allows connections towards a service running on the end host, using a service‐
FQDN (SFQDN). The use of SFQDN allows CPPA to make a more specific address
allocation that binds the port number and protocol of the service to the allocated IP
address. This makes it possible to reuse a public IP address from the pool for any com‑
bination of the port (2
16
) and transport protocol (i.e. UDP and TCP). As a result, the
scalability of CPPA improves and it becomes more difficult to enforce the blocking state
on CPPA. In this case, the CPPA intermediate state is port‐ and protocol‐dependent but
endpoint agnostic. In practice, the upper bound of CPPA scalability is determined
by the most popular service that leads to the allocation of a new circular pool address
for the already reserved port and protocol combination. Our work in [20] further dis‑
cusses the scalability due to use of SFQDN.
Our testing shows that a resource depletion attack using SFQDN is more challenging.
This is because it now requires a high‐rate DNS flood to constantly force CPPA into a
blocking state, where the CPPA would be reserved for all the combination of its public IP
addresses, ports and protocols. Such a high rate of flood makes it easier to detect the attack
and to grey‐ or blacklist the server that is constantly serving the DNS flood. Moreover, the
rate limits on simultaneous domain queries from a DNS server also hinders the attacker’s
ability to launch floods from a few named servers or open resolvers, for long durations.
The more specific address allocation due to SFQDN also hardens RGW against
malicious flows from spoofed and non‐spoofed addresses, which aim to hijack the
valid user connections. This is because besides the public address, a hacker also has to
target the correct port and protocol to compromise the state allocated to a user. This
is in contrast to general‐purpose FQDN query where IP address allocation is not
restricted to a port or transport protocol, and thus applies end‐point independent
filtering relative to the client.
For the purpose of testing, we forward different concentrations of DNS queries that
include both FQDN and SFQDN towards RGW. Traffic patterns: Test‐1 carries 100%
FQDN traffic towards RGW; Test‐2 carries 50% FQDN and 50% SFQDN queries; Test‐3,
100
90
80
70
60
50
40
30
20
10
0
0.5
1
1.5
2
2.5
Time (in seconds)
3.5
4
3
0
Load (in % of circular pool addresses)
Result of ratelimiting greylist DNS traffic
Greylist DNS traffic before allocation model
Figure 9.8 Tackling DNS flood towards RGW.