Maintaining up-to-date KVM hypervisors requires regular upgrades to the host kernel, hence rebooting the physical host with the consequent termination of running Virtual Machines (VMs). Cloud platforms capable of massive large-scale live migrations evacuate VMs from the hosts before rebooting, minimizing the impact over VM up-time. However, scenarios exist where resource constraints make live migration undesirable, or the presence of fault-tolerant instances (e.g., replicated services) favors the adoption of VM termination, a simpler but more disruptive strategy. In this article, we present Hy-FiX, a fast in-place upgrade solution for KVM hypervisors. Hy-FiX preserves VM memory across host reboots, protecting the execution state of running guests while hypervisor upgrades are applied. Hy-FiX memory preservation across reboot, combined with a mixed suspend-to-disk/suspend-to-RAM technique, achieves a 2.31-second checkpoint/restore time for a 256 GB VM, and Hy-FiX lazy memory initialization reboots an enterprise-class host in constant time (7.6 seconds) regardless of its equipped memory. Hy-FiX is, therefore, a better alternative to classical VM termination and restart.

Hypervisors are critical components in cloud data centers. Maintaining up-to-date KVM hypervisors requires replacing the host kernel, hence rebooting the physical host with consequent termination of running virtual machines (VMs). We introduce Hy-FiX, an in-place upgrade tool for KVM hypervisors that applies host kernel and/or user-space components upgrades while transparently preserving running VMs, constituting a better alternative for platforms where VMs are inevitably terminated and restarted.

In Data Centers (DCs), an abundance of virtual machines (VMs) remain idle due to network services awaiting for incoming connections, or due to established-and-idling sessions. These VMs lead to wastage of RAM - the scarcest resource in DCs - as they lock their allocated memory. In this paper, we introduce SEaMLESS, a solution designed to (i) transform fully-fledged idle VMs into lightweight and resourceless virtual network functions (VNFs), then (ii) reduces the allocated memory to those idle VMs. By replacing idle VMs with VNFs, SEaMLESS provides fast VM restoration upon user activity detection, thereby introducing limited impact on the Quality of Experience (QoE). Our results show that SEaMLESS can consolidate hundreds of VMs as VNFs onto one single machine. SEaMLESS is thus able to release the majority of the memory allocated to idle VMs. This freed memory can then be reassigned to new VMs, or lead to massive consolidation, to enable a better utilization of DC resources.

Idle virtual machines (VMs) are a waste of resources in data centers. We introduce SEaMLESS, which transforms a fully-Hedged idle VM into a lightweight and resourceless Virtual Network Function (VNF). Idle VMs can then be saved to disk and release their memory. Simultaneously, the VNF provides service availability. Upon user activity, the appropriate VM is restored, without introducing any interruption for service users. Tens of VNFs can be contained within the same memory space required for one single VM, thereby facilitating ample resources savings when scaled up to a data center.

The detection of BGP prefix hijacking attacks has been the focus of research for more than a decade. However, the state-of-the-art techniques fall short of detecting more elaborate types of attack. To study such attacks, we devise a novel formalization of Internet routing, and apply this model to routing anomalies in order to establish a comprehensive attacker model. We use this model to precisely classify attacks and to evaluate their impact and detectability. We analyze the eligibility of attack tactics that suit an attacker's goals and demonstrate that related work mostly focuses on less impactful kinds of attacks. We further propose, implement, and test the Hijacking Event Analysis Program (HEAP), a new approach to investigate hijacking alarms. Our approach is designed to seamlessly integrate with the previous work in order to reduce the high rates of false alarms inherent to these techniques. We leverage several unique data sources that can reliably disprove malicious intent. First, we make use of an Internet routing registry to derive business or organizational relationships between the parties involved in an event. Second, we use a topology-based reasoning algorithm to rule out events caused by legitimate operational practice. Finally, we use Internet-wide network scans to identify SSL/TLS-enabled hosts, which helps to identify non-malicious events by comparing public keys prior to and during an event. In our evaluation, we prove the effectiveness of our approach, and show that day-to-day routing anomalies are harmless for the most part. More importantly, we use HEAP to assess the validity of publicly reported alarms. We invite researchers to interface with HEAP in order to crosscheck and narrow down their hijacking alerts.

BGP hijacking is a well known threat to the Internet routing infrastructure. There has been considerable interest in developing tools that detect prefix hijacking but such systems usually identify a large number of events, many of them being due to some benign BGP engineering practice or misconfiguration. Ramachandran et al. [1] and later Hu et al. [2] also correlated suspicious routing events with spam and claimed to have found evidence of spammers temporarily stealing prefixes to send spam. In an effort to study at large scale the existence and the prevalence of malicious BGP hijacks in the Internet we developed a system which (i) identifies hijacks using BGP, traceroute and IRR data and (ii) investigates traffic originating from the reported networks with spam and netflow data. In this paper we present a real case where suspicious BGP announcements coincided with spam and web scam traffic from corresponding networks. Through this case study we show that a correlation of suspicious routing events with malicious activities is insufficient to evidence harmful BGP hijacks. We thus question previously reported cases and conclude that identifying malicious BGP hijacks requires additional data sources as well as feedback from network owners in order to reach decisive conclusions.