120 likes | 324 Views
Middlebox OpenAPI. Shinae Woo @ NDSL. Introduction. Network middleboxes play critical roles for many in-network functionalities # middleboxes ≈ # routers ( CoMB ) High performance Middleboxes Dedicated hardware:
E N D
Middlebox OpenAPI Shinae Woo@ NDSL
Introduction • Network middleboxes play critical roles for many in-network functionalities • # middleboxes ≈ # routers (CoMB) • High performance Middleboxes • Dedicated hardware: • High-performance, inflexible, little programmability, vendor-specific solutions, hard to manage distributed machines • Software-based middleboxes: • Not high-performance recently we open new possibility • high flexibility enough to build any functionalities • SSLshader, IDS, Packet shader
Motivating examples (1) Network stack for middleboxes • New network stack for middleboxes • Traditional network stack react as an end nodes • Middlebox needs to control network in middle • Need to manage contexts for both ends – server, client • Some middleboxes have no need to react with state update • The other end has the charge of control • Multiple functionality share the same TCP context • Currently, some S/W middleboxes implements their own network stacksFlow-friendly packet dumping system (FloSIS)Monitoring system (PRADS)Intrusion detection system (Bro, Kargus)Accounting system which aware TCP retransmission (Abacus) • Although, each system needs different level of TCP context, but they share the commonality – TCP (or its subset)
Motivating examples (1) Network stack for middle boxes Full TCP functionality React as an End-node- Send data, send ACK - Send control packets PacketReception TCP context creation / destroy SYN, SYN/ACK, FIN, RST TCP data context management # SEQ, # ACK Packet loss detection Timeout detectionRetransmission detection
Motivating examples (2) Controlling packets / flows • Control packets and/or flows at each stage of stack processing • FlowSIS need to know every TCP context and packets not handled in TCP context • PRADS need to forward flows to IDS @ specified TCP fingerprinting • Kargus need to match signatures with merged bytes • Abacus need to make a report @ Retransmission detection • Middleboxes also need to get control over packets and/or flows in terms of • Whether forward / sink / close / reset • Where to forward (next functionality or next network) • Change packets contents (IP address, port for VPN, NAT) Full TCP functionality React as an End-node- Send data, send ACK - Send control packets PacketReception TCP context creation / destroy SYN, SYN/ACK, FIN, RST TCP data context management # SEQ, # ACK Packet loss detection Timeout detectionRetransmission detection
Motivating examples (3) Build multiple functionality – modular apps • Traditionally: single machine for few functionalityA machine for SSL proxyA machine for Service MonitoringA machine for HTTP proxy • A machine could be used only in a way it design as intended • No sharing context between machines • Packetizing / Un-packetizing / Build TCP context / Reordering packets are repeated for each machines
Motivating examples (3)(3) Build multiple functionality – modular apps • Primitives • Built-in events / User-defined events for building composition condition • Callback for synchronous module • Packets, TCP context • Event-drive pipe • Sharing Byte-steam
Motivating examples (3)(3) Build multiple functionality – modular apps • Build multiple functionality – modular apps • Multiple sockets for a flow • 1 for proxy, the others (N) for monitor flows or packet-level • 1 for packet socket, 1 for flow sockets • Sharing TCP context and it’s byte-stream for every modules • Virtual interfaces for packet forwarding • Virtual interfaces to forward packets to other module • Virtual interfaces to reassemble packets for tunneling protocols Packet I/O SSL proxy mSOC DPI TCP proxy Byte Monitoring(Kargus) packets packets packets virtual interfaces physical interfaces
Motivating examples (3)(3) Build multiple functionality – modular apps User-defined event and callback for add functionality • User-defined eventDefine a user-specific event related with a packet or TCP status • Define a retransmission • Define merged bytes are larger than N KB • Define for a specific application detection (HTTP, FTP, ..) • Callback module: Add a intended functionality in a synchronous way in middle of TCP processing with a specified events • Create a log for an malicious retransmission detection • Change packets address (NAT) • Mix multiple callback modules to build multiple functionality
Motivating examples (3)(3) Build multiple functionality – modular apps Event-driven push & pull for byte stream HTTP cache HTTP monitor read() read() write() read() write() byte stream HTTP module SSL module filter: IS_HTTP read() read() write() write() filter: IS_HTTP HTTP socket(!443) SSL socket (443) mTCP
Contributions • Software platforms for building middleboxes • New set of APIs for middle boxes • Control flows and packets in middle of both ends • Control packets and/or flows at each stage of stack processing • Hooking at various control points from stack processing Give controls to apps for the blackbox(Network stack) • Exploit modularity • Multiple functionality could cooperatively works in a machine • [Discussion] Control over distributed multiple machines • Load balancing between multiple machines for multiple apps
Target system!!! proxy Callback Event driven Event driven Packet I/O Firewall HTTP contextbyte stream HTTP context byte stream Event driven Event driven packets HTTPinspector Webcaching mSOC DPI Not proxy Proxy Byte inspector Web Filter HTTP VPN SSL Event driven bytestream bytestream bytestream bytestream bytestream bytestream Callback Event driven packets byte stream Callback packets packets virtual interfaces physical interfaces