FlowTags: Enforcing Network-Wide Policies in the Presence of Dynamic Middlebox Actions Seyed K. Fayazbakhsh Vyas Sekar Minlan Yu Jeff Mogul Hi today I am going to present a framework for extending SDN so that we can continue to effectively enforce policies even in the presence of dynamic middlebox actions such as NATs/proxies/Wan optimizers modifying traffic flows..

Middleboxes complicate policy enforcement in SDN Policy routing Access control Diagnostics Forensics Control Apps Logical view: Specify policy goals Admin Network OS Physical View A key advantage of SDN is the ability to logically specify some high level policy goal e.g., for routing or access control and then being able to enforce that in the data plane automatically. While this picture looks quite nice and there has been a lot of work fulfilling this vision, things get a bit murkier when you throw middleboxes like NATs, IDS, proxy etc into the picture .. The key challenge is that these bxes can dynamically modify traffic, sometimes depending on the past history of observed traffic, and such context may not be available to the SDN controller! Let us look at some simple examples to see why this is the case. Dynamic traffic-dependent modifications! e.g., NATs, proxies “Flow” Action … Data Plane

Example: Policy Routing H1: NAT  Firewall H2: NAT  IDS NAT IDS Firewall H1 Internet S1 S2 H2 Consider a very canonical middlebox specific policy routing example. Here we want traffic from host1 to go thru nat + firewall and traffic from host 2 to go thru nat/ids. The problem is that the NAT is going to dynamically modify srcips based on some proprietary logic. Thus its unclear how we can correctly setup forwarding Rules at S2 to direct the packets thru the right paths. How do we setup correct forwarding rules?

Example: Dynamic Dependence Web ACL: Block H2  xyz Proxy H1 Get xyz.com Cached response Response Internet To make matters worse, the actions of the middelbox may depend on stateful semantics -- for instance consider the example where we have a proxy and an web access control device .. And we want to block access from Host2 to xyz.com .. The trouble of course is that the proxy may return a cached response to H2 that violates our intent of blocking its access to xyz.com. Note that this is orthogonal to the previous examples .. There we didn’t have to worry abt traffoc dependent actions. Get xyz.com S1 S2 H2 Cached response Cached responses may violate policy

Strawman Solutions Careful placement? (i.e., manual) May not always be feasible Consolidating middleboxes? (e.g., CoMb) Just “punting” the problem Inferring flow mappings? (e.g., SIMPLE) Hard to reason about accuracy + high overhead The previous examples showed the diff ways in which mboxes can mess up our ability to implemente policies correctly. At first glance, there appear to be some seemingly natural strawman solutions to this problem .. . For instance, may we can make sure mboxes are placed to avoid such conflicts – e.g., run ids before nat?. The problem is that there are cases where there is no feasible placement and morever this manual/error prone – goes against the sdn philosophy of logical/physical decoupling Another option is to cosoldate –e.g., if we run both proxy and webacl on the same box then presumably we can avoid such problems? Thing is that this isnt really solving the problem .. That consolidated box wll have some shim policy routing layer that needs to address this Another idea is why don’t we correlate the incoming/outgoing traffic – its not reloiable especially not all mboxes follow a pkt in pkt out semantics. The key here is that none of these solutions are really tackling the root of the problem – the lack of visilibut into middlebox specific context – what mappings what internal modifications it did etc. Add more text to this slide .. Key missing piece: Lack of “visibility” into middlebox context

FlowTags: High-level Idea Middleboxes “help” with the lack of visibility Add FlowTags to packets to bridge gaps NAT gives IP mappings; Proxy gives cache hit/miss Middleboxes “produce” + “consume” FlowTags Switches only “consume” FlowTags Our high-level idea with this work is to essentially address the root of the problem rather than some ad hoc workarounds. Our vision is a world where middelboxes also embrace SDN and help with the lack of bisibilty . Specifixlaly they add what we call “FlowTags” to the packet headers to bridge the gaps in our visiligyt. e.g., in our examples the nat will give private-public ip mappings or the proxy may expose cache hit/miss state in the header Note that middleboxes are both producers and consumers of flowtags -- they generate them and use them to implement their semantics Switches are passive consumers and use this in their forwarding logic.

