Introduction

How can Internet measurements be used to keep track of the current status of the Internet? Measurements can be divided between active and passive ones. Active measurements rely on information gathering by sending packets to f.e. Internet-connected devices and evaluating their responses. Active measurements have several use cases. CERTs (Computer-Emergency-Response Teams) and threat actors scan the Internet for vulnerabilities. Measurements allow to monitor the protocols used by Internet-connected devices to communicate with each other. Connecting to a service allows to verify if the service supports a certain protocol feature or not, i.e. connecting to an email server allows to verify if it supports encrypting emails in transit or not. Connecting to all accessible email servers can then be used to draw a global picture of transport encryption for email. Passive measurements on the other hand, rely on data collectors and are used to for example monitor DNS (Domain-Name-System) resolution, the process of translating human-readable names in IP addresses and vice versa. BGP (Border-Gateway-Protocol) route collectors provide insights on how packets are routed in the Internet. To sum up, Internet measurements add a great layer of transparency in a world of ubiquitous networking. Ubiquitous networking also introduced new challenges. First, we put higher demands on service availability. Related work highlighted the ongoing move to cloud services and the reduction of on-premise hosting [1]. The responsibility for our data being available and secure at all time is put to a handful of operators. While protocol designers began to consider security during the design process, operators were found to take a conservative stance on protocol security features with increased complexity [2]. This opens up a gap on how systems are designed to be used and how they are actually used. Secondly, users trust that data is properly secured, no matter if in transit or at rest. However, a lot of today’s standard origins can be traced back to the origins of the Internet. Since then a lot of these have received numerous additions and updates to cover the gaps they were not originally designed to fulfill. This emphasizes the need for Internet measurements on whether and how these additional features are used by operators. The Figure shows the increase in email and DNS-related standards over time. For example, nowadays over 500 different standards are at play when an email is sent, yet to the average user, this process is as simple as a few clicks in the browser or email-client.

Protocol Adoption

RFCs (Request For Comments), managed by the IETF (Internet Engineering Task Force) describe the protocols used in the Internet and are published as text documents. The first documents exist since the beginning of the Internet. With an increasing number of Internet-connected devices, the requirements for those protocols also changed. For example email servers were originally built without authentication, allowing anyone to relay their emails through them. The requirements for email servers changed when people figured out how to abuse this to send their free advertisements. Today RFCs include a security section, evaluating how attackers could interfere with respective protocols. RFCs on their own can also update older standards, f.e. by adding additional features as authentication or encryption to protocols that were originally designed without. Because it is difficult to replace an already well established standard in the Internet ecosystem, it is more practical to carefully adapt it. Thus, I plan to investigate how operators adopt these protocol additions and how to help them to run their setups in full standard compliance. Because there are many different technologies used in the Internet, I rely on a selection– beginning with one that represents one of the oldest types of communication in the Internet– email.

The first research question has been partly treated by my first paper Not that Simple: Email Delivery in the 21st Century [3]. To measure email standard adoption a test-bed of multiple email and DNS server were created. We configured different email addresses relying on different systems. While this is a passive measurement system it requires active user interaction to receive emails. By actively promoting the measurement system over different channels (social media, presentations, blog posts) emails from different providers and different countries were collected. Received emails are then parsed and evaluated based on whether the sender is delivering emails to a specific target or not. This allows to verify if a provider supports a certain standard or not. In terms of security features we also configured email addresses where the optimal case is that the sender should refrain from sending emails, i.e. an address with an invalid TLSA record (simulating a strict TLS error). In my future research I plan to adapt the measurement infrastructure to measure new standards and evaluate how to support operators to run their infrastructure in full standard compliance. The platform is now open to the Internet community under www.email-security-scans.org. In the Figure you can see a screenshot of the report you receive during a test of your email provider. In my future research I plan to adapt the measurement infrastructure to also include newer standards such as ARC, display information on how to reach a better scoring and show further statistics on standard adoption.

IPv6 Measurements

In addition the underlying network layer changed. With the increasing number of Internet-connected devices the length of IP addresses was increased from 32 to 128 bit in IPv6. This also means the size of the address space increased from 4.3 billion addresses to an indescribable great number. As a consequence active IPv6 measurements were considered nonfunctional. While passive measurements were unaffected there is need for further research for scanning methodologies for active measurements in IPv6.

The probability of hitting an active IPv6 address by chance is virtually zero; instead, it appears more promising to analyze ICMPv6 error messages that are returned in case of an undeliverable packet. In my second paper "Destination Reachable: What ICMPv6 Error Messages Reveal About Their Sources" I investigate the implementation of ICMPv6 error messages by different router vendors, whether a remote network’s deployment status might be inferred from them, and analyze ICMPv6 error messaging behavior of routers in the IPv6 Internet [4]. 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 inactive networks. Furthermore, we found that ICMPv6 rate-limiting implementations, used to protect routers, allow the fingerprinting of vendors and OS-versions. The code to measure ICMPv6 error messages and error message rate limits is publicly availble: https://github.com/sbaresearch/icmpv6-destination-reachable. In the Table we can see the router vendor implementations of error message type 1 "Destination Unreachable" code 0 "No route to destination". Based on RFC4443 this code should pinpoint inactive networks, indicating that the router had no matching in the routing table for the destination address. However, it is also used by Mikrotik in the presence of Access-Control-Lists. Thus, without knowing the router vendor, we do not know if the network behind the router is active or not.

Current Status

Gaps in Internet standardization also arise, when standards are not used for their original purpose. ICMP, also known for Ping, was designed to diagnose the connection between two nodes on the Internet. However, what information is revealed when using ICMP to test the connectivity of all IP nodes inside a country? With enough location points for Internet devices, these IP nodes also provide relevant information to track f.e. war or natural disasters. There have been first attempts that measured the impact of hurricane Sandy, but they still lack accuracy [5]. Further research is necessary to improve both accuracy and detection which device and network properties are impacted by natural disasters. The same methodology can also be used to track Internet outages during kinetic warfare. Finally, in my dissertation I explore the widespread adoption of the ICMP protocol to do exactly this, track the Internet connectivity of a country through large-scale ping measurements.

References

[1] Tobias Fiebig, Seda Gürses, Carlos H Gañán, Erna Kotkamp, Fernando Kuipers, Martina Lindorfer, Menghua Prisse, and Taritha Sari. Heads in the clouds: measuring the implications of universities migrating to public clouds. arXiv preprint arXiv:2104.09462, 2021.

[2] Yoshiro Yoneya Masanori Yajima, Daiki Chiba and Tatsuya Mori. How prevalent is the operation of DNS security mechanisms? Retrieved Sept. 15, 2021 from https://indico.dns-oarc.net/event/39/contributions/867/

[3] Florian Holzbauer, Johanna Ullrich, Martina Lindorfer, and Tobias Fiebig. Not that simple: Email delivery in the 21st century. In 2022 USENIX Annual Technical Conference (USENIX ATC 22), pages 295–308, 2022.

[4] Florian Holzbauer, Markus Maier, and Johanna Ullrich. 2024. Destination Reachable: What ICMPv6 Error Messages Reveal About Their Sources. In Proceedings of the 2024 ACM Internet Measurement Conference (IMC ’24), November 4–6, 2024, Madrid, Spain. ACM, New York, NY, USA, 15 pages. https://doi.org/10.1145/3646547.3688420

[5] Zakir Durumeric, Eric Wustrow, and J Alex Halderman. Zmap: Fast internet-wide scanning and its security applications. In 22nd USENIX Security Symposium (USENIX Security 13), pages 605–620, 2013.