New services are designed for the future of Internet, and some of them will require the network to provide low latency traffic. Many optimizations targeting latency reduction have been proposed. Among them, re-architecting congestion control and active queue management (AQM) has been particularly studied. L4S [1,2,3] (Low Latency, Low Loss and Scalable Throughput) is a new network architecture that aims at allowing coexistence between low latency traffic and classic traffic within a single node, involving a dual queue coupled AQM. Although this architecture sounds promising for latency improvement, an attacker can exploit some vulnerabilities to defeat its low-latency features and consequently make some services unusable. In addition, we prove that application-layer protocols such as QUIC can easily be hacked in order to exploit the over sensitivity of those new services to network variations. By implementing undesirable flows in a testbed and evaluating how they impact the delivery of low-latency flows, we demonstrate their reality and the need of research in the detection of this new kind of threats [4,5].

New types of services with low-latency requirements have become a major challenge for the future Internet. Many optimizations, all targeting the latency reduction have been proposed, and among them, jointly re-architecting congestion control and active queue management has been particularly considered. In this effort, the L4S (Low Latency, Low Loss and Scalable Throughput) proposal aims at allowing both classic and low-latency traffic to cohabit within a single node architecture. Although this architecture sounds promising for latency improvement, it can be exploited by an attacker to perform malicious actions whose purposes are to defeat its low-latency feature and consequently make their supported applications unusable. In this paper, we analyze the set of weaknesses of the L4S proposal and we show that application-layer protocols such as QUIC can easily be hacked in order to exploit the over-sensitivity of those new services to network variations. By implementing such undesirable flows in a real testbed and characterizing how they impact the proper delivery of lowlatency flows, we demonstrate their reality and give insights for research directions on the detection of flows threatening low latency services.

The Low-Latency Low-Loss Scalable throughput (L4S) architecture has recently been proposed to reduce the network latency of low-latency services and to allow their flows to coexist with classic ones in the same domain. This coexistence implies monitoring and security challenges. However current monitoring methods, primarily based-on sampling and polling, exhibit performance and granularity limitations. This paper describes the challenges for monitoring LL services and details our solution when introducing a fine-grained and real-time monitoring capability in our P4-based L4S implementation using In-band Network Telemetry. The initial experimental evaluation shows that our solution is able to monitor the metrics of an L4S switch with very few networking and processing overhead and without disturbing the L4S behaviour.

New types of services with low-latency requirements have become a major challenge for the future Internet. Many optimizations, all targeting the latency reduction have been proposed, and among them, jointly re-architecting congestion control and active queue management has been particularly considered. In this effort, the L4S (Low Latency, Low Loss and Scalable Throughput) proposal aims at allowing both classic and low-latency traffic to cohabit within a single node architecture. Although this architecture sounds promising for latency improvement, it can be exploited by an attacker to perform malicious actions whose purposes are to defeat its low-latency feature and consequently make their supported applications unusable. In this paper, we analyze the set of weaknesses of the L4S proposal and we show that application-layer protocols such as QUIC can easily be hacked in order to exploit the over-sensitivity of those new services to network variations. By implementing such undesirable flows in a real testbed and characterizing how they impact the proper delivery of low-latency flows, we demonstrate their reality and give insights for research directions on the detection of flows threatening low latency services.