One document matched: draft-claise-export-application-info-in-ipfix-04.txt
Differences from draft-claise-export-application-info-in-ipfix-03.txt
IPFIX Working Group B. Claise
Internet-Draft P. Aitken
Intended Status: Informational N. Ben-Dvora
Expires: May 29, 2012 Cisco Systems, Inc.
December 3, 2011
Export of Application Information in IPFIX
draft-claise-export-application-info-in-ipfix-04
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 16, 2011.
<Claise, Aitken, Ben-Dvora> Expires May 29 2012 [Page 1]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Abstract
This document specifies an extension to the IPFIX information
model specified in [RFC5102] to export application information.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [RFC2119].
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 2]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
Table of Contents
1. Overview................................................. 4
1.1. IPFIX Documents Overview............................ 4
2. Introduction............................................. 5
2.1. Application Information Use Cases...................... 7
3. Terminology.............................................. 8
3.1. New Terminology..................................... 8
4. applicationTag Information Element Specification......... 8
4.1. Existing Classification Engine IDs.................. 9
4.2. Options Template Record for the Application Name... 12
4.3. Resolving IANA L4 port collisions.................. 12
5. Grouping the Applications with the Attributes........... 16
5.1. Options Template Record for the Attribute Values... 18
6. Application Tag Examples................................ 18
6.1. Example 1: Layer 2 Protocol........................ 18
6.2. Example 2: Standardized IANA Layer 3 Protocol...... 19
6.3. Example 3: Cisco Systems Proprietary Layer 3 Protocol20
6.4. Example 4: Standardized IANA Layer 4 Port.......... 22
6.5. Example 4: Layer 7 Application..................... 23
6.6. Example: port Obfuscation.......................... 25
6.7. Example: Application Mapping Options Template...... 26
6.8. Example: Attributes Values Options Template Record. 27
7. IANA Considerations..................................... 28
7.1. applicationDescription............................. 28
7.2. applicationTag..................................... 28
7.3. applicationName.................................... 28
7.4. classificationEngineId............................. 29
7.5. applicationCategoryName............................ 29
7.6. applicationSubCategoryName......................... 29
7.7. applicationGroupName............................... 29
7.8. p2pTechnology...................................... 30
7.9. tunnelTechnology................................... 30
7.10. encryptedTechnology............................... 30
8. Security Considerations................................. 30
9. References.............................................. 31
9.1. Normative References............................... 31
9.2. Informative References............................. 31
10. Acknowledgement........................................ 32
11. Authors' Addresses..................................... 33
Appendix A. Additions to XML Specification of IPFIX
Information Elements....................................... 34
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 3]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
List of Figures and Tables
Figure 1: applicationTag Information Element ................ 8
Figure 2: Selector ID encoding .............................. 9
Table 1: Existing Classification Engine IDs ................ 11
Table 2: IANA layer 4 port collisions between UDP and TCP .. 13
Table 3: IANA layer 4 port collisions between SCTP and TCP . 16
Table 4: Existing Application Tag Static Attributes ........ 17
1. Overview
1.1. IPFIX Documents Overview
The IPFIX Protocol [RFC5101] provides network administrators with
access to IP Flow information.
The architecture for the export of measured IP Flow information
out of an IPFIX Exporting Process to a Collecting Process is
defined in the IPFIX Architecture [RFC5470], per the requirements
defined in RFC 3917 [RFC3917].
The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records
and Templates are carried via a congestion-aware transport
protocol from IPFIX Exporting Processes to IPFIX Collecting
Processes.
IPFIX has a formal description of IPFIX Information Elements,
their name, type and additional semantic information, as specified
in the IPFIX information model [RFC5102].
In order to gain a level of confidence in the IPFIX
implementation, probe the conformity and robustness, and allow
interoperability, the Guidelines for IPFIX Testing [RFC5471]
presents a list of tests for implementers of compliant Exporting
Processes and Collecting Processes.
The Bidirectional Flow Export [RFC5103] specifies a method for
exporting bidirectional flow (biflow) information using the IP
Flow Information Export (IPFIX) protocol, representing each Biflow
using a single Flow Record.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 4]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
The "Reducing Redundancy in IP Flow Information Export (IPFIX)
and Packet Sampling (PSAMP) Reports" [RFC5473] specifies a
bandwidth saving method for exporting Flow or packet
information, by separating information common to several Flow
Records from information specific to an individual Flow Record:
common Flow information is exported only once.
2. Introduction
Today service providers and network administrators are looking
for visibility into the packet content rather than just the
packet header. Some network devices Metering Processes inspect
the packet content and identify the applications that are
utilizing the network traffic. Applications in this context
are defined as networking protocols used by networking
processes that exchange packets between them (such as the web
applications, peer to peer applications, file transfer, e-mail
applications, etc.). Combined with other information elements,
some of which being application specific, the applications can
be further characterized.
Examples include: web application to a specific domain, per
user specific traffic, a video application with a specific
codec, etc...
The application identification is based on different kind of
methods or even a combination of such methods:
1. L2 protocols (such as ARP, PPP, LLDP)
2. IP protocols (such as ICMP, IGMP, GRE)
3. TCP or UDP ports (such as HTTP, Telnet, FTP)
4. Application layer header (of the application to be
identified)
5. Packet data content
6. Packets and traffic behavior
The exact application identification methods are part of the
Metering Process internals that aims to provide an accurate
identification with a minimum false identification. This task
requires a sophisticated Metering Process since the protocols
do not behave in a standard manner.
1. Applications use port obfuscation where the application
run on different port than the IANA assigned one. For
example a HTTP server might run a TCP port 23 (assigned
to telnet in [IANA-PORTS])
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 5]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
2. IANA does not accurately reflect how certain ports are
"commonly" used today. Some ports are reserved, but
the application either never became prevalent or is not
in use today.
3. The application behavior and identification logic
become more and more complex
For that reason, such Metering Processes usually detect
application based on multiple mechanisms in parallel.
Detecting applications based only on port matching might
wrongly identify the traffic. Note that this example stresses
the need for the engine strength. If the Metering Process is
capable of detecting applications more accurately it is
considered as stronger and more accurate.
Similarly, a reporting mechanism that uses L4 port based
applications only, such as L4:<known port>, would have a
similar issues. The reporting system should be capable of
reporting the applications classified using all types for
mechanisms. In particular applications that does not have any
IANA port definition. While a mechanism to export application
information should be defined, the L4 port being in use must be
exported using the destination port (destinationTransportPort
at [IANA-IPFIX]) in the corresponding NetFlow record.
Cisco Systems uses the IPFIX application tag as described in
section 4. to export the application information with the IPFIX
protocol [RFC5101].
Application could be defined at different OSI layers, from the
layer 2 to the layer 7. Examples: Cisco Discovery Protocol is
layer 2 application, ICMP is layer 3 application [IANA-PROTO],
HTTP is layer 4 application [IANA-PORTS], and skype is layer 7.
While an ideal solution would be an IANA registry for
applications above (or inside the payload of) the well known
ports [IANA-PORTS], this solution is not always possible as the
some applications require well known specifications.
Therefore, some reverse engineering is required, as well as a
ubiquitous language for application identification. Clearly
not realistic.
As this specification focuses on the application information
encoding, this document doesn't contain an application registry
for non IANA applications. However, a reference to the Cisco
assigned numbers for the Application Tag and the different
attribute assignments can be found at [CISCO].
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 6]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
2.1. Application Information Use Cases
There are several use cases on which the application
information is used:
1. Network Visibility
This is one of the main use cases for using the application
information. This use case is also called application
visibility. Network administrators are using such
application visibility to understand the main network
consumers, network trends and user behavior.
2. Billing Services
In some cases, network providers are willing to bill
different applications differently. For example, provide
different billing for VoIP and Web browsing.
3. Congestion Control
While the traffic demand is increasing (mainly due to the
high usage of peer to peer applications, video applications
and web download applications), the providers revenue doesn't
grow. Providers are looking at a more efficient way to
control and prioritize the network utilization. An
application aware bandwidth control system is used to
prioritize the traffic based on the applications, giving the
critical applications priority over the non-critical
applications.
4. Security Functions
Application knowledge is sometimes used in security functions
in order to provide comprehensive functions such as
Application based firewall, URL filtering, Parental control,
Intrusion detection, etc.
All of the above use cases require exporting of application
information to provide the network function itself or to log
the network function operation.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 7]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
3. Terminology
IPFIX-specific terminology used in this document is defined in
Section 2 of the IPFIX protocol specification [RFC5101]. As in
[RFC5101], these IPFIX-specific terms have the first letter of
a word capitalized when used in this document.
3.1. New Terminology
Application Tag
A unique identifier for an application.
4. applicationTag Information Element Specification
This document specifies the applicationTag Information
Element, which is composed of two parts:
1. 8 bits of Classification Engine ID. The Classification
Engine can be considered as a specific registry for
application assignment.
2. m bits of Selector ID. The Selector ID length varies
depending on the Classification Engine ID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Class. Eng. ID| Selector ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: applicationTag Information Element
Classification Engine ID
A unique identifier for the engine which determined the
Selector ID. Thus the Classification Engine ID defines the
context for the Selector ID.
Selector ID
A unique identifier of the application for a specific
Classification Engine ID.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 8]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
Note that the Selector ID term is in sync with the PSAMP
terminology. See [RFC5476], Packet Sampling (PSAMP) Protocol
Specifications.
When an application is detected, the most granular
application is encoded in the Application Tag: for example,
ICMP would be encoded as layer 3 value 1, SNMP as layer 4
value 161, bittorent as layer 7 value 69.
The overall length of the applicationTag Information Element
may be specified either in the IPFIX Template Record or by
using an IPFIX Variable-Length Information Element. The
receiver / decoder must respect this length rather than using
the Classification Engine ID to make an assumption about the
Selector ID size. When exporting applicationTag information
in IPFIX, the applicationTag SHOULD be encoded in a variable-
length Information Element [RFC5101]. However, if a legacy
protocol such as NetFlow version 9 is used, and this protocol
doesn't support variable length Information Elements, then
either multiple Template Records (one per applicationTag
length), or a single Template Record corresponding to the
maximum sized applicationTag MUST be used. As a consequence,
although some Application Tags can be encoded in a smaller
number of bytes (eg, an IANA L3 protocol encoding would take
2 bytes, while an IANA L4 port encoding would take 3 bytes),
nothing prevents an Exporting Process from exporting all
Application Tags with a larger fixed length.
Note that the Selector ID value is always encoded in the
least significant bits as shown:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Class. Eng. ID | zero-valued upper-bits ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Selector ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Selector ID encoding
4.1. Existing Classification Engine IDs
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 9]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
The following Engine IDs have been allocated by Cisco
Systems.
Name Value Description
0 Invalid.
IANA-L3 1 The IANA protocol (layer 3)
number is exported in the
Selector ID.
See [IANA-PROTO].
CANA-L3 2 Cisco Systems proprietary layer 3
definition. Cisco Systems can
still export its own layer 3
protocol numbers, while waiting
for IANA to assign it. The
Selector ID has a global
significance for all Cisco
Systems devices under CANA
governance. Hopefully the same
IDs will be maintained after the
IANA standardization.
IANA-L4 3 IANA layer 4 well-known port
number is exported in the
Selector ID. See [IANA-PORTS].
Note: as a flow is
unidirectional, it contains the
destination port in a flow from
the client to the server.
CANA-L4 4 Cisco Systems proprietary layer 4
definition. Cisco Systems can
still export its own layer 4 port
numbers, while waiting for IANA
to assign it. The Selector ID has
global significance for all Cisco
Systems devices under CANA
governance. Hopefully the same ID
will be maintained after the IANA
standardization. Example: IPFIX
had the port 4739 pre-assigned in
the IETF draft for years. While
waiting for the IANA
registration, Cisco could use
this Selector ID.
5 Reserved.
USER- 6 The Selector ID represents
Defined applications defined by the user
(using CLI or GUI) based on the
methods described in section 2.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 10]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
7 Reserved.
8 Reserved.
9 Reserved.
10 Reserved.
11 Reserved.
CANA-L2 12 The Selector ID represents the
Cisco Systems unique global layer
2 applications. The Selector ID
has a global significance.
Examples include Cisco Subnetwork
Access Protocol (SNAP)
CANA-L7 13 The Selector ID represents the
Cisco Systems unique global ID
for the layer 7 applications. The
Selector ID has global
significance for all Cisco
Systems devices.
14 Reserved.
15 Reserved.
16 Reserved.
17 Reserved.
ETHERTYPE 18 The Selector ID represents the
well-known Ethertype. See
[ETHERTYPE]. Note that the
Ethertype is usually expressed in
hexadecimal. However, the
corresponding decimal value is
used in this Selector ID
LLC 19 The Selector ID represents the
well-known IEEE 802.2 Link Layer
Control (LLC) Destination Service
Access Point (DSAP). See [LLC].
Note that LLC DSAP is usually
expressed in hexadecimal.
However, the corresponding
decimal value is used in this
Selector ID
20 to
254 Available.
MAX 255 255 is the maximum Engine ID.
Table 1: Existing Classification Engine IDs
Note 1: "CANA = Cisco Systems Assigned Number Authority",
Cisco Systems' version of IANA for internal IDs.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 11]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
Note 2: This is an extensible list, and new Classification
Engine IDs may be allocated at any time. See [CISCO] for the
latest version.
4.2. Options Template Record for the Application Name
For engines which specify locally unique Application Tags
(which means unique per engine and per router), an Options
Template Record (see [RFC5101]) MUST be used to export the
correspondence between the Application Tag, the Application
Name, and the Application Description. This is called the
"options application-table". For engines which specify
globally unique Application Tags, an Options Template Record
SHOULD be used to export the correspondence between the
Application Tag, the Application Name and the Application
Description, unless the mapping is hardcoded in the NetFlow
Collector, or known out of band (for example, by polling a
MIB).
4.3. Resolving IANA L4 port collisions
Even if the IANA L4 ports usually point to the same protocols
for both UDP, TCP or other transport types, there are some
exceptions. The following table lists 10 ports that have
different protocols assigned for TCP and UDP:
exec 512/tcp remote process execution;
authentication performed
using passwords and UNIX
login names
comsat/biff 512/udp used by mail system to
notify users of new mail
received; currently
receives messages only from
processes on the same
machine
login 513/tcp remote login a la telnet;
automatic authentication
performed based on
priviledged port numbers
and distributed data bases
which identify
"authentication domains"
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 12]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
who 513/udp maintains data bases
showing who's logged in to
machines on a local
net and the load average of
the machine
shell 514/tcp cmd
like exec, but automatic
authentication is performed
as for login server
syslog 514/udp
oob-ws-https 664/tcp DMTF out-of-band secure web
services management
protocol
Jim Davis
<jim.davis&wbemsolutions.com>
June 2007
asf-secure-rmcp 664/udp ASF Secure Remote
Management and Control
Protocol
rfile 750/tcp
kerberos-iv 750/udp kerberos version iv
submit 773/tcp
notify 773/udp
rpasswd 774/tcp
acmaint_dbd 774/udp
entomb 775/tcp
acmaint_transd 775/udp
busboy 998/tcp
puparp 998/udp
garcon 999/tcp
applix 999/udp Applix ac
Table 2: IANA layer 4 port collisions between UDP and TCP
The following table lists 19 ports that have different
protocols assigned for TCP and SCTP:
# 3097/tcp Reserved
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 13]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
itu-bicc-stc 3097/sctp ITU-T Q.1902.1/Q.2150.3
Greg Sidebottom
<gregside&home.com>
# 5090/tcp <not assigned>
car 5090/sctp Candidate AR
# 5091/tcp <not assigned>
cxtp 5091/sctp Context Transfer Protocol
RFC 4065 - July 2005
# 6704/tcp Reserved
frc-hp 6704/sctp ForCES HP (High Priority)
channel [RFC5811]
# 6705/tcp Reserved
frc-mp 6705/sctp ForCES MP (Medium
Priority) channel
[RFC5811]
# 6706/tcp Reserved
frc-lp 6706/sctp ForCES LP (Low priority)
channel [RFC5811]
# 9082/tcp <not assigned>
lcs-ap 9082/sctp LCS Application Protocol
Kimmo Kymalainen
kimmo.kymalainen&etsi.org>
04 June 2010
# 9902/tcp <not assigned>
enrp-sctp-tls 9902/sctp enrp/tls server channel
[RFC5353]
# 11997/tcp <not assigned>
# 11998/tcp <not assigned>
# 11999/tcp <not assigned>
wmereceiving 11997/sctp WorldMailExpress
wmedistribution 11998/sctp WorldMailExpress
wmereporting 11999/sctp WorldMailExpress
Greg Foutz
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 14]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
<gregf&adminovation.com>
March 2006
# 25471/tcp <not assigned>
rna 25471/sctp RNSAP User Adaptation for
Iurh
Dario S. Tonesi
<dario.tonesi&nsn.com>
07 February 2011
# 29118/tcp Reserved
sgsap 29118/sctp SGsAP in 3GPP
# 29168/tcp Reserved
sbcap 29168/sctp SBcAP in 3GPP
# 29169/tcp <not assigned>
iuhsctpassoc 29169/sctp HNBAP and RUA Common
Association
John Meredith
<John.Meredith&etsi.org>
08 September 2009
# 36412/tcp <not assigned>
s1-control 36412/sctp S1-Control Plane (3GPP)
KimmoKymalainen
<kimmo.kymalainen&etsi.org>
01 September 2009
# 36422/tcp <not assigned>
x2-control 36422/sctp X2-Control Plane (3GPP)
Kimmo Kymalainen
<kimmo.kymalainen&etsi.org>
01 September 2009
# 36443/tcp <not assigned>
m2ap 36443/sctp M2 Application Part
Dario S. Tonesi
<dario.tonesi&nsn.com>
07 February 2011
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 15]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
# 36444/tcp <not assigned>
m3ap 36444/sctp M3 Application Part
Dario S. Tonesi
<dario.tonesi&nsn.com>
07 February 2011
Table 3: IANA layer 4 port collisions between SCTP and TCP
Instead of imposing the transport protocol (UDP/TCP/SCTP/etc.)
in the scope of the "options application-table" Options Template
for all applications (on top of having the transport protocol as
key-field in the Flow Record definition), the convention is that
the L4 application is always TCP related. So, whenever the
Collector has a conflict in looking up IANA, it would choose the
TCP choice. As a result, the UDP L4 applications from Table 2
and the SCTP L4 applications from table 3 are assigned in the
Cisco L7 Application Tag range (ie, under Classification Engine
ID 13):
Currently, there are no discrepancies between the well known
ports for TCP and DCCP.
5. Grouping the Applications with the Attributes
Due to the high number of different application tags,
categorizing them into groups offers the benefits of easier
reporting and action, such as QoS policies. Indeed, most
applications with the same characteristics should be treated the
same way; for example, all video traffic.
Attributes are statically assigned per application tag and are
independent of the traffic. The attributes are listed below:
Name Description
Category An attribute that provides a first
level categorization for each
application tag. Examples include:
browsing, email, file-sharing,
gaming, instant messaging, voice-
and-video, etc...
The category attribute is encoded by
the ApplicationCategoryName
Information Element.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 16]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
Sub-Category An attribute that provides a second
level categorization for each
application tag. Examples include:
backup-systems, client-server,
database, routing-protocol, etc...
The sub-category attribute is
encoded by the
ApplicationSubCategoryName
Information Element.
Application- An attribute that groups multiple
Group application tags that belong to the
same networking application. For
example, the ftp-group contain the
ftp-data (port 20), ftp (port 20),
ni-ftp (port 47), sftp (port 115),
bftp (port 152), ftp-agent(port
574), ftps-data (port 989). The
application-group attribute is
encoded by the ApplicationGroupName
Information Element.
P2P-Technology Specifies if the application tag is
based on peer-to-peer technology.
The P2P-technology attribute is
encoded by the p2pTechnology
Information Element.
Tunnel- Specifies if the application tag is
Technology used as a tunnel technology. The
tunnel-technology attribute is
encoded by the tunnelTechnology
Information Element.
Encrypted Specifies if the application tag is
an encrypted networking protocol.
The encrypted attribute is encoded
by the encryptedTechnology
Information Element.
Table 4: Existing Application Tag Static Attributes
Every application is assigned to one ApplicationCategoryName,
one ApplicationSubCategoryName, one ApplicationGroupName, has
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 17]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
one p2pTechnology, one tunnelTechnology, and one
encryptedTechnology.
5.1. Options Template Record for the Attribute Values
An Options Template Record (see [RFC5101]) is used to export the
correspondence between each Application Tag and its related
Attribute values. An alternative way for the Collecting Process
to learn the correspondence is to populate these mappings out of
band, for example, by loading a CSV file containing the
correspondence table.
The Attributes Option Template contains the ApplicationTag as a
scope field, followed by the ApplicationCategoryName, the
ApplicationSubCategoryName, the ApplicationGroupName, the
p2pTechnology, the tunnelTechnology, and the encryptedTechnology
Information Elements.
A list of attributes may conveniently be exported using a
subTemplateList per [RFC6313].
An example is given in section 6.8. below.
6. Application Tag Examples
The following examples are created solely for the purpose of
illustrating how the extensions proposed in this document are
encoded.
6.1. Example 1: Layer 2 Protocol
The list of Classification Engine IDs in Table 1 shows that the
layer 2 Classification Engine IDs are 12, 18, and 19.
From the Ethertype list, LLDP has the Selector ID value 0x88CC,
so 35020 in decimal:
NAME Selector ID
LLDP 35020
So, in the case of LLDP, the Classification Engine ID is 18
while the Selector ID has the value 35020.
Therefore the Application Tag is encoded as:
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 18]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 18 | 35020 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So the Application Tag has the decimal value of 1214668. Instead
of representing the Application Tag in hexadecimal format, the
format '18..35020' is used for simplicity in the examples below.
Flexible NetFlow creates a Template Record with a few
Information Elements: amongst other things, the Application Tag.
For example:
- applicationTag (key field)
- octetTotalCount (non key field)
For example, a Flow Record corresponding to the above Template
Record may contain:
{ applicationTag='18..35020',
octetTotalCount=123456 }
The Collector has all the required information to determine that
the application is LLDP, because the Application Tag uses a
global and well know registry, ie the Ethertype.
The Collector can determine which application is represented by
the Application Tag by loading the registry out of band.
6.2. Example 2: Standardized IANA Layer 3 Protocol
From the list of Classification Engine IDs in Table 1, the IANA
layer 3 Classification Engine ID is 1:
IANA- 1 The IANA protocol (layer 3) number is
L3 exported in the Selector ID.
See [IANA-PROTO].
From the list of IANA layer 3 protocols (see [IANA-PROTO]), ICMP
has the value 1:
Decimal Keyword Protocol Reference
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 19]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
1 ICMP Internet Control Message [RFC792]
So in the case of the standardized IANA layer 3 protocol ICMP,
the Classification Engine ID is 1, and the Selector ID has the
value of 1.
Therefore the Application Tag is encoded as:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So the Application Tag has the value of 257. Instead of
representing the Application Tag in hexadecimal format, the
format '1..1' is used for simplicity in the examples below.
Flexible NetFlow creates a Template Record with a few
Information Elements: amongst other things, the Application Tag.
For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- ipDiffServCodePoint (key field)
- applicationTag (key field)
- octetTotalCount (non key field)
For example, a Flow Record corresponding to the above Template
Record may contain:
{ sourceIPv4Address=192.0.2.1,
destinationIPv4Address=192.0.2.2,
ipDiffServCodePoint=0,
applicationTag='1..1',
octetTotalCount=123456 }
The Collector has all the required information to determine that
the application is ICMP, because the Application Tag uses a
global and well know registry, ie the IANA L3 protocol number.
6.3. Example 3: Cisco Systems Proprietary Layer 3 Protocol
Assume that Cisco Systems has specified a new layer 3 protocol
called "foo".
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 20]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
From the list of Classification Engine IDs in Table 1, the Cisco
Systems layer 3 Classification Engine ID is 2:
CANA- 2 Cisco Systems proprietary layer 3
L3 definition. Cisco Systems can still export
its own layer 3 protocol numbers, while
waiting for IANA to assign it. The
Selector ID has a global significance for
all Cisco Systems devices under CANA
governance. Hopefully the same IDs will be
maintained after the IANA standardization.
A global registry within Cisco Systems specifies that the "foo"
protocol has the value 90:
Protocol Protocol Id
foo 90
So in the case of Cisco Systems layer 3 protocol foo, the
Classification Engine ID is 2, and the Selector ID has the value
of 90.
Therefore the Application Tag is encoded as:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 90 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So the Application Tag has the value of 602. Instead of
representing the Application Tag in hexadecimal format, the
format '2..90' is used for simplicity in the examples below.
Flexible NetFlow creates a Template Record with a few
Information Elements: amongst other things, the Application Tag.
For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- ipDiffServCodePoint (key field)
- applicationTag (key field)
- octetTotalCount (non key field)
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 21]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
For example, a Flow Record corresponding to the above Template
Record may contain:
{ sourceIPv4Address=192.0.2.1,
destinationIPv4Address=192.0.2.2,
ipDiffServCodePoint=0,
applicationTag='2..90',
octetTotalCount=123456 }
Along with this Flow Record, a new Options Template Record would
be exported, as shown in Section 6.7.
6.4. Example 4: Standardized IANA Layer 4 Port
From the list of Classification Engine IDs in Table 1, the IANA
layer 4 Classification Engine ID is 3:
IANA- 3 IANA layer 4 well-known port number is
L4 exported in the selector ID.
See [IANA-PORTS].
Note: as a flow is unidirectional, it
contains the destination port in a flow
from the client to the server.
From the list of IANA layer 4 ports (see [IANA-PORTS]), SNMP has
the value 161:
Keyword Decimal Description
snmp 161/tcp SNMP
snmp 161/udp SNMP
So in the case of the standardized IANA layer 4 SNMP port, the
Classification Engine ID is 3, and the Selector ID has the value
of 161.
Therefore the Application Tag is encoded as:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 22]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
| 3 | 161 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flexible NetFlow creates a Template Record with a few
Information Elements: amongst other things, the Application Tag.
For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- protocol (key field)
- ipDiffServCodePoint (key field)
- applicationTag (key field)
- octetTotalCount (non key field)
For example, a Flow Record corresponding to the above Template
Record may contain:
{ sourceIPv4Address=192.0.2.1,
destinationIPv4Address=192.0.2.2,
protocol=17, ipDiffServCodePoint=0,
applicationTag='3..161',
octetTotalCount=123456 }
The Collector has all the required information to determine that
the application is SNMP, because the Application Tag uses a
global and well know registry, ie the IANA L4 protocol number.
6.5. Example 4: Layer 7 Application
In this example, the Metering Process has observes some Citrix
traffic.
From the list of Classification Engine IDs in Table 1, the L7
unique Classification Engine ID is 13:
L7 13 The Selector ID represents the Cisco Systems
unique global ID for the layer 7
application. The Selector ID has a global
significance for all Cisco Systems devices.
Suppose that the Metering Process returns the ID 10000 for
Citrix traffic.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 23]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
So, in the case of this Citrix application, the Classification
Engine ID is 13 and the Selector ID has the value of 10000.
Therefore the Application Tag is encoded as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 13 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So the Application Tag has the value of '13..10000'.
Note that the figure shows that the Exporting Process exports
the value 10000 in 7 bytes: this is pure speculation. However,
it doesn't matter as the applicationTag would be exported in a
variable length Information Element.
Flexible NetFlow creates a Template Record with a few
Information Elements: amongst other things, the Application Tag.
For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- ipDiffServCodePoint (key field)
- applicationTag (key field)
- octetTotalCount (non key field)
For example, a Flow Record corresponding to the above Template
Record may contain:
{ sourceIPv4Address=192.0.2.1,
destinationIPv4Address=192.0.2.2,
ipDiffServCodePoint=0,
applicationTag='13..10000',
octetTotalCount=123456 }
The 10000 value is globally unique within Cisco Systems, so the
Collector can determine which application is represented by the
Application Tag by loading the registry out of band.
Along with this Flow Record, a new Options Template Record would
be exported, as shown in Section 6.7.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 24]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
6.6. Example: port Obfuscation
For example, a HTTP server might run a TCP port 23 (assigned to
telnet in [IANA-PORTS]). If the Metering Process is capable of
detecting HTTP in the same case, the Application Tag
representation must contain HTTP. However, if the reporting
application wants to determine whether or the default HTTP port
80 or 8080 was used, it must export the destination port
(destinationTransportPort at [IANA-IPFIX]) in the corresponding
NetFlow record.
In the case of a standardized IANA layer 4 port, the
Classification Engine ID is 2, and the Selector ID has the value
of 80 for HTTP (see [IANA-PORTS]).
Therefore the Application Tag is encoded as:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flexible NetFlow creates a Template Record with a few
Information Elements: amongst other things, the Application Tag.
For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- protocol (key field)
- destinationTransportPort (key field)
- applicationTag (key field)
- octetTotalCount (non key field)
For example, a Flow Record corresponding to the above Template
Record may contain:
{ sourceIPv4Address=192.0.2.1,
destinationIPv4Address=192.0.2.2,
protocol=17,
destinationTransportPort=23,
applicationTag='3..80',
octetTotalCount=123456 }
The Collector has all the required information to determine that
the application is HTTP, but runs on port 23.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 25]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
6.7. Example: Application Mapping Options Template
Along with the Flow Records shown in the above examples, a new
Options Template Record would be exported to express the
Application Name and Application Description associated with
each Application Tag.
The Options Template Record contains the following Information
Elements:
1. Scope = applicationTag.
From RFC 5101: "The scope, which is only available in the
Options Template Set, gives the context of the reported
Information Elements in the Data Records."
2. applicationName.
3. applicationDescription.
The Options Data Record associated with the examples above would
contain, for example:
{ scope=applicationTag='2..90',
applicationName="foo",
applicationDescription="The Cisco foo protocol",
scope=applicationTag='13..10000',
applicationName="Citrix",
applicationDescription="A Citrix application" }
When combined with the example Flow Records above, these Options
Template Records tell the NetFlow collector:
1. A flow of 123456 bytes exists from sourceIPv4Address
192.0.2.1 to destinationIPv4address 192.0.2.2 with a DSCP value
of 0 and an applicationTag of '12..90', which maps to the "foo"
application.
2. A flow of 123456 bytes exists from sourceIPv4Address
192.0.2.1 to destinationIPv4address 192.0.2.2 with a DSCP value
of 0 and an Application Tag of '13..10000', which maps to the
"Citrix" application.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 26]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
6.8. Example: Attributes Values Options Template Record
Along with the Flow Records shown in the above examples, a new
Options Template Record is exported to express the values of the
different attributes related to the Application Tags.
The Options Template Record would contain the following
Information Elements:
1. Scope = applicationTag.
From RFC 5101: "The scope, which is only available in the
Options Template Set, gives the context of the reported
Information Elements in the Data Records."
2. applicationCategoryName.
3. applicationSubCategoryName.
4. applicationGroupName
5. p2pTechnology
6. tunnelTechnology
7. encryptedTechnology
The Options Data Record associated with the examples above would
contain, for example:
{ scope=applicationTag='2..90',
applicationCategoryName="foo-category",
applicationSubCategoryName="foo-subcategory",
applicationGroupName="foo-group",
p2pTechnology=NO
tunnelTechnology=YES
encryptedTechnology=NO
When combined with the example Flow Records above, these Options
Template Records tell the NetFlow collector:
A flow of 123456 bytes exists from sourceIPv4Address 192.0.2.1
to destinationIPv4address 192.0.2.2 with a DSCP value of 0 and
an applicationTag of '12..90', which maps to the "foo"
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 27]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
application. This application can be characterized by the
relevant attributes values.
7. IANA Considerations
This document specifies 9 new IPFIX Information Elements: the
applicationDescription, applicationTag, applicationName,
classificationEngineId, applicationCategoryName,
applicationSubCategoryName, applicationGroupName, p2pTechnology,
tunnelTechnology, and encryptedTechnology.
New Information Elements to be added to the IPFIX Information
Element registry at [IANA-IPFIX] are listed below.
EDITOR'S NOTE: the XML specification in Appendix A must be updated
with the elementID values allocated below.
7.1. applicationDescription
Name: applicationDescription
Description:
Specifies the description of an application.
Abstract Data Type: string
Data Type Semantics:
ElementId: 94
Status: current
7.2. applicationTag
Name: applicationTag
Description:
Specifies an Application Tag.
Abstract Data Type: octetArray
Data Type Semantics: identifier
Reference: See section 4. of [EDITORS NOTE: this document] for the
applicationTag Information Element Specification.
ElementId: 95
Status: current
7.3. applicationName
Name: applicationName
Description:
Specifies the name of an application.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 28]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
Abstract Data Type: string
Data Type Semantics:
ElementId: 96
Status: current
7.4. classificationEngineId
Name: classificationEngineId
Description:
Specifies the classification engine according to Table 1 in
[EDITORS NOTE: this document].
Abstract Data Type: unsigned8
Data Type Semantics: identifier
ElementId: 101
Status: current
7.5. applicationCategoryName
Name: applicationCategoryName
Description:
An attribute that provides a first level categorization for each
Application Tag.
Abstract Data Type: string
Data Type Semantics:
ElementId: <to be assigned>
Status: current
7.6. applicationSubCategoryName
Name: applicationSubCategoryName
Description:
An attribute that provides a second level categorization for
each Application Tag
Abstract Data Type: string
Data Type Semantics:
ElementId: <to be assigned>
Status: current
7.7. applicationGroupName
Name: applicationGroupName
Description:
An attribute that groups multiple Application Tags that belong
to the same networking application
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 29]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
Abstract Data Type: string
Data Type Semantics:
ElementId: <to be assigned>
Status: current
7.8. p2pTechnology
Name: p2pTechnology
Description:
Specifies if the Application Tag is based on peer-to-peer
technology. Possible values are: "yes", "no", and "unassigned"
Abstract Data Type: string
Data Type Semantics:
ElementId: 288
Status: current
7.9. tunnelTechnology
Name: tunnelTechnology
Description:
Specifies if the application tag is used as a tunnel technology.
Possible values are: "yes", "no", and "unassigned"
Abstract Data Type: string
Data Type Semantics:
ElementId: 289
Status: current
7.10. encryptedTechnology
Name: encryptedTechnology
Description:
Specifies if the application tag is an encrypted networking
protocol. Possible values are: "yes", "no", and "unassigned"
Abstract Data Type: string
Data Type Semantics:
ElementId: 290
Status: current
8. Security Considerations
The same security considerations as for the IPFIX Protocol
[RFC5101] apply.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 30]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
9. References
9.1. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997.
[RFC5101] Claise, B., Ed., "Specification of the IP Flow
Information Export (IPFIX) Protocol for the Exchange of
IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and
J. Meyer, "Information Model for IP Flow Information
Export", RFC 5102, January 2008.
9.2. Informative References
[RFC792] J. Postel, Internet Control Message Protocol, RFC 792,
September 1981.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
Requirements for IP Flow Information Export, RFC 3917,
October 2004.
[RFC5103] Trammell, B., and E. Boschi, "Bidirectional Flow
Export Using IP Flow Information Export (IPFIX)", RFC
5103, January 2008.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J.
Quittek, "Architecture for IP Flow Information Export",
RFC 5470, March 2009.
[RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines
for IP Flow Information Export (IPFIX) Testing", RFC
5471, March 2009.
[RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing
Redundancy in IP Flow Information Export (IPFIX) and
Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
[RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol
Specifications", RFC 5476, March 2009.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 31]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
[RFC6313] Claise, B., Dhandapani, G. Aitken, P., and S. Yates,
"Export of Structured Data in IP Flow Information
Export (IPFIX)", RFC6313, July 20111
[IANA-IPFIX] http://www.iana.org/assignments/ipfix/ipfix.xml
[IANA-PORTS] http://www.iana.org/assignments/port-numbers
[IANA-PROTO] http://www.iana.org/assignments/protocol-numbers
[ETHERTYPE]
http://standards.ieee.org/develop/regauth/ethertype/eth
.txt
[LLC] http://standards.ieee.org/develop/regauth/llc/public.html.
[CISCO] http://www.cisco.com
10. Acknowledgement
The authors would like to thank their many colleagues across Cisco
Systems who made this work possible. Specifically Patrick Wildi
for his time and expertise.
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 32]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
11. Authors' Addresses
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem 1813
Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Paul Aitken
Cisco Systems, Inc.
96 Commercial Quay
Commercial Street
Edinburgh, EH6 6LX, United Kingdom
Phone: +44 131 561 3616
EMail: paitken@cisco.com
Nir Ben-Dvora
Cisco Systems, Inc.
32 HaMelacha St.,
P.O.Box 8735, I.Z.Sapir
South Netanya, 42504
Israel
Phone: +972 9 892 7187
EMail: nirbd@cisco.com
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 33]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
Appendix A. Additions to XML Specification of IPFIX Information
Elements
This appendix contains additions to the machine-readable
description of the IPFIX information model coded in XML in
Appendix A and Appendix B in [RFC5102]. Note that this appendix
is of informational nature, while the text in Section 7.
(generated from this appendix) is normative.
The following field definitions are appended to the IPFIX
information model in Appendix A of [RFC5102].
<field name="applicationDescription"
dataType="string"
group="application"
elementId="94" applicability="all" status="current">
<description>
<paragraph>
Specifies the description of an application.
</paragraph>
</description>
</field>
<field name="applicationTag"
dataType="octetArray"
group="application"
dataTypeSemantics="identifier"
elementId="95" applicability="all" status="current">
<description>
<paragraph>
Specifies an Application Tag.
</paragraph>
</description>
<reference>
<paragraph>
See section 4. of [EDITORS NOTE: this document] for the
applicationTag Information Element Specification.
</paragraph>
</reference>
</field>
<field name="applicationName"
dataType="string"
group="application"
elementId="96" applicability="all" status="current">
<description>
<paragraph>
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 34]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
Specifies the name of an application.
</paragraph>
</description>
</field>
<field name="classificationEngineId"
dataType="unsigned8"
group="application"
dataTypeSemantics="identifier"
elementId="101" applicability="all" status="current">
<description>
<paragraph>
Specifies the classification engine according to Table
1 in [EDITORS NOTE: this document].
</paragraph>
</description>
</field>
<field name="applicationCategoryName"
dataType="string"
group="application"
elementId="<to be assigned>" applicability="all"
status="current">
<description>
<paragraph>
An attribute that provides a first level categorization
for each Application Tag.
</paragraph>
</description>
</field>
<field name="applicationSubCategoryName"
dataType="string"
group="application"
elementId="<to be assigned>" applicability="all"
status="current">
<description>
<paragraph>
An attribute that provides a second level
categorization for each Application Tag.
</paragraph>
</description>
</field>
<field name="applicationGroupName"
dataType="string"
group="application"
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 35]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
elementId="<to be assigned>" applicability="all"
status="current">
<description>
<paragraph>
An attribute that groups multiple Application Tags
that belong to the same networking application.
</paragraph>
</description>
</field>
<field name="p2pTechnology"
dataType="string"
group="application"
elementId="288" applicability="all" status="current">
<description>
<paragraph>
Specifies if the Application Tag is based on peer-
to-peer technology. Possible values are: "yes",
"no", and "unassigned".
</paragraph>
</description>
</field>
<field name="tunnelTechnology"
dataType="string"
group="application"
elementId="289" applicability="all" status="current">
<description>
<paragraph>
Specifies if the application tag is used as a
tunnel technology. Possible values are: "yes",
"no", and "unassigned".
</paragraph>
</description>
</field>
<field name="encryptedTechnology"
dataType="string"
group="application"
elementId="290" applicability="all" status="current">
<description>
<paragraph>
Specifies if the application tag is an encrypted
networking protocol. Possible values are: "yes",
"no", and "unassigned".
</paragraph>
</description>
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 36]
Internet-Draft <Export of App. Info. in IPFIX > Nov 2011
</field>
<Claise, Aitken, Ben-Dvora> Expires May 29 2011 [Page 37]
| PAFTECH AB 2003-2026 | 2026-04-23 14:54:51 |