1. DiFMon Distributed Flow Monitor Dario Salvi Consorzio Interuniversitario Nazionale per l’Informatica (CINI) Naples, Italy

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 packet headers For example: 1.IP addresses (source and destination) 2.The 5-uple (source address, destination address, source port, destination port, and protocol) …and by means of a timeout… The choice of the flow definition depends on 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.As a packet arrives, update the metrics of the flow which the packet belongs to 4.Keep in memory the metrics related to the “living” flows (not timed out) in data structures (flow records) 5.Save the computed metrics related to 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 about each living flow 3.“Exports” timed out flows to the Collector 4.Exports some “interesting” living flows 1.Keeps in memory the metrics related to timed out flows 2.Informs the application about some “interesting” living flows 1.Captures packets 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 as a packet arrives (for this reason it is distributed) Packet multiplexing is done by means of a hash function (mmh) computed on the flow id Metrics can be implemented in a flexible way through an API Ordering of flow records relies on the Least Recently Used algorithm (on the basis of the last acces time) The flow record of a just-arrived packet will be positioned within 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 otpimized search for timed out flows (starting from the tail of the queue and stopping when a not-timed out flow is found)

7. Some implementation details: Communication 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 network connecting system modules must be faster than the monitored network Modules can run on the same / different machines The Meter must perform packet capturing within the 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 operation: 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 work: The proposed protocol is scalable with respect to the increase in 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. http://sourceforge.net/projects/difmon/ dsalvi@napoli.consorzio-cini.it