Monday, October 27, 2014

Paper 5: " Intentional Network Monitoring: Finding the Needle without Capturing the Haystack" (Donovan, Feamster)

Presenter: Sean Donovan

Authors: Sean Donovan, Nick Feamster (Georgia Institute of Technology)

Sean starts by describing the story of catching a spy acting in a company, only knowing that he/she uses some VoIP technology. Out of a network log, the obvious first thing to do is to isolate VoIP flows. The problem though is that it is likely that there will be a lot of concurrent VoIP traffic and often, a lot more will be mixed in. How can someone filter out everything that does not relate to the spy? You could filter based on the IP address, but the spy can move, e.g. change access point, or start using a different VoIP services (Google Hangout today, Skype tomorrow). Sean believes that "SDN is a good hammer to nail this problem".

In this paper, the authors introduce Intentional Network Monitoring (INM) which can be seen as an extension of the Intentional Naming System concept (see With INM, one can express monitoring requirements at a high-level, one that maps operator's understanding of what is going on in the network. For instance, INM enables to express requirements such as "Capture all traffic from Sean". Other examples of INM usage include billing based on traffic type or redirecting traffic based on source networks.

To realize INM in practice, Sean implemented NetAssay (check out his code: NetAssay is a SDN-based system built on top of Pyretic ( NetAssay policies are declarative. You say what you want, and the system figures out (compiles) the low-level rules that need to be spit out to the SDN devices. At a high-level, NetAssay can therefore be seen as a mapping engine that can harness whatever existing mapping systems out there such as BGP, DNS, ARP, LDAP, etc. Right now, they have two mapping engines in place: DNS and BGP.

The biggest challenge faced in compiling NetAssay policies is the number of forwarding rules they currently require. It is indeed possible to completely exhaust switches' forwarding resources with a single NetAssay policy. The authors are currently looking at optimizations mechanisms to speed up: the compilation time; as well as the size of the produced forwarding policies.

- Q&A

Q: What is the difference between NetAssay and functional programming?
A: Different objectives. NetAssay is working at a higher level, and is only concerned by the match() part of a SDN forwarding rule, not the action part.

Q (Vyas Sekar): How do you deal with name changes? 
A: Interesting question. We haven't considered that case yet.