1 / 16

DiFMon

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.

robertmccracken
Download Presentation

DiFMon

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DiFMon Distributed Flow Monitor Salvatore D’Antonio1, Claudio Mazzariello2, Francesco Oliviero2, Dario Salvi1 1: Lab Item, Consorzio Interuniversitario Nazionale per l’Informatica, Napoli2: Dipartimento di Informatica e sistemistica, Università degli studi di Napoli Federico II

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

  3. Flows are defined by means of some properties appliable to packets headers • For example: • IP addresses, source and destination • 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: • Capture packets from the network • Associate a flow id to each packet on the basis of the chosen definition of flow • When a packet arrives, update the metrics of the flow the packet belongs to • Keep in memory the metrics related to the “living” flows (not timed out yet) in data structures (flow records) • Save the measured metrics of each timed out flow in order to make them available to the applications

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

  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) 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) 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)

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

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

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

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

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

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

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

  15. 1 – ALIVE Req 1 – ALIVE Req 2 – ACK 2 – ACK Crashes: Flow Cache Meter Collector Flow Cache’s crash Collector’s crash Meter’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.

More Related