Kabir, Kantola, and Llorente Santos
212
Since RGW relies on standard inbound DNS resolutions, it does not require any changes
in the current hosts, protocols or applications to support its adoption. The adoption of
RGW is transparent to the end hosts, and limits all the changes to edge nodes, allowing
the adoption of the technology in the edge networks with minimal disturbance.
9.3.6 RGW Security Mechanisms
RGW could be susceptible to the inherent Internet weaknesses, such as:
1) the DNS abuse and source address spoofing. For example, a DNS flood to FQDNs of
the private hosts (via open DNS Resolvers, i.e. GoogleDNS) can force the CPPA into
DoS, by reserving all the addresses in the CPPA. As a result, the RGW would be
unable to accept new inbound DNS requests and corresponding connections.
2) Hackers can also send the malicious traffic from spoofed addresses or botnets to
claim a connection state reserved by a legitimate user. This would lead to DoS to the
legitimate user of the service and would also leak unwanted traffic into the private
network. It is pertinent to mention that the already established connections are not
vulnerable to these abuses, instead only new inbound connections are affected.
RGW adheres to a set of principles to effectively tackle the impact of these inherent
Internet weaknesses:
a) UDP flow initiations are admitted after the connection was signalled through a
secure channel, e.g. SIP(S) [16];
b) flow acceptance is limited to verifiable sources only;
c) under network stress, resource access is granted based on the source reputation;
d) the security mechanisms shall limit all the changes to the edge network.
Although it is possible to take a clean‐slate approach and design an architecture free
of security weaknesses, we take the deployment constraints as a cornerstone of our
design and thus lay special emphasis on the last rule. Adhering to these principles, we
define the following mechanisms to tackle the threats to RGW communications.
9.3.6.1 Name Server Classification and Allocation Model
RGW classifies the public name servers into white, grey and black lists. Servers in
each category are treated differently by RGW. A DNS server can be white‐listed
based on the service‐level agreement (SLA) with the remote network; or if it
executes ingress filtering and indicates the source of DNS query, for example in
DNS extensions or Additional records, or if it meets some other pre‐conditions. By
default, the rest of the name servers have grey‐listed and ‐non‐priority access to
RGW resources. The name servers are constantly monitored and dynamically
redefined into white, grey or black lists based on the influx of the attack traffic.
For example, a server that repeatedly exceeds its SLA is penalized with a degraded
service and serves the time penalty.
In addition, RGW employs a CPPA address allocation model that rate‐limits the
number of simultaneous queries from a DNS server or towards a host. The model limits
greylist requests to a portion of the circular pool, and under network stress prefers
address allocation to white‐list servers, and thus assures that whitelist servers always
have resources to their disposal.
212
Since RGW relies on standard inbound DNS resolutions, it does not require any changes
in the current hosts, protocols or applications to support its adoption. The adoption of
RGW is transparent to the end hosts, and limits all the changes to edge nodes, allowing
the adoption of the technology in the edge networks with minimal disturbance.
9.3.6 RGW Security Mechanisms
RGW could be susceptible to the inherent Internet weaknesses, such as:
1) the DNS abuse and source address spoofing. For example, a DNS flood to FQDNs of
the private hosts (via open DNS Resolvers, i.e. GoogleDNS) can force the CPPA into
DoS, by reserving all the addresses in the CPPA. As a result, the RGW would be
unable to accept new inbound DNS requests and corresponding connections.
2) Hackers can also send the malicious traffic from spoofed addresses or botnets to
claim a connection state reserved by a legitimate user. This would lead to DoS to the
legitimate user of the service and would also leak unwanted traffic into the private
network. It is pertinent to mention that the already established connections are not
vulnerable to these abuses, instead only new inbound connections are affected.
RGW adheres to a set of principles to effectively tackle the impact of these inherent
Internet weaknesses:
a) UDP flow initiations are admitted after the connection was signalled through a
secure channel, e.g. SIP(S) [16];
b) flow acceptance is limited to verifiable sources only;
c) under network stress, resource access is granted based on the source reputation;
d) the security mechanisms shall limit all the changes to the edge network.
Although it is possible to take a clean‐slate approach and design an architecture free
of security weaknesses, we take the deployment constraints as a cornerstone of our
design and thus lay special emphasis on the last rule. Adhering to these principles, we
define the following mechanisms to tackle the threats to RGW communications.
9.3.6.1 Name Server Classification and Allocation Model
RGW classifies the public name servers into white, grey and black lists. Servers in
each category are treated differently by RGW. A DNS server can be white‐listed
based on the service‐level agreement (SLA) with the remote network; or if it
executes ingress filtering and indicates the source of DNS query, for example in
DNS extensions or Additional records, or if it meets some other pre‐conditions. By
default, the rest of the name servers have grey‐listed and ‐non‐priority access to
RGW resources. The name servers are constantly monitored and dynamically
redefined into white, grey or black lists based on the influx of the attack traffic.
For example, a server that repeatedly exceeds its SLA is penalized with a degraded
service and serves the time penalty.
In addition, RGW employs a CPPA address allocation model that rate‐limits the
number of simultaneous queries from a DNS server or towards a host. The model limits
greylist requests to a portion of the circular pool, and under network stress prefers
address allocation to white‐list servers, and thus assures that whitelist servers always
have resources to their disposal.