StreaMon: a data-plane programming abstraction forSoftware-defined Stream Monitoring∗

Giuseppe Bianchi, Marco Bonola, Giulio Picierro, Salvatore Pontarelli, Marco MonaciUniversity of Rome "Tor Vergata"

name.surname@uniroma2.it

ABSTRACTThe fast evolving nature of modern cyber threats and net-work monitoring needs calls for new, “software-defined”,approaches to simplify and quicken programming and de-ployment of online (stream-based) traffic analysis functions.StreaMon is a carefully designed data-plane abstraction de-vised to scalably decouple the “programming logic” of atraffic analysis application (tracked states, features, anomalyconditions, etc.) from elementary primitives (counting andmetering, matching, events generation, etc), efficiently pre-implemented in the probes, and used as common instructionset for supporting the desired logic. Multi-stage multi-stepreal-time tracking and detection algorithms are supported viathe ability to deploy custom states, relevant state transitions,and associated monitoring actions and triggering conditions.Such a separation entails platform-independent, portable, on-line traffic analysis tasks written in a high level language,without requiring developers to access the monitoring deviceinternals and program their custom monitoring logic via lowlevel compiled languages (e.g., C, assembly, VHDL). Wevalidate our design by developing a prototype and a set ofsimple (but functionally demanding) use-case applicationsand by testing them over real traffic traces.

1. INTRODUCTIONThe sheer volume of networked information, in con-

junction with the complexity and polymorphous na-ture of modern cyberthreats, calls for scalable, accurate,and, at the same time, flexible and programmable mon-itoring systems [13, 11]. The challenge is to promptlyreact to fastly mutating needs by deploying custom traf-fic analyses, capable of tracking event chains and multi-stage attacks, and efficiently handle the many hetero-geneous features, events, and conditions which char-acterize an operational failure, a network applicationmis-behavior, an anomaly or an incoming attack. Suchneeded level of flexibility and programmability shouldaddress scalability by design, through systematic ex-ploitation of stream-based analysis techniques. And,even more challenging, traffic analyses and mitigation

∗This work will be submitted for possible publication. Copyright may be trans-

ferred without notice, after which this version may no longer be accessible.

primitives should be ideally brought inside the monitor-ing probes themselves at data plane, so as to avoid ex-porting traffic data to central analysis points, an hardlyadequate way to cope with the traffic scale and the strict(ideally real time) mitigation delay requirements.

To face this rapidly evolving scenario, in this paper wepropose StreaMon, a data-plane programming abstrac-tion for stream-based monitoring tasks directly runningover network probes. StreaMon is devised as a prag-matic tradeoff between full programmability and ven-dors’ need to keep their platforms closed. StreaMon’sstrategy closely resembles that pioneered by Openflow[25] in the abstraction of networking functionalities, thuspaving the road towards software-defined networking1.However, the analogy with Openflow limits to the strate-gic level; in its technical design, StreaMon significantlydeparts from Openflow for the very simple reason that(as discussed in Section 2) the data-plane programma-bility of monitoring tasks exhibits very different require-ments with respect to the data-plane programmabilityof networking functionalities, and thus mandate for dif-ferent programming abstractions.The actual contribution of this paper is threefold.

(1) We identify (and design an execution platformfor) an extremely simple abstraction which appears ca-pable of supporting a wide range of monitoring appli-cation requirements. The proposed API decouples themonitoring application “logic”, externally provided bya third party programmer via (easy to code) eXtendedFinite State Machines (XFSM), from the actual “prim-itives”, namely configurable sketch-based measurementmodules, d-left hash tables, state management primi-tives, and export/mitigation actions, hard-coded in thedevice. While our handling of sketch-based measure-ment primitives may recall [34], we radically differenti-ate from any other work we are aware of, in our pro-

1 And in fact, even if the focus of this paper is (as a first step)only on the data plane interface itself, we believe that Strea-Mon could eventually candidate to play the role of a pos-sible southbound data-plane interface for Software-DefinedMonitoring frameworks, devised to translate high level mon-itoring tasks into a sequence of low-level traffic analysis pro-grams distributed into network-wide StreaMon probes.

1

arX

iv:1

311.

2442

v1 [

cs.N

I] 1

1 N

ov 2

013

Event match

Event ID Event ID Primary Key Flow State

Triggered Action

IDENTIFICATION (of tracked entity)

MEASUREMENT (associated to entity and its state)

DECISION (condition evaluation)

(consequent action & state transition)

Primary Key Event ID Primary Key Flow Status Features

Packet or

Timeout

Entitymatch

State Lookup

Sketch-based O(1) meas. bank

Feature extraction

Condition verification

State transition

External

Data/alert Export when applicable

Figure 1: StreaMon data plane identification/measurement/decision abstraction, and its mapping to implementation-specific workflow tasks

posal to inject monitoring logic in the form of XFSMdevised to locally orchestrate and run-time adapt mea-surements to the tracked state for each monitored entity(flows, hosts, DNS names, etc), with no need to resortto an external controlling device.

(2) We implement two StreaMon platform prototypes,a full SW and a FPGA/SW integrated implementation.We functionally validate them with five use case exam-ples (P2P traffic classification, Conficker botnet detec-tion, packet entropy HW analysis, DDos detection, PortKnocking), not meant as stand-alone contributions, butrather selected to showcase the StreaMon’s adaptabilityto different application requirements.

(3) We assess the performance of the proposed ap-proach: even if the current prototype implementation isnot primarily designed with performance requirementsin mind, we show that it can already sustain traffic inthe multi-gbps range even with several instantiated met-rics (for example 2.315 Gbps of real world replayed traf-fic with 16 metrics, see section 5.2); moreover, we showthat scalability can be easily enhanced by offloading theSW implementation with HW accelerated metrics; inessence, it seems fair to say that scalability appears tobe an architectural property of our proposed API, ratherthan a side effect of an efficient implementation.

2. STREAMON ABSTRACTIONOur strategy in devising an abstraction for deploying

stream-based monitoring tasks over a (general-purpose)network monitoring probe is similar in spirit to thatbrought about by the designers of the Openflow [25]match/action abstraction, for programming network-ing functionalities over a switching fabric. Indeed, wealso aim at identifying a compromise between full pro-gramming flexibility, so as to adapt to the very diverseneeds of monitoring application developers and permita broad range of innovation, and consistency with thevendors’ need for closed platforms. However, the re-quirements of monitoring applications appear largelydifferent from that of a networking functionality, andthis naturally drives towards a different pragmatic ab-straction with respect to a match/action table.

At least three important differences do emerge. First,the “entity” being monitored is not consistently associ-ated with the same field (or set of fields) in the packetheader. For instance, if the target is to detect whether

an IP address (monitored entity) is a bot, and the cho-sen mechanism is to analyze if the percentage of DNSNXDomain replies (feature) is greater than a given thresh-old (condition), the flow key to use for accounting is thesource IP address when the arriving packet is a DNSquery (event), but becomes the destination IP addresswhen the packet is a DNS response (a different event).

