Network Metadata

Network Metadata – What is it? Why do we need it?

Network Metadata (literally, “data about the data”) is information about Enterprise Applications that describes them. Metadata provides a way to describe what the application IS, and what it NEEDS.

  • What they are (Application ID)
  • What RFC class they equate to in the network (real-time, transactional, best effort, etc)
  • What “bucket” they equate to in terms of business relevance and organization importance (business-relevant, business-irrelevant, business-critical, etc)
  • Other parameters as may be defined and added over time (extensible architecture to allow for future changes)

Instead of guessing device by device we holistically program the network via DNS-AS metadata

Network Metadata – possible sources of truth

Multiple Application ID’s out there

  • Snort Open App ID
  • SourceFire
  • FireSIGHT eStreamer Application Protocol
  • NBAR
  • Meraki
  • Simple Matches
  • Application Information in IP Flow Information Export (IPFIX)
  • AVC: Global Application ID assignment model RFC6759

Network Metadata strategy we have chosen for DNS-AS: RFC6759

Network Metadata – RFC6759 Components

Attributes Short Name Comments
Application Name app-name
  • Application name with a length of min 3 and max 24 characters
  • No whitespace
  • ASCII Alphanumeric characters
  • The following characters are allowed in addition: ‘-‘ (hyphen)
  • On switches without NBAR the app-name can match the NBAR local taxonomy
  • Custom names for applications are possible
Application ID app-id
  • RFC 6759 based application ID
  • numeric value between <1-65535>
  • Should be unique for consistent FNF reporting
  • Application ID is divided into an Selector ID and Engine ID
  • Selector-ID is encoded as a simple number.
  • DNS-AS apps are treated as custom apps, therefore use the Engine ID CU (custom) with the prefix cu/
  • Engine-ID is encoded as either a textual representation or a number
  • e.g.: Protocol Name: active-directory, id: 473, type: L7, app-id: L7/473
Application Category app-category
Application Sub-Category app-sub-category
Traffic Class (QoS) app-class RFC 4594 based short names
Business Relevance business
  • YES: business-relevant
  • NO: business-irrelevant
  • DEFAULT: NBAR Taxonomy default
Next Hop next NSH – Service Chaining Next Hop
Attributes (tunneled, encrypted, p2p) tunneled, encrypted, p2p tunneled, encrypted, p2p
Server Port Range port-range
  • The port format is as follows:
    /-
  • In order to specify metadata for specific ports on a host rather than the whole host, a list of server ports can be provided using the “port-range” option.
  • The ports in the list are separated by a comma.
  • If this option is not specified, any server port is accepted
  • e.g.: port-range:TCP/443,UDP/80-88
IP Protocol Specifier ip-protocol
  • IP Protocol Specifier: ip-proto:{,}*
  • In order to specify metadata for specific IP protocols on a host rather than the whole host, a list of IP protocols can be provided using the “ip-proto” option.
  • The ip protocols in the list are separated by a comma.
  • If this option is not specified, any IP protocol is accepted.
  • e.g.: ip-proto:41,42
IP Version Specifier ip-version
  •  IP version Specifier: ip-version:[v4|v6|any]
  • In order to specify metadata for specific IP version on a host rather than the whole host, the desired IP protocol version can be specified.
  • If this option is not specified, any IP version is accepted.
  • E.g.: ip-proto:any
Min/Avg/Max Bandwidth consumption min-bw, avg-bw, max-bw
  • Average Bandwidth: avg-bw:
  • Applications can specify the average bandwidth they require so that network devices can take optimal decisions in handling their traffic.
  • Avg-bw is a number measured in kilo-bits per second
  • Max Bandwidth: max-bw:
  • Applications can specify the max bandwidth they would ever require so that network devices can take optimal decisions in handling their traffic.
  • Max-bw is a number measured in kilo-bits per second
Max. Possible Packet Loss max-pkt-loss In %
Max. Possible Jitter max-jitter In ms
Max. Possible Latency max-latency In ms
Metadata derived from source NBAR2, DNS-AS-server, DNS-AS-proxy, RPZ

Network Metadata – DNS-AS

RFC6759 Metadata Components mapping for DNS-AS Resource Records

Mandatory Attributes:

  1. Application Name (app-name)
  2. Application ID (app-id)

QoS Attributes:

  1. Traffic Class (app-class)
  2. Business Relevance (business)

Optional Attributes:

  • Server Port Range (port-range)
  • Application Category (app-category)
  • Application Sub-Category (app-sub-category)
  • Attributes (tunneled, encrypted, p2p)
  • IP Protocol Specifier (ip-protocol)
  • IP Version Specifier (ip-version)
  • Min/Avg/Max Bandwidth consumption (min-bw, avg-bw, max-bw)
  • Max. Possible Packet Loss (max-pkt-loss)
  • Max. Possible Jitter (max-jitter)
  • Max. Possible Latency (max-latency)
  • Source of Metadata (source)

Only Short Names are supported within DNS-AS Resource Records!

Network Metadata – Where to stuff these into?

  • TXT RRs are used to hold descriptive text. The semantics of the text depends on the domain where it is found.
  • Originally for arbitrary human-readable text in a DNS record.
  • Since the early 1990s, however, this record more often carries machine-readable data, such as specified by RFC 1464, opportunistic encryption, Sender Policy Framework, DKIM, DMARC, DNS-SD, etc.
  • The base DNS specification limits DNS messages over UDP to 512 octets
  • You can use multiple RRs, but this will make it complicated to sort the records
  • TXT RRs are used to hold descriptive text. The semantics of the text depends on the domain where it is found.
  • Originally for arbitrary human-readable text in a DNS record.
  • Since the early 1990s, however, this record more often carries machine-readable data, such as specified by RFC 1464, opportunistic encryption, Sender Policy Framework, DKIM, DMARC, DNS-SD, etc.
  • The base DNS specification limits DNS messages over UDP to 512 octets
  • You can use multiple RRs, but this will make it complicated to sort the records

