Biblio

When disasters occur, they not only affect the human life. Therefore, communication in disaster management is very important. During the disaster recovery phase, the network infrastructure may be partially fragmented and mobile rescue operations may involve many teams with different roles which can dynamically change. Therefore, disaster management services require high flexibility both in terms of network infrastructure management and rescue group communication. Existing studies have shown that IP-based or traditional telephony solutions are not well-suited to deal with such flexible group communication and network management due to their connection-oriented communication, no built-in support for mobile devices, and no mechanism for network fragmentation. Recent studies show that information-centric networking offers scalable and flexible communication based on its name-based interest-oriented communication approach. However, considering the difficulty of deploying a new service on the existing network, the programmability and virtualization of the network are required. This paper presents our implementation of an information-centric disaster management system based on network function virtualization (vICSNF). We show a proof-of-concept system with a case study for Seoul disaster management services. The system achieves flexibility both in terms of network infrastructure management and rescue group communication. Obtained testbed results show that vICSNF achieves a low communication overhead compared to the IP-based approach and the auto-configuration of vICSNFs enables the quick deployment for disaster management services in disaster scenarios.

Network adversaries, such as malicious transit autonomous systems (ASes), have been shown to be capable of partitioning the Bitcoin's peer-to-peer network via routing-level attacks; e.g., a network adversary exploits a BGP vulnerability and performs a prefix hijacking attack (viz. Apostolaki et al. [3]). Due to the nature of BGP operation, such a hijacking is globally observable and thus enables immediate detection of the attack and the identification of the perpetrator. In this paper, we present a stealthier attack, which we call the EREBUS attack, that partitions the Bitcoin network without any routing manipulations, which makes the attack undetectable to control-plane and even to data-plane detectors. The novel aspect of EREBUS is that it makes the adversary AS a natural man-in-the-middle network of all the peer connections of one or more targeted Bitcoin nodes by patiently influencing the targeted nodes' peering decision. We show that affecting the peering decision of a Bitcoin node, which is believed to be infeasible after a series of bug patches against the earlier Eclipse attack [29], is possible for the network adversary that can use abundant network address resources (e.g., spoofing millions of IP addresses in many other ASes) reliably for an extended period of time at a negligible cost. The EREBUS attack is readily available for large ASes, such as Tier-1 and large Tier-2 ASes, against the vast majority of 10K public Bitcoin nodes with only about 520 bit/s of attack traffic rate per targeted Bitcoin node and a modest (e.g., 5-6 weeks) attack execution period. The EREBUS attack can be mounted by nation-state adversaries who would be willing to execute sophisticated attack strategies patiently to compromise cryptocurrencies (e.g., control the consensus, take down a cryptocurrency, censor transactions). As the attack exploits the topological advantage of being a network adversary but not the specific vulnerabilities of Bitcoin core, no quick patches seem to be available. We discuss that some naive solutions (e.g., whitelisting, rate-limiting) are ineffective and third-party proxy solutions may worsen the Bitcoin's centralization problem. We provide some suggested modifications to the Bitcoin core and show that they effectively make the EREBUS attack significantly harder; yet, their non-trivial changes to the Bitcoin's network operation (e.g., peering dynamics, propagation delays) should be examined thoroughly before their wide deployment.