Search

Software-defined networking (SDN) has been widely adopted in different networks, such as datacenter and service providers. The SDN controller has the entire network view and is responsible for managing it. To obtain such a view of the network, the controller employs link discovery protocols, which are vulnerable to attacks such as link fabrication attacks (LFAs). TopoGuard and TopoGuard+ are two major systems detecting LFAs. This paper introduces a link latency attack (LLA) that can bypass the defence mechanism of both systems. LLA can poison the view of the SDN controller from the network topology and causes outages, resulting in poor quality of service (QoS) or quality of experience (QoE). To mitigate this, we develop two machine learning-based defence systems, namely machine learning-based link guard (MLLG) and real-time link verification (RLV), to preserve the required defence for LLA. The MLLG works when the network topology rarely updates, while RLV can support frequent updates. Furthermore, RLV trains itself over a link latency dataset (LLD)– including latency data of fabricated and normal links– that is captured from the ongoing packets in the network. It also implements outlier detection techniques to identify a dynamic threshold for link latency. We test both systems on different scenarios using Mininet and show that they achieve reasonable results compared with current defence algorithms. Specifically, RLV presents the highest detection performance (F1-score) to 70% at less than 0.2% false-positive rate. The system also supports the robustness features when the attack rates vary from 3% to 7% in our simulated network.

Many applications, such as video streaming, congestion control, and server selection, can benefit when the data rate of different priority groups between two endpoints is accurately estimated over the end-to-end path. With the introduction of programmable networks, e.g., P4, it is now possible to offload the measurements to the data plane of intermediate devices. Recently, tools have been developed to react to changes in available bandwidth, but a tool to accurately estimate end-to-end per-priority data rates needs to be added. This motivates us to design and implement a new end-to-end and per-priority data rate estimation tool, PrioMeter. PrioMeter can accurately report the data rate per priority group of flows in programmable networks using high-precision timestamps for arbitrary traffic scales. PrioMeter leverages two primitives: quantization and truncation, to achieve its goals. We implement PrioMeter in P4 and test it on BMv2 switches, and our preliminary results using NS3 simulations show that it can accurately estimate the data rate of different priority flows with minimal overhead., Cyber Security

Geographically distributed (geo-distributed) datacenters for stream data processing typically comprise multiple edges and core datacenters connected through Wide-Area Network (WAN) with a master node responsible for allocating tasks to worker nodes. Since WAN links significantly impact the performance of distributed task execution, the existing task assignment approach is unsuitable for distributed stream data processing with low latency and high throughput demand. In this paper, we propose SAFA, a resource provisioning framework using the Software-Defined Networking (SDN) concept with an SDN controller responsible for monitoring the WAN, selecting an appropriate subset of worker nodes, and assigning tasks to the designated worker nodes. We implemented the data plane of the framework in P4 and the control plane components in Python. We tested the performance of the proposed system on Apache Spark, Apache Storm, and Apache Flink using the Yahoo! streaming benchmark on a set of custom topologies. The results of the experiments validate that the proposed approach is viable for distributed stream processing and confirm that it can improve at least 1.64× the processing time of incoming events of the current stream processing systems.

Big data analytics platforms have played a critical role in the unprecedented success of data-driven applications. However, real-time and streaming data applications, and recent legislation, e.g., GDPR in Europe, have posed constraints on exchanging and analyzing data, especially personal data, across geographic regions. To address such constraints data has to be processed and analyzed in-situ and aggregated results have to be exchanged among the different sites for further processing. This introduces additional network delays due to the geographic distribution of the sites and potentially affecting the performance of analytics platforms that are designed to operate in datacenters with low network delays. In this paper, we show that the three most popular big data analytics systems (Apache Storm, Apache Spark, and Apache Flink) fail to tolerate round-trip times more than 30 milliseconds even when the input data rate is low. The execution time of distributed big data analytics tasks degrades substantially after this threshold, and some of the systems are more sensitive than others. A closer examination and understanding of the design of these systems show that there is no winner in all wide-area settings. However, we show that it is possible to improve the performance of all these popular big data analytics systems significantly amid even transcontinental delays (where inter-node delay is more than 30 milliseconds) and achieve performance comparable to this within a datacenter for the same load.

Big data analytics platforms have played a critical role in the unprecedented success of data-driven applications. However, real-time and streaming data applications, and recent legislation, e.g., GDPR in Europe, have posed constraints on exchanging and analyzing data, especially personal data, across geographic regions. To address such constraints data has to be processed and analyzed in-situ and aggregated results have to be exchanged among the different sites for further processing. This introduces additional network delays due to the geographic distribution of the sites and potentially affecting the performance of analytics platforms that are designed to operate in datacenters with low network delays. In this paper, we show that the three most popular big data analytics systems (Apache Storm, Apache Spark, and Apache Flink) fail to tolerate round-trip times more than 30 milliseconds even when the input data rate is low. The execution time of distributed big data analytics tasks degrades substantially after this threshold, and some of the systems are more sensitive than others. A closer examination and understanding of the design of these systems show that there is no winner in all wide-area settings. However, we show that it is possible to improve the performance of all these popular big data analytics systems significantly amid even transcontinental delays (where inter-node delay is more than 30 milliseconds) and achieve performance comparable to this within a datacenter for the same load., Cyber Security

Applications of Software-Defined Networking (SDN) to the Internet Routing hold great promises for supporting the ever-growing performance requirements of Internet applications. The inherent centralization of these SDN approaches on the Internet routing comes with the following concerns: 1) privacy , the operators are reluctant to share private routing information, 2) separation of responsibilities , the Internet eXchange Point (IXP) running the centralized controller is involved in the routing and forwarding at too many levels, and 3) scalability , the growing number of IP prefixes routed on the Internet (i.e., hundreds of thousands) pose extremely high requirements at both the control- and data-planes, e.g., several minutes for policy compilations and a large number of forwarding rules, in SDN. In this paper, we propose DeSI to apply SDN at IXPs by considering the above concerns. We break this centralization by devising an SDN-enabled IXP architecture in which each member connects to an SDN-enabled IXP through its SDN controller and SDN switches, thus tackling privacy, scalability, and separation of concerns issues. To spur adoption, we introduce an expressive, yet simple, language to configure the routing policies of the members. Our evaluation shows that DeSI needs n times fewer forwarding table entries for an IXP in which n is the number of IXP members. DeSI also gives the possibility of slowly migrating to the SDN-enabled IXPs., QC 20211018