SearcharxivSearch

arXiv subjects

Oliver Gasser

Publications and source records attributed to Oliver Gasser.

At least 19 recordsLinked to original sources

IPv6 Hitlist Service: Lessons Learned From 10 Years of Operation

After becoming an Internet Draft more than 30 years ago, IPv6 has seen an increase in deployment and use in the past years. As measurements in the IPv6 Internet require new approaches due to the vastly larger address space, hitlists have come along as one possible source for finding IPv6 targets. One of the most prominent hitlists is provided by the IPv6 Hitlist Service. In this paper, we share insights from 10 years of operations of the IPv6 Hitlist Service: We show different evolutions of the service, highlighting important changes along the way. To better understand the representativeness of the hitlist, we perform a coverage analysis using real-world traffic data from a major central European ISP and Tier-1 network, finding that at least one address is known to the IPv6 Hitlist Service for 87.1 % of ASes and 56.5 % of /48 prefixes originating IPv6 traffic. We also share results from a conducted user survey and analyze users accessing the IPv6 Hitlist Service, finding diverse use cases and access patterns across time (e.g., one-off vs. continuous downloads) and available data (e.g., all vs. responsive addresses). Finally, we provide best practice recommendations when working with the hitlist and share lessons learned during its 10-year operation.

cs.NI

WHEREIS: IP Address Registration Geo-Consistency

The five Regional Internet Registries (RIRs) provide the critical function of IP address resource del egation and registration. The accuracy of registration data directly impacts Internet operation, management, security, and optimization. In addition, the scarcity of IP addresses has brought into focus conflicts between RIR policy and IP registration ownership and use. The tension between a free-market based approach to address allocation versus policies to promote fairness and regional equity has resulted in court litigation that threatens the very existence of the RIR system. We develop WHEREIS, a measurement-based approach to geolocate delegated IPv4 and IPv6 prefixes at an RIR-region granularity and systematically study where addresses are used post-allocation and the extent to which registration information is accurate. We define a taxonomy of registration ``geo-consistency'' that compares a prefix's measured geolocation to the allocating RIR's coverage region as well as the registered organization's location. While in aggregate over 98% of the prefixes we examine are consistent with our geolocation inferences, there is substantial variation across RIRs and we focus on AFRINIC as a case study. IPv6 registrations are no more consistent than IPv4, suggesting that structural, rather than technical, issues play an important role in allocations. We solicit additional information on inconsistent prefixes from network operators, IP leasing providers, and collaborate with three RIRs to obtain validation. We further show that the inconsistencies we discover manifest in three commercial geolocation databases. By improving the transparency around post-allocation prefix use, we hope to improve applications that use IP registration data and inform ongoing discussions over in-region address use and policy.

cs.NI

Multiple Sides of 36 Coins: Measuring Peer-to-Peer Infrastructure Across Cryptocurrencies

Blockchain technologies underpin an expanding ecosystem of decentralized applications, financial systems, and infrastructure. However, the fundamental networking layer that sustains these systems, the peer-to-peer layer, of all but the top few ecosystems remains largely opaque. In this paper, we present the first longitudinal, cross-network measurement study of 36 public blockchain networks. Over 9 months, we deployed 15 active crawlers, sourced data from two additional community crawlers, and conducted hourly connectivity probes to observe the evolving state of these networks. Furthermore, by leveraging Ethereum's discovery protocols, we inferred metadata for an additional 19 auxiliary networks that utilize the Ethereum peer discovery protocol. We also explored Internet-wide scans, which only require probing each protocol's default ports with a simple, network-specific payload. This approach allows us to rapidly identify responsive peers across the entire address space without having to implement custom discovery and handshake logic for every blockchain. We validated this method on Bitcoin and similar networks with known ground truth, then applied it to Cardano, which we could not crawl directly. Our study uncovers dramatic variation in network size from under 10 to more than 10,000 active nodes. We quantify trends in IPv4 versus IPv6 usage, analyze autonomous systems and geographic concentration, and characterize churn, diurnal behavior, and the coverage and redundancy of discovery protocols. These findings expose critical differences in network resilience, decentralization, and observability. Beyond characterizing each network, our methodology demonstrates a general framework for measuring decentralized networks at scale. This opens the door for continued monitoring, benchmarking, and more transparent assessments of blockchain infrastructure across diverse ecosystems.

