Towards High Speed Network Analysis

1
Towards High Speed Network Analysis

• The NetVM Approach
• Fulvio Risso (fulvio.risso_at_polito.it)

2
Outline

• High Speed means
• Raw performances
• Clever components
• So, thats the outline
• How to increase performance in packet capture
• In general, applications that need to process
  information contained in network packets
• How to create smarter processing engines

3
The path for speed (1)
Step ONE Optimize as much as you can
Step TWO Move intelligence into the
kernel Decrease overhead when moving data from
kernel to user space Not suitable for some
applications like packet capture Kernel-related
overheads are still one of the most important
issues
Processing
User code
User Level
user-buffer
Packet Capture Library
Kernel Buffer
Kernel Level
Other protocol stacks
packet filter
Network Tap
NIC Driver
Packets
Network
4
Lets talk about performances...

• To increase performance should have
• Hardware-based timestamp
• Avoid NIC driver and OS-related costs
• Avoid un-necessary copies (e.g. shared
  buffer)

Current Winpcap 3.0 overhead in clock
cycles 3164 clock cycles
5
The path for speed (2)
User code
Step THREE Get rid of the kernel processing
(almost) completely Custom NIC driver Intrusive
modification of the operating system No longer
able to support other services (e.g. TCP/IP on
the interface) Astonishing performances Capture
on a Gigabit Ethernet PCI bottleneck Timestamp
precision
Step FOUR Create smarter NICs Hardware
processing Avoid PCI bus botteneck Timestamp
precision Need advanced mechanism for
customizable processing
User Level
Packet Capture Library
Kernel Level
Custom NIC Driver
Network
Packets
6
So, the ultimate step is...
... processing in hardware
7
Which kind of processing?
8
Other options?

• FPGA
• Mixture between Network Processors
  (reprogrammability) and ASICs (speed)
• How many are able to play with VHDL?
• Offloading engines
• E.g. Crypto, classification, etc.
• Are these functionalities enough for reaching
  high speed?
• How difficult is to interact with them from
  user-application?
• What about if we need other engines?

9
The best compromise...

• The Network Processor approach seems to be the
  best option
• Engineered to operate on network packets
• Programmable (potentially)
• Fast
• We can exploit advances in silicon technology
• Usually several micro-engines can work together
• But
• Difficult to program (do we need assembly?)
• Not very mature
• How can we deal with different NP?
• Is there any simple way to exploit their
  intrinsic parallelism?

10
... is a Virtual Network Processor!
User code

• Optimized to operate on network packets
• Programmable (programs can be customized)
• Fast
• Lightweight
• Exploits advances in silicon technology
• Several micro-engines can work together
• User programs can benefit from hw resources
  thanks to the JIT compilation
• Adaptable to different hardware (only?)
  architectures

Packet (Capture) Library
Custom NIC
Processing
11
Esisting alternatives BPF

• Berkeley Packet Filter
• Widely used (embedded in libpcap, WinPcap and
  many operating systems)
• Register-based
• Difficult to map efficiently to existing
  architectures
• Only one processing engine supported
• No support for multiple processing engines (in
  parallel or pipeline)
• Limited instruction set (e.g. backward jump)
• No support for coprocessors (e.g. hw components
  for doing hashing, encryption, etc)
• Other solutions are similar to BPF

12
Esisting alternatives Click

• Click (MIT)
• Not really a virtual network processor
• Modular and extendible router architecture
• Listed here just because people tend to ask what
  about Click?
• Too many differences with the Virtual NP approach
• Very complex components (e.g. IP forwarding,
  etc.)
• Components cannot be programmed from user space
• Does not have an assembler
• It is a set of pre-built components
• Cannot be mapped on existing hardware
  accelerators for specific functions
• Does not support remotization (see later)
• Click does, a Virtual NP allows you to do