Second, the type of analysis (and possibly the mon-itoring entity target) entailed by a monitoring applica-tion may change over time, dynamically adapting to theknowledge gathered so far. For instance, if an IP ad-dress exhibits a critical percentage of DNS NXDomainreplies, hence a bot suspect, we may further track itsTCP SYNACK/SYN ratio and determine whether hor-izontal network scans occur, so as to reinforce our sus-picion. And we might then follow up by deriving evenmore in-depth features, e.g., based on deep packet in-spection. But at the same time, we would like to avoidtracking all features for all the possible flows, as thiswould unnecessarily drain computational resources.

Finally, activities associated to a monitoring task arenot all associated to a matching functionality: onlymeasurement and accounting tasks are. Rather, lessfrequent, but crucial, activities (such as forging and ex-porting alerts, changing states, setting a mitigation fil-tering rule, and so on) are based on decisions taken onwhat we learned so far, and which are hence triggeredby conditions applied to the gathered features.

Our proposed StreaMon abstraction, illustrated infigure 1, appears capable to cope with such require-ments (as more extensively shown with the use casespresented in section 4). It comprises of three “stages”,programmable by the monitoring application developervia external means (i.e. not accessing the internal probeplatform implementation).

(1) The Identification stage permits the program-mer to specify what is the monitored entity (more pre-cisely, deriving its primary key, i.e., a combination ofpacket fields that identify the entity) associated to anevent triggered by the actual packet under arrival, aswell as retrieve an eventually associated state2.

2 Our implementation uses d-left hashes for O(1) complex-ity in managing states. Also, memory consumption can begreatly reduced by opportunistically storing only non-default(e.g. anomalous) states. See the illustrative experiment inFig. 2 for a rough idea of the attainable saving in the Con-ficker detection example, use case 4.2.

2

0  

500  

1000  

1500  

2000  

2500  

0   300   600   900  

TCP  [packets  per  se

cond

]  

9me  [sec]  (b)  

pkt1  

pkt2  

1  

10  

100  

1000  

0   20   40   60   80   100   120   140   160  

Num

ber  o

f  hosts  

Number  of  NXDomain  responses  (a)  

Figure 2: Experimental analysis of number of NXDomain DNS re-sponses received (a feature commonly used in Botnet de-tection, e.g., [22]). Data obtained using a trace of 155minutes with 955 different hosts belonging to 36 differ-ent /24 subnetworks. (a): Number F1 of DNS NXDomainresponses received per host (430 IPs performing at least1 DNS query, 401 of them don’t receive any NXDomainresponse); (b): number of tcp packet per seconds for allthe flows (pkt1) and only for the flows for which F1 >= 1(pkt2), 15 minutes sample; analysis time for whole pkt1trace: 1179 seconds, versus 68 seconds for pkt2.

(2) The Measurement stage permits the program-mer to configure which information should be accounted.It integrates hard-coded and efficiently implemented hash-based measurement primitives (metric modules), fed byconfigurable packet/protocol fields, with externally pro-grammed features, expressed as arbitrary arithmetic op-erations on the metric modules’ output.

(3) The Decision stage is the most novel aspectof our abstraction. It permits to take decisions pro-grammed in the form of eXtended Finite State Machines(XFSM), i.e. check conditions associated to the currentstate and tested over the currently computed features,and trigger associated actions and/or state transitions.

The obvious compromise in our proposed approachis that (as per the match/action Openflow primitives)new metrics or actions can only be added by directlyimplementing them over the monitoring devices, thusextending the device capabilities. However, even re-stricting to our actual StreaMon prototype, the subsetof metrics we implemented appear reusable and suffi-cient to support features proposed in a meaningful setof literature applications - see Table 1 in Section 3.2.

3. STREAMON PROCESSING ENGINE

3.1 System componentsThe previously introduced abstraction can be con-

cretely implemented by a stream processing engine whosearchitecture is depicted in Figure 3. It consists of fourmodular layers descriptively organized into two subsys-

M1  

Metric Layer

M2  

M3  

Feature Layer

F1  =  M1+M2  

F2  =  M3/M2  

Decision Layer

if  (f1>200)  then  ACTION    

if  (f2<.05)    then  ACTION  

Event Layer

Timeouts  

Status  Table  

Capture  Engine  

   

incoming packet

   

   

   

state transition

timeout update

timeout expiration

Logic subsystem Measurement

subsystem

Figure 3: StreaMon processing engine architecture

tems, namely Measurement subsystem and Logic sub-system, detailed in sections 3.2 and 3.3, respectively.

Event layer - Such layer is in charge of parsing eachraw captured packet, and match an event among thoseuser-programmed via the StreaMon API. The matchedevent identifies a user-programmed primary key whichpermits to retrieve an eventually stored state. The eventlayer is further in charge of supplementary technicaltasks (see section 3.3), such as handling special time-out events, deriving further secondary keys, etc.

Metric layer - StreaMon operates on a per-packetbasis and does not store any (raw) traffic in a localdatabase. The application programmer can instanti-ate a number of metrics derived by a basic commonstructure, implemented as computation/memory effi-cient multi-hash data structures (i.e., Bloom-type sketches),updated at every packet arrival.

Feature layer - this layer permits to compute user-defined arithmetic functions over (one or more) metricoutputs. Whereas metrics carry out the bulky task ofaccounting basic statistics in a scalable and computa-tion/memory efficient manner, the features compute de-rived statistics tailored to the specific application needs,at no (noticeable) extra computational/memory cost.

Decision layer - this final processing stage imple-ments the actual application logic. This layer keepsa list of conditions expressed as mathematical/logicalfunctions of the feature vector provided by the pre-vious layer and any other possible secondary status.Each condition will trigger a set of specified and pre-implemented actions and a state transition.

StreaMon’s programming languageApplication programmers describe their desired moni-toring operations through an high-level XML-like lan-guage, which permits to specify custom (dynamic) states,configure measurement metrics, formalize when (e.g.inwhich state and for which event) and how (i.e. byperforming which operations over available metrics andstate information) to extract features, and under whichconditions trigger relevant actions (e.g. send an alert ordata to a central controller). We remark that a moni-toring application formally specified using our XML de-

3

Figure 4: Excerpt of XML based StreaMon code showing: (i) met-ric element allocation, (ii) feature compositions, (iii) anevent logic description. In particular this picture shows atimeout event handler, described in terms of metric oper-ations, feature extractions, conditions, actions and statetransition

scription does not require to be compiled by applicationdevelopers, but is run-time installed, thus significantlysimplifying on-field deployment. Figure 4 shows an ex-cerpt of a StreaMon application code.

HW accelerationStreaMon allows the seamless integration of HW ac-celerated metrics, e.g. mandated by stringent perfor-mance requirements. This remains transparent to theapplication programmer, which can thus port the sameapplication from a SW based probe to a dedicated HWplatform with no changes in the application program.Seamless HW integration is technically accomplishedby performing all metrics, parsing, and event match-ing HW-accelerated computations in a front-end (in ourspecific case, an FPGA), and by bringing the relevantresults up to the user plane through a HW/SW inter-face, by appending the meta-data generated by the HWtasks to the packet.

