SDN Using DNS Naming for Classification

SDN Using DNS Naming for Classification

Internet Traffic Evolution


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.

Required.v1.3.Openflow.Feilds

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.

sdn.paths

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.

TE-OpenFlow-DNS

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.

Sec-Policy-SDN-Naming-border

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.

About the Author

Brent SalisburyI have over 20 years of experience wearing various hats from, network engineer, architect, ops and software engineer. More at Brent's LinkedInView all posts by Brent Salisbury →

  1. Ben DaleBen Dale11-12-2012


    Just wow! Mind officially blown open!!

    I have been looking at Openflow and wondering if anything useful will ever come of it outside of academia. None of its *capabilities* are particularly unique in the vanilla-networking sense, and it remains to be seen how well applications will scale up into large “real-world” networks.

    That said, I think the applicability of Openflow in the security space is the most under-discussed, but exciting change in recent times – and your blog entry has just confirmed that for me 100%.

    My personal view is that operational complexity, closely followed by poor visibility are the two biggest threats in network security, and ideas/applications like these are going to hold the answers.

    Well done.

    • Brent SalisburyBrent Salisbury11-12-2012


      Hi Ben, you nailed it with your last statement. The complexity will get in the way of us absorbing the growth and policy application in coming years. I read something the other day that said we have 300 Million mobile IP devices today and expect 20 Billion by 2020. Today’s operational tools are not going to cut it for sure.
      Thanks for the comment and keep my abreast of your thoughts as you dig in.