SDN Using DNS Naming for Classification

SDN Using DNS Naming for Classification Update: First, a Refresher. The initial project was outlined here

Abstract

Current generation networks are under scrutiny for not presenting the proper amount of flexibility at scale to accomplish technical and business objectives. At the core of the problem are the constraints imposed by the network revolving around the inflexible nature of IP addressing being so tightly coupled to geography. Traffic classification and policy application has been far too entwined with IP prefixes rather than providing any abstractions to extract flexibility while still maintaining the scalability that is required in networks that require constant availability with ability to absorb exponential growth. This project proposes using canonical naming structures and mapping them to policy classification and policy application.

In order to apply this concept the underpinning network is assumed to support basic flow based forwarding leveraging a wire protocol such as OpenFlow. Basic forwarding primitives are required in order to instantiate proper forwarding with applied policy instructions. Using naming conventions for IP mapping and compute classification has been used by applications for decades. The same naming construct in the network as objects and leveraging network elements that are, name to policy mappings aware will insert a layer of abstraction. This framework could reduce operational complexity while increasing provisioning overhead and begin to create networks that are taxonomically application aware.

Figure 1. Minium required support for headers in OpenFlow v1.3 spec. Those headers capture anything that is a Layer-2-4 device such as switches, routers, firewalls and load balancers (minus packet inspection) to name a few.

Figure 2. Conceptual Quite Simple.

Two Quick Example SDN Naming Use Cases

Use Case #1: Traffic Engineering – Mapping any portion of the Fully Qualified Domain Name (FQDN) or combinations thereof to the forwarding paths in the network elements would abstract the strict nature of being confined to IP prefixes in order to participate in colored path classifications. The name to policy conventions could even theoretically be exchanged between two autonomous entities and overcome administrative boundary limitations.

Figure 3. Mapping for any host *.erp.foo.* (host1.erp.foo.org) -> gold traffic path with the highest priority, bandwidth etc. host2.foo.org -> silver traffic policy with lower priority since it is a less critical application than the gold path policy. Foo has to be checked to be in the proper field in this case domain name since a host could have a hostname of foo and match improperly. Programmatically that is easily solved by extracting the ArrayList<E> with this snippet for those who have contacted me about this project (int size = ListArray.length); and then subtracting top levels.

Use Case #2: Security Policy – A major pain point in todays data centers and enterprises is security classification. Mapping DNS naming to polict would simplify the inefficient processes of workflow from Systems to Security to Network to get resources in place and provisioned. Again this is agnostic to the network IP addressing since the interesting fields being matched upon in the FQDN determine policy mapping.

Figure 4. Mappings for any host (denoted with the * wildcard “match anything” or “don’t care” bit) *.erp.foo.org -> Security policy with highest restriction (and any other resource, IDS, Flow Monitoring etc). Mappings for any host with *.foo.org -> Security policy with lower restrictions.

Back to the IDE

The use case list could go on for miles which is reflective of the enormous amount of flexibility combining programmatic abstractions and networking elements acting as hardware rather than distributed mainframes. Back to the IDE, I will update algorithms later as we work through the logic of storing and updating the key/value mappings. After that we will start looking to the FloodLight-Dev group for the best method of integration into our fork to get closer to a demo in coming weeks.