FlowTags Architecture Overview Control Apps Existing Interfaces e.g., OpenFlow Controller FlowTags API FlowTags Enhanced Middleboxes Config SDN enabled Switches FlowTable “decouple” Analaogous to SDN apis like openflow, we envision new flowtags api that will programmatically install tag-related rules in these mboxes. finally we need analogous control apps for tag rule generation and policy verification .. e.g., NAT exposes mappings Proxy gives hit/miss state IDS uses tags to disambiguate

FlowTags Southbound API FlowTags Controller FlowMatch, Action RqstTag(Pkt,Context) FlowMatch, {Tags} RqstAction(Pkt + Tags) TagsActionTable H1 TagsFlowTable Proxy ACL S2 S1 Pkt Let us look a bit more in depth at what this new southbound api may look like .. Let us consider this example topology where we have a proxy in conjunction with the access control device. As we discussed earlier mboxes are both produces/consumers – in this case the proxy is a producer that has the tagsflowtable and the acl is the consusumer which has an actions table . Let us assume both are empty. When a proxy receives a pkt and processes it, it queries the conrtoller for the tag addition rule – here it will give addl contexst such as cache hit.miss state to the controller. The controller then returns a flowmach pattern and the tags that need to be added .. Which may be reused for future pkts as well . The proxy adds this tag to the pkt. When the acl device receives the pkt with the tag, it sends a msg to the controller to request a suitable set of action rules – e.g., block/drop this pkt or fwd it and the controler again installs a flowmatch pattehr with an action. Pkt w/ Tags Internet H2 8

Policy Implementation via FlowTags Policy: Block H2  xyz TagsFlowTable TagsActionTable H1, MISS  1 H1, HIT  2 H2, MISS  3 H2, HIT  4 Tag Src Action 4 H2 Block H1 Proxy ACL S2 S1 Internet Let us walk through an end to end example combining some of the things we have seen .. Suppose our policy here is to block host2 from accessing xyz and ratelimit wan bandwidth for all srces. As discussed the problem here is two fold .. The src that we see at S2 will be the proxy ip second, if there is a cached response it may bypass the acl device. So in this case we need tags to disambiguate both srces and provide hit/miss information. In this case the tagflowtable on the proxy will map these scenarios with some encoded tags. The forwarding rules of S1/S2 will now use tag information in addition to traditional flow match/interface fields to decide where to steer this pkt. Finally. When we come to the ACL/ratelimiting deivce, it has actions corresponding to the various scenars – for tags 1 hich are misses from host 1it will just do rate limitn. For tag 4, it will implement blocking w/o ratelimitng and for tag3 it will do both. Note that tag2 will not even be seen at acl since it’s a hit from H1. Input Tag Out Proxy 2 H1 1,3,4 S2 Input Tag Out S1 1,3,4 ACL 4 1,3 Internet H2

FlowTags Proof-of-Concept Using Squid (> over 100,000 lines of code) About 30 lines of code to add FlowTags support Manually identify code chokepoints Validated use-cases with examples As a proof of concept we have initially modified squid to add flowtags support .. We do this by identifying code chokepoints where we need to add the relevant Hooks and we have validated the examples in this tlak and a few more in the paper.

Conclusions Middleboxes make policy enforcement hard Dynamic modifications are hard to account for FlowTags can make “flow context” visible Minimal modifications to middleboxes No changes to switch/switch APIs Enabler for new verification and forensic tasks Simpler HSA; Dynamic policies; Correlating logs Early promise, but many challenges remain E.g., How many bits? Automatic patches? Control apps? To summairze the motivation for this work is that the dynamic modifications by mboxes make it hard to implement policies efficiently .. Its a bit weird because policy compliance is in fact a key driver for mbox adoptin. Our vision is to have a clean mechanism to address this visibility gaps rather than ad hoc heuristics … we emvision adding flowtags will impose minimal changes To mboxes .. And moreoever no changes to exisitng sdn switches and their apis. The overall vision here is tha such a mechanism can be an anabler for new policy verification and forensic functions and potentially simplify existing SDN tools as well .. Our proof of concept and examples are promising but we have quite a disance to go before this is “real” -- there are many challenges that we don’t quite know how to adrdress eyet – do we hae enough space with exsting header bits, how do we utomaitclaly patch this support into exisitng mvox software? How do we syamteically model the dynamic actions to genertate tagging rulets etc.