MAT Working Group Minutes - RIPE 93
Date: Tuesday, 27 October 2026, 16:00–17:30 (UTC+2)
Location: Main Room, RIPE 93, Sofia, Bulgaria
Working Group Chairs: Massimo Candela and Stephen Strowes
Scribe: Anastasiya Pak
Status: Draft
https://ripe93.ripe.net/programme/meeting-plan/sessions/136/
https://ripe93.ripe.net/programme/meeting-plan/sessions/136/transcript/
https://ripe93.ripe.net/programme/meeting-plan/sessions/136/chat/
Welcome
Massimo Candela and Stephen Strowes, MAT Working Group Chairs
Massimo Candela opened the MAT Working Group session by welcoming attendees and introducing Stephen Strowes as his fellow co-chair. He explained that the Working Group provides an opportunity for researchers from academia and industry to present their work to network operators, receive feedback and use that feedback to guide further research and tool development.
Massimo encouraged participants to ask questions, state their names and affiliations at the microphones, and rate the presentations. He highlighted the packed agenda and noted that the research being presented had been peer-reviewed.
The chairs encouraged participants to continue discussions on the MAT Working Group mailing list.
The Internet's Path MTUs: How Big Can You Go?
Vaishnavi Raghavajosyula, Max Planck Institute for Informatics
Tobias Fiebig, TU Wien
Vaishnavi Raghavajosyula presented research examining Path Maximum Transmission Units (PMTUs) across the Internet and how they affect efficient packet transmission. She explained that PMTU determines the largest packet size that can travel from one endpoint to another without fragmentation. Selecting an appropriate packet size is particularly important for IPv6, where routers cannot fragment packets in transit.
Vaishnavi explained that Path MTU Discovery (PMTUD) is frequently unreliable because the network messages required to identify packet-size limitations may be filtered or lost. As a result, applications often fall back to conservative packet sizes, reducing transmission efficiency even when the underlying network could support larger packets.
The research aimed to provide a data-driven understanding of actual PMTU values across Internet paths. The team used RIPE Atlas to conduct measurements across approximately 76,700 paths, including access networks, Internet core paths and paths towards web-serving infrastructure. Their traceroute-based methodology did not depend on successful PMTUD signalling or TCP Maximum Segment Size (MSS) inference.
The measurements identified 97 distinct PMTU values. A value of 1,500 bytes dominated, accounting for approximately 80.5% of measured paths. The next most common values were 1,492 bytes, representing 11.7%, and 1,480 bytes, representing 1.5%. The researchers also observed differences between IPv4 and IPv6 paths and between access networks and the Internet core.
Vaishnavi explained that smaller PMTU values were primarily associated with network edges, where technologies such as PPPoE and tunnelling introduce additional overhead.
The researchers also identified differences between forward and reverse PMTUs. Vaishnavi explained that paths between the same endpoints could support different maximum packet sizes depending on the direction of traffic. The findings suggested that applications and protocols could improve efficiency through path-specific or protocol-specific packet sizing rather than relying exclusively on conservative defaults.
She concluded that optimistic probing, combined with data-driven fallback values, could allow implementations to make better use of available network capacity without sacrificing reachability.
Giovane Moura, SIDN Labs and TU Delft, thanked Vaishnavi for the presentation and asked whether the researchers had compared their findings with earlier DNS research investigating the maximum practical size of DNS queries and responses. Giovane referred to previous work on DNS packet sizes and wanted to know whether the results had influenced the researchers' methodology.
Vaishnavi confirmed that the team had reviewed previous DNS-related measurements. She mentioned earlier recommendations suggesting a DNS packet size of approximately 1,232 bytes when using EDNS. However, she explained that the researchers had not based their measurements on DNS queries or responses. Previous studies often used multiple vantage points querying a particular server, whereas the team's objective was to investigate a broader variety of Internet paths.
The research therefore complemented previous DNS studies while addressing some of their limitations. Giovane confirmed that his question concerned whether the comparison had been made and thanked her for the clarification.
Stephen Strowes, MAT Working Group Co-Chair, asked a follow-up question about the reliability of PMTUD. He noted that Packet Too Big messages frequently fail to reach their intended recipients, making traditional PMTU discovery notoriously unreliable. He asked whether the researchers had collected data that could quantify this problem.
Vaishnavi replied that only around 30% of the measured paths had supplied PMTU information through the relevant network messages. She explained that the proportion varied substantially between path categories, with access paths accounting for most of the useful messages. In contrast, web and core paths produced relatively few responses, with figures around 5–7% or lower.
She said that the limited availability of these messages supported the need for measurement approaches that did not depend on PMTUD. By actively testing packet sizes and using network hints when available, the researchers could obtain information even when conventional discovery messages were missing. Stephen thanked Vaishnavi for the explanation. No further questions were raised.
LightScope: Turning Production Machines into Telescopes and Honeypots
Eric Kapitanski, USC Information Sciences Institute
Eric Kapitanski presented remotely LightScope, a lightweight system designed to turn unused ports on production machines into network telescopes and honeypots.
Eric explained that researchers traditionally study malicious Internet activity using network telescopes and honeypots deployed in unused IP address space, often called dark space. However, attackers may recognise established monitoring infrastructure and behave differently when targeting real production systems. LightScope aims to address this limitation by collecting information about unwanted traffic reaching unused ports on operational machines.
LightScope offers two modes of operation. In passive telescope mode, it collects information about traffic arriving at unused ports without interfering with legitimate services. In honeypot mode, selected unused ports accept connections and transparently forward traffic to a remote honeypot. This allows researchers to observe attempted logins, commands and other potentially malicious behaviour without hosting the honeypot directly on the production machine.
Eric emphasised that the system was designed to have low resource requirements so that operators could deploy it safely alongside existing applications. He reported that LightScope had been running on approximately 200 National Research Platform nodes for eight months without issues, while some cloud deployments had been operating for more than two years.
The study analysed data from 235 LightScope deployments and compared the observations with seven other datasets. The researchers discovered that attackers interacted differently with production machines than with conventional dark-space monitoring systems. They also found that individual machines within the same production network could receive substantially different scanning and attack traffic.
LightScope exclusively observed approximately 64,686 scanners that were not visible in the other datasets used for comparison. Eric also demonstrated that scanners progressing to attempted authentication and command execution were significantly less visible to conventional monitoring infrastructure than scanners merely sending TCP SYN packets.
He explained that LightScope did not replace traditional telescopes, which remained essential for broad visibility across the Internet. Instead, it provided complementary information about targeted behaviour and interactions with production infrastructure.
Eric encouraged network operators to deploy LightScope, including on virtual machines if they preferred not to install it directly on production servers. He noted that the software was open source and welcomed feedback and contributions from the community.
Jasper den Hertog, NLnet Labs, asked why LightScope did not support backscatter traffic. He wanted to know whether the limitation resulted from the computational resources required to process backscatter or whether the architecture fundamentally prevented such measurements.
Eric replied that backscatter support had initially been included during development. However, the processing requirements were higher than he considered appropriate for software running on production machines. He explained that the design prioritised keeping resource consumption low and avoiding interference with existing services.
Eric said he was investigating more efficient ways to support backscatter and might introduce the functionality in a future update. He encouraged potential users to explain which features would make deployment more attractive, adding that he would consider prioritising backscatter support if operators indicated that it would influence their willingness to deploy LightScope.
Jasper followed up by asking what additional information backscatter would provide. He noted that CAIDA relies heavily on backscatter observations and asked how LightScope's capabilities differed from those of large network telescopes.
Eric explained that CAIDA monitors a much larger IP address range and can therefore observe substantial amounts of backscatter associated with distributed denial-of-service attacks and spoofed source addresses. LightScope, by comparison, was deployed on only 235 endpoints at the time of the study. Consequently, it was unclear how much backscatter traffic such a limited deployment would receive.
Eric suggested that LightScope might observe backscatter if attackers spoofed addresses belonging to participating production machines. However, he did not yet know whether this would reveal new attack techniques or particularly useful information. He acknowledged that this was an interesting question but said further experimentation would be necessary before drawing conclusions.
Jasper thanked Eric and indicated that NLnet Labs would consider deploying LightScope. Massimo Candela, MAT Working Group Co-Chair, thanked Eric for the presentation and discussion. There were no further questions.
The State of ECN Adoption in the Internet
Danesh Zeynali, Max Planck Institute for Informatics
Danesh Zeynali presented research investigating the adoption of Explicit Congestion Notification (ECN) across the Internet. He explained that ECN enables routers to signal congestion by marking packets before buffers overflow and packet loss occurs. This allows endpoints to adjust their sending rates without relying exclusively on packet loss as an indication of congestion.
Danesh noted that ECN has existed for more than two decades, but several developments have made renewed measurements necessary. These include increased IPv6 deployment, broader operating-system support for ECN and the emergence of Low Latency, Low Loss and Scalable Throughput (L4S) technology.
He highlighted interest in L4S from cloud gaming providers, operating-system vendors and broadband operators. In particular, he mentioned developments involving Nvidia GeForce NOW, Apple services and Comcast. These deployments demonstrated the growing importance of understanding whether Internet endpoints and intermediate network devices correctly preserve ECN signalling.
The researchers investigated ECN adoption using active and passive measurements. For endpoint measurements, they assembled target addresses from popular website lists, university websites and an IPv6 hitlist. They then conducted measurements from seven vantage points distributed across different continents, testing whether servers successfully negotiated ECN during TCP connection establishment.
Danesh reported that more than 90% of the measured endpoints supported ECN. However, approximately 2–3.5% failed to negotiate it consistently. He noted that most large infrastructure providers supported ECN, although some autonomous systems, including systems operated by major providers, showed limited or inconsistent support.
The study also examined ECN bleaching, in which routers or middleboxes remove or modify ECN markings. The researchers used active measurements to determine whether ECN bits were preserved along network paths. Approximately 90% of measured paths preserved the markings, while the remaining paths exhibited some form of interference.
Danesh explained that ECN bleaching often involved removing the markings entirely rather than changing between ECN codepoints. This prevented the congestion notification mechanism from operating as intended, even when the endpoints themselves supported it.
He added that passive measurements indicated increasing ECN adoption over time. He concluded by encouraging network operators to examine ECN support within their own networks, particularly given the growing interest in L4S and other congestion-control developments.
Stephen Strowes, MAT Working Group Co-Chair, asked whether the researchers had identified differences between IPv4 and IPv6 transit networks regarding ECN bleaching. He was particularly interested in whether the same transit networks removed ECN markings in both protocols or whether the behaviour differed between IPv4 and IPv6.
Danesh replied that ECN bleaching occurred less frequently on IPv6 paths than on IPv4 paths in their measurements. He suggested that newer IPv6 deployments might have more appropriate configurations, potentially explaining why fewer intermediate devices removed ECN markings.
However, Danesh emphasised that this was only a possible explanation. The measurements established a difference in observed bleaching rates but did not definitively identify the operational reasons behind it.
Stephen thanked Danesh for the clarification. No more questions were raised.
BigTime: Characterizing Large Time Service Providers
Pascal Huppert, University of Twente
Pascal Huppert presented BigTime, a research project investigating the characteristics of large Internet time synchronisation services. He explained that accurate time is essential for many Internet applications, including certificate validation, logging, caching, RPKI and other security mechanisms.
Pascal noted that billions of devices depend on Network Time Protocol (NTP) services operated by large technology companies. Operating systems and devices are often configured to use their vendors' time services by default, creating a degree of centralisation and dependency on a relatively small number of providers.
The research examined seven major time service providers: Amazon, Apple, Cloudflare, Google, Meta, Microsoft and Ubuntu. The team investigated their replication architectures, client mapping, time accuracy, availability and support for security features.
Pascal explained that providers can distribute their time services using DNS-based server selection, IP anycast or local load balancing. The researchers used RIPE Atlas to collect DNS responses from different vantage points and publicly available anycast data to investigate how providers distributed their services geographically.
The measurements identified three broad architectural approaches. Amazon and Apple relied primarily on DNS-based distribution using multiple addresses. Cloudflare, Google and Meta relied heavily on anycast. Microsoft and Ubuntu used relatively small numbers of addresses without extensive anycast distribution.
Pascal highlighted the importance of providing multiple time servers to clients. If a client receives only one server address, it becomes dependent on that server's accuracy and availability. Multiple independent servers would allow clients to detect discrepancies and reduce the risk of synchronising to an incorrect clock.
He reported that Microsoft's time service had twelve IPv4 addresses but no native IPv6 addresses in the measurements. He also discussed time accuracy, noting that three Microsoft servers in Western Europe had exhibited offsets of approximately 40–50 milliseconds during one measurement period.
The study further examined support for NTP versions and security mechanisms. Pascal reported that Microsoft continued to offer NTP version 3, while other providers used newer implementations. Network Time Security (NTS) was supported only by Cloudflare and Ubuntu among the services examined. RPKI support was relatively widespread, while DNSSEC adoption remained limited.
Pascal concluded that large time service providers could improve reliability and security through relatively straightforward changes, including better geographic distribution, returning multiple server addresses, identifying their reference time sources and supporting more modern security features.
Jen Linkova, Google, commented on Pascal's observation that Microsoft's time service lacked native IPv6 support. She agreed that the lack of IPv6 was unfortunate but cautioned against suggesting that devices operating on IPv6-only networks would necessarily be unable to synchronise their clocks.
Jen explained that IPv6-only devices could still access IPv4-only services through translation mechanisms such as CLAT. She gave an example from her own experience, explaining that she had successfully synchronised time on a Mac operating in an IPv6-only environment.
Massimo Candela suggested that the participants continue investigating the issue after the session and thanked Pascal for the presentation. No further questions were raised.
Rooting Out Incorrect RIPE Atlas Probe Geolocations
Katherine Izhikevich, University of California, San Diego
Katherine Izhikevich presented research investigating incorrect geolocation information associated with RIPE Atlas probes. She explained that Internet researchers frequently rely on probe locations reported by operators, and that inaccurate information can lead to incorrect conclusions about latency, network performance and geographic connectivity.
Katherine introduced the problem with an example of a probe registered as being located in Germany. Initially, its latency measurements were consistent with that location. However, after the probe had been offline for a period, it began reporting round-trip times to Singapore that were too low to be physically possible if it were still in Germany.
Further investigation revealed that the probe had moved to Brunei without its registered location being updated. Katherine explained that this illustrated how a probe could remain incorrectly geolocated for a substantial period and potentially affect research using its measurements.
The researchers developed a methodology using existing RIPE Atlas measurements to DNS root servers. By identifying the responding root server instance and calculating the minimum physically possible round-trip time between the reported locations, the team could identify probes whose measurements violated propagation-delay constraints.
The study examined measurements collected between January 2019 and April 2026 and identified 731 probes with demonstrably inconsistent location information. The researchers conservatively estimated that at least 2% of RIPE Atlas vantage points had been incorrectly geolocated during the study period.
Katherine reported that the location discrepancies could be significant. Approximately 25% of the identified probes were between 100 and 330 kilometres away from their reported locations, while around half were more than 700 kilometres away.
The researchers examined possible reasons for incorrect geolocation. Approximately 41% of the identified probes had stale locations that were eventually corrected, while 23.5% had been configured with incorrect locations from the beginning but were subsequently updated. The remaining 35.5% continued to report locations inconsistent with the measurements.
The team worked with the RIPE NCC to contact affected probe operators. As a result, 93 operators updated their reported locations. However, ten operators disputed the findings. Katherine explained that some cases involved virtual machines being migrated between data centres without their operators being aware of the move.
She concluded by introducing a publicly available dataset and methodology that researchers could use to check whether RIPE Atlas probes had potentially incorrect geolocation information. She encouraged researchers to consult these resources when selecting measurement vantage points.
Stephen Strowes, MAT Working Group Co-Chair, began the discussion by admitting that he had personally experienced the problem. He explained that one of his hardware probes had moved between locations and that he had sometimes taken time to update its registered geolocation.
Stephen asked whether the researchers had identified particular categories of RIPE Atlas probes that were more likely to report incorrect locations. He wanted to know whether the risk was related to probe type, age or other identifiable characteristics.
Katherine replied that software probes were approximately three times more likely to violate the physical location constraints than hardware probes. She explained that this was consistent with software probes being easier to move, including between hosting environments or virtual machines.
She added that younger probes were also more likely to have incorrect geolocation information, while older probes tended to remain in the same place. Katherine referred to additional analysis supporting these findings and explained that the differences were useful for understanding the sources of location inaccuracies.
Joe Abley, Cloudflare, then offered a clarification about one of the virtual machine migration examples mentioned during Katherine's presentation. He explained that the abbreviation KW, appearing in a Canadian location reference, was associated with the Kitchener-Waterloo area of southwestern Ontario.
Joe suggested that this could explain the location information associated with the virtual machine and its apparent migration in the Toronto region. His comment was intended to help interpret the geographical reference rather than challenge the research findings.
Katherine thanked Joe for the clarification and acknowledged that it helped explain the example. The exchange illustrated how infrastructure naming conventions and location identifiers can complicate investigations into virtual machine movement.
Martin Pels, RIPE NCC, asked whether the researchers had verified the locations of the DNS root server instances used as reference points in their measurements.
Katherine explained that the researchers had used CAIDA Ark probes to measure DNS root server instances and investigate whether their observed latency was consistent with their reported locations. The researchers identified one DNS root server instance that appeared to be incorrectly geolocated. Katherine explained that the instance was reported as being in Concepción, Chile, but the measurements suggested that it was probably located in Santiago.
Katherine added that the team had consulted DNS root server operators, who generally expressed confidence in the locations of their infrastructure. Nevertheless, the discovery of a potentially mislocated instance demonstrated the importance of checking reference locations when using physical distance constraints to identify probe geolocation errors. Martin thanked her for the explanation.
Giovane Moura, SIDN Labs and TU Delft, asked whether the reported number of incorrectly geolocated probes should be interpreted as a lower bound. He wanted to know what the researchers could conclude about probes that had not been identified as violating the physical constraints.
Katherine confirmed that the results represented a conservative lower bound. She explained that the methodology used the shortest theoretically possible path and the propagation speed of light to identify measurements that could not be consistent with the reported geographic locations. The objective was to identify clear and substantial errors rather than estimate the precise position of every probe.
She noted that additional probes could have incorrect locations without producing impossible round-trip times. For example, a probe could be located in a different city or elsewhere within the same country and still produce latency measurements compatible with the reported location.
Katherine emphasised that the researchers had deliberately avoided introducing uncertainty by making assumptions about less obvious cases. Their priority was to identify probes with demonstrably incorrect locations that researchers should be cautious about using. She therefore confirmed that the findings did not represent the total number of incorrectly geolocated probes in RIPE Atlas.
Stephen thanked Katherine for the presentation and the discussion.
RIPE NCC Update
Robert Kisteleki, RIPE NCC
Robert Kisteleki presented the regular RIPE NCC update covering developments in the Routing Information Service (RIS), RIPEstat and RIPE Atlas. He reviewed improvements introduced since the previous RIPE Meeting and outlined ongoing work and plans for 2027.
Robert began with RIS, explaining that the service had undergone a significant hardware migration from on-premises infrastructure to rented hardware. The migration had improved operational stability and led to additional monitoring and service health metrics.
He noted that the RIPE NCC had been publishing more detailed operational status updates to keep users informed about issues affecting RIS. He also referred to presentations earlier during RIPE 93 covering the renewed RISwhois service and the RIS peering strategy, encouraging participants to review them and provide feedback.
Robert highlighted the continued availability of RIS data in Parquet format, which was intended to simplify processing and analysis in large-scale data pipelines. He referred attendees to the RIPE NCC Draft Activity Plan and Budget 2027 for further information about planned developments.
Turning to RIPEstat, Robert explained that the team had continued improving monitoring and alerting. He noted that the service depended on complex underlying systems and databases, making reliability improvements an important ongoing activity.
He highlighted improvements to the Looking Glass functionality, including the addition of BGP community information. The team had also been replacing older RIPEstat widgets with updated implementations to improve security and maintainability.
Robert reported improvements to the Routing History feature and noted that Upstream Visibility had become significantly faster following the removal of performance bottlenecks. He encouraged users to provide feedback on the Routing History functionality and explain which additional capabilities would be useful.
The largest part of the update focused on RIPE Atlas. Robert explained that the user interface had undergone extensive modernisation, with pages rebuilt around API-based functionality. This had improved performance and made the platform easier to use.
He described a new quick-start experience for users unfamiliar with RIPE Atlas, including guidance on creating measurements. He also highlighted improvements to RIPE Atlas anchor self-management, allowing operators to update certain details without requiring manual intervention from the RIPE NCC.
Robert introduced several RIPE Atlas use cases designed to simplify common measurement activities. These included domain monitoring, reachability testing, multipath visualisation, regional meshes, path divergence analysis, probe connectivity monitoring and anchor mesh status.
The domain monitoring functionality allows users to configure measurements of DNS zones through a simplified interface. Reachability testing provides a quick way to investigate whether a target is reachable from different locations, while multipath visualisation helps identify routing paths and potential bottlenecks.
Robert explained that regional meshes were intended to investigate whether traffic between probes in the same country or region remained local. Other tools allowed users to visualise differences in network paths, examine correlated connectivity problems and monitor the status of measurements between RIPE Atlas anchors.
He also previewed a planned visibility monitoring tool that could help operators determine whether their network prefixes were reachable from expected geographic locations. The tool would compare observed data-plane reachability with operator-defined expectations, potentially helping identify unexpected routing behaviour.
Robert described additional API improvements, new measurement capabilities and tools to reduce probe-selection bias. He highlighted a feature designed to help users select more diverse probes rather than concentrating measurements in areas with a high density of available vantage points.
He also presented the automatic probe replacement functionality, which allows long-running measurements to maintain their desired number of participating probes. When probes become unavailable, the system can automatically select suitable replacements, reducing the need for manual intervention.
Robert discussed software probe improvements, measures to discourage probe farming and firmware upgrades. He encouraged operators to keep their probes updated for security and reliability reasons.
Finally, he outlined work on a bring-your-own-device approach to RIPE Atlas probes. The concept would allow users to install a prepared image on supported hardware, such as Raspberry Pi devices, and operate them as RIPE Atlas probes. Robert explained that this could reduce dependence on hardware distribution and help address supply-chain limitations.
Robert concluded by encouraging the community to review the RIPE NCC's draft plans for 2027 and provide feedback while priorities and activities could still be adjusted.
Gert Döring thanked Robert and the RIPE NCC team for implementing the automatic probe replacement functionality.
Gert explained that he had been requesting this feature for approximately ten years and was pleased that it was now available.
Robert thanked Gert for the feedback and explained that the functionality had already been available for some time, but that the presentation gave him an opportunity to highlight it to the wider community.
Stephen Strowes asked whether there were any further questions. None were raised, and he thanked Robert for the update.
Closing Notes
Massimo Candela and Stephen Strowes, MAT Working Group Chairs
Stephen Strowes closed the MAT Working Group session by thanking all presenters and attendees for their participation. He reflected on the range of topics covered.
Stephen encouraged participants to rate the presentations, explaining that this feedback was useful to the Working Group Chairs. He also invited attendees to continue technical discussions on the MAT Working Group mailing list and encouraged submissions for RIPE 94.