13
The idea Network Processing VM
User code
NetVM
NOTE the JIT compiler has been omitted for
clarity
14
Network Processing Virtual Machine
NetVM
NetPE1 (e.g. filtering)
NetPE2 (e.g. statistics)
Local PU
Local Memory
Local PU
Local Memory
Exchange Buffer 2
Output Port
Exchange Buffer 2
Output Port
Input Port
Input Port
OUT
IN
Exchange Port
Exchange Port
NetVM internal communication bus (or switching
fabric)
General Purpose CPU
Classification coprocessor
Crypto coprocessor
CRC coprocessor
Shared Memory
. . .
15
Network Processing Element
NetPE
Local Processing Unit
Registers
PC program counter
NetPE internal communication bus
Code Memory
CSL code segment length
Data Memory
Exchange Buffer
DSL data segment length
Evaluation Stack
EBL exchange buffer length
Connection Table
CTL connection table length
SP stack pointer
16
Some numbers...
Tests run on a PC Dual Xeon, 2GHz clock 1 16
assembly BPF instructions against 36 assembly
NetPE instructions (due to the several push/pop
operations needed on a stack-based machine). 2 In
case of the BPF implementation, the JIT compiler
counts for additional 650 lines of code.
17
Lets move a step forward

• What we can do now when interacting on remote
  devices?
• Capture traffic (thanks, WinPcap)
• Only on remote PCs and Cisco Catalyst 9000
• Get, in some way, generic traffic statistics
• RMON, NetFlow
• Are these suitable for appliances like ADSL
  modems?
• How much do these cards cost?
• Can you customize the type of statistics you
  want?
• What about if we want to
• Do more (not only statistics or packet capture)
• Be open to the future?

18
The NetVM can be a solution!
Ethernet phone
User application
Send an alarm when a SIP INVITE is received
Get a summary of each TCP session
Router
Count IPv6 and IPv6- in-IPv4 packets
Capture PPPOE packets
Local workstation
ADSL Modem
Remote workstation
Reassembly all TCP sessions on port 8888 and look
for keyword MP3 in there
Lets implement the Virtual Network Processor in
remote devices!
19
Remotizing the NetVM

• Allow to create small programs that can be
  downloaded anywhere
• Like Java
• A remote management console can control their
  behavior
• Potentially, the network can become programmable
  (at least in some components)
• We can have our firewall running on remote
  devices
• We can customize generated alarms
• We can compute custom statistics
• Etc...

20
New issues due to the remote interaction

• To make the Virtual NP remote we need some new
  components
• We need an extensible transport protocol to send
  commands to the Virtual NP and to get data back
• User application must behave in the same way when
  the Virtual NP is local or remote
• NetVMHandle NetVMCreate(localhost)
• / some other code goes here /
• NetVMHandle-gtDownloadCode(code)
• Results NetVMHandle-gtGetResult()

21
Putting the pieces together

• High level filtering language
• - ip and tcp.port80
• - ipv6.hopbyhop_opthdr
• ipv6.hopbyhop_opthdr 10

User app
Application-level API NetBee
Processor (e.g. x86 code on standard PCs)
Compiler
NetVM Assembler
Just in Time Compiler
Native Assembler
NetPDL Protocol definitions database
Packets
Network
22
The NetBee Library Control Path
Applications
NAT
Firewall
IDS
Traffic Monitor
L4/7 Switches
Access List
L3 forwarding
Packet Capture
. . .
Protocol Visualizer (GUI)
NetBee API
Packet Filter
Packet Decoder
Stream Reassembler
Traffic statistics
Packet Fields Extractor
. . .
NetVM
NetPDL Protocol database
NetBee
23
The NetBee Library Data Path
Input Handlers (push or pull)
Output Handlers (push or pull)
File
File
Packets
Packets
Local NIC
Local NIC
Packets
Packets
Packets
Remote NIC
Remote NIC
Packets
NetBee
Packets
User application
User application
Packets
Decoded packets
Statistics
Protocol field values
. . .
24
NetBee example of use
Traffic Monitor
NetBee API
Output Handler
NetBee
Input Handler
25
NetBee status

• New generation packet (manipulation, handling,
  etc.) library
• Allows to program a NetVM
• Hide the location of packets source (i.e. packet
  tap) and transfers processed data to the caller
• Some functionalities exist right now
• Packet Decoding
• NetPDL
• NetVM (rather primitive)
• NetPE (more stable)
• Still work in progress
• Both users and developers wanted

26
Conclusions

• Raw performance
• This objective can be considered reached (at
  least in software)
• Clever components
• NetVM
• How to manage these clever components from the
  application
• NetBee

27
Questions?
Thanks for your attention!