1. 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..

2. 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

3. 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?

4. 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

5. 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

6. 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.

7. 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

8. 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

9. 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

10. 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.

11. 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.