Transcript The presentation of the paper above - DiFMon

DiFMon
Distributed Flow Monitor
Salvatore D’Antonio1, Claudio Mazzariello2, Francesco Oliviero2, Dario Salvi1
1: Lab Item, Consorzio Interuniversitario Nazionale per l’Informatica, Napoli
2: Dipartimento di Informatica e sistemistica, Università degli studi di Napoli Federico II
o Context: Internet Flow Monitoring
o Possible Uses: traffic profiling, Intrusion Detection
o Contribution: Development of a distributed software
for flow monitoring
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
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
Proposed architecture:
Application
Application
Application
1. Calculates the metrics at
each packet arrival
1. Keeps in memory th
2. Keeps in memory the
emtrics
of capturing
each timed out
1.
Packet
metrics
of each
living flow
flow
3. “Exporting”
of timed
out
2. Associates
flow id
to
flows
to
the
Collector
2. Eventually
advises the
the packet
4. Eventually
applicationexports
of somesome
“interesting”
“interesting”living
livingflow
flow
Collector
Flow Cache
Flow Cache
Meter
Flow Cache
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)
ordering
allows the packet
otpimized
of timedamong the
The flowLRU
record
of a just-arrived
will search
be positioned
out flows
(starting
tail of
the queue
and
first elements
of the
queuefrom
with the
a high
probability
(temporal
locality
stopping
whentailed
a not-timed
out flow
is found)
properties,
i.e. heavy
distributions
of the
packet rates)
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
The management Protocol:
The system must be: reliable, robust and flexible.
Some assumptions:
The collector and the
meter use defined port
numbers for signalling
messages
Collector
Flow Cache
Flow Cache
Meter
Flow Cache
Modules can run on
the same / different
machines
The system internal
network must be faster
enough
than the
monitored
The Meter
must
perform
network
packet capturing between
packet interarrival time
– Export
3 –3CONN
Req
4 –4END
– ACK
Req
5 – ACK
Collector
1 – CONN Req
2 – END Req
2 – ACK
6 – ACK
6 – ACK
Flow Cache
Meter
Start and Stop of the system:
1 – END Req
Starting
Stopping
On defined port number
On dinamically chosen port
number
2 – ACK
1 – Exporting Data
2 – ACK
Collector
1 – Captured Data
Flow Cache
Meter
Steady state protocol:
On defined port number
On dinamically chosen port
number
2 – ABORT
3 – ABORT
2 – ABORT
2 – ABORT
Flow Cache
Meter
2 – ABORT
1 – ABORT
2 – ABORT
3 – ABORT
Collector
1 – ABORT
Flow Cache
Aborting (from Flow Cache): 2 – ABORT
1 – ABORT
2 – ABORT
2 – ABORT
2 – ABORT
Flow Cache
Meter
1 – ABORT
2 – ABORT
2 – ABORT
2 – ABORT
Collector
2 – ABORT
1 – ABORT
Flow Cache
Aborting (from Meter):
2 – ABORT
2 – ABORT
1 – ABORT
1 – ABORT
Flow Cache
Meter
2 – ABORT
2 – ABORT
1 – ABORT
2 – ABORT
Collector
2 – ABORT
2 – ABORT
Flow Cache
Aborting (from Collector):
Removing
Adding
3 – CONN Req
1 – DISCONN Req
4 – ACK
2 – ACK
5 – ACK
Collector
1 – CONN Req
1 – DISCONN Req
2 – ACK
2 – ACK
6 – ACK
Flow Cache
Meter
Adding/Removing a Flow Cache:
On defined port number
On dinamically chosen port
number
2 – ACK
Flow Cache’s
crash
Collector’s
Meter’s
crash
crash
1 – ALIVE Req
2 – ACK
Collector
1 – ALIVE Req
Flow Cache
Meter
Crashes:
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.