3.2 Measurement SubsystemThe StreaMon Measurement subsystem provides a

fast, computation/memory efficient, set of n highly con-figurable built-in modules that allows a programmer todeploy and compute a wide range of traffic features instream mode.

Multi-Hash Metric module (MH) - From a highlevel point of view, StreaMon metric modules are func-

Detector BF

Variation Detector Variation Monitor

Monitor BF (TBF, CBF, SC,

DLEFT)

Flowkey Extractor

Flowkeys (DFK, MFK)

parser config

   

   

params packet +

metadata Learning BF

   

   

DFK

   

MFK

   

Figure 5: Metric module structure

tional blocks exporting a simple interface to update andretrieve metric values associated to a given key. Eventhough in principle such modules can be implementedwith any compact data structure compatible to our pro-posed stream mode approach (and indeed the currentarchitecture support pluggable user defined metric mod-ules), several metrics of practical interest can be derivedfrom a basic structure depicted in Figure 5 and extend-ing the construction proposed in [5]. It permits to count(or time-average, see below) distinct values (called vari-ations in [5]) associated to a same key; for example: thenumber of distinct IP destinations contacted by a sameIP source, or the number of distinct DNS names asso-ciated to a same IP address. The MH module is imple-mented using Bloom filter extensions [9, 5, 6]. Process-ing occurs in three stages: (i) extract from the packet3

two binary strings, Detector FlowKey (DFK) and Mon-itor FlowKey (MFK), that will be used in to query thesubsequent filters; (ii) detect whether the DFK has al-ready appeared in a past time window (Variation De-tector filter, VD), and if this is the case, iii) account tothe MFK key some packet-related quantity (e.g. num-ber of bytes, or simply add 1 if packet count is targeted)to the third stage’s Variation Monitor (VM) filter. Thereader interested in the rationale behind such construc-tion and in further design details may refer to [5]. Fi-nally note that, as a special case, the MH module canbe configured to either i) provide an ordinary count,by disabling the VD stage, or ii) perform a match forchecking whether some information associated to theincoming packet is first seen (in a given time window),by disabling the VM stage.

Programming the Measurement subsystem -StreaMon programmers can deploy two types of “count-ing” data structures: (i) an ordinary Count Sketch thatsums a value associated to the MFK (CBF) or (ii) aTime decaying Bloom Filter (TBF) [6] that performs asmoothed (exponentially decaying) average of a valueassociated to the MFK. At deployment time, an MHmodule is configured by: (i) enabling/disabling the VDor the VM; (ii) specifying the counting data structurein the VM; (iii) setting the MH parameters, i.e., num-

3 Even if, for simplicity of explanation, we account suchan extraction to the MH module, for obvious performancereasons we perform packet parsing and the consequent ex-traction of the flowkeys DFK and MFK once for all, for allmetrics, in the Event Layer. Indeed, different metrics maymake usage of a same packet field.

4

Paper Description Brief description of reference features supported by StreaMon[7] Passive DNS anal. x mali-

cious domain detection(i) Short life and Access Ratio per domain; (ii) Multi-homing/multi-address perdomain; (iii) AVG, STD, total number, CDF of the TTL for a given domain

[32] Traffic charact. via Com-plex Network modeling

CDF, STD, Max/Min of: (i) total number of endpoints and correspondent host perendpoint; (ii) bytes exchanged between two endpoints

[17] DNS analysis for fastfluxdomain detection

Arithmetic functions of: (i) number of unique A records returned in all DNS lookups,(ii) number of A records in a DNS response, (iii) number of name server (NS) recordsin one single lookup, (iv) number of unique ASNs for each A record

[33] Stateful VOIP attack de-tection

Stateful rules: (i) RTP traffic after SIP BYE? (ii) source IP address changed in timewindow? (iii) RTP sequence numbers evolve correctly?

[26] DDOS detection throughICMP and L4 analysis

Sent/received TCP packet ratio; Sent/received for different ICMP messages; UDPbitrate; No. different UDP connections per destination; Connection packet count

[12] SVM-based method forP2P traffic classification

Per distinct host and port: (i) ratio between TCP and UDP traffic; (ii) AVG trafficspeed; (iii) ratio between TCP and UDP AVG packet length; Per distinct IP: (i)ARP request count, (ii) ratio between sent/received TCP, UDP packet, (iii) ratiobetween {TCP, UDP} and total traffic; Per distinct port: traffic duration

[16] Mail spammer detectionvia Network level analysis

(i) AVG/STD msg len in past 24h; (ii) AVG distance to 20 nearest IP neighbors ofthe sender; (iii) AVG/STD of geodesic distance between sender and recipient; (iv)Message body len; (v) AVG, STD and total no. different recipients

Table 1

ber of hash functions, total memory allocated, swappingthreshold [5] or memory time window in the VD, TBF’ssmoothing parameter [6]; (iv) chain multiple MH mod-ule (so as to update a metric only if a former one was up-dated). At run time, the programmer may dynamicallychange flowkeys and updating quantities. In particu-lar, for each possible event and (if needed) flow status(i.e., XFSM entry), a list of Metric Operations (MOP)is defined, where a MOP is a set/get primitive that de-fines the flowkeys (as a packet fields combinations) andquantities to be monitored/accounted. Finally, a set ofStreaMon metrics are combined into Features by simplydefining mathematical functions Fi = fi(M), where Mis a Metric vector.

What practical features can be supported? -We believe that the above metrics fulfill the needs of anon negligible fraction of real world monitoring appli-cations. Indeed, [6] shows a concrete example of a realworld application reimplemented by just using modulesderived from our general MH module described above.Indeed, limiting to the StreaMon’s measurement sub-system (we will significantly extend the framework inthe next section), table 1 shows features considered ina number of works taken from a somewhat heteroge-neous set (different targets, operating at different net-work layers, different classification approaches) which,according to our analysis, are readily deployed throughsuitable configuration of the above metrics/features. In-deed, most applications either require to track/match(1) features that are directly retrievable from a singlepacket and do not have memory of past values (e.g.:short life of a DNS domain, message body length, allthe features in [17] except the first one); and/or (2) re-quire counting or averaging over a various set of param-eters (eventually uniquely accounted - e.g. variations),

which are readily instantiated with an MH module4;and/or (3) require logical/mathematical combinationsof different statistics, which is the goal of our FeatureLayer. Traffic features not covered by the families listedabove are those which require a stateful correlation ofdifferent flows status. Such metrics (like the ones ex-ploited in [33]) are supported by StreaMon but requirethe stateful framework described in Section 3.3.

3.3 Logic subsystemStreaMon’s Logic Subsystem is the result of the inter-

