Abstractions for Network Functions Aditya Akella UW-Madison

Network functions (NFs): Devices that introduce custom packet processing into the network Routers and switches do simple packet forwarding Firewall Proxy Intrusion Prevention Traffic scrubber Load balancer … SSL Gateway WAN optimizer

NFV SDN Dynamic reallocation in distr. processing Service chaining dynamically allocate (s/w) NF instances SDN dynamically reroute flows Service chaining Dynamic reallocation in distr. processing

NFV SDN complicated by statefulness complicated by mangling dynamically allocate (s/w) NF instances SDN dynamically reroute flows complicated by statefulness complicated by mangling Dynamic reallocation in distr. processing Service chaining

Abstractions to overcome What are these scenarios? How do NFs’ attributes impede them? Abstractions to overcome Some open questions

Dynamic reallocation in distributed processing Load balancing Elastic scaling High availability Network migration Remote invocation Always updated NFs

Stateful operation Dynamically updated per packet Connection TcpAnalyzer HttpAnalyzer Per-flow state ConnCount Multi-flow state Bro IDS All-flows state Statistics Dynamically updated per packet NF’s action for packet depends on state

Output equivalence: Multiple instances of an NF should collectively produce the same output as a single instance Difficult to achieve Output depends on state Desire for ↑ performance and ↓resource usage R2 R1 R2 B2 B1 R1 R2 B2 B1 R1 R2 B2 B1 R1 B2 B1

? ? Perform Resource usage Output equiv. Reroute new flows SLA: <1% Packet loss SLO: < 1% Perform Resource usage Output equiv. Reroute new flows Reroute existing flows Wait for flows to die ?

Quickly move or copy NF state alongside updates to network forwarding state Safety guarantees on updates (none lost; no reordering) Performance + resource use + output cons.  … 1 2 3 …

Gember-Jacobson et al., SIGCOMM’14 OpenNF Gember-Jacobson et al., SIGCOMM’14 Control Application move(http, NF1, NF2) OpenNF Controller NF State Manager Flow Manager get(http) state forward(http, NF2) put(state) State API is narrow and simple to simplify control application design NF1 NF2 Packet Route Update

Lost updates during move detect- MHR move(red,Bro1 ,Bro2 ) R2 R3 Missing state Missing updates R2 R1 B1 Bro1 Bro2 Loss-free: All state updates should be reflected in the transferred state, and all packets should be processed Assume that each Bro instance is running Bro’s detect-MHR script which computes the MD5 sum of HTTP replies and checks the hash against a database of known malware. Halts the flow of traffic at the switch and buffers packets at the SDN controller

Events for loss-free move Order-preserving move enableEvents(red) on Bro1 get/delete on Bro1 Buffer events at controller put on Bro2 Flush packets in events to Bro2 Update forwarding Eventual, strict, strong consistency for state sharing R3 R2 R1 Output equiv. It’s not essential that events go to the controller; they could be sent directly to the 2nd instance and buffered there R1 R1,R2,R3 R1,R2 Automatically det. guarantees needed? R2 Directly guarantee output equiv.? Filter Bro1 Bro2 Initial work: Static NF code analysis (Khalid et. al)

Elastic scaling Bro IDS @ 10K pkts/sec 260ms for a loss-free move At 180 sec: move HTTP flows to new IDS At 360 sec: move back to old IDS 260ms for a loss-free move Output cons.: same log entries as using one IDS VM replication: incorrect log entries Resource eff.: 260ms to move state back; scale down soon after Wait for flows to die  delayed 25+ minutes In this experiment, we elastically scale the Bro IDS. We replay a trace of cloud traffic at a rate of ten thousand packets/second. Move time is quick & can be estimated

Service chaining Cellular networks Enterprise networks ISPs firewall scrub. NAT Cellular networks Enterprise networks ISPs Virtual networking in the cloud

Mangling NAT Src = 156.0.0.9 : 1025 Dst = 128.0.0.5 : 80

Forwarding ambiguity: Forwarding depends on packet headers, which may be changed by mangling NFs Home Users Web Server Office Users srcIP = NAT SIMPLE: heuristics  inaccurate FlowTags: powerful, but custom NF modifications

Stratos: leverage compute for correctness- preserving logical chain transformations Identify manglingNFs When downstream forwarding is ambiguous: Clone and don’t share across chains

Composition ambiguity: Web Server Home Users Mangling nature of NFs makes composition of independently specified chains difficult Firewall Drop all traffic with certain signatures ? VPN Gateway Encrypt traffic on the wide-area 1 could be data center admin, 2 – enterprise admin, 3 – application admin Profiler Identify attributes of clients

Profiler and firewall need decrypted traffic “Every packet that hits web server must be profiled” 1 and 2 don’t work because the traffic is encrypted and so doesn’t make sense to have fw or prads before the tunnel endpoint. So it’s clear that VPN-GW should come first. Still, the ordering between FW and Prads is not clear. Prads’ asset detection is affected by whether it is placed ahead or behind the FW. “All incoming packets must be profiled”

Open problem! NF transformation model + clear expression of intent Initial work: PGM (Prakash et. al)

NFs in SDN: a rich space NFs are complex – makes life interesting Early days, no clear consensus – opportunity to shape practice