cs.DC

Unveiling IPv6 Scanning Dynamics: A Longitudinal Study Using Large Scale Proactive and Passive IPv6 Telescopes

We introduce new tools and vantage points to develop and integrate proactive techniques to attract IPv6 scan traffic, thus enabling its analysis. By deploying the largest-ever IPv6 proactive telescope in a production ISP network, we collected over 600M packets of unsolicited traffic from 1.9k Autonomous Systems in 10 months. We characterized the sources of unsolicited traffic, evaluated the effectiveness of five major features across the network stack, and inferred scanners' sources of target addresses and their strategies.

cs.NI

Intractable Cookie Crumbs: Unveiling the Nexus of Stateful Banner Interaction and Tracking Cookies

In response to the ePrivacy Directive and the consent requirements introduced by the GDPR, websites began deploying consent banners to obtain user permission for data collection and processing. However, due to shared third-party services and technical loopholes, non-consensual cross-site tracking can still occur. In fact, contrary to user expectations of seemingly isolated consent, a user's decision on one website may affect tracking behavior on others. In this study, we investigate the technical and behavioral mechanisms behind these discrepancies. Specifically, we disclose a persistent tracking mechanism exploiting web cookies. These cookies, which we refer to as intractable, are initially set on websites with accepted banners, persist in the browser, and are subsequently sent to trackers before the user provides explicit consent on other websites. To meticulously analyze this covert tracking behavior, we conduct an extensive measurement study performing stateful crawls on over 20k domains from the Tranco top list, strategically accepting banners in the first half of domains and measuring intractable cookies in the second half. Our findings reveal that around 50% of websites send at least one intractable cookie, with the majority set to expire after more than 10 days. In addition, enabling the Global Privacy Control (GPC) signal initially reduces the number of intractable cookies by 30% on average, with a further 32% reduction possible on subsequent visits by rejecting the banners. Moreover, websites with Consent Management Platform (CMP) banners, on average, send 6.9 times more intractable cookies compared to those with native banners. Our research further reveals that even if users reject all other banners, they still receive a large number of intractable cookies set by websites with cookie paywalls.

cs.NI

Sibling Prefixes: Identifying Similarities in IPv4 and IPv6 Prefixes

Since the standardization of IPv6 in 1998, both versions of the Internet Protocol have coexisted in the Internet. Clients usually run algorithms such as Happy Eyeballs, to decide whether to connect to an IPv4 or IPv6 endpoint for dual-stack domains. To identify whether two addresses belong to the same device or service, researchers have proposed different forms of alias resolution techniques. Similarly, one can also form siblings of IPv4 and IPv6 addresses belonging to the same device. Traditionally, all of these approaches have focused on individual IP addresses. In this work, we propose the concept of "sibling prefixes", where we extend the definition of an IPv4-IPv6 sibling to two IP prefixe-one IPv4 prefix and its sibling IPv6 prefix. We present a technique based on large-scale DNS resolution data to identify 76k IPv4-IPv6 sibling prefixes. We find sibling prefixes to be relatively stable over time. We present SP-Tuner algorithm to tune the CIDR size of sibling prefixes and improve the perfect match siblings from 52% to 82%. For more than half of sibling prefixes, the organization names for their IPv4 and IPv6 origin ASes are identical, and 60% of all sibling prefixes have at least one of the prefixes with a valid ROV status in RPKI. Furthermore, we identify sibling prefixes in 24 hypergiant and CDN networks. Finally, we plan to regularly publish a list of sibling prefixes to be used by network operators and fellow researchers in dual-stack studies.

cs.NI

ECSeptional DNS Data: Evaluating Nameserver ECS Deployments with Response-Aware Scanning