work between the Event Layer and the Decision Layer.It provides the application developer with the ability tocustomize the tracking logic associated to a monitoredentity subject to specific user-defined conditions, so asto provide a verdict and/or perform analyses beyondthose provided by the Monitoring Subsystem.

Event Layer - The Event Layer generates the eventstriggering the StreaMon processing chain, identifies themonitored entity (primary key), and retrieves the spe-cific event context (in particular the flow status). Thislayer is further composed of three functional compo-nent: (i) the capture engine responsible for “captur-ing” the triggering event, either a “packet arrival” or a“timeout expiration”;(ii) the timeout manager in chargeof keeping track of all registered timeouts and managetheir expiration; (iii) the status table, a (dleft hash) ta-ble storing the status associated to the processed flows- the primary key status - and the so-called secondary

4 For instance, the number of bytes exchanged between twohosts can be obtained by setting as VMK is the concate-nation of source and destination IP address and as updat-ing quantity the length field of the packet; similarly, uniquecounts such as the total number of distinct TTL for a givenDNS domain is obtained by setting as VDK the concatena-tion of Domain Name and TTL in the DNS response and asVMK is the Domain Name.

5

support table, a table storing states not associated tothe primary key but required by the application statemachine to take some decision.

The triggering event is associated to a primary key,i.e. the monitored entity (flow, host, etc) under inves-tigation for which the monitoring application will pro-vide a final verdict, like “infected” or “legitimate”. Forintercepted packets, the primary key is a combinationof packet fields parsed by the (extensible) protocol dis-sector implemented in this layer. For locally generatedtimeout expiration events, the primary key is retrievedfrom the timeout context. The primary key is used toretrieve the current status of the flow: no match in thestate table is considered to be a default state.

If the primary key is not directly retrievable from thepacket, and instead the flow status is related to someother flow previously processed, a secondary supporttable storing the references to the entries in the statustable is used. Such secondary support table is called re-lated status table. For example, this can be the case ofan application keeping track of SIP URIs, (i.e.: the pri-mary key is the SIP user ID in SIP INVITE messages)and consider as suspicious all UDP packets related to adata connection with a suspicious SIP user. In case ofUDP packets, neither of the packet fields can be used toretrieve the flow status. Instead, a secondary supporttable is used to keep a reference between the socket 5-tuple and the status entry of the associated SIP initiatoruser. If the application does not take into account theflow status, the primary extraction is skipped.

Decision Layer - The Decision Layer is the lastprocessing unit of the StreaMon architecture and re-ceives the event context carrying an indication of thecurrent flow status and a set of traffic features con-tainer. This layer keeps a list of Decision Entries (DEs)defined as the 3-tuple (enabling Condition (C), Out-put actions (O), State Transition (ST)). For each trig-gering event, and according to the current flow status,the decision layer verifies the enabling conditions andexecutes the actions and the state transition associ-ated to the matched condition. Since secondary sup-port tables can be updated, StreaMon support vari-able conditions, i.e. in which the comparison operandsmay change during time. The first matched conditionwill trigger the execution of a action set (like DROP,ALERT, SET TIMEOUT etc..).

Programming the Logic Subsystem - Program-mers describe an XFSM specifying (i) states and trig-gering events; (ii) for each state, which metrics and fea-tures are updated and which auxiliary information iscollected/processed (secondary table); (iii) which con-ditions trigger a state transition and the associated ac-tions.

To identify the triggering event, StreaMon keeps alist of user-defined “event descriptors”, expressed as a

Logic Subsystem built-in primitives

OperatorsSUM, DIFF, DIV, MULT, MODEQ, NEQ, LT, GT, SQRT, LOG, POWAND, OR, NOT, XOR

ActionsSET_TIMEOUT, UPDATE_TIMEOUTSAVE_TIMEOUT_CTX, DROP, ALLOW, MARKNEXT_STATUS, UPDATE_TABLE, PRINT, EXPORT

Table 2

3-tuple (type, descriptor, primary key). For example,in case of intercepted packets, an event can be definedas: (packet; (udp.dport == 53); ip.src).

Moreover, programmers are given primitives to definefor each event and state: (i) a set of metric operations(MOP) as described in section 3.2; (ii) a set of con-ditions expressed as an arithmetic function of featuresand secondary support table values. For each condi-tion, programmers define a set of built-in actions and astate transition. Table 2 summarizes the logic subsys-tem supported condition operators and actions.

4. SIMPLE USE CASE EXAMPLESWe use the following simple examples to highlight

the flexibility of StreaMon in supporting heterogeneousfeatures commonly found in real-world monitoring ap-plications. The input data traces are obtained by prop-erly merging a packet trace gathered from a regionalInternet provider with either (i) real malicious trafficextracted from traces captured in our campus network(use case 4.1 and 4.2) or (ii) synthetic traces properlygenerated in our laboratories (use case 4.3).

4.1 P2P traffic classificationThis example shows how straightforward is the im-

plementation of three transport layer traffic features de-scribed in [20], for detecting peer to peer protocols thatuse UDP and TCP connections. The (stateless) appli-cation considers the following packet events (which willignore well known UDP and TCP ports.):E1 : if(ip.proto == UDP )&&(udp.port 6= 25, 53, 110, ...)

E2 : if(ip.proto == TCP )&&(tcp.port 6= 25, 53, 110, ...)

This application extracts the following traffic featuresF1 = M1&M2; F2 = |M3 −M4| where:{M1,M2}: VD enabled - return 1 for each IP src/dstpair which previously opened a {UDP, TCP} socket, 0otherwise;{M3,M4}: VD enabled and VM type CBF - countthe number of different {TCP source ports, hosts} con-nected to the same destination IP address.

Metrics are read/updated on the basis of the matchedevent, as follows:

E1 E2

set(M1, ip.src|ip.dst) get(M1, ip.src|ip.dst);get(M2, ip.src|ip.dst) set(M2, ip.src|ip.dst)get(M3, ip.dst) set(M3, tcp.sport|ip.dst, ip.dst)get(M4, ip.dst) set(M4, ip.src|ip.dst, ip.dst)

get(Mi, ip.src), i = 3, 4

6

TRANSITION_EVENT metric_operations() [conditions] <transition_action()>

(a) (b)

INFECTED

