Network Neutrality checkers and aggregation

From La Quadrature du Net
Jump to navigationJump to search

With Respect My Net, we realized that there are quite a lot of Network Neutrality violations out there, especially for mobile users. This wiki page discusses how we could automate the detection of such violations, agregate the results, and produce a nice-looking visualization of these results.

Network neutrality checkers?[edit]

They are tools designed to help people seek and report Network Neutrality violations automatically.

Closed outgoing ports[edit]

This is one of the most concerning issue (especially for mobile users), and one that is relatively easy to check.

Vinci has set up a responder that allows writing tools easily.

Currently, we've developped a few tools to check this:

  • nncheck.sh (written in bash… it was merely written for test purpose, but quite usable)
  • a javascript application, which was great but required the user to change the configuration of her browser in a non-obvious way (because browsers themselves block a number of outgoing ports by default)

Setting up a server answering to all ports[edit]

Since http://responder.lqdn.fr is not very reliable, you might want to setup your own server that answers on all TCP and UDP ports.

To do this, you need a two IPv4 addresses: `$IP_MAIN` for normal access to the server (SSH, etc), and `$IP_ANYPORT` that will provide a service on all ports. Then use the following iptables rules:

iptables -t nat -A PREROUTING -d $IP_ANYPORT/32 -p tcp -j DNAT --to-destination $IP_MAIN:80
iptables -t nat -A PREROUTING -d $IP_ANYPORT/32 -p udp -j DNAT --to-destination $IP_MAIN:53

Here, we redirect all TCP ports to port 80, and all UDP ports to port 53. You can of course change this.

Other violations[edit]

These one might be a bit harder to check, and we haven't implemented them yet:

  • transparent proxy
  • spoofing SMTP servers (any connection on port 25 is redirected to your ISP's mail server, see this Respect My Net entry in French)
  • anything else? …

TODO[edit]

  • Find a cool name for these tools (instead of plain'old "Network Neutrality checker")
  • Android application (since we want to target mobile users)
  • Python program, more portable than bash (and could provide a GUI?)
  • Setup a reporting & vizualisation tool, eg. a Django app (see below)

Webapp for aggregation[edit]

The idea would be that various clients (python program, Android application, …) send their results to a webapp, allowing to visualize graphically the status of Network Neutrality by country/operator (eg. a table of the most widely used outgoing ports, with a score for each pair of port/operator based on the closed/open state of the port as reported by users)

A simple Django webapp seems fitted for this purpose.

Reporting API[edit]

Reporting could be done in JSON (simple & widespread)

This is an example of API, feel free to edit/add fields:

appname
a string describing the name of the reporting program (eg "nncheck.sh")
country
a string representing the country in which the test has been conducted → (two-letters code, we need an ISO-**** to make everybody happy)
operator
a string representing the operator being tested → we need a database for this, or it will be unmaintainable (see below)
contract
a string describing the contract → idem
media
a string, can be either "fixed" (for ADSL/cable/fiber connection) or "mobile" (for 3G/4G/…) → what about hotspots like Free WiFi or SFR WiFi?
ports-out
a list of outgoing ports, of the form:
port
an integer between 1 and 65536 representing the port being described
protocol
a string, can be "tcp" or "udp"
state
a string describing the state of the given outgoing port.
Can be either:
  • "open": this outgoing port is opened, connection to the responder was successful
  • "failure": the connection was unsuccessful (without being more accurate on why). If your language/framework is able to distinguish between a connection attempt that is refused and one that timeouts, please use one of the following
  • "closed": the connection was refused (probably by someone between the user and the responder, most probably by the ISP)
  • "timeout": the connection attempt has timeouted

to be continued…


Additionally, these fields are generated upon reporting:

  • IP address of the reporter → is that necessary? It allows to throttle multiple reports from the same source, to avoid spam, but it brings some privacy issuesmathieui had the good idea of hashing the IP in the db
  • date of the report

The issue of "operator" and "contract"[edit]

It might not be a good idea to let the user chose freely the operator and the contract (it would lead to a lot of almost-duplicates)

Maybe the applications can ask the webapp for a list of operators/contracts to provide to users (allowing them to create new operators/contracts if need be)

Visualization[edit]

Collecting report data is one thing, but the webapp should also be able to display the data in a processed form.

The idea would be to display nice-looking tables, along the lines of the following example (with 100% entries marked as green, and any other result as red).

+-------+-----------------------+---------------+-----------------------+-------+
|       |        France         | Great-Britain |        Germany        |  ...  |
|       |                       |               |                       |       |
+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
|       | Free  | SFR   |Orange |  O2   |Orange |  ...  |  ...  |  ...  |  ...  |
|       |       |       |       |       |       |       |       |       |       |
+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
|Overall|  98%  |  72%  |  40%  |       |       |       |       |       |       |
| score |       |       |       |       |       |       |       |       |       |
+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
|  22   | 100%  |  60%  |  66%  |       |       |       |       |       |       |
|  ssh  |(12/12)| (3/5) | (2/3) |       |       |       |       |       |       |
+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
|  23   | 100%  | 100%  | 100%  |       |       |       |       |       |       |
|telnet |(12/12)| (5/5) | (3/3) |       |       |       |       |       |       |
+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
|  25   | 100%  | 100%  |  0%   |       |       |       |       |       |       |
| smtp  |(12/12)| (5/5) | (0/3) |       |       |       |       |       |       |
+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
| 110   |  92%  |  80%  |  33%  |       |       |       |       |       |       |
| pop3  |(11/12)| (4/5) | (1/3) |       |       |       |       |       |       |
+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
| 6667  | 100%  |  20%  |  0%   |       |       |       |       |       |       |
| irc   |(12/12)| (1/5) | (0/3) |       |       |       |       |       |       |
+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+

Of course, we would need two tables for outgoing ports results: one for landline, one for mobile. This is because the results are likely to be very different.

Maybe we can also find a way to display other results, such as transparent proxy or SMTP spoofing.