Diapositiva 1

1
DiFMon
Distributed Flow Monitor
Salvatore DAntonio1, Claudio Mazzariello2,
Francesco Oliviero2, Dario Salvi1
1 Lab Item, Consorzio Interuniversitario
Nazionale per lInformatica, 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

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
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 management Protocol
The system must be reliable, robust and
flexible. Some assumptions
Collector
Flow Cache
Flow Cache
Flow Cache
Meter
9
Start and Stop of the system
Flow Cache
Meter
Collector
On defined port number
Starting
Stopping
On dinamically chosen port number
10
Steady state protocol
Flow Cache
Meter
Collector
On defined port number
On dinamically chosen port number
11
Aborting (from Flow Cache)
Flow Cache
Meter
Collector
Flow Cache
12
Aborting (from Meter)
Flow Cache
Meter
Collector
Flow Cache
13
Aborting (from Collector)
Flow Cache
Meter
Collector
Flow Cache
14
Adding/Removing a Flow Cache
Flow Cache
Meter
Collector
Removing
Adding
On defined port number
On dinamically chosen port number
15
Crashes
Flow Cache
Meter
Collector
Flow Caches crash
Meters crash
Collectors 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.