Pushback protocol performance

In this section we quantify the performance of the simple pushback protocol we devised: we run our experiments enabling nodes to rate limit the aggregate flow that contains the malicious flow using probabilistic rate limiting. The dropping probability is determined based on the deviation of the aggregate flow from the average making the flow conform to within δ from the measured average. Moreover, the node detecting the attack notified its corresponding incoming neighbor of the problem denoting also the sets of key(s) that were affected by this excessive aggregate flow. If the node was unresponsive to the rate limiting request for more than 100 packets (ı.e. the rate of the detected aggregate flow remained above the average) this node was immediately marked as malicious and was removed from the overlay by being replaced with a non-attacking node to avoid reconstruction of the overlay routing table. The selection of the 100 packet threshold is a parameter of our system and allows a little more time to the neighbor to adjust to the rate limiting request. It cannot be exploited by attackers since its too low to make a significant impact to the target server. The most important metric for the performance of our system is the additional load imposed on the attacked node. Figure7.11shows that the load imposed on that node during an attack for various attack intensities remains low, namely below 2 and when the percentage

Figure 7.11: Increase in server load when under attack and with pushback protocol activated. A load of value 2 means that the server is serving twice the amount of normal requests. The performance of the pushback protocol remains acceptable even when 15% of

the overlay nodes are attacking the target.

of the attackers is below 15%. If the fraction of the attacking nodes is increased beyond 15%, our system can only provide partial protection and the load of the server increases dramatically.

Figure 7.12 shows the total number of packets transmitted to the overlay network, this includes packets that traversed even one hop and then where dropped. Again, the performance of the system is not affected significantly by the attack even when 15% of the overlay nodes are subverted.

Figure 7.12: Total number of packets transmitted to the overlay network, this includes packets that traversed even one hop and then where dropped. Again, the performance of the

system is not affected significantly by the attack even when 15% of the overlay nodes are subverted.

Chapter 8

Our System in Practice: Access-Assured

Mobile Desktop Computing

8.1

Introduction

Using previously proposed DDoS protection mechanisms, such as SOS [91], Mayday [9] and Move [155] to protect access to a desktop service, hits a latency performance barrier: these systems cannot offer protection to time-critical or real-time applications, since they increase the end-to-end latency by more than 250% in some cases with high latency variance over time. For the large portion of the connected clients, the network latency performance degrades fast when these systems are under attack, since the clients have to detect this attack and re-establish their connections to different access points. To be of any practical use, interactive and real-time applications such as user GUI operations and multimedia streaming demand a low-latency pipe at all times.

Unfortunately, simply using existing DDoS protection mechanisms, such as SOS [91] and Mayday [9], to protect access to a desktop hosting service does not provide a viable solution. These systems cannot offer protection to interactive applications, as they increase end-to-end latency by up to 250%, with high latency variance over time. Furthermore, as

the infrastructure comes under attack, a large portion of the clients experience network latency performance degradation, as clients need to detect the attack and re-establish their connections to the hosting services using different access points. To be of any practical use, typical desktop interactive applications, such as UI interactions and multimedia streaming, demand a low-latency connection at all times. Caching of information to other nodes is not a solution since it requires vast amount of storage and network bandwidth. Additionally, it raises privacy concerns since the trust is moved to nodes, other than the originating center, that need to store and manage the cached information.

In this context, we introduce Access-Assured Mobile (A2_{M) desktop computing, a} hosted computing infrastructure that combines a remote-display architecture with a stateless indirection-based network (IBN) composed of dedicated nodes. A2_{M provides both protected} and efficient access to hosted desktop computing environments, even in the presence of denial of service attacks. Nodes participating in the IBN communicate only to exchange control messages, but not to route the client’s data, unlike previous overlay-based approaches [91,9, 155]. A2M clients exploit the path diversity naturally exhibited by a distributed IBN to “spread” their traffic such that directed attacks do not cause service disruptions. To further alleviate any potential delays introduced by the IBN and reduce the latency in the end-to-end communication, A2_{M uses a number of other optimizations at the remote} display level to minimize the impact these delays may have on the user’s experience. A2_M combines a simple low-level display protocol and a server-push model to minimize client- server synchronization and network round-trips. Atop this basic model, A2M implements higher-lever mechanisms, such as client-managed cursor display, shortest-job-first display command scheduling, and a non-blocking drawing pipeline, further increasing the overall interactive response of the system. We believe A2_{M to be the first demonstrably practical} overlay-based DDoS-protection mechanism.

A2_{M treats a connection from a client device to the server as having two parts: an} upstream/uplink data channel i.e., data transmitted from the client to the server, and a

