MAPRG - IETF 125 Meeting - 17 March 2026
Chairs: Mirja Kühlewind, Dave Plonka
Note takers: Pete Resnick, Tomek Mrugalski, Brian Trammell
Overview and Status - Mirja/Dave
https://datatracker.ietf.org/meeting/125/materials/slides-125-maprg-heads-up-talk-measurement-of-systemic-dns-resolver-vulnerabilities-informing-six-dnsop-i-ds-01
- Reviewed spec vulnerabilities - Found 90+ CVEs, 6 novel attacks,
evaluated 2.4M deployed servers
- DNSBomb attack - claim 100% implementations to be vulnerable
- RebithDay attack
- Result: 6 drafts proposed to DNSOP to address the problems
discovered.
No questions
Are you RPKI ready? the Road Left to Full ROA Adoption - Deepak Gouda (remote) (10 mins)
https://datatracker.ietf.org/meeting/125/materials/slides-125-maprg-are-you-rpki-ready-the-road-left-to-full-roa-adoption-01
- Reviews of RPKI principles and consensus around adoption of RPKI
- Adoption is over 50% at this point (a bit higher for IPv6 than for
IPv4), but what will it take to get the rest of the deployment?
- Turns out adoption is relatively complex, but technical and
non-technical reasons
- Explains the problem with more specific prefixes needing their own
ROAs
- Created a framework(https://ru-rpki-ready.iss.cc.gatech.edu) for
issuing ROA including planning and deployment, provided a survey of
questions, and then a platform to collect answers to the questions
and gives instructions for how to deploy
- Analysis of the prefixes that don't have ROAs: some that currently
don't have ROAs had them in the past; formal difficulties for US
govt organizations to issue certificates
No questions
RScope: Unveiling Global ROV Deployments and Dependencies in the Post-ROV Era - Weitong Li (10 mins)
https://datatracker.ietf.org/meeting/125/materials/slides-125-maprg-rscope-unveiling-global-rov-deployments-and-dependencies-in-the-post-rov-era-00
- Another quick overview of RPKI (this one also explaining ROV=Route
Origin Validation)
- Two questions: 1) How do ops use the ROA? 2) How is RPKI used to
protect against bad traffic?
- We are seeing less vulnerabilities with deployment of ROV, so how do
we measure?
- Give different ROAs (some invalid) to different relying parties
- Able to distinguish between local vs. upstream filtering
Deepak: What problems might occur if you follow the RFC and deploy
multiple relying parties?
Weitong: We are trying to test different combinations of multiple RPs.
What IPv6 RFCs Don't Say About VPNs - Yejin Cho (remote) (10 mins)
https://datatracker.ietf.org/meeting/125/materials/slides-125-maprg-what-ipv6-rfcs-dont-say-about-vpns-02
- IPv6 capable != IPv6 preferred; there's a gap, and IPv4 is often
preferred
VPNs de-prefer v6 quite severely
- Analyzed 40M logs from users using 123 different VPNs
- some VPN implementors use ULA for IPv6, seems they use it as
equivalent of private (RFC1918) address space in IPv4
- Proposed solutions: 1) assign unique GUA, 2) assign shared static
GUA, 3) create new address class TLA: tunnel local address (similar
to Teredo) - This is preferred; 4)Change the prioritization
- Authors recommend solutions 2 and 3.
Lorenzo Colitti: Think about which solution preserves e2e connectivity
and keeps amount of state low. Recommends reading RFC7934, also you can
run DHCPv6-PD. Concerns are about the tracking problem. Perhaps there
are ways to help.
Suresh Krishnan: Take this to 6man. If you want to create a new class,
6man is the place to go. This would affect address selection. They spent
years to get it right, tweaking it might be a challenge.
https://datatracker.ietf.org/meeting/125/materials/slides-125-maprg-understanding-and-characterizing-intermediate-paths-of-email-delivery-01
- Review of traditional email architecture and changes more recently
to include intermediate services (particularly between sending node
and outgoing node, what we call "middle nodes")
- Middle nodes can be vulnerable. But they are hard to study because
you can't see them from outgoing or incoming servers.
- Using Received headers to analyze middle node actions (studying data
from Coremail, large Chinese email supplier) - 105 million messages
in data set
- Find that most middle nodes belong to ESPs
- Find that many middle nodes for any given message involve multiple
SLDs
- Seeing big differences between dependencies on outside
intermediaries in different countries/regions
- Find high centralization of intermediaries; Microsoft is dominant
(HHI 70%).
- Analyzer is published on GitHub
No questions.
Analyzing Compliance and Complications of Integrating Internationalized X.509 Certificates - Mingming Zhang (15 mins)
https://datatracker.ietf.org/meeting/125/materials/slides-125-maprg-analyzing-compliance-and-complications-of-integrating-internationalized-x509-certificates-01
- Overview of PKI infrastructure
- Internationalized certs ("Unicerts") break things: Spoofing, Parsing
errors, Buffer overflows
- Asked 3 questions in this paper: 1) issuance compliance - the specs
(X.509, DNS & IDN specs...) evolve independently (used RFCGPT - a
custom AI agent trained on RFCs); 2) parsing accuracy; 3)real-world
impact
- 34.8M unicerts out of 70 billion certs dataset., identified 249K
problematic certs, problems: 1) improper char checks; 2) lack of
value normalization; 3)(See very dense data slides)
- Parsing accuracy (Tested 9 TLS libraries): thereotical expoits that
haven't been seen in the wild yet.
- User spoofing: Found Chrome warning can be corrupted by
bi-directional text
Mirja: did you reach out to any of the issuing orgs?
Mingming: we did talk to e.g. Let's Encrypt, got evasive answer
("technically correct")
Liwen Xu (ETHZ): q. on slide 22, vuln can be exploited to damage CT
monitoring. are you aware of an exploit or is this theoretical?
Mingming: no known exploit. Some monitors have mishandled (no search or
rendering) IDN names, so we assume implementations cannot handle these
names, and have blind spots.
Measuring the Time Source Vulnerabilities in the NTP Ecosystem - Zhentian Huang (15 mins)
https://datatracker.ietf.org/meeting/125/materials/slides-125-maprg-measuring-the-time-source-vulnerabilities-in-the-ntp-ecosystem-05
- Explaining MITM attack on NTP, introduced NTP security (NTS)
- Found around 7M open NTP servers.
- 1115k open servers are bad timekeepers. (bad = offset more than 10s)
- 92.1% open NTP servers suffer from anomalies.
- Sent surveys to 377 operators, got 40 replies.
- Single-source vulnerability attack (attacker poisons the upstream
response, using various techniques)
- Dangling IP address vuln (244 servers vulnerable to dangling IP
upstream)
- Possible mitigation - NTP pool
- NTxMon - presented results under various loads, promising especially
for high load scenarios
Karen O'Donohughe: please take this to the (ntp?) working group
Dave: would be nice to have a followup a meeting cycle or two later to
see how these sorts of connections lead to work in the IETF.