Abstract-Middleboxes are pervasive in today's Internet as they are deployed for an increasing number of reasons. An example is the network address translation (NAT), one of the first task to be performed to cope with the lack of IPv4 addresses. Recently the landscape for NATs has become even more crowded, especially in mobile networks, mainly due to the impossibility of IPv6 to be a large-scale solution to addressing issues. In this paper, we present a novel methodology for detecting NATs embodied in Mobile Tracebox, a measurement tool for Android smart devices that detects a wide range of middleboxes. It analyzes ICMP time-exceeded messages received during traceroute and points at IP and transport checksum inconsistencies in the embedded packets to uncover address translation along a path. We deployed Mobile Tracebox through a crowdsourcing approach and used the collected dataset to validate our methodology. Results showed that, in absence of middleboxes breaking traceroute, it can help to detect and locate NATs in the majority of the cases.

Over the years middleboxes have established themselves as a solution to a wide range of networking issues, progressively changing network landscape and turning the endto-end principle into a reminder of an Arcadian age of the Internet. Among them, proxies have found breeding ground especially in mobile networks that, moreover, have become the most popular way to access the Internet. In this paper, we present Mobile Tracebox, an Android measurement tool, and describe how its methodology, coping with the lack of privileges of mobile devices, can not only detect proxies but also characterize different facets, from their transport layer behavior to their location inside the network. Data collected from a crowdsourced deployment over more than 90 carriers and 350 Wi-Fi networks contributes to describe the potential of the tool and to draw a panorama of proxies across mobile networks. Our study confirms their prevalence and reveals that their scope is not limited to HTTP but can include several TCP services and even non standard ports. We detail the different implementations observed and delve into specific aspects of their configuration, like the initial Receive Window, the Window Scale factor or the set of Options supported, to understand how proxies can affect performance or obstruct extensions. Finally, we focus on fingerprinting and attempt to draw a dividing line between packet modifications performed by proxies and those performed by other classes of middleboxes.

No abstract