Network Function Virtualization. CSU CS557, Spring 2018 Instructor: Lorenzo De Carli

Transcription

1 Network Function Virtualization CSU CS557, Spring 2018 Instructor: Lorenzo De Carli

2 Managing middleboxes Middlebox manifesto (ref. previous lecture) pointed out the need for automated middlebox management Many different solutions proposed afterwards Typical model: middleboxes are virtualized software appliances Can be deployed on general-purpose servers Area typically referred to as Network Function Virtualization

3 Managing middleboxes - II Implementing middleboxes in software offers great freedom Allowing things like scaling and dynamic load balancing: Scaling Load-balancing Input traffic IDS 1 IDS3 IDS2 IDS 1 IDS2

4 Managing middleboxes - III The ability of shuffling middleboxes around creates various challenges Most are related to the stateful nature of middlebox processing E.g., an IDS keeps some detection state for each flow it is analyzing What happens to the state if the IDS is terminated or the flow is remapped to another IDS node?

5 Example: IDS MB scaled out during portscan detection All traffic processed by the same middlebox: Conn attempt #1 Scale-out mid-attack: Conn attempt #1 Conn attempt #2 IDS 1 Conn attempt #2 Conn attempt #3 IDS 1 Portscan Conn attempt #3 IDS 2

6 OpenNF OpenNF: Enabling Innovation in Network Function Control Aaron Gember-Jacobson, Raajay Viswanathan, Chaithan Prakash, Robert Grandl, Junaid Khalid, Sourav Das, and Aditya Akella University of Wisconsin-Madison ABSTRACT Network functions virtualization (NFV) together with softwaredefined networking (SDN) has the potential to help operators satisfy tight service level agreements, accurately monitor andmanipulate network traffic, and minimize operating expenses. However, in scenarios that require packet processing to be redistributed across acollectionofnetworkfunction(nf)instances,simultaneously achieving all three goals requires a framework that provides efficient, coordinated control of both internal NF state and network forwarding state. To this end, we design a control plane called OpenNF. We use carefully designed APIs and a clever combination of events and forwarding updates to address race conditions, bound overhead, and accommodate a variety of NFs. Our evaluation shows that OpenNF offers efficient state control without compromising flexibility, and requires modest additions to NFs. Categories and Subject Descriptors C.2.1 [Computer Communication Networks]: Network Architecture and Design; C.2.3 [Computer Communication Networks]: Network Operations Keywords Network functions, middleboxes, software-defined networking 1. INTRODUCTION Network functions (NFs), or middleboxes, are systems that examine and modify packets and flows in sophisticated ways: e.g., intrusion detection systems (IDSs), load balancers, caching proxies, etc. NFs play a critical role in ensuring security, improving performance, and providing other novel network functionality [37]. Recently, we have seen a growing interest in replacing dedicated NF hardware with software-based NFs running on generic compute resources a trend known as network functions virtualization (NFV) [12]. In parallel, software-defined networking (SDN) is being used to steer flows through appropriate NFs to enforce policies and jointly manage network and NF load [17, 20, 22, 26, 32]. Permission to make digital or hard copies of all or part of this workforpersonalor classroom use is granted without fee provided that copies are notmadeordistributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, orrepublish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. SIGCOMM 14, August 17 22, 2014, Chicago, IL, USA. Copyright 2014 ACM /14/08...$ Together, NFV and SDN can enable an important class of management applications that need to dynamically redistribute packet processing across multiple instances of an NF e.g., NF load balancing [32] and elastic NF scaling [21]. In the context of such applications, NFV + SDN can help achieve three important goals: (1) satisfytightservicelevelagreements(slas)onnfperformance or availability; (2) accurately monitor and manipulate network traffic, e.g., an IDS should raise alerts for all flows containing known malware; and (3) minimize NF operating costs. However, simultaneously achieving all three goals is not possible today, and fundamentally requires more control than NFV + SDN can offer. To see why, consider a scenario where an IDS is overloaded and must be scaled out in order to satisfy SLAs on throughput (Figure 1). With NFV we can easily launch a new IDS instance, and with SDN we can reroute some in-progress flows to the new instance [17, 32]. However, attacks may go undetected because the necessary internal NF state is unavailable at the new instance. To overcome this problem, an SDN control application can wait for existing flows to terminate and only reroute new flows [22, 38], but this delays the mitigation of overload and increases the likelihood of SLA violations. NF accuracy may also be impacted due to some NF-internal state not being copied or shared. In this example, the only way to avoid a trade-off between NF accuracy and performance is to allow a control application to quickly and safely move the internal IDS state for some flows from the original instance to the new instance, and update network forwarding state alongside. Similarneedsariseinthecontextofotherapplications that rely on dynamic reallocation of packet processing: e.g., rapid NF upgrades and dynamic invocation of remote processing. In this paper, we present OpenNF, a control plane architecture that provides efficient, coordinated control of both internal NF state and network forwarding state to allow quick, safe, and fine-grained reallocation of flows across NF instances. Using OpenNF, operators can create rich control applications that redistributeprocessing to optimally meet their performance, availability, security and cost objectives, thus avoiding the need to make undesirable trade-offs. We address three major challenges in designing OpenNF: C1: Addressing race conditions. This is the most basic issue that arises when reallocating in-progress flows: When some internal NF state is being moved, packets may arrive at the source instance after the move starts, or at the destination instance before the state transfer finishes. Unless care is taken, updates to NF state due to such packets may either be lost or happen out of order, violating move safety. Similarly, when state is copied across NF instances, updates occurring contemporaneously may cause state to become inconsistent. Depending on the NF, these issues may hurt its accuracy. To account for race conditions, we introduce two novel constructs: (1) an event abstraction to externally observe and prevent