RECV_DNS_RESP update(M2, ip.dst) get(M1, ip.src) [if (F1 > .25) <set_timeout(10s)>

RECV_DNS_REQ update(M1, ip.src)

get(M2, ip.src) DEFAULT

RECV_SYNACK update(M4, ip.dst)

RECV_SYN update(M3, ip.src)

EXPIRED_TIMEOUT [if F2 > .5] <alert()>

ALERT

EXPIRED_TIMEOUT [if F2 <= .5]

RECV_TCP_SYN update(M1, ip.dst)

update(M2, ip.src|ip.dst)

RECV_TCP_SYN update(M1, ip.dst) update(M2, ip.src|ip.dst) [if F1 < 100]

EXPIRED_TIMEOUT [if F1 >= 1.2*F1_old] <set_timeout(10)> <update_table(ip.dst, F1)>

MONITORED

RECV_ANY_FROM_IFACE1 [If F2 > 5] <DROP>

RECV_TCP_SYN update(M1, ip.dst)

EXPIRED_TIMEOUT [if F1 < 0.8*F1_old] <set_timeout(10)>

<update_table(ip.dst, F1)>

ATTACK

EXPIRED_TIMEOUT [if F1 > 1.2*F1_old] <quarantine(ip.dst)> <set_timeout (10)> <update_table(ip.dst, F1)>

NORMAL

RECV_TCP_SYN update(M1, ip.dst) update(M2, ip.src|ip.dst) [if F1 >= 100] <set_timeout(10)> <update_table(ip.dst, F1)>

EXPIRED_TIMEOUT [if F1 < 1.2*F1_old] <update_table(ip.dst, F1)>

ALERT

Figure 6: Application XFSMs: (a) Conficker use case; (b) DDOS use case

The application detects a p2p client if the follow-ing condition holds after a transitory period: (F1 ==1&&(F2 < 10)).

4.2 Conficker botnet detectionConficker is one of the largest Botnets found in re-

cent years [29]. A multi-step detection algorithm canattempt to track the two following (separated) phase:(1) a bot tries to contact the C&C Server, and (2) asingle bot tries to contact and infect other hosts.

To contact the C&C Server, infected hosts performa huge number of DNS queries (with a high NXDo-main error probability) to resolve randomly generateddomains. In the infection phase, every host tries toopen a TCP connection to the ports 445 of randomIPs. Our Conficker detector will use the following met-rics (VD disabled and VM of type TBF ): number oftotal DNS queries per host (M1), number of DNS NX-Domain per host (M2) and number of TCP SYN andSYNACK to/from port 445 (respectively M3 and M4).These metrics are combined into the following features:F1 = M2/M1, F2 = M4/M3.

For a DNS NXDomain response, the condition F1 >0.25 is checked. If the condition is true, the state of theactual flow changes to alert and an event timeout is set.In the alert state the application updates M3 and M4

and, when this timeout expires, these metrics are usedto compute F2 and to verify the related condition: if thecondition is true, then the host is considered infectedand goes to the next state, otherwise it returns to thedefault state.

The application XFSM is graphically described (withsimplified syntax) in Figure 6.a. Figure 7 shows thetrend of features used in this configuration, for an hostinfected by Conficker (A) and for a clean host (B). Inthe first case, the value of F1 is relatively high sincethe beginning of the monitoring (due to the presence

0.0001  

0.001  

0.01  

0.1  

1  

0   400   800   1200   1600   2000   2400   2800   3200   3600  

Features  value

 

Time  [sec]  

F1  A   F2  A  

F1  B   F2  B  

Figure 7: Conficker features temporal evolution

of reverse DNS queries, easily filtered by the applica-tion); the value increases when the host starts to per-form Conficker queries. The value of F2 instead is verylow, clearly denoting a port scan. Also for the host Bthe presence of rDNS queries increases the value of F1

and this involve a change of state, and the applicationstarts to analyze TCP feature. However the F2 value(nearly 100% of SYNACKs are received) reveals thatthis is clearly not a network scan. Testing this configu-ration in a 90-hours trace with 53 different hosts in idlestate, we obtained 100% of detection (8 infected hostsdetected) without false positive or false negative.

4.3 DDOS detection and mitigationIn this section we sketch a simple algorithm which

can be used as an initial base for detecting and miti-gating DDOS attacks. The algorithm is driven by thenumber of SYN packets received by possible DDOS tar-gets. The XFSM of this configuration is depicted in 6.b,and is governed by the following two events:E1 : if(ip.proto == TCP )&&(tcp.flags == SY N)

E2 : timeoutexpired

Metric M1 (VD=off, VM=TBF) tracks the numberof TCP SYN addressed to a same target in 60 seconds(with 240s TBF’s memory). All external servers for

7

0,1  

1  

10  

100  

1000  

allowed pre dos allowed post dos SYN rate

0   50   100   150   200   250   300   350   400  Time [s]

server state a*ack  alert  

monitored  default  

Figure 8: DDOS temporal representation: (i) DDOS target hoststatus (red curve), (ii) F1 value for the DDOS target(blu curve) and (iii) F2 for two different legitimate trafficsources connecting to the DDOS target server

which F1 = M1 is under a given threshold (100 in thisexample) are in default state (because they are obvi-ously not under attack and thus do not need an ex-plicit status). When F1 exceeds this threshold, the tar-get goes in monitored state, a timeout is set and thecurrent value of F1 value is stored into a secondarysupport table with key ip.dst. As soon as this time-out expires, the difference between the current featurevalue and the one stored is computed. If the conditionif(F1(t) > 1.2 ∗ F1(t − 1)), holds for two consecutivetimes, i.e. the rate of TCP SYN has increased twice formore than 20%, the flow goes into an attack state.

Our use case example mimics this mitigation strat-egy by considering legitimate all the source hosts thathave already shown meaningful activity and contactedthe server before the actual emergence of the attack,and thus likely dropping most of the TCP SYN hav-ing a spoofed source IP address. In our use case ex-ample, a second metric M2 tracks the TCP SYN rate,smoothed over a chosen time window, at which whicheach host contacts each destination IP addresses (M2 isconfigured with VD disabled and VM of type TBF withsmoothing window 240s, and it is updated with MFK(IPsrc, IPdst).

Figure 8 shows the temporal evolution of the state ofa server, in an experiment where we performed a DDoSattack, with spoofed TCP SYN packets, after about140s. The figure also reports the measured TCP SYNrate, as well as the traffic generated by two hosts per-forming regular queries towards the server: one startingat time 0, and the other starting right in the middle ofthe attack. When the actual attack is detected, themitigation strategy starts filtering traffic. Thanks tothe second tracked metric, M2, the user starting ac-tivities before the DDoS attack is not filtered; on thecontrary, connections from sources not previously de-tected via the M2 metric are blocked, as shown by thegreen curve. New connections can be accepted as soonthe server leaves the attack state (see the F2 growth of

Figure 9: (a) percentage of printable character as function of thepercentage of packets (b) percentage of bit set to 1 asfunction of the percentage of packets

the second host).

4.4 HW accelerated detection of non standardencrypted traffic

This example shows how HW metrics can be inte-grated in StreaMon. Since one of the task performedduring deep packet inspection is the collection of statis-tics on byte frequencies, offsets for common byte-values,packet information entropy, we illustrate an use casethat is a simplified version of the approach described in[14], in which encrypted flows are detected by combin-ing two traffic features: (i) the bit information entropyof a packet; (ii) the percentage of printable characters,i.e. ASCII characters in the range [32 . . . 127]. Bothfeatures are computationally demanding for a softwareimplementation, whereas they are best delegated to anFPGA implementation (just 250 logic cells for our im-plementation).

This use case implements a simple stateless Strea-Mon application with the following characteristics: (i)it considers as event the reception of a UDP or TCPpacket with length greater than 100 bytes; (ii) the pri-mary key is the socket 5-tuple of the packet; (iii) itmakes use of two FPGA precomputed metrics: pop-count (number of bit set to 1) M1 and printable charspercentage M2 (which is directly mapped into a Strea-Mon feature F1 = M1); (v) the packet entropy Feature

F2 is obtained as − 1N

∑1i=0 ni ·(log(ni)− log(N), where

N = len, n0 = N −M1, n1 = M1. An encrypted flow isdetected if: (F2 < 0.75)&(−3σ < F1−HU (l) < 3σ)

where HU (l) is the entropy of a packet with uniformdistribution of 1 in the payload and length l and σ isthe standard deviation. Figure 9 shows M1 and M2

to the simple case of HTTP (unencrypted flow) andSSL (encrypted flow) traffic, and as in [14] justify thecondition expressed above.

4.5 Port knocking

8

default

4000contacted

allowed

TCP_SYN5000 <set_timeout(5)>

TCP_SYN4000 <set_timeout(5)>

TCP_SYN7000 <allow(from %ip.src to tcp.dport 22)>

TIMEOUT_EXIPERED

TCP_SYN update(M1) [if F1 > 30] <set_timeout(120)> <alert(%ip.src scanning)> TIMEOUT_EXIPERED

TIMEOUT_EXIPERED

TIMEOUT_EXIPERED

5000contacted

attack

Figure 10: Port Knocking use case XFSM

This use case shows how a stateful firewall applicationcan be easily implemented with StreaMon. In particu-lar, this use case implements a port knocking mecha-nism to enable SSH access. The application’s XFSM isdepicted in figure 10. SSH access will be granted onlyto those clients guessing the correct port sequence 5000,4000, 7000 (a short sequence only for presentation con-venience).

The application considers four events (TCP SYN re-ceived respectively on port 5000, 4000, 7000, other ports)and four states (default, 5000contacted, 4000contacted,allowed). A state transition is triggered only if the client(identified by the IP source address) contacts the ex-pected port in the sequence. If after a state transitionthe next expected port is not contacted in five seconds,the flow status is rolled back to default.

In addition, to avoid random port scanning for guess-ing the correct sequence, a metricM1 (VD=ON, VM=TBFwith smoothing window 5s) counting the SYN rate isused. If a port scan is detected (if(F1 = M1) > 40) theflow status is updated to ”attack”, the host is blocked for2 minutes and an alert is generated. M1 is updated withDFK = ip.src|ip.dst|tcp.dport and MFK = ip.srcwhen a SYN to an unexpected port is contacted.

5. PERFORMANCE EVALUATION

5.1 Implementation OverviewWe experimented StreaMon on two platforms. A

SW-only deployment leverages off-the-shelf NIC drivers,integrating the efficient PFQ packet capturing kernelmodule [8]. To test HW acceleration, we also deployedStreaMon using a 10 gbps Combo FPGA card as packetsource. In what follows, unless otherwise specified (specif-ically, section 5.2.3 which deals with HW acceleratedmetrics implemented over the Combo FPGA card) wefocus on the SW-only configuration.

StreaMon start-up sequence is summarized as follows.The application program is given as input to a pre-processor script as a XML formatted textual file. Theprogram is parsed, StreaMon process is configured andexecuted while in parallel the interpreted feature and

   

NIC driver

PFQ driver

Kernel

incoming packets

. . .

Q1

Q2

QN

Event source

Event source

Event source

Shared Status Tables

Metric/feature computation

Metric/feature computation

Metric/Feature computation

Shared Metric Banks

Chain thread N: affinity set tu CPU N

Decision

Decision

Decision

Shared Timeout Tables

Chain thread 2: affinity set tu CPU 2

Chain thread 1: affinity set tu CPU 1

User-space StreaMon SW implementation

Figure 11: StreaMon prototype implementation architecture

condition expressions are transformed them into C++code and build a ”on-demand DLL”5;

StreaMon implementation takes advantages from mul-ticore platforms by implementing parallel processing chainsas shown in the implementation architecture depicted infigure 11 (for the SW-only setup). The PFQ driver isused as packet filter and configured with a number ofsoftware queues equal to the number of cores. Trafficflows are dispatched from the physical queues of theNIC by the PFQ steering function. For each PFQ, aseparate StreaMon chain is executed by a single threadwith CPU affinity fixed to one of the available core andshare the metric banks, status tables and timeout tables(the concurrent access to the shared data is protectedby spinlocks).

The throughput measurement has been performed ona Intel Xeon X5650 (2.67 GHz, 6 cores) Linux serverwith, 16 GB ram and Intel 82599eb 10Gbit optical in-terfaces.

5.2 Performance Analysis

5.2.1 Measurement subsystem performanceFigure 12 shows the processing throughput expressed

as percentage of the maximum throughput (6,468 Gbps)obtained with one PFQ source block without the over-head of StreaMon, expressed as function of the numberof metrics (1, 4, 8, 16, 24, 32) in case of (1, 2, 3, 6)CPU core parallel processing. The input test data isa small portion of a long trace captured within a localinternet provider infrastructure and its parameters aresummarized in the following table:

5 Note that this is an optimization step which is devisedto on-the-fly compile (transparent to the programmer), theapplication code, so as to avoid a ”feature/condition inter-preter”, which would have lowered the overall performanceand would not have permitted line rate feature computationand condition verification. Since no recompilation of theStreaMon code is ever needed, but user defined features areintegrated as a DLL, dynamic deployment of user programsis made possible.

9

0%  10%  20%  30%  40%  50%  60%  70%  80%  90%  

100%  

0   4   8   12   16   20   24   28   32  

Thro

ughp

ut [%

]

Metric Number

Figure 12: System throughput evaluation

pkt no. AVG pkt len Host no. TX rate6320928 632.82 bytes 31827 6.47 Gbps

where pkt len and TX are the average packet lengthand replayed transmission bitrate respectively.

As expected, the throughput decreases with the num-ber of metrics and grows with the number of cores (eventhough the growth is lower than expected due to thesimple thread concurrency management adopted in thisprototype). It is important to underline that such graphshows the worst metric computational scenario in which:(i) all metrics are sequentially updated and retrievedfor each packet (single event and stateless logic) andare configured with both the VD (a BF pair) and theMV (DLEFT) enabled; (ii) all flow keys are different(n metrics, n * 2 flow keys). Nevertheless, the resultsare promising, as for example in case of 16 metrics, forwhich we observe the following average bitrate (Gbps):

1 core 2 cores 3 cores 6 cores0.566 0.983 1.367 2.315

Without discussing here the advantages of a state-ful pre-filtering (which will be shown in section 5.2.2),we want to underline that, in the typical case in whichnot all the metrics are updated for each packet and re-quire distinct flow keys, we can experience a better rela-tion between the processing throughput and the numberof metrics. For this reason, we compared the averagethroughput obtained by executing the traffic classifi-cation algorithm described in [32] (the most compu-tational demanding algorithm cited in 1, in terms ofnumber of distinct metrics and flow keys, and portionof processed traffic). The following table shows the av-erage bitrate (in Gbps) obtained by [32] in case of TCPtraffic classification ([32]: 6 metrics, 3 flowkeys) andthe average bitrate of the worst case configuration (6metrics and 12 flow keys).

1 core 2 cores 3 cores[32] 2.792 4.316 5.199

worst case 1.243 2.812 2.008

5.2.2 Use case performance evaluation

Table 3 shows the details of the test traces used forthree among the use cases presented in Section 4 andthe their performance evaluation, where pkt. no is thetotal number of packets, AVG plen is the average packetlength, M is the total number of metrics, FK is that thetransmission bitrate is fixed by the injector probe anddepends on the average packet length.

As already underlined, the use case applications ex-perience a better throughput with respect to the bitrateobtained with the same number of metrics in the worstcase measurement showed in 12. Note that due to thedifferent performances of the COMBO card processorand the limitation to single core processing6, the en-crypted flow detection use case performance is omittedto avoid confusion, as it would present results not di-rectly comparable with the remaining ones.

5.2.3 FPGA accelerated primitivesAs already discussed, our current StreaMon proto-

type supports seamless integration of HW precomputedprimitives, and in particular we have implemented packetentropy computation (see section 4.4) and event parsingon a INVEA-TECH Combo FPGA card [1]. The inter-face between the Combo card and StreaMon core soft-ware is realized via a footer appended to the ethernetframe. The Combo card capture the packet travelingin the network under inspection, performs the requiredoperation and transfer the resulting metrics and signalsas a list of Type Len Value (TLV) to the PC hosting thecapture card. This list of TLV is parsed by the EventLayer and will be available to the remaining layers.

Our next step is to implement a full deep packet in-spection module. To confirm its necessity, we have so farimplemented a simplified content matching packet pay-load inspection primitive in both SW and HW. Figure13 compares the two implementations for a toy exam-ple of just 32 content strings, showing the severe perfor-mance degradation of the SW implementation even insuch small scale example. At the same time, the figureshows that, by offloading content matching primitivesto the HW front-end, our prototype achieves almost op-timal throughput performance.

6. RELATED WORKIn the literature, several monitoring platforms have

targeted monitoring applications’ programmability. AMonitoring API for programmable HW network adaptersis proposed in [31]. On top of such probe, network ad-ministrators may implement custom C++ monitoringapplications. One of the developed applications is App-mon [4]. It uses deep packet inspection to classify ob-served flows and attribute these flows to an application.

6This is due the fact that the COMBO card capture driverdoes not allow to open multiple instances of the same com-munication channel toward the FPGA NIC

10

case pkts. AVG plen [bytes] Ms, FKs. TX [Gbps] RX [# core: Gbps]4.1 7676958 404.97 8, 4 3.658 1: 1.956, 2: 2.954, 3: 3.6544.2 11852112 329.77 4, 2 2.462 1: 2.4624.3 9387240 215.38 2, 2 2.067 1: 2.003, 2: 2.067

Table 3: Use case trace parameters and throughput

Figure 13: FPGA accelerated and SW string matching comparison

Flow states are stored in an hash table and retrievedwhen an old flow is observed again. This way to handlestates bears some resemblance with that proposed inthis work, which however makes usage of (much) moredescriptive eXtended Finite State Machines. CoMo [19]is another well known network monitoring platform. Weshare with CoMo the (for us, side) idea of extensibleplug-in metric modules, but besides this we are quiteorthogonal to such work, as we rather focus on how tocombine metrics with features and states using higherlevel programming techniques (versus CoMo’s low levelqueries).

Bro [27] provides a monitoring framework relying onevent-based programming language for real time statis-tics and notification. Despite the attempt to define aversatile high level language, Bro is not designed to ex-pose a clear and simple abstraction for monitoring ap-plication development and leave full programmability toits users (which we believe results in a more descriptiveand yet more complex programming language).

The Real-Time Communications Monitoring (RTC-Mon) framework [15] permits development of monitor-ing applications, but again the development languageis a low level one (C++), and (unlike us) any featureextraction and state handling must be dealt with insidethe custom application logic developed by the program-mer. CoralReef [21], FLAME [3] and Blockmon [18]are other frameworks which grant full programmabilityby permitting the monitoring application developers to“hook” their custom C/C++/Perl traffic analysis func-tion to the platform. On a different line, a numberof monitoring frameworks are based on suitable exten-sions of Data Stream Management Systems (DSMS).PaQueT [23], and more recently BackStreamDB [24],are programmable monitoring frameworks developed asan extension of the Borealis DSMS [2]. Ease of pro-gramming and high flexibility is provided by permitting

users to define new traffic metrics by simply performingqueries to the DSMS. The DSMS is configured throughan XML file that is processed to obtain a C++ applica-tion code. Gigascope [10] is another stream database fornetwork monitoring that provide an architecture pro-grammable via SQL-like queries.

Opensketch [34] is a recent work proposing an effi-cient generic data plane based on programmable metricsketches. If on the one hand we share with Opensketchthe same measurement approach, on the other hand itsdata plane abstraction delegates any decision stage andlogic adaptation the control plane and, with referenceto our proposed abstraction, does not go beyond thefunctionalities of our proposed Measurement Subsys-tem. On the same line, ProgME [35] is a programmablemeasurement framework which revolves around the ex-tended and more scalable notion of dynamic flowsetcomposition, for which it provides a novel functionallanguage.

Even though equivalent dynamic tracking strategiesmight be deployed over Openflow based monitoring tools,by exploiting multiple tables, metadata and by dele-gating ”monitoring intelligence” to external controllers,this approach would require to fully develop the specificapplication logic and to forward all packets to an exter-nal controller, (like in Openflow based monitoring toolFresco [28]), which will increase complexity and affectperformance.

Finally, while our work is, to the best of our knowl-edge, the first which exploits eXtended Finite StateMachines (XFSM) for programming custom monitor-ing logic, we acknowledge that the idea of using XFSMas programming language for networking purposes wasproposed in a completely different field (wireless MACprotocols programmability) by [30].

7. CONCLUSIONThe StreaMon programmable monitoring framework

described in this paper aims at making the deploymentof monitoring applications as fast an easy as configuringa set of pre-established metrics and devising a state ma-chine which orchestrates their operation while followingthe evolution of attacks and anomalies. Indeed, themajor contribution of the paper is the design of a prag-matic application programming interface for developingstream-based monitoring tasks, which does not requireprogrammers to access the monitoring device internals.Despite their simplicity, we believe that the wide range

11

of features accounted in the proposed use cases suggestthat StreaMon’s flexibility can be exploited to developand deploy several real world applications.

8. REFERENCES[1] COMBO product brief. http://www.invea-

tech.com/data/combo/combo pb en.pdf.[2] D. J. Abadi, Y. Ahmad, M. Balazinska, M. Cherniack,

J. hyon Hwang, W. Lindner, A. S. Maskey, E. Rasin,E. Ryvkina, N. Tatbul, Y. Xing, and S. Zdonik. Thedesign of the borealis stream processing engine. In InCIDR, pages 277–289, 2005.

[3] K. G. Anagnostakis, M. Greenwald, S. Ioannidis, andS. Miltchev. Open packet monitoring on flame: Safety,performance, and applications. In 4th Int. Conf. onActive Networks, IWAN ’02, 2002.

[4] D. Antoniades, M. Polychronakis, S. Antonatos, E. P.Markatos, S. Ubik, and A. Oslebo. Appmon: Anapplication for accurate per application network trafficcharacterisation. In IST Broadband Europe, 2006.

[5] G. Bianchi, E. Boschi, S. Teofili, and B. Trammell.Measurement data reduction through variation ratemetering. In INFOCOM, pages 2187–2195, 2010.

[6] G. Bianchi, N. d’Heureuse, and S. Niccolini.On-demand time-decaying bloom filters fortelemarketer detection. ACM SIGCOMM Comput.Commun. Rev., 41(5):5–12, 2011.

[7] L. Bilge, E. Kirda, C. Kruegel, and M. Balduzzi.EXPOSURE : Finding malicious domains usingpassive DNS analysis. In NDSS 2011, 2011.

[8] N. Bonelli, A. Di Pietro, S. Giordano, and G. Procissi.On multi-gigabit packet capturing with multi-corecommodity hardware. In Passive and ActiveMeasurement (PAM), pages 64–73, 2012.

[9] A. Broder and M. Mitzenmacher. Networkapplications of bloom filters: A survey. In InternetMathematics, pages 636–646, 2002.

[10] C. Cranor, T. Johnson, and O. Spataschek. Gigascope:a stream database for network applications. InSIGMOD, pages 647–651, 2003.

[11] A. Dainotti, A. Pescape, and K. Claffy. Issues andfuture directions in traffic classification. IEEENetwork, 26(1):35–40, 2012.

[12] H. Deng, A. M. Yang, and Y. D. Liu. P2p trafficclassification method based on svm. Comp. Eng. andApplications, 44(14):122, 2008.

[13] L. Deri, F. Fusco, and J. Gasparakis. Towardsmonitoring programmability in future internet:Challenges and solutions. In Trustworthy Internet,pages 249–259. Springer, 2011.

[14] P. Dorfinger, G. Panholzer, B. Trammell, and T. Pepe.Entropy-based traffic filtering to support real-timeskype detection. In Proc. 6th Int. Wireless Commun.and Mobile Computing Conf. (IWCMC ’10), 2010.

[15] F. Fusco, F. Huici, L. Deri, S. Niccolini, and T. Ewald.Enabling high-speed and extensible real-timecommunications monitoring. In 11th IFIP/IEEEIntegrated Network Management Symp., IM’09, 2009.

[16] S. Hao, N. A. Syed, N. Feamster, A. G. Gray, andS. Krasser. Detecting spammers with snare:Spatio-temporal network-level automatic reputationengine. In USENIX Sec. Symp., pages 101–118, 2009.

[17] T. Holz, C. Gorecki, K. Rieck, and F. C. Freiling.Measuring and detecting fast-flux service networks. InNDSS, 2008.

[18] F. Huici, A. di Pietro, B. Trammell, J. M.

Gomez Hidalgo, D. Martinez Ruiz, and N. d’Heureuse.Blockmon: a high-performance composable networktraffic measurement system. In Proc. ACMSIGCOMM 2012, Demo, pages 79–80, 2012.

[19] G. Iannaccone, C. Diot, D. McAuley, A. Moore,I. Pratt, and L. Rizzo. The como white paper. 2004.

[20] T. Karagiannis, A. Broido, M. Faloutsos, andK. Claffy. Transport layer identification of p2p traffic.In 4th ACM Internet Measurement Conference (IMC’04), pages 121–134, 2004.

[21] K. Keys, D. Moore, R. Koga, E. Lagache, M. Tesch,and K. Claffy. The architecture of coralreef: aninternet traffic monitoring software suite. In Passiveand Active Measurements (PAM), 2001.

[22] F. Leder and T. Werner. Know Your Enemy:Containing Conficker, To Tame a Malware. Technicalreport, The Honeynet Project, Apr. 2009.

[23] N. Ligocki and C. H. C. Lyra. A flexible networkmonitoring tool based on a data stream managementsystem. In ISCC 2008, pages 800–805, 2008.

[24] C. Lyra, C. Hara, and J. Duarte, EliasP.Backstreamdb: A distributed system for backbonetraffic monitoring providing arbitrary measurements inreal-time. In Passive and Active Measurement (PAM),pages 42–52, 2012.

[25] N. McKeown, T. Anderson, H. Balakrishnan,G. Parulkar, L. Peterson, J. Rexford, S. Shenker, andJ. Turner. Openflow: enabling innovation in campusnetworks. SIGCOMM Comput. Commun. Rev.,38(2):69–74, Mar. 2008.

[26] J. Mirkovic, G. Prier, and P. L. Reiher. Attackingddos at the source. In ICNP, pages 312–321, 2002.

[27] V. Paxson. Bro: a system for detecting networkintruders in real-time. Computer networks,31(23):2435–2463, 1999.

[28] S. Shin, P. Porras, V. Yegneswaran, M. Fong, G. Gu,and M. Tyson. Fresco: Modular composable securityservices for software-defined networks. In ISOC NDSS,2013.

[29] B. Stone-gross, M. Cova, L. Cavallaro, B. Gilbert,M. Szydlowski, R. Kemmerer, C. Kruegel, andG. Vigna. Your botnet is my botnet: Analysis of abotnet takeover, 2009.

[30] I. Tinnirello, G. Bianchi, P. Gallo, D. Garlisi,F. Giuliano, and F. Gringoli. Wireless mac processors:Programming mac protocols on commodity hardware.In INFOCOM, pages 1269–1277, 2012.

[31] P. Trimintzios, M. Polychronakis, A. Papadogiannakis,M. Foukarakis, E. P. Markatos, and A. Oslebo.Dimapi: An application programming interface fordistributed network monitoring. In 10th IEEE/IFIPNOMS, 2006.

[32] X. Wu, K. Yu, and X. Wang. On the growth ofinternet application flows: A complex networkperspective. In INFOCOM, 2011.

[33] Y.-S. Wu, S. Bagchi, S. Garg, N. Singh, and T. K.Tsai. Scidive: A stateful and cross protocol intrusiondetection architecture for voice-over-ip environments.In DSN, pages 433–442, 2004.

[34] M. Yu, L. Jose, and R. Miao. Software defined trafficmeasurement with opensketch. In 10th USENIX NSDI2013, pages 29–42.

[35] L. Yuan, C.-N. Chuah, and P. Mohapatra. Progme:towards programmable network measurement.IEEE/ACM Trans. Netw., 19(1):115–128, 2011.

12