Mike Kosek, Trinh Viet Doan, Simon Huber, Vaibhav Bajpai

Abstract

The Domain Name System (DNS) is one of the most crucial parts of the Internet. Although the original standard defined the usage of DNS over UDP (DoUDP) as well as DNS over TCP (DoTCP), UDP has become the predominant protocol used in the DNS. With the introduction of new Resource Records (RRs), the sizes of DNS responses have increased considerably. Since this can lead to truncation or IP fragmentation, the fallback to DoTCP as required by the standard ensures successful DNS responses by overcoming the size limitations of DoUDP. However, the effects of the usage of DoTCP by stub resolvers are not extensively studied to this date. We close this gap by presenting a view at DoTCP from the Edge, issuing 12.1M DNS requests from 2,500 probes toward Public as well as Probe DNS recursive resolvers. In our measurement study, we observe that DoTCP is generally slower than DoUDP, where the relative increase in Response Time is less than 37% for most resolvers. While optimizations to DoTCP can be leveraged to further reduce the response times, we show that support on Public resolvers is still missing, hence leaving room for optimizations in the future. Moreover, we also find that Public resolvers generally have comparable reliability for DoTCP and DoUDP. However, Probe resolvers show a significantly different behavior: DoTCP queries targeting Probe resolvers fail in 3 out of 4 cases, and, therefore, do not comply with the standard. This problem will only aggravate in the future: As DNS response sizes will continue to grow, the need for DoTCP will solidify.

Download from ACM

Nicola Bonelli, Fabio Del Vigna, Alessandra Fais, Giuseppe Lettieri, Gregorio Procissi

Abstract

Software data planes running on commodity servers are very popular in real deployments. However, to attain top class performance, the software approach requires the adoption of accelerated network I/O frameworks, each of them characterized by its own programming model and API. As a result, network applications are often closely tied to the underlying technology, with obvious issues of portability over different systems. This is especially true in cloud scenarios where different I/O frameworks could be installed depending on the configuration of the physical servers in the infrastructure. The nethuns library proposes a unified programming abstraction to access and manage network operations over different I/O frameworks. The library is freely available to the community under the BSD license and currently supports AF_XDP and netmap for fast packet handling along with the classic AF_PACKET and the pcap library. Network applications based on nethuns need only to be re-compiled to run over a different network API. The experiments prove that the overhead introduced by nethuns is negligible, hence making it a convenient programming platform that eases the coding process while guaranteeing high performance and portability. As proofs of concept, a handy traffic generator as well as the popular Open vSwitch application have been successfully ported and tested over nethuns.

Download from ACM

Khwaja Zubair Sediqi, Lars Prehn, Oliver Gasser

Abstract

Autonomous Systems (ASes) exchange reachability information between each other using BGP—the de-facto standard inter-AS routing protocol. While IPv4 (IPv6) routes more specific than /24 (/48) are commonly filtered (and hence not propagated), route collectors still observe many of them. In this work, we take a closer look at those hyper-specific prefixes (HSPs). In particular, we analyze their prevalence, use cases, and whether operators use them intentionally or accidentally. While their total number increases over time, most HSPs can only be seen by route collector peers. Nonetheless, some HSPs can be seen constantly throughout an entire year and propagate widely. We find that most HSPs represent (internal) routes to peering infrastructure or are related to address block relocations or blackholing. While hundreds of operators intentionally add HSPs to well-known routing databases, we observe that many HSPs are possibly accidentally leaked routes.

Download from ACM

Said Jawad Saidi, Oliver Gasser, Georgios Smaragdakis

Abstract

IPv6 is being more and more adopted, in part to facilitate the millions of smart devices that have already been installed at home. Unfortunately, we find that the privacy of a substantial fraction of end-users is still at risk, despite the efforts by ISPs and electronic vendors to improve end-user security, e.g., by adopting prefix rotation and IPv6 privacy extensions. By analyzing passive data from a large ISP, we find that around 19% of end-users’ privacy can be at risk. When we investigate the root causes, we notice that a single device at home that encodes its MAC address into the IPv6 address can be utilized as a tracking identifier for the entire end-user prefix—even if other devices use IPv6 privacy extensions. Our results show that IoT devices contribute the most to this privacy leakage and, to a lesser extent, personal computers and mobile devices. To our surprise, some of the most popular IoT manufacturers have not yet adopted privacy extensions that could otherwise mitigate this privacy risk. Finally, we show that third-party providers, e.g., hypergiants, can track up to 17% of subscriber lines in our study.

Download from ACM