downstream/downlink data channel, with data going to the client. A2M’s client-to-server traffic directly reflects its interactive nature, and can be characterized by small, fairly sparse upstream packets (sent by the client as a result of user-input events, TCP ACKs, etc.), with significantly larger downstream bursts of traffic containing the visual changes generated in response to the user’s events. By routing only the upstream data through the IBN, thus protecting the upstream data channel, A2M takes advantage of this traffic asymmetry to increase the resilience of the hosting infrastructure with minimum impact on the performance of the system (throughput and latency between client and server).

A2_{M achieves this by using the following two mechanisms. First, since DoS attacks only} congest the upstream link to the hosting servers, A2_{M only needs to protect delivery of the} relatively sparse client-to-server traffic. Second, to minimize the overhead that protecting traffic has on the performance of the system, A2_{M uses several mechanisms to reduce both} the quantity of upstream remote display traffic, and the effects additional delays may have on the overall performance of the system. We should note that A2M can protect both directions in a communication channel, albeit at the cost of increased end-to-end latency.

Client traffic admitted in the IBN is redirected to a special node or set of nodes (that change over time) and from there forwarded to the protected server. Only that node, which we call secret forwarder, is allowed to send traffic to the server; all other traffic is filtered by the ASP’s home ISP. The IBN is a distributed network of dedicated nodes that receive the traffic destined to the end server, discriminating between legitimate traffic and potentially malicious traffic, reflecting the former and dropping the latter. Thus, attacks aimed directly at the server will be stopped deep inside the ISP’s network, where congestion has not yet occurred. The distributed nature of the IBN means that it will take an extremely well provisioned adversary to suppress its functionality, since attack traffic must be split among all the IBN nodes. This approach provides a very desirable solution for A2_{M, because it has} very little latency overhead since the system introduces only two extra hops for each packet. In addition, A2M uses multi-path routing in the upstream, client-to-server direction, and

replicates packets in that relatively low-traffic stream to improve resilience as well as lower latency, while allowing packets in the server-to-client direction to follow regular routing paths. By exploiting multi-path routing for each replicated packet, the system can reduce the overall end-to-end latency to values that are, in some cases, even lower than the latency of the direct client-server connection, at the expense of extra bandwidth utilization.

We have implemented and deployed A2M on PlanetLab [133]. We measured the impact of our prototype on the end-to-end communication latency and throughput, and the resilience of the system under attack. Our results show that in all scenarios where we enable multi-path routing using packet replication, A2_{M imposes minimal overhead on the end-to-end latency,} even when the system is under attack. Furthermore, A2_{M significantly increases the attack} resilience of the hosting infrastructure, being able to operate optimally even when up to 50% of the indirection nodes have become unresponsive, and for different types of traffic between clients and the infrastructure (web traffic, video playback and GUI actions). In all the WAN experiments, end-to-end latency increases by less than 5% even when 40% of nodes have been compromised. Our experiments in a wireless network environment further demonstrate the effectiveness of A2_{M for truly mobile users using lightweight devices. Through a} simple quantitative model based on typical ISP interconnection topologies, we quantify the resilience of our IBN (and any indirection or overlay-based anti-DDoS mechanism).

To summarize, in this chapter we present the following contributions:

• We introduce and describe A2_{M, a single-hop indirection-based access infrastructure,} based on our previous work on packet spreading [154], that protects end-user access to remotely hosted interactive applications that require a low end-to-end network latency at all times to operate and for large indirection networks.

• We implement and evaluate A2_{M in the real Internet using PlanetLab. Our experiments} show that A2M introduces very little latency in most scenarios. In this context, the latency-sensitive design of A2M vastly outperforms existing overlay DDoS protection mechanisms, such as SOS [91], Mayday [9] and MOVE [155].

Figure 8.1:A2M Architecture. The two directions of the client-server connection take different paths: the client-to-server direction goes over the indirection-based network, while the server-to-client direction goes directly to the client (not through the infrastructure). Legitimate uplink traffic is spread among the IBN nodes and competes with denial of service traffic for capacity in the links close to the server; allowing legitimate traffic through the indirection system allows us to differentiate the two. Indirection nodes can simultaneously serve as system entry points and secret

forwarders, and are dedicated to this task (i.e., they are not end-user-controlled nodes).

• We are the first to conduct realistic (non-simulation) experiments to evaluate the resilience of our system against DDoS attacks, and its performance under attack. Our results validate the design of A2_{M, showing good performance for multimedia and} interactive applications even with 30%–50% of the IBN nodes under attack.