Industrial Internet of Things (IIoT) is present in many participants from the energy, health, manufacturing, transport, and public sectors. Many factors catalyze IIoT, such as robotics, artificial intelligence, and intelligent decentralized manufacturing. However, the convergence between IT, OT, and IoT environments involves the integration of heterogeneous technologies through protocols, standards, and buses. However, this integration brings with it security risks. To avoid the security risks, especially when systems in different environments interact, it is important and urgent to create an early consensus among the stakeholders on the IIoT security. The default Common Vulnerability Scoring System (CVSS) offers a mechanism to measure the severity of an asset's vulnerability and therefore a way to characterize the risk. However, CVSS by default has two drawbacks. On the one hand, to carry out a risk analysis, it is necessary to have additional metrics to the one established by CVSSv3.1. On the other hand, this index has been used mostly in IT environments and although there are numerous efforts to develop a model that suits industrial environments, there is no established proposal. Therefore, we first propose a survey of the main 33 protocols, standards, and buses used in an IIoT environment. This survey will focus on the security of each one. The second part of our study consists of the creation of a framework to characterize risk in industrial environments, i.e., to solve both problems of the CVSS index. To this end, we created the Vulnerability Analysis Framework (VAF), which is a methodology that allows the analysis of 1,363 vulnerabilities to establish a measure to describe the risk in IIoT environments.

A Survey of IIoT Protocols: A Measure of Vulnerability Risk Analysis Based on CVSS

Existing performance comparisons of QUIC and TCP compared an optimized QUIC to an unoptimized TCP stack. By neglecting available TCP improvements inherently included in QUIC, comparisons do not shed light on the performance of current web stacks. In this paper, we can show that tuning TCP parameters is not negligible and directly yields significant improvements. Nevertheless, QUIC still outperforms even our tuned variant of TCP. This performance advantage is mostly caused by QUIC's reduced RTT design during connection establishment, and, in case of lossy networks due to its ability to circumvent head-of-line blocking.

A performance perspective on web optimized protocol stacks: TCP+TLS+HTTP/2 vs. QUIC

IETF QUIC, the standardized version of Google’s UDP-based layer-4 network protocol, has seen increasing adoption from large Internet companies for its benefits over TCP. Yet despite its rapid adoption, performance analysis of QUIC in production is scarce. Most existing analyses have only used unoptimized open-source QUIC servers on non-tuned kernels: these analyses are unrepresentative of production deployments which raises the question of whether QUIC actually outperforms TCP in practice. In this paper, we conduct one of the first comparative studies on the performance of QUIC and TCP against production endpoints hosted by Google, Facebook, and Cloudflare under various dimensions: network conditions, workloads, and client implementations. To understand our results, we create a tool to systematically visualize the root causes of performance differences between the two protocols. Using our tool we make several key observations. First, while QUIC has some inherent advantages over TCP, such as worst-case 1-RTT handshakes, its overall performance is largely determined by the server’s choice of congestion-control algorithm and the robustness of its congestion-control implementation under edge-case network scenarios. Second, we find that some QUIC clients require non-trivial configuration tuning in order to achieve optimal performance. Lastly, we demonstrate that QUIC’s removal of head-of-line (HOL) blocking has little impact on web-page performance in practice. Taken together, our observations illustrate the fact that QUIC’s performance is inherently tied to implementation design choices, bugs, and configurations which implies that QUIC measurements are not always a reflection of the protocol and often do not generalize across deployments.

Dissecting Performance of Production QUIC

