Date: Monday, 24 July 2024, Session I 9:30-11:30
Full client with Video: https://meetecho.ietf.org/conference/?group=maprg&short=maprg&item=1
Room: Georgia B
IRTF Note Well: https://irtf.org/policies/irtf-note-well-2019-11.pdf
Overview and Status - Mirja/Dave (5 min)
Heads-Up/ANRW talk: HTTP/3’s Extensible Prioritization Scheme in the Wild - Joris Herbots (5 mins) (in-person)
Peaking Beyond the Best Route: An Extensive Dataset for Looking Glasses - Pascal Hennen (15 mins) (remote)
Testing Protocols in Simulated Network Conditions - Tommy Pauly (10 mins) (in-person)
Watching Stars in Pixels: The Interplay of Traffic Shaping and YouTube Streaming QoE over GEO Satellite Networks - Jiamo Liu (remote) (15 mins) (remote)
A First Look At NAT64 Deployment In-The-Wild - Amanda Hsuan (15 mins) (remote)
Preparing to Detect IPv6 Attacks on Your IoT Devices - Phil Roberts (15 mins) (remote)
Understanding anomalies using a baseline dataset comparison - Wes Hardaker (10 mins) (in-person)
Field Experiments on Post-Quantum DNSSEC - Peter Thomassen/Jason Goertzen (15 mins) (in-person)
J. Herbots, R. Marx, M. Wijnants, P. Quax, and W. Lamotte
For HTTP/2 and HTTP/3, multiple (Web page) resources are loaded by multiplexing them onto a single TCP or QUIC connection. A "prioritization system" is used to properly schedule the order in which the resources are sent. As HTTP/2's "prioritization tree" underperformed, a more straightforward setup called the Extensible Prioritization Scheme (EPS) was proposed for HTTP/3 (RFC 9218). This paper presents the first real-world measurement study into how this new scheme is supported and employed in practice by the three main browser engines and 12 different popular servers and cloud/CDN deployments. We find considerable heterogeneity in overall EPS (sub)feature support and even fundamental differences in approach/philosophy between the stacks, with several implementations surprisingly ignoring the signals. As incorrect prioritization can have a negative effect on (Web) performance metrics, our work not only provides essential insights for browser vendors and server deployments but also offers recommendations for future improvements and helps guide Web developers trying to optimize their page load process with features like FetchPriority.
Pascal Hennen, Poornima Mani, Anja Feldmann
The Internet relies on the Border Gateway Protocol (BGP) to establish
routes. Each Autonomous System (AS) uses BGP to realize its routing
policies based on their (mostly private) business agreements with their
neighbouring ASes. One of BGP's drawbacks is that ASes typically do not
see the effects of their routing policies as this information is only
visible within other ASes. Yet, for an AS to check their BGP
configuration they need to see the effect. Thus, ASes collaborate and
operate publicly accessible Looking Glasses (LGs). LGs are websites that
allow the users to query one or several routers within the ASes for
routing information. This information may be restricted to BGP routes
(routing prefix plus AS path) only or other BGP attributes as well,
e.g., local preference, MED, and BGP communities. Such LG data is
required by many BGP topology inference methods either as input or for
validation. The dataset that this paper focuses on collects BGP
attributes from more than 149 LGs in 154 ASes from 931 routers via
scraping the LGs. Hereby, the difficulties relate to the non-uniformity
of the LGs---most interfaces differ, the fluctuating accessibility of
the LGs, as well as the different output formats. To overcome this we
combined manual configuration with an automated scraping process
followed by careful post-processing and manual checks. Our current
dataset covers one and a half months of continuous data collection every
4 hours. In this paper, we describe both our collection pipeline as well
as initial analysis results which focus on route diversity for ASes with
multiple LGs. We find that up to 43% of these ASes use diverse routes to
at least one of their peers. Routes can differ in local preference 40%,
AS paths 37%, or BGP communities 41%. While the former is expected the
latter is surprising.
Tommy Pauly
Share results of how simulated network impairments using Apple’s Network Link Conditioner and other tools helps evaluate the performance impact of various protocol features (QUIC, ECN, different congestion controllers).
Jiamo Liu (University of California Santa Barbara), David Lerner (Viasat), Jae Chung (Viasat), Udit Paul (University of California Santa Barbara), Arpit Gupta (University of California Santa Barbara), Elizabeth M. Belding
Geosynchronous satellite (GEO) networks are an important Internet access option for users beyond terrestrial connectivity. However, unlike terrestrial networks, GEO networks exhibit high latency and, as a result, deploy TCP proxies and traffic shapers. Currently, it is unclear how the interplay between GEO networks' high latency, TCP proxies, and traffic shaping policies affects the quality of experience (QoE) for commonly used video applications. In this talk, I will share insights from a study conducted on a 1Mbps shaped production GEO network, focusing on the QoE for YouTube video streaming. Despite the network's shaped bandwidth being theoretically sufficient for the targeted video bitrate, the actual QoE falls significantly short of expectations. This discrepancy raises important questions about the efficacy of traffic shaping policies in GEO networks, especially when dealing with adaptive bitrate video streaming services. By investigating the reasons behind the observed discrepancies in expected versus actual network throughput, we showcase the nuanced interplay between protocol, traffic shaping and application-level optimizations. The findings underscore an important evaluation of current traffic shaping approaches in GEO networks, highlighting their challenges in effectively managing video streaming quality.
Amanda Hsu, Frank Li, Paul Pearce, Oliver Gasser
IPv6-only networks cannot, by default, communicate with the IPv4 Internet. This lack of interoperability necessitates mechanisms for bridging networks so that non-dual-stack systems can interact with the whole Internet. NAT64 is one such mechanism that allows IPv6-only clients to connect to the entire Internet, leveraging DNS to identify IPv4-only networks, inject IPv6 response addresses pointing to an internal gateway, and seamlessly translate connections.
In this talk, we present a first look at the active measurement of NAT64 deployment on the Internet focused on deployment prevalence, configuration, and security. We seek to measure NAT64 via two distinct large-scale measurements: 1) open resolvers on the Internet, and 2) client measurements from RIPE Atlas. In both cases, we broadly find that despite substantial anecdotal reports of NAT64 deployment, measurable deployments are exceedingly sparse. While our measurements do not preclude the large-scale deployment of NAT64, they do point to substantial challenges in measuring deployments with our existing best-known methods. Finally, we also identify problems in NAT64 deployments, with gateways not following the RFC specification and posing potential security risks. We seek input from the IETF community on our methodology and findings.
Phil Roberts, Global Cyber Alliance (GCA); Leslie Daigle, Global Cyber
Alliance
It is relatively easy to scan the entire IPv4 Internet for threats, but
IPv6 is on the rise, and its address space is so big attackers cannot use
the same techniques we have been using on IPv4. While IPv4 is still
pervasive for now, IPv6-based attacks are already happening, and we must
find ways to identify and mitigate them.
In the latest Global Cyber Alliance Internet Integrity Paper, “Expanding
IoT Honeypots to Include IPv6-Connected Devices,” we explore potential ways
to stop malware at its source. Based on our research, we propose extending
ProxyPot, GCA’s own honeypot technology, to detect attacks over SSH,
Telnet, HTTP, and HTTPS, over both IPv4 and IPv6 – a first of its kind.
Attack detection is extremely limited over IPv6 today. This research and
work enable us to stay ahead of the curve and be prepared for the
inevitable growth of IPv6-based attacks. As we build a database measuring
attacks on IPv6 infrastructure, we continue to work with network operators
to promote methods of stopping his kind of malicious activity at its source.
Wes Hardaker
Network anomalies, whether malicious or benign, are easy to analyze when
they are large in size. Determining their composition during smaller
events that are only a small to medium increase above remains
challenging as the level of increase is less and less significant. This
talk will show the results of a 6 month project, sponsored by Comcast,
to build an easy to use tool for comparisons of deep packet inspections
of network traffic.
Peter Thomassen, Jason Goertzen
deSEC and SandboxAQ have conducted a joint research project on post-quantum DNSSEC 1, involving RIPE ATLAS measurements using around 10,000 probes. We implemented multiple PQC signing schemes (Falcon, XMSS, Dilithium, Sphincs+) in both BIND and PowerDNS, and investigated DNS response success and failure rates depending on the signing scheme and other parameters (such as whether queries were conducted via UDP or TCP, or whether validation was requested). The purpose of the study is to inform future PQC engineering developments in the DNSSEC context.
We find that depending on circumstances, a significant fraction of clients choke, mainly depending on the response packet properties such as size, but also on query parameters like transport protocol. This is qualitatively in ine with earlier operational experience, but adds quantitative detail. We also find surprising results, such as that a number of resolvers claim to have validated PQC signatures, even though it is implausible for resolvers to support these algorithms.
In addition to our signing implementations, we added validation support to PowerDNS recursor and BIND resolver. Both functions (signing and validation) can be tested using a do-it-yourself frontend 2, which the public can use to work and familiarize themselves with our testbed.
This project is a continuation of deSEC's 2022 experiments with a PowerDNS implementation of the Falcon signing scheme 3.