MENU: multicast emulation using netlets and unicast

High-end networking applications such as Internet TV and software distribution have generated a demand for multicast protocols as an integral part of the network. This will allow such applications to support data dissemination to large groups of users in a scalable and reliable manner. Existing IP multicast protocols lack these features and also require state storage in the core of the network which is costly to implement. In this paper, we present a new multicast protocol referred to as MENU. It realises a scalable and a reliable multicast protocol model by pushing the tree building complexity to the edges of the network, thereby eliminating processing and state storage in the core of the network. The MENU protocol builds multicast support in the network using mobile agent based active network services, Netlets, and unicast addresses. The multicast delivery tree in MENU is a two level hierarchical structure where users are partitioned into client communities based on geographical proximity. Each client community in the network is treated as a single virtual destination for traffic from the server. Netlet based services referred to as hot spot delegates (HSDs) are deployed by servers at "hot spots" close to each client community. They function as virtual traffic destinations for the traffic from the server and also act as virtual source nodes for all users in the community. The source node feeds data to these distributed HSDs which in turn forward data to all downstream users through a locally constructed traffic delivery tree. It is shown through simulations that the resulting system provides an efficient means to incrementally build a source customisable secured multicast protocol which is both scalable and reliable. Furthermore, results show that MENU employs minimal processing and reduced state information in networks when compared to existing IP multicast protocols

HLOC: Hints-Based Geolocation Leveraging Multiple Measurement Frameworks

Geographically locating an IP address is of interest for many purposes. There are two major ways to obtain the location of an IP address: querying commercial databases or conducting latency measurements. For structural Internet nodes, such as routers, commercial databases are limited by low accuracy, while current measurement-based approaches overwhelm users with setup overhead and scalability issues. In this work we present our system HLOC, aiming to combine the ease of database use with the accuracy of latency measurements. We evaluate HLOC on a comprehensive router data set of 1.4M IPv4 and 183k IPv6 routers. HLOC first extracts location hints from rDNS names, and then conducts multi-tier latency measurements. Configuration complexity is minimized by using publicly available large-scale measurement frameworks such as RIPE Atlas. Using this measurement, we can confirm or disprove the location hints found in domain names. We publicly release HLOC's ready-to-use source code, enabling researchers to easily increase geolocation accuracy with minimum overhead.Comment: As published in TMA'17 conference: http://tma.ifip.org/main-conference

Characterization of Anycast Adoption in the DNS Authoritative Infrastructure

Anycast has proven to be an effective mechanism to enhance resilience in the DNS ecosystem and for scaling DNS nameserver capacity, both in authoritative and the recursive resolver infrastructure. Since its adoption for root servers, anycast has mitigated the impact of failures and DDoS attacks on the DNS ecosystem. In this work, we quantify the adoption of anycast to support authoritative domain name service for top- level and second-level domains (TLDs and SLDs). Comparing two comprehensive anycast census datasets in 2017 and 2021, with DNS measurements captured over the same period, reveals that anycast adoption is increasing, driven by a few large operators. While anycast offers compelling resilience advantage, it also shifts some resilience risk to other aspects of the infrastructure. We discuss these aspects, and how the pervasive use of anycast merits a re-evaluation of how to measure DNS resilience

Understanding and evaluating the Behaviour of DNS resolvers

The Domain Name System is a core service of the Internet, as every computer relies on it to translate names into IP addresses, which are then utilised to communicate with each other. In order to translate the names into IP addresses, computers resort to a special server, called a resolver. A resolver is a special DNS server that knows the DNS structure and is able to navigate the huge number of DNS servers in order to find the final answer to a query. It is important for a resolver to be able to deliver the final answer as quickly as possible, to have the smallest impact on user experienced latency. Since there is a very large amount of domains and servers, and the system is highly replicated, there has to be some logic as to how a resolver selects which server to query. This brings us to the problem we will study in this thesis: how do resolvers select which DNS server to contact? If a resolver always selects the best DNS server - the one that will be able to provide the answer to the query the fastest - then resolvers can more quickly answer their clients, and thus speed up the Internet. However, if they contact different, more or less equivalent, servers they could contribute to load balancing. To understand how exactly the resolvers select the DNS servers to contact, we conducted an experimental study, where we analysed different resolvers and evaluated how they select the servers. We base the structure and parameters of our study in previous research that has been conducted on the topic, which shows that resolvers tend to use the latency of its queries to the servers as a means of selecting which server to contact

Improving Anycast with Measurements

