[ooni-dev] Ooni / M-Lab integration.

Nathan Wilcox nathan at leastauthority.com
Fri Aug 1 19:25:55 UTC 2014

Dear OTF, Ooni, and M-Lab,


We've hashed out a design to integrate Ooni with mlab-ns on the M-Lab
deployment, and we've implemented a fully functional deployment that
approximates this by simulating mlab-ns (this is attached).  This
completes Milestone D of our contract with OTF.

Design Goals

Our top goals for this integration are:

It does not rely on any changes to upstream Ooni.  (For example,
probes still use a bouncer .onion, and the backend has stock bouncers,
collectors, and test helpers running.)

It can be disabled easily without redeploying the M-Lab backend.  Our
branch's ooni-support README.md has instructions to disable the
integration, merely by editing a cron job to unset an ENABLED flag.
There's no need to redeploy different versions of ooni-support.

When enabled, it allows M-Lab operations to monitor collectors and
test_helpers status with the same infrastructure as all other M-Lab

Future Architectural Changes

In the future, it may be nice to augment ooni / mlab-ns integration.
For example, mlab-ns is designed to support different policies which
may be useful to tools, such as geo-location of test_helpers.

The Simulator

This deployment architecture uses a simulator.  While it is fully
functional and useful for testing it lacks security or robustness, so
we want to emphasize *not to deploy this* to non-test environments.


There are three rationales for this approach:

First, Least Authority didn't want to push through modifications to
mlab-ns without first creating and testing a proof-of-concept.

Second, we didn't want to block our effort on M-Lab engineering
effort, so this allows a clean division of labor.

Third, by creating and testing a working proof of concept we can help
define the necessary changes to mlab-ns in a tightly scoped and
concrete manner.


This system is insecure because it does not use the M-Lab nagios
system to gather data, and instead lets anyone paste any data they
want into the simulator.  Nagios integration is future work captured
in this ticket:

* https://github.com/m-lab-tools/ooni-support/issues/10

Next Steps

Our contract with OTF proposes our next two milestones will focus on
improving integration testing and unit test coverage.  Our focus at
that time was on test automation and documentation for diagnosing
integration problems.  Test automation has already been improved since
that time, and we've accomplished most of the work for documentation:


Therefore, we propose to focus on some outstanding issues which will
improve mlab-ns integration while continuing not to block on, or
interfere with, M-Lab operations as follows:

The primary change to mlab-ns will be to allow any tool to include
arbitrary data per slivver to be gathered and distributed by mlab-ns.
Ooni will use this to distribute data such as collector `.onion`
addresses.  The need for this change is discussed here:

* https://github.com/m-lab-tools/ooni-support/issues/4

This proposed change is documented in this ticket:

* https://github.com/m-lab-tools/ooni-support/issues/47

A secondary change is to implement `match=all` described in #47 above.
It may not be necessary, so there is further investigation and testing


Along with these changes to `mlab-ns`, we need trivial updates to our
integration scripts to work with mlab-ns rather than the simulator:

* https://github.com/m-lab-tools/ooni-support/issues/10
* https://github.com/m-lab-tools/ooni-support/issues/11

Details & Links

Attached is a shortish overview of possible approaches to implement
this integration.  We've implemented a deployment with a mock mlab-ns
(called mlab-ns-simulator) and the "arbitrary data" approach from the
attached design document.  The pull request is here:

* https://github.com/m-lab-tools/ooni-support/pull/59

Specific details about this pull request:

* A script for gathering necessary information from collectors and
testhelpers, then updating the mlab-ns-simulator.
* A script for updating a bouncer's state based on the mlan-ns-simulator.
* A cron script to update the bouncer on an hourly schedule.
* The mlab-ns-simulator itself, which approximates the production mlab-ns.
* `.init/` script changes to automatically launch the simulator and
bouncer on `mlab1.nuq0t.measurement-lab.org`.
* Design documentation for mlab-ns integration (including this
stepping stone architecture).
* Each instructions to disable mlab-ns integration without any redeployment.

We also created a subset pull request that has bug fixes but no
mlab-ns integration features:

* https://github.com/m-lab-tools/ooni-support/pull/58

Github Milestones

We split the mlab-ns-simulator deployment tasks out from the larger
mlab-ns integration deployment.  The mlab-ns-simulator milestone is

* https://github.com/m-lab-tools/ooni-support/issues?q=is%3Aissue+milestone%3A%22mlab-ns-simulator+deployment%22

The full mlab-ns integration milestone:

* https://github.com/m-lab-tools/ooni-support/issues?q=is%3Aissue+milestone%3A%22mlab-ns+Integration%22

As always, let us know if you have any feedback!

Nathan Wilcox
Least Authoritarian

email: nathan at leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED  E9C9 3BFE 5263 1116 9993
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mlabns-integration.rst
Type: application/octet-stream
Size: 4272 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/ooni-dev/attachments/20140801/f689a8e4/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mlabns-integration.pdf
Type: application/pdf
Size: 13938 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/ooni-dev/attachments/20140801/f689a8e4/attachment-0001.pdf>

More information about the ooni-dev mailing list