FFPF: Fairly Fast Packet Filters uspace kspace nspace Vrije Universiteit Amsterdam Herbert Bos Willem de Bruijn Trung Nguyen Mihai Cristea Georgios Portokalidis Universiteit Leiden Vrije Universiteit Amsterdam u k n

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

Application B reduce copying ● FFPF avoids both ‘horizontal’ and ‘vertical’ copies ● 3 buffers: PBuf, IBuf, and MBuf Application A U K ‘filter’ - no ‘vertical’ copies - no ‘horizontal’ copies within flow group - more than ‘just filtering’ in kernel (e.g.,statistics)

Fairly Fast Packet Filters Flow: “a stream of packets that matches arbitrary user criteria” TCP SYN UID 0 eth0 U TCP UDP IP HTTP RTSP RTP “contains worm”

? x ? ? ? kernel userspace network card Efficient ● flowgroups: sharing data ● flowgraphs: sharing computations ● reduced copying and context switches “push filtering tasks as far down the processing hierarchy as possible”

(device,eth0) | (device,eth1) -> (sampler,2) -> (FPL-2,”..”) | (BPF,”..”) -> (bytecount) (device,eth0) -> (sampler,2) -> (BPF,”..”) -> (packetcount) Extensible ✔ modular framework ✔ language agnostic ✔ plug-in filters (device,eth0) -> (sampler,2) -> (BPF,”..”) -> (packetcount) (device,eth0) -> (sampler,2) -> (BPF,”..”) -> (strsearch) devicesamplerBPFpktcount strsearch

uspace kspace nspace MAPI PCAP ANY APP Compatible processing hierarchy

Buffers ● MBuf – unstructured array of bytes ● PBuf – circular buffer with N fixed-size slots – large enough to hold packet ● 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 position  reader explicitly advances its read pointer X O O O O O OO W R

Buffers ● MBuf – unstructured array of bytes ● PBuf – circular buffer with N fixed-size slots – large enough to hold packet ● 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 position  reader explicitly advances its read pointer X O O O O O OO W R

● MBuf – unstructured array of bytes ● PBuf – circular buffer with N fixed-size slots – large enough to hold packet ● 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 position  reader explicitly advances its read pointer (typically by >1) X X X X X X OO W R Buffers

Buffer management  what to do if writer catches up with slowest reader? ● slow reader preference – drop new packets (traditional way of dealing with this) – overall speed determined by slowest reader ● fast reader preference – overwrite existing packets – application responsible for keeping up ● can check that packets have been overwritten ● different drop rates for different apps O O O O O OO R1 O O O O O O O O O W

Languages ● FFPF is language neutral ● Currently support: – BPF – C – OKE Cyclone – FPL-1 – FPL-2 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) IF (PKT.IP_PROTO == PROTO_TCP) THEN // reg.0 = hash over flow fields R[0] = Hash (14,12,256) // increment pkt counter at this // location in MBuf MEM[ R[0] ]++ FI

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

Performance results

NIC-FIX: FFPF on IXPs uspace kspace nspace bottom of the processing hierarchy eliminates mem & bus bottlenecks

Network Processors “programmable NIC” zero copy copy once on-demand copy

Performance

More Information

microbenchmarks