Date: Tuesday, 5 Nov 2024, Session I 9:30-11:30
Full client with Video: https://meetecho.ietf.org/client/?group=maprg
Room: Wicklow Hall 2B
IRTF Note Well: https://irtf.org/policies/irtf-note-well-2019-11.pdf
Overview and Status - Mirja/Dave (5 min)
Heads-Up: Application Outcome Aware Root Cause Analysis - Bjørn Ivar Teigen (5 mins) (in-person)
Heads-Up: DNS TTL's: some observations from the wild - John Ronan (10 mins) (in-person)
Reverse-Engineering Congestion Control Algorithm Behavior - Margarida Ferreira (15 mins) (remote)
Do CAA, CT, and DANE Interlink in Certificate Deployments? A Web PKI Measurement Study
Pouyan Fotouhi Tehrani (15 mins) (remote)
Destination Reachable: What ICMPv6 Error Messages Reveal About Their Sources - Johanna Ullrich (15 mins) (remote)
Seeds of Scanning: Exploring the Effects of Datasets, Methods, and Metrics on IPv6 Internet Scanning - Grant Williams (15 mins) (remote)
IoT Bricks Over v6: Understanding IPv6 Usage in Smart Homes - Tianrui Hu (15 mins) (remote)
Bjørn Ivar Teigen Monclair, Magnus Olden, Nina Stolpestad (Domos)
Quality of Outcome (QoO) is an IETF IPPM ID allowing calculations of probabilities of meeting app requirements or other SLAs. The underlying framework is built on measuring latency distributions under load, with packet loss modeled as infinite latency, which allows (de)composability without losing statistical integrity.
QoO is an attempt to be a middleground between QoE measures and QoS metrics and to be useful for Users, Apps and Operators, as we believe probability of perfect app performance (outcome) is more relatable than QoS measures and the comboposability allows operators to perform contextual root cause analysis(RCA).
We recently put our assumption to the test in a user trial with Comcast Innovation where 25 households got software to measure QoO on their home router. QoO was measured for app performance and accompanied by a contextualized RCA and testing of L4S.
The end-users got a UX where they could investigate the QoO and RCA in their household, and got a questionnaire on how they felt it matched their experience. The presentation will go through the results, which are very promising!
John Ronan
This presentation will outline some initial results seen from querying DNS records that have 'expired', for various definitions of expire.
work in progress
Margarida Ferreira (Carnegie Mellon University; INESC-ID/IST), Ranysha Ware (Carnegie Mellon University), Yash Kothari (Carnegie Mellon University), Ines Lynce (INESC-ID/IST), Ruben Martins (Carnegie Mellon University), Akshay Narayan (Brown University), Justine Sherry (Carnegie Mellon University)
The rise of proprietary and novel congestion control algorithms (CCAs) opens questions about the future of Internet utilization, latency, and fairness. However, fully analyzing how novel CCAs impact these properties requires understanding the inner workings of these algorithms. We thus aim to reverse-engineer deployed CCAs’ behavior from collected packet traces to facilitate analyzing them. We present Abagnale, a program synthesis pipeline that helps users automate the reverse-engineering task. Using Abagnale, we discover simple expressions capturing the behavior of 9 of the 16 CCAs distributed with the Linux kernel and analyze 7 CCAs from a graduate networking course.
Pouyan Fotouhi Tehrani (TU Dresden), Raphael Hiesgen (HAW Hamburg), Teresa Lübeck (HAW Hamburg), Thomas Schmidt (HAW Hamburg), Matthias Wählisch (TU Dresden)
Integrity and trust on the web build on X.509 certificates. Misuse or misissuance of these certificates threaten the Web PKI security model, which led to the development of several guarding techniques. In this paper, we study the DNS/DNSSEC records CAA and TLSA as well as CT logs from the perspective of the certificates in use. Our measurements comprise 4 million popular domains, for which we explore the existence and consistency of the different extensions. Our findings indicate that CAA is almost exclusively deployed in the absence of DNSSEC, while DNSSEC protected service names tend to not use the DNS for guarding certificates. Even though mainly deployed in a formally correct way, CAA CA-strings tend to not selectively separate CAs, and numerous domains hold certificates beyond the CAA semantic. TLSA records are repeatedly poorly maintained and occasionally occur without DNSSEC.
Florian Holzbauer (University of Vienna), Markus Maier (SBA Research), Johanna Ullrich (University of Vienna)
The probability of hitting an active IPv6 address by chance is vir- tually zero; instead, it appears more promising to analyze ICMPv6 error messages that are returned in case of an undeliverable packet. In this paper, we investigate the implementation of ICMPv6 er- ror messages by different router vendors, whether a remote net- work’s deployment status might be inferred from them, and analyze ICMPv6 error messaging behavior of routers in the IPv6 Internet. We find that Address Unreachable with a delay of more than a second indicates active networks, whereas Time Exceeded, Reject Route and Address Unreachable with short delays pinpoint inac- tive networks. Furthermore, we found that ICMPv6 rate-limiting implementations, used to protect routers, allow the fingerprinting of vendors and OS-versions. This enabled us to detect more than a million periphery routers relying on Linux kernels from 2018 (or before); these kernels have reached end of life (EOL) and no longer receive security updates.
Grant Williams (Georgia Institute of Technology), Paul Pearce (Georgia Institute of Technology)
Large-scale Internet scanning is a vital research tool. While IPv4 can be exhaustively probed, the size of IPv6 precludes complete enumeration, limiting large-scale measurement. Target Generation Algorithms (TGAs)—algorithms which ingest lists of prediscovered addresses (“seeds”) and produce new addresses to scan—have begun bridging this IPv6 measurement gap. To date, there has been limited exploration of how changes in seed addresses, scanning methods, and dataset composition impact TGA-driven IPv6 host discovery.
In this work, we provide a roadmap for how to use TGAs for Internet-wide scanning by evaluating how changes to input datasets, preprocessing, liveness, alias detection, and metrics impact TGA performance. We also explore how choice of scan target—ICMP Echo, TCP80, TCP443, or UDP53—across both inputs and outputs, impact discovered addresses.
From this analysis, we provide guidance on how to properly pre-process a TGA input (seed) dataset and the importance of removing aliases; simple preprocessing at scan time can significantly improve network diversity and can increase discovered hosts by over 700% across combined approaches. We further compare TGA generation budgets, analyze discovered populations, and demonstrate the utility of running multiple TGAs together. Finally, we summarize recommendations for effective TGA use for Internet-wide IPv6 scanning.
Tianrui Hu (Northeastern University), Daniel J. Dubois (Northeastern University), David Choffnes (Northeastern University)
Recent years have seen growing interest and support for IPv6 in residential networks. While nearly all modern networking devices and operating systems support IPv6, it remains unclear how this basic support translates into higher-layer functionality, privacy, and security in consumer IoT devices. In this paper, we present the first comprehensive study of IPv6 usage in smart homes in a testbed equipped with 93 distinct, popular consumer IoT devices. We investigate whether and how they support and use IPv6, focusing on factors such as IPv6 addressing, configuration, DNS and destinations, and privacy and security practices.
We find that, despite most devices having some degree of IPv6 support, in an IPv6-only network just 20.4% transmit data to Internet IPv6 destinations, and only 8.6% remain functional, indicating that consumer IoT devices are not yet ready for IPv6 networks. Furthermore, 16.1% of devices use easily traceable IPv6 addresses, posing privacy risks. Our findings highlight the inadequate IPv6 support in consumer IoT devices compared to conventional devices such as laptops and mobile phones. This gap is concerning, as it may lead to not only usability issues but also privacy and security risks for smart home users.