Since the first Distributed Denial-of-Service (DDoS) attacks were launched, the strength of such attacks has been steadily increasing, from a few megabits per second to well into the terabit/s range. The damage that these attacks cause, mostly in terms of financial cost, has prompted researchers and operators alike to investigate and implement mitigation strategies. Examples of such strategies include local filtering appliances, Border Gateway Protocol (BGP)-based blackholing and outsourced mitigation in the form of cloud-based DDoS protection providers. Some of these strategies are more suited towards high bandwidth DDoS attacks than others. For example, using a local filtering appliance means that all the attack traffic will still pass through the owner's network. This inherently limits the maximum capacity of such a device to the bandwidth that is available. BGP Blackholing does not have such limitations, but can, as a side-effect, cause service disruptions to end-users. A different strategy, that has not attracted much attention in academia, is based on anycast. Anycast is a technique that allows operators to replicate their service across different physical locations, while keeping that service addressable with just a single IP-address. It relies on the BGP to effectively load balance users. In practice, it is combined with other mitigation strategies to allow those to scale up. Operators can use anycast to scale their mitigation capacity horizontally. Because anycast relies on BGP, and therefore in essence on the Internet itself, it can be difficult for network engineers to fine tune this balancing behavior. In this thesis, we show that that is indeed the case through two different case studies. In the first, we focus on an anycast service during normal operations, namely the Google Public DNS, and show that the routing within this service is far from optimal, for example in terms of distance between the client and the server. In the second case study, we observe the root DNS, while it is under attack, and show that even though in aggregate the bandwidth available to this service exceeds the attack we observed, clients still experienced service degradation. This degradation was caused due to the fact that some sites of the anycast service received a much higher share of traffic than others. In order for operators to improve their anycast networks, and optimize it in terms of resilience against DDoS attacks, a method to assess the actual state of such a network is required. Existing methodologies typically rely on external vantage points, such as those provided by RIPE Atlas, and are therefore limited in scale, and inherently biased in terms of distribution. We propose a new measurement methodology, named Verfploeter, to assess the characteristics of anycast networks in terms of client to Point-of-Presence (PoP) mapping, i.e. the anycast catchment. This method does not rely on external vantage points, is free of bias and offers a much higher resolution than any previous method. We validated this methodology by deploying it on a testbed that was locally developed, as well as on the B root DNS. We showed that the increased \textit{resolution} of this methodology improved our ability to assess the impact of changes in the network configuration, when compared to previous methodologies. As final validation we implement Verfploeter on Cloudflare's global-scale anycast Content Delivery Network (CDN), which has almost 200 global Points-of-Presence and an aggregate bandwidth of 30 Tbit/s. Through three real-world use cases, we demonstrate the benefits of our methodology: Firstly, we show that changes that occur when withdrawing routes from certain PoPs can be accurately mapped, and that in certain cases the effect of taking down a combination of PoPs can be calculated from individual measurements. Secondly, we show that Verfploeter largely reinstates the ping to its former glory, showing how it can be used to troubleshoot network connectivity issues in an anycast context. Thirdly, we demonstrate how accurate anycast catchment maps offer operators a new and highly accurate tool to identify and filter spoofed traffic. Where possible, we make datasets collected over the course of the research in this thesis available as open access data. The two best (open) dataset awards that were awarded for these datasets confirm that they are a valued contribution. In summary, we have investigated two large anycast services and have shown that their deployments are not optimal. We developed a novel measurement methodology, that is free of bias and is able to obtain highly accurate anycast catchment mappings. By implementing this methodology and deploying it on a global-scale anycast network we show that our method adds significant value to the fast-growing anycast CDN industry and enables new ways of detecting, filtering and mitigating DDoS attacks

Taming Anycast in a Wild Internet

Anycast is a popular tool for deploying global, widely available systems, including DNS infrastructure and content delivery networks (CDNs). The optimization of these networks often focuses on the deployment and management of anycast sites. However, such approaches fail to consider one of the primary configurations of a large anycast network: the set of networks that receive anycast announcements at each site (i.e., an announcement configuration). Altering these configurations, even without the deployment of additional sites, can have profound impacts on both anycast site selection and round-trip times. In this study, we explore the operation and optimization of any-cast networks through the lens of deployments that have a large number of upstream service providers. We demonstrate that these many-provider anycast networks exhibit fundamentally different properties when interacting with the Internet, having a greater number of single AS hop paths and reduced dependency on each provider, compared with few-provider networks. We further examine the impact of announcement configuration changes, demonstrating that in nearly 30% of vantage point groups, round-trip time performance can be improved by more than 25%, solely by manipulating which providers receive anycast announcements. Finally, we propose DailyCatch, an empirical measurement methodology for testing and validating announcement configuration changes, and demonstrate its ability to influence user-experienced performance on a global anycast CDN

Research on network anycast

Anycast is defined as a service in IPv6, which provides stateless best effort delivery of an anycast datagram to at least one, and preferably only one host. It is a topic of increasing interest. This paper is an attempt to gather and report on the work done on anycast. There are two main categories at present: network-layer anycast and application-layer anycast. Both involve anycast architectures, routing algorithms, metrics, applications, etc. We also present an efficient algorithm for application-layer anycast, and point out possible research directions based on our research. <br /