After nearly five years and 34 draft versions, standardization of the new connection oriented transport protocol QUIC was finalized in May 2021. Designed as a fundamental network protocol with increased complexity due to the combination of functionality from multiple network stack layers, it has the potential to drastically influence the Internet ecosystem. Nevertheless, even in its early stages, the protocol attracted a variety of parties including large providers. Our study shows, that more than 2.3 M IPv4 and 300k IPv6 addresses support QUIC hosting more than 30 M domains. Using our newly implemented stateful QUIC scanner (QScanner) we are able to successfully scan 26 M targets. We show that TLS as an integral part is similarly configured between QUIC and TLS over TCP stacks for the same target. In comparison, we identify 45 widely varying transport parameter configurations, e.g., with differences in the order of magnitudes for performance relevant parameters. Combining these configurations with HTTP Server header values and associated domains reveals two large edge deployments from Facebook and Google. Thus, while found QUIC deployments are located in 4667 autonomous systems, numerous of these are again operated by large providers. In our experience, IETF QUIC already sees an advanced deployment status mainly driven by large providers. We argue that the current deployment state and diversity of existing implementations and seen configurations solidifies the importance of QUIC as a future research topic. In this work, we provide and evaluate a versatile tool set, to identify QUIC capable hosts and their properties. Besides the stateful QScanner we present and analyze a newly implemented IPv4 and IPv6 ZMap module. We compare it to additional detection methods based on HTTP Alternative Service Header values from HTTP handshakes and DNS scans of the newly drafted HTTPS DNS resource record. While each method reveals unique deployments the latter would allow lightweight scans to detect QUIC capable targets but is drastically biased towards Cloudflare.

https://dl.acm.org/doi/pdf/10.1145/3487552.3487826

It's over 9000: analyzing early QUIC deployments with the standardization on the horizon

QUIC was launched in 2013 with a goal to provide reliable, connection-oriented and end-to-end encrypted transport and is recently standardized in May 2021 by the Internet Engineering Task Force (IETF). This work evaluates QUIC performance over the web, cloud storage, and video workloads and compares them to traditional TLS/TCP. To this end, we have designed tests (<monospace>quic_perf</monospace>, <monospace>tls_perf</monospace> and <monospace>video</monospace>) and conducted measurements from 2018 – 2021 using multiple vantage points: an educational network, a high-bandwidth low-RTT residential link in Germany and a low-bandwidth high-RTT residential link in India. We target Alexa Top-1M for web workloads and probe them towards the support for QUIC, TLS 1.2 and TLS 1.3. By measuring <inline-formula> <tex-math notation="LaTeX">$\lt 5.7$ </tex-math></inline-formula>K websites that support QUIC, we observe that QUIC has up to <inline-formula> <tex-math notation="LaTeX">$\approx 140$ </tex-math></inline-formula>% lower mean connection times than TLS 1.2/1.3 over TCP for low-bandwidth and high-RTT networks. When comparing different versions of QUIC, we observe that IETF QUIC connection times are slightly better than different versions (<monospace>Q050</monospace>, <monospace>Q046</monospace>, <monospace>Q044</monospace>, <monospace>Q043</monospace>, <monospace>Q039</monospace> and <monospace>Q035</monospace>) of gQUIC. For cloud storage workloads, we observe that TLS 1.2 over TCP exhibits higher throughput for larger file sizes (>20 MB up to 2 GB), while QUIC exhibits higher throughput for smaller file sizes (<inline-formula> <tex-math notation="LaTeX">$\leq 20$ </tex-math></inline-formula> MB) while downloading files from Google Drive. At the same time, QUIC has much higher CPU utilization than TLS 1.2 over TCP, almost double while downloading a large file (200 MB) from Google Drive due to in-kernel optimizations that benefit TCP. For video workloads, we observe that QUIC is 534 ms faster than TLS 1.2 over TCP from India (406 ms from Germany) in establishing a connection to YouTube media servers. Although we witness that (similar to cloud storage workloads) the overall download rate is higher over TLS, QUIC still tends to depict better video content delivery with reduced stall events and up to 50% lower stall durations due to its lower latency overheads. To support reproducibility, the developed tests and the collected data are made publicly available to the community.

Evaluating QUIC Performance Over Web, Cloud Storage, and Video Workloads

Current Internet transport protocols are being revisited in an attempt to respond to traffic growth in size, diversity and the emergence of new applications. Designed to reduce Web TCP latency and connection establishment time, QUIC uses UDP and defines its own congestion control. To verify some of QUIC’s performance claims, we carried out an extensive set of controlled experiments reflecting Internet traffic conditions by configuring various parameters, such as the round trip time (RTT), the packet loss ratio, web pages, and caching. Surprisingly, our experimental results show that QUIC presented worst page load time (PLT) results than TCP. We next present some of our interpretations of these results.