DNS is one of the cornerstones of the Internet. Nowadays, a substantial fraction of DNS queries are handled by public resolvers (e.g., Google Public DNS and Cisco's OpenDNS) rather than ISP nameservers. This behavior makes it difficult for authoritative nameservers to provide answers based on the requesting resolver. The impact is especially important for entities that make client origin inferences to perform DNS-based load balancing (e.g., CDNS). The EDNS0 Client Subnet (ECS) option adds the client's IP prefix to DNS queries, which allows authoritative nameservers to provide prefix-based responses. In this study, we introduce a new method for conducting ECS scans, which provides insights into ECS behavior and significantly reduces the required number of queries by up to 97% compared to state-of-the-art techniques. Our approach is also the first to facilitate ECS scans for IPv6. We conduct a comprehensive evaluation of the ECS landscape, examining the usage and implementation of ECS across various services. Overall, 53% of all nameservers support prefix-based responses. Furthermore, we find that Google nameservers do not comply with the Google Public DNS guidelines. Lastly, we plan to make our tool, and data publicly available to foster further research in the area.

cs.NI

A First Look At NAT64 Deployment In-The-Wild

IPv6 is a fundamentally different Internet Protocol than IPv4, and IPv6-only networks cannot, by default, communicate with the IPv4 Internet. This lack of interoperability necessitates complex mechanisms for incremental deployment and bridging networks so that non-dual-stack systems can interact with the whole Internet. NAT64 is one such bridging mechanism by which a network 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. To date, our understanding of NAT64 deployments is limited; what little information exists is largely qualitative, taken from mailing lists and informal discussions. In this work, 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. For both datasets, 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 also posing potential security risks.

cs.NI

Packed to the Brim: Investigating the Impact of Highly Responsive Prefixes on Internet-wide Measurement Campaigns

Internet-wide scans are an important tool to evaluate the deployment of services. To enable large-scale application layer scans, a fast, stateless port scan (e.g., using ZMap) is often performed ahead of time to collect responsive targets. It is a common expectation that port scans on the entire IPv4 address space provide a relatively unbiased view as they cover the complete address space. Previous work, however, has found prefixes where all addresses share particular properties. In IPv6, aliased prefixes and fully responsive prefixes, i.e., prefixes where all addresses are responsive, are a well-known phenomenon. However, there is no such in-depth analysis for prefixes with these responsiveness patterns in IPv4. This paper delves into the underlying factors of this phenomenon in the context of IPv4 and evaluates port scans on a total of 161 ports (142 TCP & 19 UDP ports) from three different vantage points. To account for packet loss and other scanning artifacts, we propose the notion of a new category of prefixes, which we call highly responsive prefixes (HRPs). Our findings show that the share of HRPs can make up 70 % of responsive addresses on selected ports. Regarding specific ports, we observe that CDNs contribute to the largest fraction of HRPs on TCP/80 and TCP/443, while TCP proxies emerge as the primary cause of HRPs on other ports. Our analysis also reveals that application layer handshakes to targets outside HRPs are, depending on the chosen service, up to three times more likely to be successful compared to handshakes with targets located in HRPs. To improve future scanning campaigns conducted by the research community, we make our study's data publicly available and provide a tool for detecting HRPs. Furthermore, we propose an approach for a more efficient, ethical, and sustainable application layer target selection.

cs.NI

Thou Shalt Not Reject: Analyzing Accept-Or-Pay Cookie Banners on the Web

Privacy regulations have led to many websites showing cookie banners to their users. Usually, cookie banners present the user with the option to "accept" or "reject" cookies. Recently, a new form of paywall-like cookie banner has taken hold on the Web, giving users the option to either accept cookies (and consequently user tracking) or buy a paid subscription for a tracking-free website experience. In this paper, we perform the first completely automated analysis of cookiewalls, i.e., cookie banners acting as a paywall. We find cookiewalls on 0.6% of all queried 45k websites. Moreover, cookiewalls are deployed to a large degree on European websites, e.g., for Germany we see cookiewalls on 8.5% of top 1k websites. Additionally, websites using cookiewalls send 6.4 times more third-party cookies and 42 times more tracking cookies to visitors, compared to regular cookie banner websites. We also uncover two large Subscription Management Platforms used on hundreds of websites, which provide website operators with easy-to-setup cookiewall solutions. Finally, we publish tools, data, and code to foster reproducibility and further studies.

cs.NI

Illuminating Router Vendor Diversity Within Providers and Along Network Paths

The Internet architecture has facilitated a multi-party, distributed, and heterogeneous physical infrastructure where routers from different vendors connect and inter-operate via IP. Such vendor heterogeneity can have important security and policy implications. For example, a security vulnerability may be specific to a particular vendor and implementation, and thus will have a disproportionate impact on particular networks and paths if exploited. From a policy perspective, governments are now explicitly banning particular vendors, or have threatened to do so. Despite these critical issues, the composition of router vendors across the Internet remains largely opaque. Remotely identifying router vendors is challenging due to their strict security posture, indistinguishability due to code sharing across vendors, and noise due to vendor mergers. We make progress in overcoming these challenges by developing LFP, a tool that improves the coverage, accuracy, and efficiency of router fingerprinting as compared to the current state-of-the-art. We leverage LFP to characterize the degree of router vendor homogeneity within networks and the regional distribution of vendors. We then take a path-centric view and apply LFP to better understand the potential for correlated failures and fate-sharing. Finally, we perform a case study on inter- and intra-United States data paths to explore the feasibility to make vendor-based routing policy decisions, i.e., whether it is possible to avoid a particular vendor given the current infrastructure.

cs.NI

Pushing Alias Resolution to the Limit

In this paper, we show that utilizing multiple protocols offers a unique opportunity to improve IP alias resolution and dual-stack inference substantially. Our key observation is that prevalent protocols, e.g., SSH and BGP, reply to unsolicited requests with a set of values that can be combined to form a unique device identifier. More importantly, this is possible by just completing the TCP hand-shake. Our empirical study shows that utilizing readily available scans and our active measurements can double the discovered IPv4 alias sets and more than 30x the dual-stack sets compared to the state-of-the-art techniques. We provide insights into our method's accuracy and performance compared to popular techniques.

cs.NI

Analyzing IoT Hosts in the IPv6 Internet

Users and businesses are increasingly deploying Internet of Things (IoT) devices at home, at work, and in factories. At the same time, we see an increase in the use of IPv6 for Internet connectivity. Even though the IoT ecosystem has been the focus of recent studies, there is no comprehensive analysis of IoT end-hosts in the IPv6 Internet to date. In this paper we perform an in-depth analysis of IPv6-reachable IoT hosts using active measurements. We run measurements targeting 530M IPv6 addresses on six popular IoT-related protocols. With 36.4K hosts in 156 countries we find 380x fewer IoT-speaking end-hosts compared to IPv4. Moreover, we conduct a security analysis for TLS-enabled IoT-speaking hosts identifying up to 57% untrusted certificates, with up to 32% being self-signed and 25% being expired. Finally, we plan to publish our measurement results, tools, and a website dashboard to foster further research in the area.

cs.NI

Live Long and Prosper:Analyzing Long-Lived MOAS Prefixes in BGP

BGP exchanges reachability information in the form of prefixes, which are usually originated by a single Autonomous System (AS). If multiple ASes originate the same prefix, this is referred to as a Multiple Origin ASes (MOAS) prefix. One reason for MOAS prefixes are BGP prefix hijacks, which are mostly short-lived and have been studied extensively in the past years. In contrast to short-lived MOAS, long-lived MOAS have remained largely understudied. In this paper, we focus on long-lived MOAS prefixes and perform an in-depth study over six years. We identify around 24k long-lived MOAS prefixes in IPv4 and 1.4k in IPv6 being announced in January 2023. By analyzing the RPKI status we find that more than 40% of MOAS prefixes have all origins registered correctly, with only a minority of MOAS having invalid origins. Moreover, we find that the most prominent CIDR size of MOAS prefixes is /24 for IPv4 and /48 for IPv6, suggesting their use for fine-grained traffic steering. We attribute a considerable number of MOAS prefixes to mergers and acquisitions of companies. Additionally, more than 90% of MOAS prefixes are originated by two origin ASes, with the majority of detected origin AS relations being customer-provider. Finally, we identify that the majority of MOAS users are IT companies, and just 0.9% of IPv4 MOAS and 6.3% of IPv6 MOAS prefixes are used for anycast.

cs.NI

Target Acquired? Evaluating Target Generation Algorithms for IPv6

Internet measurements are a crucial foundation of IPv6-related research. Due to the infeasibility of full address space scans for IPv6 however, those measurements rely on collections of reliably responsive, unbiased addresses, as provided e.g., by the IPv6 Hitlist service. Although used for various use cases, the hitlist provides an unfiltered list of responsive addresses, the hosts behind which can come from a range of different networks and devices, such as web servers, customer-premises equipment (CPE) devices, and Internet infrastructure. In this paper, we demonstrate the importance of tailoring hitlists in accordance with the research goal in question. By using PeeringDB we classify hitlist addresses into six different network categories, uncovering that 42% of hitlist addresses are in ISP networks. Moreover, we show the different behavior of those addresses depending on their respective category, e.g., ISP addresses exhibiting a relatively low lifetime. Furthermore, we analyze different Target Generation Algorithms (TGAs), which are used to increase the coverage of IPv6 measurements by generating new responsive targets for scans. We evaluate their performance under various conditions and find generated addresses to show vastly differing responsiveness levels for different TGAs.

cs.NI

Kirin: Hitting the Internet with Millions of Distributed IPv6 Announcements

The Internet is a critical resource in the day-to-day life of billions of users. To support the growing number of users and their increasing demands, operators have to continuously scale their network footprint -- e.g., by joining Internet Exchange Points -- and adopt relevant technologies -- such as IPv6. IPv6, however, has a vastly larger address space compared to its predecessor, which allows for new kinds of attacks on the Internet routing infrastructure. In this paper, we revisit prefix de-aggregation attacks in the light of these two changes and introduce Kirin -- an advanced BGP prefix de-aggregation attack that sources millions of IPv6 routes and distributes them via thousands of sessions across various IXPs to overflow the memory of border routers within thousands of remote ASes. Kirin's highly distributed nature allows it to bypass traditional route-flooding defense mechanisms, such as per-session prefix limits or route flap damping. We analyze the theoretical feasibility of the attack by formulating it as a Integer Linear Programming problem, test for practical hurdles by deploying the infrastructure required to perform a small-scale Kirin attack using 4 IXPs, and validate our assumptions via BGP data analysis, real-world measurements, and router testbed experiments. Despite its low deployment cost, we find Kirin capable of injecting lethal amounts of IPv6 routes in the routers of thousands of ASes.

cs.NI

How Ready Is DNS for an IPv6-Only World?

DNS is one of the core building blocks of the Internet. In this paper, we investigate DNS resolution in a strict IPv6-only scenario and find that a substantial fraction of zones cannot be resolved. We point out, that the presence of an AAAA resource record for a zone's nameserver does not necessarily imply that it is resolvable in an IPv6-only environment since the full DNS delegation chain must resolve via IPv6 as well. Hence, in an IPv6-only setting zones may experience an effect similar to what is commonly referred to as lame delegation. Our longitudinal study shows that the continuing centralization of the Internet has a large impact on IPv6 readiness, i.e., a small number of large DNS providers has, and still can, influence IPv6 readiness for a large number of zones. A single operator that enabled IPv6 DNS resolution -- by adding IPv6 glue records -- was responsible for around 20.3% of all zones in our dataset not resolving over IPv6 until January 2017. Even today, 10% of DNS operators are responsible for more than 97.5% of all zones that do not resolve using IPv6.

cs.NI

Characterizing the VPN Ecosystem in the Wild

With the shift to working remotely after the COVID-19 pandemic, the use of Virtual Private Networks (VPNs) around the world has nearly doubled. Therefore, measuring the traffic and security aspects of the VPN ecosystem is more important now than ever. It is, however, challenging to detect and characterize VPN traffic since some VPN protocols use the same port number as web traffic and port-based traffic classification will not help. VPN users are also concerned about the vulnerabilities of their VPN connections due to privacy issues. In this paper, we aim at detecting and characterizing VPN servers in the wild, which facilitates detecting the VPN traffic. To this end, we perform Internet-wide active measurements to find VPN servers in the wild, and characterize them based on their vulnerabilities, certificates, locations, and fingerprinting. We find 9.8M VPN servers distributed around the world using OpenVPN, SSTP, PPTP, and IPsec, and analyze their vulnerability. We find SSTP to be the most vulnerable protocol with more than 90% of detected servers being vulnerable to TLS downgrade attacks. Of all the servers that respond to our VPN probes, 2% also respond to HTTP probes and therefore are classified as Web servers. We apply our list of VPN servers to the traffic from a large European ISP and observe that 2.6% of all traffic is related to these VPN servers.

cs.NI