7 Core problems Middleboxes tend to maintain state pertaining to the traffic they are processing Contrast to routers, switches etc. which do not need to remember anything besides the packet they are processing Problem: what happens to this state if processing switches to another middlebox?

8 OpenNF contributions Mechanism to coordinate scaling and load-balancing of middleboxes without service interruption Based on state-transfer mechanism which can provide various useful properties (no packet lost/reordered) Helps ensuring correctness (no state is lost/corrupted due to scaling/load-balancing) Architecture to coordinate state transfer operations

9 Relocating network functions Transferring network functions w/o service interruption requires coordination of: Application-level state transfer: NF controller transfers state related to flows being redirected by the network level Network-level flow-steering: SDN controller redirects flows from source to destination middlebox (already provided by standard OpenFlow network substrate)

10 OpenNF high-level architecture Initiates/manages high-level operations (scaling, load-balancing, replication) Performs NF state transfer Performs flow steering

11 High-level functions to state manipulation operations Goal: perform load-balancing by relocating a set of flows S from middlebox A to B: Move state for flows in S from A to B Steer flows in S so that they traverse B instead of A Goal: perform scaling by terminating middlebox A and relocating its processing task to B Same as above but at the end A is terminated Goal: replicate a middlebox A1 to another middlebox A2 to provide a hot spare Instantiate A2 Periodically copy state for the set of flows S managed by A1 to A2

12 State manipulation operations to low-level operations Northbound API: move(srcinst, dstinst, filter, scope, properties) copy(srcinst, dstinst, filter, scope) share(list<inst>, filter, scope, consistency) NFV controller: implements copy/move/share operations by issuing appropriate sequences of low-level Southbound API calls Southbound API: getperflow(), putperflow(), delperflow(), getmultiflow(), putmultiflow(), delmultiflow(), getallflows(), delallflows(), enableevents(), disableevents()

13 Types of state Per-flow state: program state keeping track of properties of a single network flow Multi-flow state: program state keeping track of aggregate properties of multiple flows All-flow state: program state keeping track of global properties of middlebox processing (information referring to and/or affecting all flows being processed)

14 OpenNF: move operation Can provide various properties (loss-freeness, order preservation) Trade off: correctness vs delay Simplest case: move w/o guarantees: 4.Reconfigure forwarding table State SDN controller 1.getPerflow(F) 3.putPerflow(F) 2.delPerflow(F) OpenFlow switch Flow of interest MBSRC State Flow of interest MBDST State

15 Move w/o guarantees: issues State created in MBSRC for packets arrived after getperflow is not moved to MBDST Simplest solution: instruct MBSRC (or SDN switch) to ignore (or drop) all packets received after getperflow Only OK if processing is resilient to packet losses and still suboptimal! E.g. IDS will continue to function but may miss attacks (e.g. portscans) OpenNF can provide additional guarantees: loss-freeness, in-order delivery

16 Loss-free move Leverage a novel OpenNF contribution: the event management API Allows NFV controller to instruct middleboxes to process, buffer, or drop certain categories of packets while at the same time forwarding the same packets to the NFV controller In loss-free move, these primitives are used to buffer and then forward all packets received by MBSRC after state has been moved, to MBDST

17 Loss-free move - part I State Packets SDN controller Flow of interest 1.enableEvents(F, drop) 2.getPerflow(F) 3.delPerflow(F) OpenFlow switch Flow of interest MBSRC State MBDST

18 Loss-free move - part II State 5.Reconfigure forwarding table Packets Flow of interest SDN controller 4.putPerflow(F) Flow of interest OpenFlow switch Flow of interest Flow of interest MBSRC MBDST Issue: packets may still arrive out-of-order at MBDST (why?) State

19 OpenNF: copy operation Copy: used e.g. for failure recovery (copy state from an active middle box to a backup instance) Uses getperflow/putperflow (no deletion) Provides eventual consistency

20 OpenNF: share operation MB1 MB2 Switch... MBN Share: used to ensure that all state updates by a middlebox are directly reflected by the state of one or more other middleboxes (distributed processing) Strict consistency: state updates to a middlebox state are immediately reflected in the state of all other middleboxes (updates to the shared state reflects the order in which packets where received by switch) Strong consistency: order of state updates may differ from the order in which packets where received by switch/but all updates performed by an individual middlebox must be seen by other middleboxes in the order in which they were performed

21 Results Total Time (ms) Per-Packet Latency Increase (ms) (a) Total move time Average NG NG PL LF PL LF PL+ER LF+OP PL+ER Maximum (b) Per-packet latency increase Figure 10: Efficiency of move with no guarantees (NG), loss-free (LF), and loss-free and order-preserving (LF+OP) with and without parallelizing (PL) and early-release (ER) optimizations; traffic rate is 2500 packets/sec; times are averaged over 5 runs and the error bars show 95% confidence intervals

22 Results - II # Dropped Packets flows 500 flows 1000 flows Packet Rate (1000s of pkts/s) (a) Packet drops during a parallelized move with no guarantees Move Time (ms) flows 500 flows 1000 flows Packet Rate (1000s of pkts/s) (b) Total time for a parallelized loss-free move Figure 11: Impact of packet rate and number of per-flows states on parallelized move with and without a loss-free guarantee

23 Other challenges in middlebox management Designing policy languages to describe middlebox deployments Offloading middleboxes to the cloud