Date: Tuesday, 17 March 2026, Session III 14:00-15:30
Full client with Video: https://meetecho.ietf.org/conference/?group=maprg&short=maprg&item=1
Room: Grand Ballroom 2
IRTF Note Well: https://irtf.org/policies/irtf-note-well-2019-11.pdf
Overview and Status - Mirja/Dave (5 min)
Heads-up talk: Measurement of Systemic DNS Resolver Vulnerabilities (Informing Six DNSOP I-Ds) - Yuqi Qiu (5 mins)
ru-RPKI-ready: the Road Left to Full ROA Adoption - Deepak Gouda (remote) (10 mins)
Unveiling Global ROV Deployments and Dependencies in the Post-ROV Era - Weitong Li (10 mins)
What IPv6 RFCs Don't Say About VPNs - Yejin Cho (remote) (10 mins)
Understanding and Characterizing Intermediate Paths of Email Delivery: The Hidden Dependencies - Shibo Cui (15 mins)
Analyzing Compliance and Complications of Integrating Internationalized X.509 Certificates - Mingming Zhang (15 mins)
Measuring the Time Source Vulnerabilities in the NTP Ecosystem - Zhentian Huang (15 mins)
Based on these measurement findings, we have recently submitted six related Internet-Drafts to the DNSOP WG to address the underlying logical vulnerabilities and specification ambiguities. We propose a 10-15 minute presentation at maprg focusing on the empirical data and the systemic issues that motivated these DNSOP drafts, covering three interconnected areas:
Cache and Delegation Intricacies: We measured inconsistent bailiwick logic (e.g., in CDNS) and longest-suffix match caching exploits (PHOENIX DOMAIN), which keep revoked domains resolvable. (Informs: draft-qiu-dnsop-enhanced-bailiwick, draft-li-dnsop-deep-delegation-scrutiny)
Query Handling and Amplification Defense: We quantified how forged ECS options bypass aggregation (REBIRTHDAY), how query timeouts/aggregation facilitate powerful PDoS (DNSBomb), and how inconsistent RD=0 processing enables amplification (TsuKing). (Informs: draft-li-dnsop-ecs-aggregation-fix, draft-li-dnsop-resolver-resilience, draft-qiu-dnsop-rd-flag-clarification)
Packet Pre-processing: We analyzed flaws in processing malformed responses (TUDOOR), causing premature termination or resource exhaustion. (Informs: draft-li-dnsop-response-preprocessing)
Resource Public Key Infrastructure (RPKI) has become a standard for enhancing the security of Internet routing. Currently, more than 50% BGP prefixes are covered by RPKI Route Origin Authorizations (ROAs), enabling networks to validate the origin of prefix advertisements in BGP. However, ROA adoption is non-uniform, with key stakeholders still lagging behind. In this paper, we present a data-driven analysis of global RPKI adoption to quantify the current state of ROA coverage and we identify persistent disparities that hinder broader adoption. Our study reveals that although RPKI awareness has grown, the complexity of planning and deploying ROAs is a challenge. Since no unified workflow and documentation exist for ROA planning, many organizations are left without clear operational guidance. To address this challenge, we propose a systematic framework for ROA planning and introduce ru-RPKI-ready, a platform designed to provide data and insights to facilitate ROA planning. Using ru-RPKI-ready, we characterize the routed address space not covered by RPKI ROAs. We find that 47% IPv4 and 71% IPv6 prefixes not in RPKI could be covered with minimal technical efforts. Our analysis also reveals that if as few as ten organizations were to take necessary actions, the global ROA coverage can increase by 7% for IPv4 and 19% for IPv6.
The Resource Public Key Infrastructure (RPKI) and Route Origin Validation (ROV) are critical to securing Internet routing, yet measuring real-world ROV deployment and dependencies remains challenging. Existing methods (control-plane analysis and data-plane probing) often struggle to distinguish local ROV adoption from upstream filtering at scale and face diminishing visibility as ROV adoption grows.
We present RScope, a measurement framework that dynamically manipulates Route Origin Authorizations (ROAs) from controlled publication points to isolate the impact of individual Relying Party (RP) servers. By selectively invalidating prefixes for specific RPs and probing connectivity changes, RScope maps dependencies between 21,827 ASes, their transit providers, and RP infrastructure.
Our findings reveal that 1,127 ASes actively deploy ROV, while 1,815 rely on upstream protection, leaving 69.6% of such “protected” ASes vulnerable to local hijacks. Notably, large ISPs disproportionately influence global security—enabling ROV in the top 100 ASes protects 27.6% of networks, while disabling it in Tier-1s exposes 23.8% to hijacks. We also uncover operational delays: router enforcement lags ROA updates by 37 minutes on average. These results highlight systemic risks in incremental ROV adoption, emphasizing the need for resilient RP configurations and broader deployment. We open-source tools and datasets to support ongoing routing security efforts.
Why do some users not use IPv6? Users of dual-stack VPN can use either IPv4 or IPv6, but although they should prefer IPv6, we find that many actually consistently use IPv4. We show that some dual-stack VPNs consistently de-preference IPv6. We identify the root cause is because when user's computer follows standard address-selection rules (RFC6724), and these rules systematically prefers IPv4 addresses (public or private) over private (ULA) v6 addresses. We evaluate this behavior in for millions of VPN users
using data from WhatIsMyIPAddress.com, and confirm this behavior in five of six VPNs through lab tests on Android.
We discuss four possible approaches to mitigate this issue: assigning per-user Global Unicast Addresses (GUAs), assigning a shared static GUA, introducing a new address class (named Tunnel Local Address), or modifying address prioritization rules. Each option involves trade-offs in deployability and architectural impact.
In the cloud era, hosting-based email services have become a common business model. Various entities can participate in the email delivery process. However, the intermediate paths of email delivery have received little attention. In particular, the vulnerabilities and centralization of email intermediate paths have already posed real-world security threats. This paper conducts the first systematic analysis of intermediate paths of email delivery, aiming to understand dependence patterns and characterize the centralization. In collaboration with a large email service provider, we collected Received headers from email reception logs spanning nine months and reconstructed the complete intermediate paths of 105M clean emails. Our results reveal that Microsoft is the dominant provider of intermediate paths, participating in 66.4% of emails. We find that 86.9M (82.7%) emails rely on third-party providers in intermediate paths, and 9.1M (8.7%) paths involve multiple providers. Email signature providers frequently appear in cross-vendor intermediate paths. In addition, we reveal significant differences in the regional dependencies and centralization of intermediate paths across countries and continents. The centralization observed in intermediate paths also differs from incoming and outgoing servers. We hope our work prompts more attention to intermediate paths to enhance the security of the email ecosystem.
The global PKI supports the issuance of Unicerts, which are X.509 certificates that integrate internationalized content such as IDNs and multilingual text. This integration introduces complexity in Unicert issuance and usage. Past incidents showed that poor Unicode handling can cause security risks, including spoofing and remote code execution, yet threats specific to PKI and Unicerts remain underexplored. This paper presents the first large-scale study of Unicerts, examining both issuance and parsing compliance. By analyzing 34.8 million Unicerts from CT logs and 9 mainstream TLS libraries, we found the PKI ecosystem struggles with adopting Unicode. On the issuing side, 373 issuers produced 249.3K (0.72%) noncompliant Unicerts due to weak validation on character ranges, normalization, and formatting, of which 65.3% arise from publicly trusted CAs. These issues arise from overly complex standard requirements. On the parsing side, TLS libraries like GnuTLS and PyOpenSSL exhibited issues in decoding and handling special characters, such as incompatible decoding and improper escaping, which could lead to incorrect entity extraction or subfield forgery. We further empirically identified threat surfaces, including user spoofing, CT monitor misleading, and traffic obfuscation. Finally, we analyzed root causes and proposed recommendations to enhance Unicert compliance in the global PKI ecosystem.
Precise timekeeping is crucial for the dependable functioning and security of multiple Internet infrastructures, such as TLS certificates. Although the Network Time Protocol (NTP) is widely used for time synchronization across devices, it has several security vulnerabilities. Network Time Security (NTS) offers server authentication and integrity verification to protect against man-in-the-middle attacks. However, NTS does not address issues related to erroneous time sources. In this work, our objective is to measure the time source vulnerabilities in the NTP ecosystem. We begin by building a long-term, large-scale dataset of open NTP and NTS servers. Based on the dataset, we find that 16.4% of open NTP servers are bad timekeepers. For NTP Pool servers and refid servers, two subsets that are more likely to serve clients, the proportions are lower, with only 0.2% and 5.0% being bad timekeepers, respectively. Among these bad timekeepers, 92.1% are due to synchronization anomalies, and 6.7% are due to low-quality time sources, which are also reported by the NTP operators we surveyed. More concerningly, we uncover two security risks arising from time source configurations that could be exploited for time-shifting attacks. Our study encourages the NTP community to focus on the accuracy and security of time sources.