Transcript FFPF: Fairly Fast Packet Filters

FFPF: Fairly Fast Packet Filters
u
uspace
k
kspace
n
nspace
Herbert Bos
Willem de Bruijn
Trung Nguyen
Mihai Cristea
Georgios Portokalidis
Vrije Universiteit Amsterdam
Universiteit Leiden
http://ffpf.sourceforge.net/
Vrije Universiteit Amsterdam
●
Why?
Traffic characterisation
–
what % of traffic used by
KaZaa, Gnutella, e-Donkey,
video streams, FTP data?
 difficult due to dynamic ports
Why?
●
●
Security: worms
–
early warning: are there
any worms on the loose?
–
intrusion detection
Denial of Service attacks
spread of CODE-RED in 24 hours
Why?
●
●
Security: worms
–
early warning: are there
any worms on the loose?
–
intrusion detection
Denial of Service attacks
 difficult at high speeds
spread of SAPPHIRE in 30 minutes
Why?
●
●
●
●
traffic engineering
accounting
billing
SLA monitoring
 monitoring increasingly important
 hypothesis: multiple applications on single host
–
monitoring nodes (e.g., gateways)
Network Monitoring
●
Existing solutions:
–
–
●
designed for slow networks
or traffic engineering/QoS
not very flexible
We’re hurting because of
–
–
hardware (bus, memory)
software
 demand for solution:
–
–
–
scales to high link rates
scalable in no. of apps
flexible
-process at lowest possible level
-minimise copying
-minimise context switching
-freedom at the bottom
FFPF contributions
generalised concept of ‘flow’
copying and context switching are minimised
complex processing in kernel or NIC
- reduces no. of packets that must be sent to userspace
- language neutral
- complex packet processing by connecting
simple filters (not unlike UNIX pipes)
FPL: FFPF Packet Language
persistent storage for flow-specific state
flow groups
- applications sharing buffers
reduce copying
●
FFPF avoids both ‘horizontal’ and ‘vertical’ copies
●
3 buffers: PBuf, IBuf, and MBuf
Application A
Application B
U
K
- no ‘vertical’ copies
‘filter’
- no ‘horizontal’ copies
within flow group
- more than ‘just filtering’
Fairly Fast Packet Filters
Flow: “a stream of packets that matches arbitrary user criteria”
eth0
TCP SYN
HTTP
U
IP
TCP
RTSP
“contains worm”
UDP
RTP
UID 0
Efficient
userspace
?
flowgroups: sharing data
kernel
● flowgraphs: sharing computations
●
●
reduced copying and context switches
?
x
“push filtering tasks as far down the processing
hierarchy as possible”
?
?
network card
Extensible
(device,eth0) -> (sampler,2) -> (BPF,”..”) -> (packetcount)
(device,eth0) | (device,eth1) -> (sampler,2) -> (FPL-2,”..”) | (BPF,”..”) -> (bytecount)
(device,eth0) -> (sampler,2) -> (BPF,”..”) -> (packetcount)
(device,eth0) -> (sampler,2) -> (BPF,”..”) -> (strsearch)
✔
modular framework
✔
language agnostic
✔
plug-in filters
device
sampler
BPF
pktcount
strsearch
Compatible
processing hierarchy
MAPI
ANY
APP
PCAP
uspace
kspace
nspace
Buffers
R
O
●
MBuf
–
●
●
O
unstructured array of bytes
PBuf
O
O
–
circular buffer with N fixed-size slots
–
large enough to hold packet
O
O
O
W
IBuf
–
circular buffer with N slots of size ‘sizeof(int)+sizeof(int*)’
–
contains classification result
writer (e.g., kernel) writes in circular buffer at write positio
reader explicitly advances its read pointer
X
Buffers
O
●
MBuf
–
●
●
O
unstructured array of bytes
PBuf
O
O
–
circular buffer with N fixed-size slots
–
large enough to hold packet
O
O
O
R
IBuf
–
circular buffer with N slots of size ‘sizeof(int)+sizeof(int*)’
–
contains classification result
W
writer (e.g., kernel) writes in circular buffer at write positio
reader explicitly advances its read pointer
X
Buffers
X
●
MBuf
–
●
●
X
unstructured array of bytes
PBuf
X
X
–
circular buffer with N fixed-size slots
–
large enough to hold packet
X
O
O
R
IBuf
–
circular buffer with N slots of size ‘sizeof(int)+sizeof(int*)’
–
contains classification result
W
writer (e.g., kernel) writes in circular buffer at write positio
reader explicitly advances its read pointer (typically by >1
X
R1
O
Buffer management
 what to do if writer catches
up with slowest reader?
●
–
●
fast reader preference
–
application responsible for keeping up
●
●
O
O
O
O
can check that packets have been overwritten
different drop rates for different apps
O
O
overall speed determined by slowest reader
overwrite existing packets
O
O
drop new packets
(traditional way of dealing with this)
–
O
O
slow reader preference
–
O
O
O
O
O
W
R1
Languages
IF (PKT.IP_PROTO == PROTO_TCP)
THEN
// reg.0 = hash over flow fields
R[0] = Hash (14,12,256)
●
FFPF is language neutral
●
Currently support:
–
// increment pkt counter at this
// location in MBuf
MEM[ R[0] ]++
BPF
–
C
–
OKE Cyclone
–
FPL-1
–
FPL-2
FI
•simple to use
•compiles to C and then to optimised object code
•resource limited
•restricted FOR loop
•access to persistent storage (Mbuf)
•calls to external functions (e.g., fast C functions
or hardware assists)
•compiler for uspace, kspace, and nspace (ixp1200)
Authorisation and third-party code
●
client requests need to be approved by authd
–
●
may check that:
●
X only looks at packets destined to itself
●
Y never applies a string search
●
string search only occurs after sampling
●
FPL-2 filter really are what they claims they are
FFPF allows third party code in the lowest levels
–
based on Open Kernel Environment
http://www.cs.vu.nl/~herbertb/projects/oke/
Performance results
Performance results
NIC-FIX: FFPF on IXPs
bottom of the processing hierarchy
eliminates mem & bus bottlenecks
uspace
kspace
nspace
Network Processors
“programmable NIC”
zero copy
copy once
on-demand copy
Performance
Copy St rat egies
100
reference
d rop
accept
90
processed (in %)
80
70
60
50
40
30
20
10
0
r eg ular copy
copy once
zer o copy
More Information
http://ffpf.sourceforge.net/
microbenchmarks