Can I have a TXT or AVC record longer than 255 characters?

You may have more than 255 characters of data in a TXT or AVC record, but not more than 255 characters in a single string. This is inline with limitations you have for TXT, AVC and SPF.

If you attempt to create an TXT or AVC record with a long string (>255 characters) in it, BIND will give an error (e.g. “invalid rdata format: ran out of space”.)  Strings in TXT or AVC records should be no longer than 255 characters.  However to get around this limitation, per RFC 4408 a TXT or AVC record is allowed to contain multiple strings, which should be concatenated together by the reading application.  In the case of use for SPF (using either TXT or SPF RRs) the strings are concatenated together without spaces as described below.  Reassembly by other applications of multiple strings stored in TXT records might work differently.

ISC Knowledge base: AA-00356

Network Metadata – Syntax

For DNS-AS we can use two types of DNS Resource Records:

TXT

  • depreciated for DNS-AS
  • to be used for backward compatibility reasons
  • or with not current DNS servers

AVC

  • the official IANA assigned mnemonic
  • preferred RR going forward if the authoritative DNS server already supports this new RR

General DNS-AS TXT record syntax:

"CISCO-CLS=<option>:<val>{|<option>:<val>}*"

Option-value pairs may appear in the same record, separated by a pipe character:

"|"

Example for such a TXT record with app metadata would be:

TXT "CISCO-CLS=app-name:WOLFGANG|app-class:OAM"

General DNS-AS AVC record syntax:

"<option>:<val>{|<option>:<val>}*"

Option-value pairs may appear in the same record, separated by a pipe character:

"|"

Example for such a AVC record with app metadata would be:

AVC "app-name:WOLFGANG|app-class:OAM"

Dual, staged lookup for Resource Records:

  1. Try to pull the AVC resource record from the DNS server
    If it returns metadata according to our syntax, don’t send another request for a TXT record.
  2. If there response for AVC is eq nil, try to pull the TXT resource record from the DNS server.
    If it returns metadata according to our syntax, use it else continues with the Onion layers.

RFC6759 Metadata

Components mapping for DNS-AS Resource Records

  • Attributes
  • Application Name
  • Application ID
  • Traffic Class (QoS)
  • Business Relevance
  • Server Port Range
  • IP Protocol Specifier
  • IP Version Specifier
  • Application Category
  • Application Sub-Category
  • Attributes (tunneled, encrypted, p2p)
  • Min/Avg/Max Bandwidth consumption
  • Max. Possible Packet Loss
  • Max. Possible Jitter
  • Max. Possible Latency
  • Metadata derived from
  • Next Hop
  • Short Name
  • app-name
  • app-id
  • app-traffic-class
  • business
  • port-range
  • ip-protocol
  • ip-version
  • app-category
  • app-sub-category
  • tunneled, encrypted, p2p
  • min-bw, avg-bw, max-bw
  • max-pkt-loss
  • max-jitter
  • max-latency
  • source
  • next
  • Comments
  • minimum character length of 3
  • numeric value between <1-65535>
  • RFC 4594 based short names
  • YES: business-relevant
    NO: business-irrelevant
    DEFAULT: NBAR Taxonomy default
  • to identify an application by ports
  • IP Protocol Specifier
  • IP Version Specifier
  • see table below: app-category
  • see table below: app-sub-category
  • tunneled, encrypted, p2p
  • Min/Avg/Max Bandwidth consumption
  • In %
  • In ms
  • In ms
  • NBAR2, DNS-AS-server, DNS-AS-proxy, RPZ
  • NSH – Service Chaining Next Hop

Table: app-category

possible values for category attributes are:

  • anonymizers
  • backup-and-storage
  • browsing
  • business-and-productivity-tool
  • custom-category
  • database
  • email
  • epayement
  • file-sharing
  • gaming
  • industrial-protocols
  • instant-messaging
  • inter-process-rpc
  • internet-security
  • layer3-over-ip
  • location-based-services
  • net-admin
  • newsgroup
  • other
  • social-networking
  • software-update
  • trojan
  • voice-and-video

Table: app-sub-category

possible values for sub-category attributes are:

  • authentication-services
  • backup-systems
  • consumer-audio-streaming
  • consumer-cloud-storage
  • consumer-multimedia-messaging
  • consumer-video-streaming
  • consumer-web-browsing
  • control-and-signaling
  • custom-sub-category
  • desktop-virtualization
  • enterprise-cloud-data-storage
  • enterprise-cloud-services
  • enterprise-data-center-storage
  • enterprise-media-conferencing
  • enterprise-realtime-apps
  • enterprise-rich-media-content
  • enterprise-sw-deployment-tools
  • enterprise-transactional-apps
  • enterprise-video-broadcast
  • enterprise-voice-collaboration
  • file-transfer
  • naming-services
  • network-management
  • os-updates
  • other
  • p2p-file-transfer
  • p2p-networking
  • remote-access-terminal
  • routing-protocol
  • tunneling-protocols

Examples

DNS-AS TXT record syntax for CISCO IWAN:

CISCO-CLS=app-name:my-app|business:yes|app-class:BD|app-category:business-and-productivity-tool|app-sub-category:enterprise-voice-collaboration

DNS-AS AVC record syntax for CISCO IWAN:

app-name:my-app|business:yes|app-class:BD|app-category:business-and-productivity-tool|app-sub-category:enterprise-voice-collaboration