Fairly Fast Packet Filters: Enhancing Network Traffic Monitoring and Filtering Efficiency

1. Herbert Bos Willem de Bruijn Trung Nguyen Mihai Cristea Georgios Portokalidis Vrije Universiteit Amsterdam Universiteit Leiden uspace kspace nspace FFPF: Fairly Fast Packet Filters u k n http://ffpf.sourceforge.net/ Vrije Universiteit Amsterdam

2. Why? • Traffic characterisation • what % of traffic used byKaZaa, Gnutella, e-Donkey,video streams, FTP data?  difficult due to dynamic ports

3. Why? • Security: worms • early warning: are thereany worms on the loose? • intrusion detection • Denial of Service attacks spread of CODE-RED in 24 hours

4. Why? • Security: worms • early warning: are thereany worms on the loose? • intrusion detection • Denial of Service attacks  difficult at high speeds spread of SAPPHIRE in 30 minutes

5. Why? • traffic engineering • accounting • billing • SLA monitoring  monitoring increasingly important  hypothesis: multiple applications on single host • monitoring nodes (e.g., gateways)

6. -process at lowest possible level-minimise copying -minimise context switching -freedom at the bottom Network Monitoring • Existing solutions: • designed for slow networksor 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

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

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

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

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

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

12. MAPI ANY APP PCAP uspace kspace nspace Compatible processing hierarchy

13. Buffers R O O O • 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 O O O O W X

14. Buffers O O O • 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 O O O O W R X

15. Buffers X X X • 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 O O W R X

16. R1 Buffer management O O O O O O O O O O  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 O R1 W

17. 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 • 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) Languages • FFPF is language neutral • Currently support: • BPF • C • OKE Cyclone • FPL-1 • FPL-2

18. 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 Environmenthttp://www.cs.vu.nl/~herbertb/projects/oke/

19. Performance results

20. Performance results

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

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

23. Performance

24. More Information http://ffpf.sourceforge.net/

25. microbenchmarks