1. DiFMon Distributed Flow Monitor Salvatore D’Antonio 1, Claudio Mazzariello 2, Francesco Oliviero 2, Dario Salvi 1 1: Lab Item, Consorzio Interuniversitario Nazionale per l’Informatica, Napoli 2: Dipartimento di Informatica e sistemistica, Università degli studi di Napoli Federico II

2. o Possible Uses: traffic profiling, Intrusion Detection o Context: Internet Flow Monitoring o Contribution: Development of a distributed software for flow monitoring

3. Flows are defined by means of some properties appliable to packets headers For example: 1.IP addresses, source and destination 2.The 5-uple (source address, destination address, source port, destination port, protocol next to IP) …and by means of a timeout… The choice of the flow definition follows the needs of the application which uses monitoring data

4. A Flow Monitor should: 1.Capture packets from the network 2.Associate a flow id to each packet on the basis of the chosen definition of flow 3.When a packet arrives, update the metrics of the flow the packet belongs to 4.Keep in memory the metrics related to the “living” flows (not timed out yet) in data structures (flow records) 5.Save the measured metrics of each timed out flow in order to make them available to the applications

5. Proposed architecture: Meter Flow Cache Collector Flow Cache Application 1.Calculates the metrics at each packet arrival 2.Keeps in memory the metrics of each living flow 3.“Exporting” of timed out flows to the Collector 4.Eventually exports some “interesting” living flow 1.Keeps in memory th emtrics of each timed out flow 2.Eventually advises the application of some “interesting” living flow 1.Packet capturing 2.Associates flow id to the packet

6. The Flow Cache: It is the critical module, it must look up and update a flow record each time a packet arrives (for this reason is distributed) Packet multiplexing is done by means of a hash function (mmh) computed on the flow id Metrics can be freely implemented through an API Flow records ordering is Least Recently Used (on the basis of the last acces time) The flow record of a just-arrived packet will be positioned among the first elements of the queue with a high probability (temporal locality properties, i.e. heavy tailed distributions of the packet rates) LRU ordering allows the otpimized search of timed out flows (starting from the tail of the queue and stopping when a not-timed out flow is found)

7. Some Details: Comunication between the modules is done using UDP A flow control between modules is provided Programming language: C Operating system: Linux Used libraries: libpcap Software license: GPL Project location: SourceForge.net

8. The management Protocol: The system must be: reliable, robust and flexible. Some assumptions: Meter Flow Cache Collector Flow Cache The system internal network must be faster enough than the monitored network Modules can run on the same / different machines The Meter must perform packet capturing between packet interarrival time The collector and the meter use defined port numbers for signalling messages

9. Start and Stop of the system: Meter Collector Flow Cache 2 – ACK 6 – ACK 1 – CONN Req 4 – ACK 5 – ACK 3 – CONN Req Starting On defined port number On dinamically chosen port number 2 – END Req 6 – ACK 4 – END Req 5 – ACK 1 – END Req 3 – Export Stopping

10. Steady state protocol: Meter Collector Flow Cache On defined port number On dinamically chosen port number 1 – Captured Data 2 – ACK 1 – Exporting Data 2 – ACK

11. Meter Collector Flow Cache 2 – ABORT 1 – ABORT Flow Cache 2 – ABORT 3 – ABORT 2 – ABORT Aborting (from Flow Cache):

12. Meter Collector Flow Cache Aborting (from Meter): 1 – ABORT 2 – ABORT 1 – ABORT 2 – ABORT 1 – ABORT

13. Meter Collector Flow Cache Aborting (from Collector): 2 – ABORT 1 – ABORT 2 – ABORT 1 – ABORT 2 – ABORT

14. Adding/Removing a Flow Cache: Meter Collector Flow Cache On defined port number On dinamically chosen port number 2 – ACK 1 – DISCONN Req 2 – ACK 1 – DISCONN Req Removing 1 – CONN Req 3 – CONN Req 4 – ACK 2 – ACK 6 – ACK 5 – ACK Adding

15. Meter Flow Cache 2 – ACK 1 – ALIVE Req Collector 2 – ACK 1 – ALIVE Req Crashes: Meter’s crashCollector’s crash Flow Cache’s crash

16. Conclusions / future works: The proposed architecture and protocol is scalable to the increase of the number of the flow caches and monitored networks. The system is suitable to different contexts, such as security, traffic profiling or billing where specific metrics are of interest. Benchmarking and robustness evaluation will be conducted. The LRU sorting algorithm will be compared with other ordering algorithms. We are currently working on the implementation of an intrusion detection system and a tool for traffic profiling based on the proposed monitoring architecture.