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)
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 – RFC6759 Components
Attributes | Short Name | Comments |
Application Name | app-name |
|
Application ID | app-id |
|
Application Category | app-category | |
Application Sub-Category | app-sub-category | |
Traffic Class (QoS) | app-class | RFC 4594 based short names |
Business Relevance | business |
|
Next Hop | next | NSH – Service Chaining Next Hop |
Attributes (tunneled, encrypted, p2p) | tunneled, encrypted, p2p | tunneled, encrypted, p2p |
Server Port Range | port-range |
|
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 | 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:
- Application Name (app-name)
- Application ID (app-id)
QoS Attributes:
- Traffic Class (app-class)
- 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)
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:
General DNS-AS TXT record syntax:
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:
General DNS-AS AVC record syntax:
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:
Dual, staged lookup for Resource Records:
- 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. - 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
- 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:
DNS-AS AVC record syntax for CISCO IWAN: