Design and implementation of Portolan for desktop operating systems Linux, Windows and OS X

(1)

Universit`

a di Pisa

Department of Information Engineering

Master of Science in Computer Engineering

Design and implementation of Portolan for

desktop operating systems Linux, Windows

and OS X

Supervisors:

Prof. Luciano Lenzini Prof. Enzo Mingozzi Ing. Valerio Luconi

Candidate: Daniele Formichelli

(2)

“The Internet is based on a layered, end-to-end model that allows people at each level of the network to innovate free of any central control. By placing intelligence at the edges rather than control in the middle of the network, the Internet has created a platform for innovation.”

(3)

UNIVERSIT`A DI PISA

Department of Information Engineering

Master of Science in Computer Engineering

Abstract

Design and implementation of Portolan for desktop operating systems Linux, Windows and OS X

by Daniele Formichelli

Portolan is a research project run by the University of Pisa and the Informatics and Telematics Institute of the Italian National Research Council (IIT-CNR). The project started in 2010 with the aim of enhancing the current knowledge of the Internet structure at the Autonomous System level of abstraction. It was initially deployed in 2012 and since then it has been available on Android clients (i.e. smartphones). This thesis describes the design and the implementation of Portolan for desktop operating systems Linux, Windows and OS X. In this way the hope is to increase the number of users exploiting Portolan facilities and this will allow the designers to obtain a more precise Internet structure.

(4)

1.2.1 Motivations . . . 4 1.2.2 Difficulties . . . 4 1.2.3 Measurement Methods . . . 5 1.3 Related works . . . 7 1.3.1 Passive . . . 7 1.3.1.1 RIPE RIS . . . 7 1.3.1.2 RouteViews . . . 7 1.3.1.3 PCH . . . 7 1.3.2 Active . . . 8 1.3.2.1 CAIDA Archipelago . . . 8 1.3.2.2 DIMES . . . 8 1.3.2.3 RIPE ATLAS . . . 8 1.3.3 Portolan . . . 8

1.4 Thesis motivations, objectives and organization . . . 9

1.4.1 Motivations . . . 9

1.4.2 Objectives . . . 10

1.4.3 Organization . . . 10

2 Portolan Overview 11 2.1 Portolan Infrastructure . . . 11

2.1.1 Server and Proxies. . . 12

2.1.2 Android Client . . . 12

2.2 Portolan Desktop Architecture . . . 12

3 Portolan Desktop 15

(5)

Contents iv 3.1 Background Service . . . 15 3.1.1 Measurements . . . 15 3.1.2 Position . . . 16 3.1.3 User Listener . . . 17 3.2 User Interface . . . 18

3.2.1 Graphical User Interface. . . 18

3.2.2 Command Line User Interface . . . 18

3.3 Measures . . . 22

3.3.1 Ping . . . 22

3.3.2 Traceroute . . . 23

3.3.3 Paris Traceroute . . . 23

3.3.4 AS Traceroute . . . 26

3.3.5 Multipath Detection Algorithm . . . 27

3.3.6 Network Fingerprinting . . . 29 3.3.7 MPLS Tunnels Discovery . . . 30 3.3.8 Measures Parameters . . . 33 3.4 Analyzer . . . 35 3.4.1 BitTorrent . . . 35 3.4.2 Throughput . . . 35 3.4.3 Public Address. . . 36

3.4.4 Network Address Translator . . . 36

3.4.5 IPv6 Support . . . 36 3.4.6 Fragmentation Support . . . 37 3.4.7 MTU. . . 37 3.4.8 DNS Lookup. . . 37 3.4.9 LAN Scan . . . 38 3.4.10 Net Calculator . . . 39 3.4.11 PortMap . . . 39 3.4.12 Perform All . . . 40 3.4.13 Show Stats . . . 41 3.4.14 Report a Bug . . . 41 3.5 Other Details . . . 43

3.5.1 Low Level Network API . . . 43

3.5.2 TCP Measures. . . 43

3.5.3 IPv6 Measures. . . 43

3.5.4 Firewall . . . 43

3.5.5 Installation and Background Service . . . 44

4 Outcomes 45 4.1 Measures Validation Campaign . . . 45

4.2 Fingerprinting Validation Campaign. . . 47

4.3 MPLS Tunnel Analysis Measurements Campaign. . . 51

5 Conclusions 54 5.1 Conclusions . . . 54

5.2 Future works . . . 55

(6)

Contents v

5.2.2 Client for other platforms . . . 55

5.2.3 Desktop Graphical User Interface . . . 56

5.2.4 Expand Analyzer . . . 56

5.2.5 Improve positioning tool . . . 56

5.2.6 Fingerprint. . . 56

5.2.7 MPLS tunnel analysis . . . 57

5.2.8 Analyze measures campaign results. . . 57

(7)

List of Figures

1.1 Logical map of the ARPANET topology . . . 1

1.2 Internet simplified multi-tier hierarchical structure . . . 3

1.3 Internet complete complex structure . . . 3

1.4 Internet topology at three different levels of abstraction . . . 6

1.5 Portolan users distribution all over the world . . . 9

2.1 Portolan infrastructure . . . 11

2.2 Portolan desktop architecture schema . . . 13

3.1 Actions taken by Background Service to obtain targets from the server and send back the results . . . 16

3.2 Portolan Graphical User Interface . . . 18

3.3 Sample output of a portolan -h . . . 19

3.4 Sample output of a portolan -c measure -h. . . 20

3.5 Sample output of a portolan -c analyze -h . . . 21

3.6 Sample output of a Ping measure towards portolan.iet.unipi.it . . . 22

3.7 UDP traceroute graphical explanation . . . 23

3.8 Sample output of a Traceroute measure towards portolan.iet.unipi.it . . . 24

3.9 Example of loop anomaly . . . 25

3.10 Example of cycle anomaly . . . 25

3.11 Example of diamond anomaly . . . 26

3.12 IP header and (in blue) fields involved in flow selection . . . 27

3.13 ICMP header fields involved in flow selection [blue] and fields modified by classic [#] or paris [*] traceroute . . . 27

3.14 UDP header fields involved in flow selection [blue] and fields modified by classic [#] or paris [*] traceroute . . . 27

3.15 TCP header fields involved in flow selection [blue] and fields modified by classic [*] or paris [*] traceroute . . . 27

3.16 Sample output of AS Traceroute measure towards portolan.iet.unipi.it . . . . 28

3.17 Sample output of a Paris Traceroute with Multipath Detection Algorithm measure . . . 29

3.18 Sample output of a Paris Traceroute with Fingerprint option enabled . . . 30

3.19 Taxonomy of MPLS tunnel configurations and corresponding traceroute be-haviours . . . 32

3.20 MPLS implicit tunnel detection using u-turn . . . 33

3.21 Sample output of a Paris Traceroute measure with MPLS discovery enabled . 34 3.22 Sample output of a BitTorrent test . . . 35

3.23 Sample output of a throughput estimation . . . 36

(8)

List of Figures vii

3.24 Sample output of an MTU estimation . . . 37

3.25 Sample output of a DNS lookup . . . 38

3.26 Sample output of a LAN scan. . . 39

3.27 Sample output of Net Calculator tool . . . 40

3.28 Sample output of Port Map tool . . . 40

3.29 Sample output of Perform All tool . . . 41

3.30 Sample output of Show Stats tool . . . 42

4.1 GARR network overview. . . 46

4.2 Comparison of fingerprints obtained by Portolan with the ones reported in Vanuabel’s paper . . . 48

4.3 Distribution of ICMP destination unreachable fingerprints in response to UDP probes with respect to fingerprint related to ICMP probes . . . 49

4.4 Distribution of fingerprint for AS with at least 150 discovered interfaces . . . 50

4.5 Distribution of MPLS tunnel types for AS with at least 20 discovered tunnels 53 5.1 Distribution of Portolan mobile (red) and desktop (green) clients . . . 55

(9)

Abbreviations

API Application Programming Interface ARPA Advanced Research Projects Agency AUR Archlinux User Repository

AS Autonomous System

ARM Advanced RISC Machine

BGP Border Gateway Protocol

CNR National Research Council

CAIDA Center for Applied Internet Data Analysis

CLI Command Line Interface

DMG Disk iMaGe

GARR Gruppo per l’Armonizzazione delle Reti della Ricerca GINS Garr Integrated Networking Suite

GUI Graphical User Interface

GCM Google Cloud Messaging

ICMP Internet Control Message Protocol

IP Internet Protocol

IIT Informatics and Telematics Institute ISP Internet Service Provider

IXP Internet eXchange Point

JNI Java Native Interface

LAN Local Area Network

LER Label Edge Router

LSP Label Switching Path

LSR Label Switching Router

MDA Metection Detection Algorithm

(10)

Abbreviations ix

MIDAR Monotonic ID-based Alias Resolution MLS Mozilla Location Service

MPLS Multi Protocol Label Switching

NAT Network Address Translation

NSIS Nullsoft Scriptable Install System

OGC Open Geospatial Consortium

OS Operating System

PAT Port Address Translation

PoP Point of Presence

RRC Remote Route Collector

RIB Router Information Base

RIPE R´eseaux IP Europ´eens RIS Routing Information Service RISC Reduced Instruction Set Computer

RFC Request For Comment

RTT Round Trip Time

SOS Sensor Observation Service SPS Sensor Planning Service TCP TtransmissionControl Protocol

TTL Time To Live

(11)

to Alessia and to my parents

who always supported me

during my studies. . .

(12)

Chapter 1

Introduction

1.1 Internet history and structure

The Internet is a global computers network that connects billions of devices that can ex-change data, news and much more. It is decentralized by design because it is in fact a network of networks and each one of them is autonomously managed by its owner.

The origin of the Internet dates back to the late 1960’s when ARPANET was designed and implemented by ARPA, an agency founded in the United States in the late 1950’s that in the 1960’s launched a research project aimed to create a robust, fault-tolerant and distributed computer network. Its result, ARPANET, was the first operational packet switching network and the progenitor of what now has become the Internet. The first link was established in October 1969, the network was composed by just two nodes plus two more nodes that were added later that year (Figure 1.1).

Figure 1.1

Logical map of the ARPANET topology

(13)

Chapter 1. Introduction 2

World Regions Population Internet Users (2000) Internet Users (2014) Growth (2000-2014) Users Percentage Africa 1,125,721,038 4,514,400 297,885,898 6,498.6% 9.8% Asia 3,996,408,007 114,304,000 1,386,188,112 1,112.7% 45.7% Europe 825,824,883 105,096,093 582,441,059 454.2% 19.2% Middle East 231,588,580 3,284,800 111,809,510 3,303.8% 3.7% North America 353,860,227 108,096,800 310,322,257 187.1% 10.2% Latin America 612,279,181 18,068,919 320,312,562 1,672.7% 10.5% Oceania 36,724,649 7,620,480 26,789,942 251.6% 0.9% World Total 7,182,406,565 360,985,492 3,035,749,340 741.0% 100.0% Table 1.1

World Internet usage and growth statistics. June 30, 2014

From that moment on ARPANET slowly started to grow. From the 1980’s with the first Internet Service Providers (ISP) and the 1990’s with the birth of World Wide Web the Internet growth became faster and faster. From 2000 to 2014 there was an increment of users of 741% in just fourteen years [1] as shown in Table 1.1.

Nowadays the Internet is a multi-tier hierarchy of Internet Service Providers (ISP). The core of the Internet is composed by a few tier-1 transit providers that form a global mutually in-terconnected clique. They provide worldwide connection to tier-2 ISPs (which are customers of tier-1 ISPs) that are regional providers and so on until the hierarchy reaches the end users that are at the lower level. So when two users want to exchange a packet it should go up in the hierarchy until tier-1 and then go down towards the lowest level in which the users are located (Figure1.2).

In order to shorten such a long path and to avoid to pay fees to their providers two ISPs can establish peering agreements and traffic can flow directly from one to the other and viceversa (private peering ). When more than two ISPs want to establish a peering agreement among each other they can use an IXP (public peering ).

(14)

Figure 1.2

Internet simplified multi-tier hierarchical structure

Figure 1.3

(15)

1.2 Measuring the Internet

In this section an overview on the Internet measuring techniques is given, more information can be found on [2]

1.2.1 Motivations

Together with the growth of Internet, growth the need to discover its topology and the laws that control its expansion. A complete knowledge of the Internet topology can be useful in many fields:

Internet user optimize the building of P2P networks and chose the best internet access in case of multi-homed network

Digital Content Service Provider better distribution of servers and proxies and better redirection of clients to the best server

Internet Service Provider improve connection with other ISPs, traffic engineering

Worm Spread studies about viruses diffusion and their containment. Optimization of de-fense mechanisms placement

Network management detect and correct network anomalies, understand which are the weaker areas to know where to invest to obtain a better structure

Internet Protocols design more scalable and efficient protocols or

Graph theory obtain graph theory related characteristics such as average degree, degree distribution, etc. improve existent ones

1.2.2 Difficulties

If on one side there are many motivation to have a complete graph of the Internet on the other side the ISPs, which are the only one that can know their internal structure and their external connections, are reluctant to disclose this information because their competitors could use it to improve their services.

For this reason it is necessary to obtain such information by measuring the Internet. There are many factors that make the obtaining of the complete topology a challenging task:

• Internet size and continuous growth dictated by both cooperative (Interet has to be efficient) and competitive (ISPs wish to earn moneys) reasons

(16)

• heterogeneity of the networks

• simplicity of IP routers which don’t allow to perform complex measures • hidden pieces (e.g. due to MPLS, NATs, Firewalls)

1.2.3 Measurement Methods

The Internet topology can be obtained at different levels of abstraction:

IP Interface it is the finest level (black dots in Figure 1.4), the topology is described in terms of interfaces and links between them

Router the topology is described in terms of routers and links between them (white circles in Figure1.4), it can be obtained from the interface graph using antialiasing techniques (e.g. MIDAR [3])

Point of Presence when some routers are grouped in well defined locations they are called Point of Presence

Autonomous System the topology is described in term of Autonomous Systems1and links between them (light blue clouds in Figure 1.4). It is the coarsest level and it can be obtained from the other ones by assigning their components (i.e. interfaces, routers or PoP) to the corresponding AS

There are two main type of measurements methods to infer a map of the Internet:

Active this type of method involves injecting traffic to the network for the purpose of measurement. The most common tool that belongs to this category is traceroute that allows to discover Internet topology at the IP interface level. This approach can potentially discover the entire topology by using many cleverly placed probers. In practice it has some limitation due to routers that don’t send ICMP error messages, hidden peices (e.g. MPLS, NAT) or anomalies that can arise during measurements (see section3.3.3)

Passive this type of method involves collecting and analyzing control traffic (i.e. BGP [5]) and infer the AS level topology from it. With a few well placed monitors a lot of routes can be collected by BGP peers. Unfortunately this routes don’t cover the entire topology mainly due to route aggregation or route filtering

1

An Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes [4]

(17)

Figure 1.4

(18)

1.3 Related works

Due to the importance of the Internet topology in the last years a number of projects have been started with the objective of obtaining it. In this section the most relevant ones are described for both passive and active methods.

1.3.1 Passive

1.3.1.1 RIPE RIS

RIPE RIS [6] is an European project started in 2001 by the R´eseaux IP Europ´eens. It collects and stores Internet routing data from several locations around the globe. Remote Route Collectors (RRC) are deployed at many IXPs to obtain routing information: they collect both BGP tables snapshots and BGP update messages.

Collected data are available at

https://www.ripe.net/data-tools/stats/ris/ris-raw-data/.

1.3.1.2 RouteViews

RouteViews [7] is a project started in 2000 by the University of Oregon. It originally was as a tool to obtain real-time information about the global routing system from the perspective of several monitors around the Internet. Nowadays it owns also route collectors that collect BGP routing information by their peers.

Collected data are available at http://archive.routeviews.org/.

1.3.1.3 PCH

The Packet Clearing House (PCH [8]) is a non-profit research institute that supports oper-ations and analysis in the areas of Internet traffic exchange, routing economics and global network development.

It also collect BGP data from monitors located inside IXPs and make them availabe at

(19)

1.3.2 Active

1.3.2.1 CAIDA Archipelago

CAIDA Archipelago [9] is a project started in 2007 by the Center for Applied Data Analysis. It involves a number of fixed strategically placed monitors that perform measures towards different target lists.

Aggregated date are available at http://www.caida.org/data/active/ipv4_routed_ 24_topology_dataset.xml.

1.3.2.2 DIMES

The Distributed Internet Measurements and Simulations (DIMES [10]) is a project started in 2004 held by the University of Tel Aviv. It is a distributed scientific research project, aimed at studying the structure and topology of the Internet, with the help of a volunteer community that performs Internet measurements such as traceroutes and pings by installing DIMES agent on their PCs.

Collected data are available at http://www.netdimes.org/new/?q=node/65.

1.3.2.3 RIPE ATLAS

RIPE Atlas [11] is a project started in 2010 by the R´eseaux IP Europ´eens. It is a network of probes (i.e. a small hardware device) that perform measures and send results to RIPE servers. Volunteers can apply for probes and if they are judged idoneous they will receive one. By connecting it to the Internet via an ethernet cable they can begin to contribute to the project.

Collected data are available at https://atlas.ripe.net/results/.

1.3.3 Portolan

Portolan [12] [13] is a research project started in 2010 by the University of Pisa and the Informatics and Telematics Institute of the Italian National Research Council (IIT-CNR). It has the aim of enhancing the current knowledge of the Internet structure at the Autonomous System level of abstraction.

Differently from most of the other Internet measurement projects it follows a bottom-up and bottom-to-bottom approach. The measures are run by an Android application: each user who wants to contribute can install the Portolan client [14] on his smartphone and immediately becomes part of the project. In this way the project can have a capillary

(20)

distribution of probers that can potentially discover the entire Internet topology.

It was initially deployed in late 2012 and since then data are availabe athttp://portolan. iet.unipi.it/outcomes/.

Figure 1.5

Portolan users distribution all over the world

1.4 Thesis motivations, objectives and organization

1.4.1 Motivations

Currently Portolan can rely on about 150 mobile clients distributed around the world (more or less half of them are in Italy). Since the success of the project strictly depends on the number and the distribution of contributors, the development of a desktop client can help enhance this aspect by encouraging people that either don’t own an Android smartphone or for some reason don’t want to install the mobile client (e.g. afraid from possible additional battery usage) to join the program.

Moreover a desktop client could allow to perform new measurements that cannot be run on smartphones due to OS limitations, lack of processing power or to avoid unwanted battery consumption.

(21)

1.4.2 Objectives

The objective of this thesis is to design and implement a desktop client of the Portolan project. It has to run on Linux, Windows and OS X operating systems in order to cover almost the entire desktop market.

Besides the background execution of measures the Portolan desktop client has to offer to the client a number of tools as a payoff to be part of the project. These tools include all the tools offered by the Android client plus some other tools implemented from scratch (some of them are inspired to Netalyzr [15]).

With respect to the mobile version, the Portolan desktop client provides also the possibility to perform ICMP and TCP measures that are not supported on Android (due to OS limitations). On the other side it obviously cannot offer the RSSI tracker tools and the positioning system cannot be as precise as the one on smartphones because it cannot be based on GPS (see

3.1.2).

1.4.3 Organization

The rest of this thesis is structured as follows.

Chapter 2 shows an overview of the current Portolan infrastructure and describes Portolan desktop architecture in terms of modules and interaction between them.

Chapter3 describes in detail the implementation of Portolan desktop client.

Chapter4illustrates the measure and validation campaigns performed to assess the correct-ness of the implemented tools.

Chapter5 concludes this thesis and gives an overview on some of the possible future devel-opments of the Portolan project.

(22)

Chapter 2

Portolan Overview

In this chapter an overview on the current Portolan architecture is shown, then the architec-ture of the Portolan desktop client is described.

2.1 Portolan Infrastructure

Figure2.1 shows the current Portolan infrastructure.

Server Proxy 1 Proxy 2 Proxy N Admin Figure 2.1 Portolan infrastructure 11

(23)

Chapter 2. Portolan Overview 12

2.1.1 Server and Proxies

The Portolan Server is responsible of receiving tasks from the administrator and gives him back the results. When the user submits a task, the server divides it in microtasks to be assigned to Portolan clients. The proxies are responsible of assigning microtasks to the mobile clients and getting the results. The results are then passed back to the server that aggregates them and makes the aggregate available to the user. The proxies are needed to redistribute the load so that the system can scale if the number of users grow. The interaction between clients, server and proxies is described in details in Section 3.1.1. A task is composed of:

• an operation to be performed

• a source identification part to identify which mobile devices can perform the requested measurements (e.g. only devices located in Italy)

• a destination identification part to identify the target of the specified operation (e.g. destination addresses of a traceroute)

• a duration to specify the maximum duration for the task to be performed

• some operation specific parameters (e.g. traceroute parameters such as hop limit) • optionally an urgent flag to signal tasks that should be performed as soon as possible

2.1.2 Android Client

The Android client, once installed, periodically polls the server sending an HTTP POST request to obtain a microtask to be executed. When it is completed the results are sent back to the server via another HTTP POST request. Urgent tasks can be directly sent to mobile devices using Google Cloud Messaging (GCM [16]).

Due to restrictions imposed by Android the mobile client can perform only UDP measures. To avoid to impact too much on data usage and battery life the client never uses more than 2 MB of mobile traffic per day and stops the execution of the measures when the battery level reaches 20%.

2.2 Portolan Desktop Architecture

This section briefly describes the Portolan desktop architecture in terms of modules and interaction among them. Each module will be described deeper in Chapter3.

(24)

Figure2.2 shows the main modules of Portolan Desktop:

Portolan Desktop Client

Background Service

Low Level Network API

User Interface

Portolan Server

Internet

Measures Analyzer

Figure 2.2

Portolan desktop architecture schema

User Interface it allows the user to interact with Portolan, it provides both a Command Line user Interface (CLI) and a Graphical User Interface (GUI). Through them the user can perform measures provided by the Measures module or run tools included in the Analyzer module

Background Service it is the core of the application that allows to perform measures that contributes to the Portolan project. It periodically polls the Server to receive a mi-crotask, executes it, and sends back the result. Moreover it is invoked by the User Interface to execute tools that require elevated privileges. To perform all its jobs the Background Service starts at boot and runs until system shutdown (unless it is stopped by the user)

Measures it provides measurement tools such as Ping, Traceroute, Paris Traceroute, AS Traceroute and Multipath Detection Algorithm. The Measures module is based on the Low Level Network API and for this reason it requires root (Linux and OS X ) or Administrator (Windows) privileges (from now on root privileges) to be executed

(25)

Analyzer it provides to the user a set of tools to analyze its own network such as BitTorrent test, throughput estimation, MTU estimation and many other. Some of the tools use the Low Level Network API module and for this reason they require root privileges Low Level Network API it provides a basic interface to send probes and receive their

response. It requires root privileges because it uses raw sockets

Server it is responsible to send tasks to the Background Service and store the received results. Moreover it is involved in some of the tools provided by the Analyzer

To be as cross-platform as possible the entire application is written in Java [17] except for a small module inside the Low Level Network API which is written in c and accessed via JNI because the Java API doesn’t allow to perform some low level socket operations needed to implement many Portolan tools.

(26)

Chapter 3

Portolan Desktop

In this chapter each module of Portolan Desktop Client is described. For each component is presented an overview of the actions that it performs to fulfill its task

3.1 Background Service

The Background Service module is the core of the project, it is responsible to execute the tasks assigned by the Server that are used to infer the topology of the Internet.

It is supposed to be always on and since measures are implemented using raw sockets it needs root privileges to be executed.

3.1.1 Measurements

This is the main task of the Background Service because it is the one that contributes to infer the Internet topology. Since the architecture must be platform independent the communication with the server is done via HTTP POST requests.

Figure3.1shows the communication beetween client and server to get a target list towards which traceroutes are performed.

When the service starts it sends a request to the ProxyAssigner that, depending on the user’s position (specifically its country code) assigns it an identifier and a Proxy. The Proxy is periodically polled (every 10 minutes) by the service to get a microtask (i.e. a set of destinations towards which it has to perform ICMP paris traceroutes). When the microtask is completed the results are sent back to the proxy and then the service sleeps until the polling interval expires.

The first step is needed in order to have a scalable system: each proxy manages only a subset 15

(27)

Chapter 3. Portolan Desktop 16

Figure 3.1

Actions taken by Background Service to obtain targets from the server and send back the results

of all devices so that an increase in the amount of users can be managed with an increase of proxies.

The Portolan server is described in details in [18].

3.1.2 Position

To be assigned to the right proxy the service needs to know its position, in particular it needs its country code. Differently from what happens in Android devices where there is a built-in positioning system, getting the current actual position of a desktop node is not trivial. The easiest way to get an approximation is to use IP address geocoding which gives a position that is quite inaccurate but can be used to estimate the correct user’s country code with a good probability. To do this there are a lot of public APIs that have more or less the same accuracy (≈ 99% [19]).

However the obtained position may not be good enough for future usages, for this reason the positioning subsystem has been enhanced with a localization based on visible WiFi access points.

Among all possible services of this type the Mozilla Location Service (MLS [20]) has been chosen. MLS is an open project that provides an API that fulfills both IP geocoding and WiFi geocoding. Its results are not so accurate as some other projects (e.g. Google) but these project are neither open nor free. Moreover it is a quite young project (it started in 2012) so its precision may increase in the near future.

(28)

Using pure Java is not possible to get the list of visible WiFi access points, to accomplish this task a different system tool is invoked depending on the underlying OS and its output is parsed:

Linux iwlist scan

Windows netsh wlan show networks mode=BSSID OSX airscan -s

3.1.3 User Listener

Since some tools provided by the User Interface need root privileges, the Background Service provides also a User Listener thread that can perform these tools on behalf of the user. The communication between the User Interface and the User Listener is implemented via TCP sockets. For this reason the User Interface requires that the Background Service is running.

(29)

3.2 User Interface

3.2.1 Graphical User Interface

Figure 3.2

Portolan Graphical User Interface

The Graphical User Interface (Figure 3.2) is written in Java using Swing library [21] and it is composed of three main components:

Measures the top-right panel can be used to perform measures such as Ping, Traceroute, Paris Traceroute, AS Traceroute and MDA

Analyzer the left panel contains analysis tools measures such as BitTorrent test, Throughput estimation, MTU estimation and so on

Output the bottom-right panel contains the output of both Measures and Analyzer panels

When the User Interface starts it checks if both the Background Service and the Server are running. If it is not the case the user is notified with a popup. Moreover the User Interface queries the Server to check if a new version of Portolan client is available.

3.2.2 Command Line User Interface

All the actions that can be performed with the GUI are available also via a command line user interface to be performed in a terminal. An overview of all available commands can be

(30)

obtained with the command portolan -h (Figure3.3,3.4and 3.5).

[daniele@archlinux ~]$ portolan -h usage: portolan

-c,--command <arg> type of command (analyze / gui / measure / service)

-h,--help print this help

-v,--version print application version

Figure 3.3

(31)

[daniele@archlinux ~]$ portolan -c measure -h usage: portolan --command measure

-c,--command <arg> type of command (analyze / gui / measure /

service)

-d,--destination <arg> destination address [mandatory]

-e,--errors-to-stop <arg> number of consecutive unresponsive hops that causes stop of the measure (0 means no stop) [3]

-f,--flags <arg> TCP probe flags (syn / ack) [SYN]

-F,--fingerprint compute fingerprint of discovered

interfaces (traceroute only)

-i,--interval <arg> minimum interval between probes (ping) or

hops (traceroute) [0]

-I,--flow-id <arg> initial flow id (16 bit unsigned integer)

[random]

-m,--measure <arg> measure to be performed (ping / traceroute

/ paris / astraceroute / mda) [UDP]

-M,--mpls try to discover MPLS tunnels (traceroute only)

-n,--count <arg> number of ping to be sent [5]

-p,--protocol <arg> use given protocol (ICMP / UDP / TCP) [UDP]

-P,--payload-size <arg> size of the probe payload

-r,--attempts-per-hop <arg> number of attempts for each hop (if it is unresponsive) [1]

-s,--source-port <arg> source port for UDP or TCP probes [random]

-t,--min-ttl <arg> minimum ttl of the traceroute [1]

-T,--max-ttl <arg> ttl of the ping or maximum ttl of the

traceroute [30]

-v,--version print application version

-w,--timeout <arg> timeout for a probe to be considered not

responsive [3000]

Figure 3.4

(32)

[daniele@archlinux ~]$ portolan -c analyze -h usage: portolan --command analyze

-a,--address get your public ip address

-b,--bit-torrent check if BitTorrent traffic is discriminated

-c,--command <arg> type of command (analyze / gui / measure /

service)

-C,--net-calculator <arg> get info about an IP network

-d,--dns <arg> perform a DNS lookup

-F,--fragmentation check if fragmentation is supported on the

path to Portolan server

-M,--mtu check Maximum Trasmission Unit on the path to

Portolan server

-n,--nat check if you are behind a NAT

-p,--position <arg> get your current position based on visible wifi network

-P,--port-map <arg> check for open ports on a given IP

-S,--lan-scan scan LAN for connected devices

-s,--port-scan <arg> check for open ports on a given target

-t,--throughput check your maximum throughput

-v,--IPv6 check if your connection supports IPv6

Figure 3.5

(33)

3.3 Measures

The Measure module provides a set of tools that can be used to run measurements of the Internet. Each measure can be performed using the ICMP, UDP or TCP protocol.

3.3.1 Ping

Ping can be used to test the availability and the reachability of an address and to estimate the Round Trip Time (RTT) towards it. It sends one (or more) small packet (from now on a probe) and waits for a reply that can be:

• an ICMP Echo Reply packet if ICMP probes are used

• an ICMP Destination Unreachable packet if UDP or TCP probes are used and the target is not listening on the chosen destination port

• a TCP SYN/ACK or TCP RST packet if TCP probes are used and the target is listening on the chosen destination port

• a Timeout if the target is not responsive (it is either not reachable or it doesn’t respond to the probes) or if UDP is used and the target is listening on the chosen destination port

Figure3.6 shows the output of an ICMP ping towards portolan.iet.unipi.it. ICMP ping portolan.iet.unipi.it (131.114.58.113), 2 bytes of data Reply from portolan.iet.unipi.it (131.114.58.113): seq=1 rtt=28 ms Reply from portolan.iet.unipi.it (131.114.58.113): seq=2 rtt=26 ms Reply from portolan.iet.unipi.it (131.114.58.113): seq=3 rtt=31 ms Reply from portolan.iet.unipi.it (131.114.58.113): seq=4 rtt=26 ms Reply from portolan.iet.unipi.it (131.114.58.113): seq=5 rtt=34 ms 131.114.58.113 ping statistics

---5 packets transmitted, ---5 received, 0.000% packet loss rtt min/avg/max = 26/29.0/34 ms

Figure 3.6

(34)

3.3.2 Traceroute

Traceroute can be used to discover the IP interface level path from the local machine to an address. To do this Traceroute sends probes with an increasing Time To Live (TTL) (starting from 1) and waits for replies that can be:

• an ICMP Time Exceeded packet or a timeout for the routers along the path. This message is sent when a router receives a packet with a TTL field equals to 1 (TTL field is decreased by each router along the path) . For this reason the interfaces that will reply to a probe sent with TTL equals to x will be x hops far from the local machine • one of the replies of ping probes for the destination interface

From each response packet, the source address is extracted and the entire path from source to destination is built. At each hop a field is modified (the actual fields depends on the protocol, see Section 3.3.3) and it is used to match the error messages with the probes. This can be done because ICMP error messages include (at least) the IP header and the first eight octects of the next layer header of the packet related to the error message. Figure3.7

shows an example of a UDP traceroute.

Figure 3.7

UDP traceroute graphical explanation

Figure3.8 shows the output of an ICMP traceroute towards portolan.iet.unipi.it.

3.3.3 Paris Traceroute

Paris Traceroute [22] is an improvement of classic traceroute defined to perform correctly even in presence of load balancers on the path towards the destination.

Load balancers are devices that forward the packets not only depending on the destination address. They can be classified as:

per-destination load balancer the output interface for a packet depends uniquely on its destination address

(35)

Chapter 3. Portolan Desktop 24 ICMP traceroute to portolan.iet.unipi.it (131.114.58.113), 30 hops max

0: archlinux (192.168.1.32) 0 ms 1: * 2: 192.168.100.1 (192.168.100.1) 20 ms 3: 172.17.161.161 (172.17.161.161) 21 ms 4: 172.17.160.25 (172.17.160.25) 23 ms 5: 172.17.10.193 (172.17.10.193) 27 ms 6: r-rm83-vl3.opb.interbusiness.it (151.99.29.139) 22 ms 7: 172.17.5.206 (172.17.5.206) 26 ms 8: garr-nap.namex.it (193.201.28.15) 36 ms 9: rx1-rm2-r-rm2.rm2.garr.net (90.147.80.54) 24 ms 10: rx1-rm2-rx1-pi1.pi1.garr.net (90.147.80.206) 32 ms 11: rx1-pi1-ru-unipi.pi1.garr.net (193.206.136.14) 114 ms 12: jing-jser.unipi.it (131.114.191.130) 107 ms 13: portolan.iet.unipi.it (131.114.58.113) 118 ms Destination reached Figure 3.8

Sample output of a Traceroute measure towards portolan.iet.unipi.it

per-flow load balancer the output interface for a packet depends on both the destination address and some other fields in the header

per-packet load balancer the output interface for a packet depends not only on the packet content but also from some other external condition (e.g. link loads)

Using classic traceroute in presence of a load balancer three types of anomalies can arise:

loop when an interface appears two times separated by at least another interface in the result of a traceroute. In some cases it can be caused by routing changes, address rewriting (e.g. NAT) or 0-TTL forwarding (i.e. a router that forwards the packet also if the TTL has reached 0). In Figure 3.9 a loop is discovered on interface F because the probe with TTL equals to 4 follows a different (longer) path with respect to the other probes. For this reason hop F replies to both probe 3 and probe 4

cycle when an interface appears consecutively two or more times in the result of a traceroute. In some cases there can even be a real forwarding loop in the Internet topology. In Figure 3.10 a cycle is discovered on interface G because the probe with TTL equals to 4 follows a different (longer) path with respect to the other probes. For this reason hop G replies to both probe 3 and probe 5.

diamond when there are multiple paths from an interface to another one. It cannot be found in the result of a single traceroute but it can appear when aggregating path

(36)

from multiple traceroute measures. In some cases it can be also the real topology of a load balanced network. In Figure 3.11 a false diamond (i.e. a diamond with false links) is discovered between interface A and interface F while a real diamond is present between interface A and interface G.

A F E C B A E F TTL: 1 TTL: 2 TTL: 3 TTL: 5 TTL: 4 S D S D Figure 3.9

Example of loop anomaly

A G F C B A F G E TTL: 1 TTL: 2 TTL: 3 TTL: 6 E TTL: 5 S D D S TTL: 4 Figure 3.10

Example of cycle anomaly

To avoid these anomalies in case of per-flow load balancers the probe header must be modified in a clever way that keeps constant the fields involved in flow selection. The flow selection involves some fields of the IP header (see Figure 3.12) and the first four octet of

(37)

Chapter 3. Portolan Desktop 26 F B S C G D H E A F B S C G D E A Figure 3.11

Example of diamond anomaly

the next level header (i.e. ICMP, UDP or TCP) [22]. Since the ICMP error messages include only 8 octects of the next level header probes and replies must be matched using octects from 5 to 8.

Depending on the used protocol different fields are used:

ICMP (Figure3.13) classic traceroute increments the Sequence Number field at each hop, this causes a change in the checksum that causes the flow to change. Paris traceroute modifies also the identifier field to keep the checksum constant (sequence number is increased and identifier is decreased)

UDP (Figure3.14) classic traceroute increments Destination Port field at each hop, so the flow changes. Paris traceroute instead modifies the udp payload in order to modify the checksum that than can be used to match probe and reply

TCP (Figure3.15) classic traceroute increments Sequence Number field that is not involved in flow selection so for this protocol paris and classic traceroute are equivalent

3.3.4 AS Traceroute

AS Traceroute is built on top on Paris Traceroute. For each discovered hop information about its AS is obtained sending an HTTP request to the Portolan server. Using this tool the user can know who are the entities that manage the routers on the path to the target. Figure3.16 shows the output of an ICMP AS traceroute towards portolan.iet.unipi.it.

(38)

Figure 3.12

IP header and (in blue) fields involved in flow selection

Figure 3.13

ICMP header fields involved in flow selection [blue] and fields modified by classic [#] or paris [*] traceroute

Figure 3.14

UDP header fields involved in flow selection [blue] and fields modified by classic [#] or paris [*] traceroute

Figure 3.15

TCP header fields involved in flow selection [blue] and fields modified by classic [*] or paris [*] traceroute

3.3.5 Multipath Detection Algorithm

Multipath Detection Algorithm (MDA, [23]) is an extension of Paris Traceroute that allows to find, with a confidence level of 95%, all possible paths from the local machine to the target. To do that, for each discovered interface MDA sends a certain number of probes that pass through it to find all its successors. The number of probes to send depends on the number of discovered successors: MDA starts with 6 probes, then if it finds more than one successor it sends some other probes (see Table3.1) and so on. Moreover, for each load balancer (i.e. an interface with more than one successor) 6 packet belonging to the same

(39)

Chapter 3. Portolan Desktop 28 ICMP AS traceroute to portolan.iet.unipi.it (131.114.58.113), 30 hops max No info

AS Number: Unknown AS No location

192.168.1.0/24, 192.168.0.0/16

SBTAP-AS Comune di San Benedetto del Tronto AS Number: 59715

No location 172.16.0.0/12

ASN-IBSNAZ Telecom Italia S.p.a. AS Number: 3269

null, Italy 151.99.0.0/16

SBTAP-AS Comune di San Benedetto del Tronto AS Number: 59715 No location 172.16.0.0/12 NaMeX AS Number: Unknown No location 193.201.28.0/25

ASGARR Consortium GARR AS Number: 137

null, Italy

90.147.0.0/16, 131.114.0.0/16 Destination reached

Figure 3.16

Sample output of AS Traceroute measure towards portolan.iet.unipi.it

flow are sent: if just one successor is discovered then the load balancer is a per-flow load balancer otherwise it is a per-packet load balancer.

Figure 3.17 shows the output of an ICMP Multipath Detection Algorithm towards por-tolan.iet.unipi.it.

(40)

n 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

k 6 11 16 21 27 33 38 44 51 57 63 70 76 83 90 96

Table 3.1

Number of hops to send (k) depending on the number of discovered interfaces (n)

ICMP MDA to rx2.mi1.garr.net (90.147.84.12), 30 hops max

0: archlinux (192.168.1.32) 1: gateway (192.168.1.1) 2: 192.168.100.1 (192.168.100.1) 3: 172.17.161.33 (172.17.161.33) 4: 172.17.160.9 (172.17.160.9) 5: 172.17.5.113 (172.17.5.113) 6: r-rm180-vl3.opb.interbusiness.it (151.99.29.150) 7: 172.17.5.210 (172.17.5.210) 8: garr-nap.namex.it (193.201.28.15) 9: rx2-rm2-r-rm2.rm2.garr.net (90.147.80.58) r-rm2-r-bo1-l1.bo1.garr.net (90.147.80.1) 10: 90.147.80.5 (90.147.80.5) r-bo1-rx2-bo1.bo1.garr.net (90.147.80.38) rx2-rm2-rx2-bo1-l3.bo1.garr.net (90.147.80.113) 11: rx2.mi1.garr.net (90.147.84.12) Destination reached Figure 3.17

Sample output of a Paris Traceroute with Multipath Detection Algorithm measure

3.3.6 Network Fingerprinting

Network fingerprinting is the collection of configuration attributes of remote devices during network communication. The combination of these parameters can be used to infer some characteristics of the remote machine such as its operating system. Moreover fingerprints can be used in the process of router alias resolution.

Portolan fingerprinting classifies devices basing on the initial TTL of their packets as de-scribed in [24]: the fingerprint of a router is composed by a triplet containing the initial TTL of different types of sent IP packets, in particular three types of ICMP packets are consid-ered: TTL expired, Echo Reply and Port Unreachable. When an ICMP packet is received the original TTL is estimated as one of four possible values (32, 64, 128, 255) among which the smallest one that is greater than the received value is taken. Since more than 99% of the paths are less than 30 hops the estimation is very accurate. A TTL of -1 is associated to unresponsive hops (in this case 6 probes are sent to be sure that the router doesn’t reply).

(41)

Figure3.18 shows the output of an ICMP paris traceroute with fingerprint enabled towards portolan.iet.unipi.it.

ICMP paris traceroute to portolan.iet.unipi.it (131.114.58.113), 30 hops max

0: archlinux (192.168.1.32) 0 ms 1: gateway (192.168.1.1) 1 ms Fingerprint:<128, 128, 128> 2: 192.168.100.1 (192.168.100.1) 126 ms Fingerprint:<255, 255, -1> 3: 172.17.161.161 (172.17.161.161) 254 ms Fingerprint:<255, 255, -1> 4: 172.17.160.25 (172.17.160.25) 260 ms Fingerprint:<255, 255, -1> 5: 172.17.10.193 (172.17.10.193) 271 ms Fingerprint:<255, 255, -1> 6: r-rm83-vl3.opb.interbusiness.it (151.99.29.139) 176 ms Fingerprint:<255, 255, -1> 7: 172.17.5.206 (172.17.5.206) 178 ms Fingerprint:<255, 255, -1> 8: garr-nap.namex.it (193.201.28.15) 217 ms Fingerprint:<255, -1, -1> 9: rx1-rm2-r-rm2.rm2.garr.net (90.147.80.54) 38 ms Fingerprint:<255, 64, 255> 10: rx1-rm2-rx1-pi1.pi1.garr.net (90.147.80.206) 50 ms Fingerprint:<255, 64, 255> 11: rx1-pi1-ru-unipi.pi1.garr.net (193.206.136.14) 119 ms Fingerprint:<255, -1, -1> 12: jing-jser.unipi.it (131.114.191.130) 92 ms Fingerprint:<255, -1, -1> 13: portolan.iet.unipi.it (131.114.58.113) 93 ms Fingerprint:<64, 64, 64> Destination reached Figure 3.18

Sample output of a Paris Traceroute with Fingerprint option enabled

3.3.7 MPLS Tunnels Discovery

Using the techniques described in [25] it is possible to discover and classify Multi Protocol Label Switching (MPLS [26]) tunnel on the path to a destination.

In a tunnel like the one in Figure3.19 different components can be identified:

Label Edge Router an LER is a router at the edge of an MPLS tunnel i.e. a router that receives plain packets and trasmints labeled packets or viceversa (R1 and R5 in the figure)

(42)

RFC4950 enabled RFC4950 disabled

ttl-propagate enabled Explicit Implicit

ttl-propagate disabled Opaque Invisible

Table 3.2

MPLS tunnel classification

Label Switched Path an LSP is the path between two LER (R2-R3-R4) in the figure Label Switching Router an LSR is a router that belongs to an LSP (R2, R3 and R4 in the

figure)

When an IP packet reaches the LER of a LSP there are two different options that can be active or not for that path:

ICMP MPLS extension a router that implements RFC 4950 [27] includes in the ICMP error packet the MPLS stack of the received probe (as an ICMP extension as defined in RFC 4884 [28]). When an ICMP error message with this extension is received it is clear that the source belongs to an MPLS path

ttl-propagate if activated, the ingress LER copies the TTL field from the IP header to the LSE-TTL field of the MPLS header so each LSR of the LSP will be discovered by a traceroute. Viceversa, if ttl-propagate is not active only the the last LSR of the LSP will be discovered

From the combination of these two configurations four different types of tunnels arises (Table

3.2):

explicit tunnels all LSRs in the tunnel are discovered by traceroute and they attach the MPLS stacks to ICMP error messages

implicit tunnels all LSRs in the tunnel are discovered by traceroute but they don’t attach the MPLS stacks to ICMP error messages

opaque tunnels only the last LSR will be discovered but it attaches the MPLS stack to the ICMP error message

invisible tunnels LSRs in the tunnels are not visible at all

While performing a traceroute when an ICMP error message is received the following objects are collected:

(43)

Figure 3.19

Taxonomy of MPLS tunnel configurations and corresponding traceroute behaviours

• attached MPLS stack (if any) • TTL of the received IP packet

• TTL of the IP packet quoted in the received ICMP error messages (from now on q-ttl)

An explicit tunnel is detected when there are two or more consecutive hops with an attached MPLS stack.

An opaque tunnel is detected when there is just one hop with an attached MPLS stack. Moreover the length of the tunnel can be estimated as 256 - LSE-TTL. Unfortunately in most cases the LSE-TTL field is set to 1 or 255 which cannot be the real expected value. Invisible tunnels cannot be detected.

To infer implicit tunnels there are two methods:

• q-ttl is the easiest and consists in checking the value of the quoted TTL. If it is greater than 1 then the ICMP Time Exceeded packet can be caused only by the LSE-TTL field that reached zero. Moreover an increase in the values of q-ttl should be observed while traversing the tunnel (see Figure 3.20). Unfortunately some routers report a quoted TTL equals to 1 even in this case and for this reason not all implicit tunnels can be discovered in this way. This method can have false negatives (i.e. it doesn’t discover some implicit tunnels) but all discovered tunnels are real (no false positives) • u-turn is more complex and requires additional probing. It consists in comparing the

ttl of the response packet to two types of probe: the first one generates an ICMP Time Exceeded message and it is generally routed to the destination passing through the last hop of the LSP. The second one generates an ICMP Echo Reply or Port Unreachable message and it is usually routed directly to the destination. For this reason the TTLs of the response packets will differ and probably that hop belongs to an implicit tunnel. Moreover, since both the direct path and the path through the last hop of the LSP

(44)

usually pass through the ingress LER, the difference between the TTLs should follow a pattern like X, X − 2, X − 4, ..., 4, 2, 0, where X is two times the tunnel length (see Figure3.20). Six probes per interface are sent to be sure that there are no load balancers in the return path (in this case this technique cannot be used). This method allows to discover more implicit MPLS tunnels (with respect to q-ttl method) but it is an heuristic so it can produce both false positives and false negatives. u-turn tunnels of length one are discarded because they are probably false positives [25].

Figure 3.20

MPLS implicit tunnel detection using u-turn

Figure 3.21 shows the output of an ICMP paris traceroute with MPLS discovery enabled towards portolan.iet.unipi.it.

3.3.8 Measures Parameters

The complete list of user defined parameters for the Measure panel is:

Measure type of measure to be performed among Ping, Traceroute, Paris Traceroute, AS Traceroute and MDA

Protocol protocol to be used among ICMP, UDP and TCP (not available on Windows, see Section3.5.2)

Timeout timeout of the probe in milliseconds

Interval interval between probes of consecutive hops in milliseconds Count number of probes to send (ping only)

Max Errors number of consecutive unresponsive hops that cause the measures to stop (not for ping)

(45)

Chapter 3. Portolan Desktop 34 ICMP paris traceroute to portolan.iet.unipi.it (131.114.58.113), 30 hops max

0: archlinux (192.168.1.32) 0 ms 1: gateway (192.168.1.1) 20 ms 2: 192.168.100.1 (192.168.100.1) 25 ms 3: 172.17.161.161 (172.17.161.161) 19 ms 4: 172.17.160.25 (172.17.160.25) 28 ms 5: 172.17.10.193 (172.17.10.193) 27 ms 6: r-rm83-vl3.opb.interbusiness.it (151.99.29.139) 26 ms 7: 172.17.5.206 (172.17.5.206) 22 ms 8: garr-nap.namex.it (193.201.28.15) 22 ms 9: rx1-rm2-r-rm2.rm2.garr.net (90.147.80.54) 23 ms MPLS:<{Label:680578,Exp:0,S:1,TTL:1}> 10: rx1-rm2-rx1-pi1.pi1.garr.net (90.147.80.206) 32 ms 11: rx1-pi1-ru-unipi.pi1.garr.net (193.206.136.14) 92 ms 12: jing-jser.unipi.it (131.114.191.130) 93 ms 13: portolan.iet.unipi.it (131.114.58.113) 91 ms Destination reached

Explicit MPLS tunnel from hop 8 to hop 9

Figure 3.21

Sample output of a Paris Traceroute measure with MPLS discovery enabled

TTL Range minimum and maximum TTL for traceroute probes. For ping probes the value Maximum TTL is used

Flow flow of the probe. For ICMP it is the Identifier field. For UDP and TCP it is the Destination Port field.

Extensions enable or disable Network Fingerprint and MPLS Tunnels Discovery (traceroute and IPv4 only, see Section3.5.3)

IP Version IP version for the probes. Auto means that a DNS lookup is performed on the target address and one of the available addresses is chosen randomly. If IPv4 [29] or IPv6 [30] is selected the correct address will be chosen

(46)

3.4 Analyzer

3.4.1 BitTorrent

The BitTorrent tool has been imported and adapted from the one present in the Android version of Portolan. It allows to check if BitTorrent traffic is limited or blocked on the user’s network by simulating both a normal traffic flow and a BitTorrent traffic flow and comparing their throughput.

The traffic can be:

Not limited if the ratio between BitTorrent traffic throughput and normal traffic throughput is greater than or equal to 0.8

Limited if the ratio between BitTorrent traffic throughput and normal traffic throughput is greater than zero but smaller than 0.8

Blocked if BitTorrent traffic is completely blocked

Figure3.22 shows the output of a BitTorrent test on a network which doesn’t discriminate BitTorrent traffic.

UPLOAD TEST:

Sending control flow... Rate: 0.454 Mbps Sending BitTorrent flow... Rate: 0.412 Mbps Upload BitTorrent traffic is not discriminated DOWNLOAD TEST:

Receiving control flow... Rate: 3.461 Mbps Receiving BitTorrent flow... Rate: 3.515 Mbps Download BitTorrent traffic is not discriminated

Figure 3.22

Sample output of a BitTorrent test

3.4.2 Throughput

The Throughput tool has been imported and adapted from the one present in the Android version of Portolan which is an implementation of SmartProbe [31]. It allows to estimate the maximum upload and download throughput of the user’s network.

(47)

Figure 3.23

Sample output of a throughput estimation

3.4.3 Public Address

The Public Address tool provides the public IP address of the user. The client sends a small TCP packet to the server which replies with a packet containing the source address of the received request.

3.4.4 Network Address Translator

The Network Address Translator tool checks if the user is behind a Network Address Trans-lator (NAT [? ]) and/or a Port Address TransTrans-lator (PAT). The client sends to the server a TCP packet containing its source address and source port, the server replies with a packet containing the source address and port of the received packet. If the two addresses differ then the user is behind a NAT, if the two ports differ then the user is behind a PAT.

3.4.5 IPv6 Support

The IPv6 Support tool checks if the user’s network supports IPv6 connections. The client sends an HTTP request to an IPv6 only server (ipv6.google.com), if it receives response then IPv6 protocol is supported.

(48)

3.4.6 Fragmentation Support

The Fragmentation Support tool checks if fragmentation is supported on the path to Portolan server. The client sends a big (8192 bytes) packet to the server through a UDP socket, if it receives response then fragmentation is supported.

3.4.7 MTU

The MTU tool estimates the MTU on the path to a given target. The client performs a binary search sending some ICMP pings with don’t fragment (DF) flag set. For each probe there can be three possible results:

• the target replies, in this case a lower bound to the MTU has been found because it will be greater or equal to the size of the probe (case icmp echo reply in pseudo code) • an ICMP Fragmentation Needed package is received, in this case an upper bound to the MTU has been found which is the one included in the ICMP packet (case icmp fragmentation needed in pseudo code)

• no reply is received, in this case an upper bound to the MTU has been found because it will be certainly lower than the size of the probe (case timeout in pseudo code) In the case that the destination doesn’t reply to ICMP pings the estimated MTU becomes lower and lower. When it goes below the minimum size of an ICMP packet (i.e. 28 byte: 20 byte IP header + 8 byte ICMP header) the algorithm stops. The pseudo code of the algorithm is the following:

Figure3.24 shows the output of a MTU estimation.

Sending probe with MTU equals to 1500 bytes... Fragmentation needed packet received Sending probe with MTU equals to 1492 bytes... Response packet received

MTU on the path to portolan.iet.unipi.it is 1492 bytes

Figure 3.24

Sample output of an MTU estimation

3.4.8 DNS Lookup

The DNS Lookup tool simply performs a DNS lookup to obtain all addresses associated with a given hostname, moreover it shows information about which AS the host belongs to with the same procedure used for AS Traceroute.

(49)

Algorithm 1 MTU estimation algorithm procedure Estimate MTU

minM T U ← 0

maxM T U ← IN T EGER M AX V ALU E currentM T U ← 1500

repeat

result ← sendP ing(currentM T U ) switch results do

case icmp echo reply

if maxM T U == IN T EGER M AX V ALU E then . no upper bound

currentM T U ← currentM T U ∗ 2 . double the size

else

currentM T U ← (currentM T U + minM T U )/2 . binary search end if

case timeout . found a new upper bound

maxM T U ← currentM T U

currentM T U ← (currentM T U + minM T U )/2 . binary search

case icmp f ragmentation needed . found a new upper bound

currentM T U ← icmp f ragmentation needed M T U maxM T U ← currentM T U + 1

if currentM T U < 28 then . target doesn’t reply to ICMP pings return -1

end if

until minM T U == maxM T U − 1 return currentM T U

end procedure

Figure3.25 shows the output of a DNS lookup. Hostname: portolan.iet.unipi.it

AS Number: 137

AS Info: ASGARR Consortium GARR

Position: Serra, Italy (43.93330383300781, 12.25) Addresses:

131.114.58.113

Figure 3.25

Sample output of a DNS lookup

3.4.9 LAN Scan

The LAN Scan tool searches for devices on the LAN of the user. It sends a ping to all addresses of the subnet of the LAN. Moreover for each address it tests if some well known TCP (7, 53, 80, 455, 8080) ports are open.

(50)

Figure3.26 shows the output of a LAN scan. 254 addresses to scan gateway (192.168.1.1) Ping: responsive Accepted: TCP/80 Refused: TCP/7 TCP/53 TCP/455 TCP/8080 192.168.1.20 (192.168.1.20) Ping: responsive Accepted: Refused: TCP/7 TCP/53 TCP/80 TCP/455 TCP/8080 192.168.1.21 (192.168.1.21) Ping: responsive Accepted: Refused: TCP/7 TCP/53 TCP/80 TCP/455 TCP/8080 192.168.1.24 (192.168.1.24) Ping: responsive Accepted: Refused: TCP/7 TCP/53 TCP/80 TCP/455 TCP/8080 archlinux (192.168.1.27) Ping: responsive Accepted: Refused: TCP/7 TCP/53 TCP/80 TCP/455 TCP/8080 Done! Found 5 responsive addresses

Figure 3.26

Sample output of a LAN scan

3.4.10 Net Calculator

The Net Calculator tool has been imported and adapted from the one present in the Android version of Portolan. It provides some information about the provided network address such as its class, its network prefix, its broadcast address and so on.

Figure3.27 shows the output of Net Calculator for network 192.168.1.0/24.

3.4.11 PortMap

The PortMap tool has been imported and adapted from the one present in the Android version of Portolan. It allows to check if an address is responsive and if the given TCP ports

(51)

Chapter 3. Portolan Desktop 40 Network calculator target: 192.168.1.0/24

Network address: 192.168.1.0 11000000.10101000.00000001.00000000 Network mask: 255.255.255.0 11111111.11111111.11111111.00000000 Broadcast address: 192.168.1.255 11000000.10101000.00000001.11111111 Minimum address: 192.168.1.1 11000000.10101000.00000001.00000001 Maximum address: 192.168.1.254 11000000.10101000.00000001.11111110 Network class: C Maximum hosts: 254 Figure 3.27

Sample output of Net Calculator tool

are open on the given target.

Figure3.28 shows the output of a PortMap towards portolan.iet.unipi.it. Ping completed in 369.0 ms 100 ports to scan: Port 22 is open Port 80 is open Done Figure 3.28

Sample output of Port Map tool

3.4.12 Perform All

The Perform All tools performs in a unified interface BitTorrent, Throughput, Public Address, NAT, IPv6 Support, Fragmentation Support and MTU. It can be used to get a quick summary about the status of the user’s network.

(52)

Figure 3.29

Sample output of Perform All tool

3.4.13 Show Stats

The Show Stats tools show a statistic about Portolan usage, it reports:

• the number of measures (i.e. paris traceroute) performed by the Background Service contributing to the Portolan project

• the number of times that each analyzer tool has been used

• the number of times that the user has performed a measure organized by type of measure (Ping, Traceroute, Paris Traceroute, AS Traceroute, MDA) and protocol (ICMP, UDP, TCP)

Figure3.30 shows the output of Show Stats.

3.4.14 Report a Bug

Report a Bug allows the user to choose the tools for which he wants to report a bug and redirects him to the Contact page on Portolan website.

(53)

You have contributed to Portolan project with 1400 measures since Jan 01, 2015 ANALYZER COUNT BitTorrent 3 Throughput 4 DNS lookup 2 Fragmentation 2 MTU 3 IPv6 2 NAT 3 Public address 4 LAN scan 5 Net calculator 1

USER MEASURES ICMP UDP TCP

Ping 25 24 8 Traceroute 1 1 1 Paris Traceroute 39 52 3 AS Traceroute 4 3 2 MDA 11 14 2 Figure 3.30

(54)

3.5 Other Details

The application is designed and implemented to be platform independent as much as possible. However some functionalities are unavoidably affected by the underlying OS: this section reports these differences.

3.5.1 Low Level Network API

Many Portolan tools require to use sockets at a very low level, for example they need to modify some fields of the IP header. Since the standard Java socket API doesn’t allow such manipulation there is the need of a library which is not written in Java.

The Low Level Network API is based on the RockSaw library [32] which is written in C and accessed via JNI. It uses standard raw socket library on Linux and OS X, and Winsock library [33] on Windows.

The Low Level Network API provides a basic interface to create, open and close raw sockets and to send or receive packets through it. All other operations, from packet creation to packet parsing, are entirely written in Java.

3.5.2 TCP Measures

On Windows there is a restriction on raw sockets that doesn’t allow to send raw TCP packets. For this reason TCP measures are not implemented for this platform.

On OSX the system doesn’t deliver neither UDP nor TCP packets to raw sockets, for this reason TCP ping may not work and traceroute measures may not receive reply from the last hop. It will not be the common case since it will happen only if the destination of the measure is listening on the port chosen for that probe.

3.5.3 IPv6 Measures

On all the supported OSes the IPv6 header is not passed to the receiver socket, for this reason Network Fingerprint and MPLS Tunnel Discovery cannot be applied to IPv6 measures.

3.5.4 Firewall

The presence of a firewall may cause misbehaviours in many tools, in particular some firewalls (e.g. Windows Firewall) block by default many incoming ICMP packets. To face this problem the user has to add a rule that allows the transit of these packets (in particular TTL exceeded

(55)

and Destination Unreachable packets). The Windows installer adds this rule automatically (only for Windows Firewall) if the user allows it during installation.

3.5.5 Installation and Background Service

Portolan installation and the execution of the background service depends on the OS:

Linux Linux installation and execution varies depending on the used distribution:

Debian/Ubuntu .deb package is provided for Debian and its derivatives. The back-ground service is automatically started after installation and at each boot using either sysv, upstart or systemd

Archlinux Portolan package is available on AUR [34] for Archlinux and its derivatives. The background service is automatically started after installation and at each boot using systemd

Other .tar.gz package with an install script is provided for all other Linux distributions Windows installation package is provided as .exe and has been created using NSIS [35]. The background service is automatically started after installation and at each boot using Windows Task Scheduler [36]. Some antivirus softwares (e.g. Norton) may consider the .exe file dangerous because it is not signed by a trusted entity, the user can safely ignore the warning and continue with the installation

OSX installation package is provided as .dmg and has been created using Packages [37]. The background service is automatically started after installation and at each boot using launchd

(56)

Chapter 4

Outcomes

In this chapter the validation campaigns performed to validate the implemented tools are presented. Mappings between IP addresses and their ASes has been done using data from Isolario [38].

4.1 Measures Validation Campaign

To validate the measures such as traceroute there is the need of a network with a public topology. For this reason the GARR network (the Italian academic and research network) has been chosen since its topology is available on GINS [39]. GARR is the network Measures are performed from a network located in the University of Pisa which is attached to the RX1.PI1 PoP of the GARR network.

Each type of measure (Ping, Traceroute, Paris Traceroute, MDA) has been performed using each protocol (ICMP, UDP, TCP) towards each PoP of the GARR network (i.e. 69 targets, see Fig. 4.1) in order to have a complete topology from the point of view of the RX1.PI1 PoP. Since there are 4 types of measure, 3 protocols and 69 targets the total number of measures is 552 (i.e. (4 ∗ 3 − 4) ∗ 69, on Windows TCP measures cannot be performed (see Section 3.5.2)).

The results of the measures performed with Portolan reflect the topology presented on GINS: all discovered paths are real path in the GARR network and load balancers are discovered, too. Moreover the results is the same regardless of the underlying OS so there is no difference in performing a measure with an OS with respect to another one (except for TCP measures as stated in Section3.5.2).

Table 4.1shows the difference in measures result due to the usage of different protocols