Explaining Network Telemetry

A really interesting series of talks on how to gather and share information about the performance of networks at today’s GEANT Telemetry and Data Workshop. One of the most positive things was a clear awareness that this information can be sensitive both to individuals and to connected organisations. So, as the last speaker, I decided I didn’t need to present “be careful” and talked instead about “how to reassure lawyers, partners and users”.

Key point, in my experience of being on both sides of that question, is not to ask “Can we do this?”: that immediately gets people envisaging how wrong it could go. Instead, explain “This is what we need to do, here’s how we propose to make it safe: are you comfortable with that?”. They may still be able to suggest improvements, which is great: now we’re working together, rather than in opposition.

As usual on this blog, the GDPR provides some useful pointers to how to make things safe. Remember that its subject is “the protection of natural persons … and the free movement of data”. So how might we do both of those with information about networks? Some ideas:

  • Active measurements, especially between devices deployed for that purpose such as perfSONAR, are likely to contain less extraneous, potentially-sensitive, information than monitoring real user traffic. For many of the things you want to know about a network, they are a more reliable source anyway.
  • In GDPR terms, data about a device such as a router or server that has a large number of indistinguishable users is much easier to work with than data about something that might be a single-user’s endpoint. Again, measuring performance between institutions and/or key network nodes is often more relevant than individual flows, too.
  • If you do need to get closer to the edge of the network and measure user experience, then statistics will often provide relevant information. Data protection law doesn’t have a fixed threshold, but if you can show that you are combining data from at least 10-20 individual users then both users and lawyers will usually be more relaxed.
  • Finally, there are situations where you do need to look at individual flows: primarily to debug them (if the individual involved has reported a problem) or to investigate a possible security problem (if someone else has). In the first case it should be natural, and uncontentious, to explain that to debug a network issue you need to look at the individual’s network traffic. Professional codes, such as our System Administrator’s Charter (which also works for network admins) should add reassurance. For security problems, I’ve written and presented a lot on how the GDPR actually encourages necessary use and sharing of network and system data.

Each of these kinds of safeguards can benefit from a bit of simple (definitely not lawyerly!) documentation: how and where active measurement works; how you select devices that are privacy-safe to monitor; how your statistical techniques irreversibly anonymise general data; and the safeguards you apply when investigating faults or security issues. And, above all, how these activities benefit all users of networks and systems. With those in hand you should be able to discuss your planned network telemetry activities with confidence.

By Andrew Cormack

I'm Chief Regulatory Advisor at Jisc, responsible for keeping an eye out for places where our ideas, services and products might raise regulatory issues. My aim is to fix either the product or service, or the regulation, before there's a painful bump!

Leave a Reply

Your email address will not be published.