QUIC and TCP: A Performance Evaluation

Decision making and data management are critical features for companies to leverage their productivity and revenues. With the advancement of Industry 4.0, smart factories are increasing their investment in cyber-physical systems and digital processing. An extensive field of study that allows this growth is the Internet of Things (IoT). As factories desire velocity and impact in their systems, an IoT network connecting devices, sensors, and robots provides planning and managing advantages. In this work, we compare AMQP and MQTT, two mainstreams IoT protocols, in a smart factory environment. We also include in the comparison the popular robotic communication platform named ROS. The results show that, overall, MQTT performed better than AMQP, which is expected, given that MQTT is a lightweight protocol. However, AMQP initial connections between peers are faster. In this work, we discuss such behaviors and other questions regarding the IoT protocols and how and why they should be implemented in a smart factory environment.

An IoT Protocol Evaluation in a Smart Factory Environment

Commercial implementations of adaptive streaming systems are either too aggressive or too conservative, not being able to efficiently deliver video content to the client. Because of these issues, a great number of adaptive streaming systems have been proposed in the academia. They employ different strategies, to select the proper video level that the server should send to the client. One trend is the use of control theory, because it guarantees system stability, and enables simulation and tuning of the system prior to its implementation. However, the current proposals that employ control theory do not take full advantage of this technique, because they do not thoroughly analyze the system parameters and their influence on the overall system performance. Therefore, it is possible that they use suboptimal solutions. In this paper, we propose a control-theoretic approach for selecting the video quality in a DASH environment. We use a controller added to a state machine, to improve the QoE and to maximize bandwidth utilization. We also present a comparison of several system settings performances, by changing the controller types, their gains, and the state machine parameters. Experimental results show the effectiveness of our proposed system for buffer time control and video level smoothness, and that it outperforms a current proposal in the academia.

A fine-tuned control-theoretic approach for dynamic adaptive streaming over HTTP

For an autonomous system to perform maintenance tasks in a networking device or a radio base station (RBS), it has to deal with a series of technological challenges ranging from identifying hardware-related problems to manipulating connectors. This paper describes the development of a robot maintenance system dedicated to detect and resolve faulty links caused by unplugged or poorly connected cables. Although the maintenance system relies on four subsystems, we significantly focus on our low-cost and efficient custom gripper solution developed to handle RJ45 Ethernet connectors. To examine our gripper, we conducted three experiments. First, a qualitative questionnaire was submitted to 30 users in the case of the teleoperated scenario of the gripper attached to a robotic arm. Similarly, we also tested the automatic operation mode. The results showed that our system is reliable and delivers a highly efficient maintenance tool in both teleoperated and autonomous operation modes. The practical experiment containing the removal or unplugging of connectors demonstrated our gripper′s ability to adequately handle these, whereas the feedback from the questionnaire pointed to a positive user experience. The automatic test assessed the gripper′s robustness against the continuous operation.

Gripper Design for Radio Base Station Autonomous Maintenance System

The popularity of Internet video streaming services has dramatically increased, leveraged by the emerging Dynamic Adaptive Streaming over HTTP (DASH) standard. DASH also favors the growth of video content access by mobile devices. However, due to fluctuating bandwidth and high latency, mobile networks, e.g. 3G, remain a challenging environment. The user's Quality of Experience (QoE) in this scenario constantly needs to improve. One way to achieve this is through the development of a better adaptation logic that reduces rebuffering events and delivers higher and more stable video qualities. In this paper, we present DBuffer, a control system developed for improving the QoE during a streaming session through mobile networks. DBuffer estimates the ideal video quality to request, during a 3G streaming session, through client-side buffer analysis. The main component of the control system is a buffer-based state machine, which manages the adaptation logic. Our experimental results show that DBuffer outperforms some of the existing advanced adaptation techniques.

Djamel Sadok

Papers

QUIC and TCP: A Performance Evaluation

An IoT Protocol Evaluation in a Smart Factory Environment

A fine-tuned control-theoretic approach for dynamic adaptive streaming over HTTP

Gripper Design for Radio Base Station Autonomous Maintenance System

DBuffer: A state machine oriented control system for DASH