IPFIX Working Group B. Claise
Internet-Draft P. Aitken
Intended Status: Informational N. Ben-Dvora
Expires: January 8, 2013 Cisco Systems, Inc.
July 9, 2012
Cisco Systems Export of Application Information in IPFIX
draft-claise-export-application-info-in-ipfix-09
Status of this Memo
This document is not an Internet Standards Track
specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task
Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been
approved for publication by the Internet Engineering
Steering Group (IESG). Not all documents approved by the
IESG are a candidate for any level of Internet Standard;
see Section 2 of RFC 5741.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained
at http://www.rfc-editor.org/info/rfc<rfc-no>.
EDITOR NOTES: The above text is the consensus from the IESG
meeting regarding this document. Note that the <RFC-no>
must be updated. The text below has been kept for
completeness.
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
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 1]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
This Internet-Draft will expire on January 8, 2013.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 2]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
Copyright Notice
Copyright (c) 2012 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 Cisco Systems 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 Jan 8 2013 [Page 3]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
Table of Contents
1. Overview................................................. 5
1.1. IPFIX Documents Overview............................ 5
2. Introduction............................................. 6
2.1. Application Information Use Cases...................... 8
3. Terminology.............................................. 8
3.1. New Terminology..................................... 9
4. applicationId Information Element Specification.......... 9
4.1. Existing Classification Engine IDs................. 10
4.2. Selector ID Length per Classification IDs.......... 14
4.3. Application Name Options Template Record........... 15
4.4. Resolving IANA L4 Port Discrepancies............... 16
5. Grouping the Applications with the Attributes........... 16
5.1. Options Template Record for the Attribute Values... 18
6. Application Id Examples................................. 18
6.1. Example 1: Layer 2 Protocol........................ 19
6.2. Example 2: Standardized IANA Layer 3 Protocol...... 20
6.3. Example 3: Proprietary Layer 3 Protocol............ 21
6.4. Example 4: Standardized IANA Layer 4 Port.......... 22
6.5. Example 5: Layer 7 Application..................... 23
6.6. Example 6: Layer 7 Application with Private
Enterprise Number (PEN)................................. 24
6.7. Example: port Obfuscation.......................... 26
6.8. Example: Application Name Mapping Options Template. 27
6.9. Example: Attributes Values Options Template Record. 28
7. IANA Considerations..................................... 29
7.1. New Information Elements........................... 29
7.1.1. applicationDescription........................... 30
7.1.2. applicationId.................................... 30
7.1.3. applicationName.................................. 30
7.1.4. classificationEngineId........................... 30
7.1.5. applicationCategoryName.......................... 33
7.1.6. applicationSubCategoryName....................... 33
7.1.7. applicationGroupName............................. 34
7.1.8. p2pTechnology.................................... 34
7.1.9. tunnelTechnology................................. 34
7.1.10. encryptedTechnology............................. 34
7.2. Classification Engine Ids Registry................. 35
8. Security Considerations................................. 35
9. References.............................................. 36
9.1. Normative References............................... 36
9.2. Informative References............................. 36
10. Acknowledgement........................................ 38
11. Authors' Addresses..................................... 39
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 4]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
Appendix A. Additions to XML Specification of IPFIX
Information Elements (non normative)....................... 39
Appendix B. Port Collisions Tables (non normative)........ 45
Appendix C. Application Registry Example (non
normative)................................................. 49
List of Figures and Tables
Figure 1: applicationId Information Element .............. 9
Table 1: Existing Classification Engine IDs ............. 13
Table 2: Selector ID default length per Classification
Engine ID ............................................ 14
Table 3: Application Id Static Attributes ............... 18
Table 4: Different Protocols on UDP and TCP ............. 47
Table 5: Different Protocols on SCTP and TCP ............ 49
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
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 5]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
[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.
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 web applications, peer to
peer applications, file transfer, e-mail applications,
etc.). Applications can be further characterized by other
criteria, some of which are application specific.
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 several
different methods or even a combination of methods:
1. L2 (Layer 2) protocols (such as ARP (Address Resolution
Protocol), PPP (Point-to-Point Protocol), LLDP (Link
Layer Discovery Protocol))
2. IP protocols (such as ICMP (Internet Control Message
Protocol), IGMP (Internet Group Management Protocol),
GRE (Generic Routing Encapsulation)
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
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 6]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
The exact application identification methods are part of
the Metering Process internals that aim to provide an
accurate identification and minimize 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 runs on different port than the IANA
assigned one. For example an HTTP server might
run a TCP port 23 (assigned to telnet in [IANA-
PORTS])
2. IANA port registries do 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
applications based on multiple mechanisms in parallel.
Detection based only on port matching might wrongly identify
the application. If the Metering Process is capable of
detecting applications more accurately, it is considered to
be stronger and more accurate.
Similarly, a reporting mechanism that uses L4 port based
applications only, such as L4:<known port>, would have
similar issues. The reporting system should be capable of
reporting the applications classified using all types of
mechanisms. In particular applications that do not have
any IANA port definition. While a mechanism to export
application information should be defined, the L4 port
being used must be exported using the destination port
(destinationTransportPort at [IANA-IPFIX]) in the
corresponding IPFIX record.
This document specifies the Cisco Systems application
information encoding (as described in section 4. ) to
export the application information with the IPFIX protocol
[RFC5101].
Applications could be identified at different OSI layers,
from layer 2 to layer 7. For example: Link Layer
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 7]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
Distribution Protocol (LLDP) [LLDP] can be identified in
layer 2, ICMP can be identified in layer 3 [IANA-PROTO],
HTTP can be identified in layer 4 [IANA-PORTS], and Webex
can be identified in 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. Indeed, the specifications for some applications
embedded in the payload are not available. Some reverse
engineering as well as a ubiquitous language for
application identification, would be required conditions to
be able to manage an IANA registry for these types of
applications. Clearly, these are blocking factors.
This document specifies the Cisco Systems application
information encoding. However, the layer 7 application
registry values are out of scope of this document.
2.1. Application Information Use Cases
There are several use cases for application information:
1. Application Visibility
This is one of the main cases for using the application
information. Network administrators are using
application visibility to understand the main network
consumers, network trends and user behavior.
2. 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 application
information to provide the network function itself or to
log the network function operation.
3. Terminology
IPFIX-specific terminology used in this document is defined
in Section 2 of the IPFIX protocol specification [RFC5101].
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 8]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
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 Id
A unique identifier for an application.
When an application is detected, the most granular
application is encoded in the Application Id.
4. applicationId Information Element Specification
This document specifies the applicationId Information
Element, which is a single field composed of two parts:
1. 8 bits of Classification Engine ID. The
Classification Engine can be considered as a
specific registry for application assignments.
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: applicationId 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.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 9]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
Selector ID
A unique identifier of the application for a specific
Classification Engine ID. Note that the Selector ID
length varies depending on the Classification Engine
ID.
The Selector ID term is similar in concepts with the
selectorId Information Element, specified in the PSAMP
Protocol [RFC5476][RFC5477].
4.1. Existing Classification Engine IDs
The following Classification Engine IDs have been
allocated:
Name Value Description
0 Invalid.
IANA-L3 1 The Assigned Internet Protocol
Number (layer 3 (L3)) is exported
in the Selector ID.
See [IANA-PROTO].
PANA-L3 2 Proprietary layer 3 definition.
An enterprise can export its own
layer 3 protocol numbers. The
Selector ID has a global
significance for all devices from
the same enterprise.
IANA-L4 3 The IANA layer 4 (L4) well-known
port number is exported in the
Selector ID. See [IANA-PORTS].
Note: as an IPFIX flow is
unidirectional, it contains the
destination port in a flow from
the client to the server.
PANA-L4 4 Proprietary layer 4 definition.
An enterprise can export its own
layer 4 port numbers. The
Selector ID has global
significance for devices from the
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 10]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
same enterprise. Example: IPFIX
had the port 4739 pre-assigned in
the IETF draft for years. While
waiting for the RFC and its
associated IANA registration, the
Selector ID 4739 was used with
this PANA-L4.
5 Reserved.
USER- 6 The Selector ID represents
Defined applications defined by the user
(using CLI, GUI, etc.) based on
the methods described in section
2. The Selector ID has a local
significance per device.
7 Reserved.
8 Reserved.
9 Reserved.
10 Reserved.
11 Reserved.
PANA-L2 12 Proprietary layer 2 (L2)
definition. An enterprise can
export its own layer 2
identifiers. The Selector ID
represents the enterprise's
unique global layer 2
applications. The Selector ID has
a global significance for all
devices from the same enterprise.
Examples include Cisco Subnetwork
Access Protocol (SNAP).
PANA-L7 13 Proprietary layer 7 definition.
The Selector ID represents the
enterprise's unique global ID for
the layer 7 applications. The
Selector ID has a global
significance for all devices from
the same enterprise. This
Classification Engine Id is used
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 11]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
when the application registry is
owned by the Exporter
manufacturer (referred to as the
"enterprise" in this document).
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.
PANA-L7- 20 Proprietary layer 7 definition,
PEN including a Private Enterprise
Number (PEN) [PEN] to identify
that the application registry
being used is not owned by the
Exporter manufacturer (referred
to as the "enterprise" in this
document, and identified by the
PEN), or to identify the original
enterprise in the case of a
mediator or 3rd party device. The
Selector ID represents the
enterprise unique global ID for
the layer 7 applications. The
Selector ID has a global
significance for all devices from
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 12]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
the same enterprise.
21 to
255 Available (255 is the maximum
Engine ID)
Table 1: Existing Classification Engine IDs
"PANA = Proprietary Assigned Number Authority". In other
words, an enterprise specific version of IANA for
internal IDs.
The PANA-L7 Classification Engine ID SHOULD be used when
the application registry is owned by the Exporter
manufacturer, referred to as the "enterprise" in this
document, and identified by the PEN. Even if the
application registry is owned by the Exporter
manufacturer, the PANA-L7-PEN MAY be used, specifying the
manufacturer.
The mechanism for the Collector to know about Exporter
PEN is out of scope of this document. Possible tracks
are: SNMP polling, an Options Template export, hardcoded
value, etc.
An Exporter may classify the application according to
another vendor's application registry. E.g., an IPFIX
Mediator [RFC6183] may need to re-export applications
received from different Exporters using different PANA-L7
application registries. For example, X's IPFIX Mediator
aggregates traffic from some Exporters which report
enterprise Y applications and other Exporters which
report enterprise Z applications. Or, X's device
implements enterprise Y's application classifications.
In these cases, the PANA-L7-PEN Classification Engine
MUST be used, which allows the original enterprise ID to
be reported. The ID of the enterprise which defined the
application ID is identified by the enterprise's PEN. An
example is displayed in section 6.6.
Note that the the PANA-L7 Classification Engine ID is
also used for resolving IANA L4 port Discrepancies (see
Section 4.4)
The list in table 1 is maintained by IANA thanks to the
registry within the classificationEngineId Information
Element. See the "IANA Considerations" section. The
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 13]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
Classification Engine Id is part of the Application Id
encoding, so the classificationEngineId Information
Element is currently not required by the specifications
in this document. However, this Information Element was
created for completeness, as it was anticipated that this
Information Element will be required in the future.
4.2. Selector ID Length per Classification IDs
As the Selector Id part of the Application Id is variable
based on the Classification Engine ID value, the
applicationId SHOULD be encoded in a variable-length
Information Element [RFC5101] for the IPFIX export.
The following table displays the Selector ID default
length for the different Classification Engine IDs.
Classification Selector ID default
Engine ID Name length (in bytes)
IANA-L3 1
PANA-L3 1
IANA-L4 2
PANA-L4 2
USER-Defined 3
PANA-L2 5
PANA-L7 3
ETHERTYPE 2
LLC 1
PANA-L7-PEN 3 (*)
Table 2: Selector ID default length
per Classification Engine ID
(*) There is an extra 4 bytes for the PEN. However, the PEN
is not considered part of the Selector ID.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 14]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
If a legacy protocol such as NetFlow version 9 [RFC3954] is
used, and this protocol doesn't support variable length
Information Elements, then either multiple Template Records
(one per applicationId length), or a single Template Record
corresponding to the maximum sized applicationId MUST be
used.
Application Ids MAY be encoded in a smaller number of
bytes, following the same rules as for the IPFIX Reduced
Size Encoding [RFC5101].
Application Ids MAY be encoded with a larger length.
For example, a normal IANA L3 protocol encoding would take
2 bytes since the Selector ID represents the protocol field
from the IP header encoded in one byte. However, an IANA
L3 protocol encoding may be encoded with 3 bytes. In this
case, the Selector ID value MUST always be encoded in the
least significant bits as shown in Figure 2.
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.3. Application Name Options Template Record
For Classification Engines which specify locally unique
Application Ids (which means unique per engine and per
router), an Options Template Record (see [RFC5101]) MUST
be used to export the correspondence between the
Application Id, the Application Name, and the Application
Description.
For Classification Engines which specify globally unique
Application Ids, an Options Template Record MAY be used
to export the correspondence between the Application Id,
the Application Name and the Application Description,
unless the mapping is hardcoded in the Collector, or
known out of band (for example, by polling a MIB).
An example Options Template is shown in section 6.8.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 15]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
Enterprises may assign company-wide Application Id values
for the PANA-L7 Classification Engine. In this case, a
possible optimization for the Collector is to keep the
mappings between the Application Ids and the Application
Names per enterprise, as opposed to per Exporter.
4.4. Resolving IANA L4 Port Discrepancies
Even though the IANA L4 ports usually point to the same
protocols for both UDP, TCP or other transport types, there
are some exceptions, as mentioned in the Appendix B.
Instead of imposing the transport protocol
(UDP/TCP/SCTP/etc.) in the scope of the "Application Name
Options Template Record" (section 6.8. ) 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 3 and the SCTP L4 applications from
Table 4 are assigned in the PANA_L7 Application Id range,
i.e. 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 Ids,
Application Ids MAY be categorized into groups. This 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 Id 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 Id. Examples include:
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 16]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
browsing, email, file-sharing,
gaming, instant messaging, voice-
and-video, etc...
The category attribute is encoded by
the ApplicationCategoryName
Information Element.
Sub-Category An attribute that provides a second
level categorization for each
Application Id. 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 Ids 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 Id is
based on peer-to-peer technology.
The P2P-technology attribute is
encoded by the p2pTechnology
Information Element.
Tunnel- Specifies if the Application Id is
Technology used as a tunnel technology. The
tunnel-technology attribute is
encoded by the tunnelTechnology
Information Element.
Encrypted Specifies if the Application Id is
an encrypted networking protocol.
The encrypted attribute is encoded
by the encryptedTechnology
Information Element.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 17]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
Table 3: Application Id Static Attributes
Every application is assigned to one
ApplicationCategoryName, one ApplicationSubCategoryName,
one ApplicationGroupName, has one p2pTechnology, one
tunnelTechnology, and one encryptedTechnology. These new
Information Elements are specified in the IANA
Consideration Section 7.1. 7.1.
Maintaining the attribute values in IANA seems impossible
to realize. Therefore the attribute values per application
are enterprise specific.
5.1. Options Template Record for the Attribute Values
An Options Template Record (see [RFC5101]) SHOULD be used
to export the correspondence between each Application Id
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 ApplicationId
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.9.
6. Application Id Examples
The following examples are created solely for the purpose
of illustrating how the extensions proposed in this
document are encoded.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 18]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
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 (PANA-L2), 18,
(Ethertype) and 19 (LLC).
From the Ethertype list, LLDP [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
(LLC) while the Selector ID has the value 35020.
Per section 4. , the applicationId Information Element,
is a single field composed of 8 bits of Classification
Engine ID, followed by m bits of Selector ID.
Therefore the Application Id 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 18 | 35020 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
So the Application Id has the decimal value of 1214668.
The format '18..35020' is used for simplicity in the
examples below, to clearly express that two components of
the Application ID.
The Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application
Id. For example:
- applicationId (key field)
- octetTotalCount (non key field)
For example, a Flow Record corresponding to the above
Template Record may contain:
{ applicationId='18..35020',
octetTotalCount=123456 }
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 19]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
The Collector has all the required information to determine
that the application is LLDP, because the Application Id
uses a global and well known registry, i.e. the Ethertype.
The Collector can determine which application is
represented by the Application Id 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 (IANA-L3) is 1.
From the list of IANA layer 3 protocols (see [IANA-PROTO]),
ICMP has the value 1:
Decimal Keyword Protocol Reference
1 ICMP Internet Control [RFC792]
Message
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 Id 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 Id has the value of 257. The format
'1..1' is used for simplicity in the examples below.
The Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application
Id. For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- ipDiffServCodePoint (key field)
- applicationId (key field)
- octetTotalCount (non key field)
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 20]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
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,
applicationId='1..1',
octetTotalCount=123456 }
The Collector has all the required information to determine
that the application is ICMP, because the Application Id
uses a global and well know registry, ie the IANA L3
protocol number.
6.3. Example 3: Proprietary Layer 3 Protocol
Assume that a enterprise has specified a new layer 3
protocol called "foo".
From the list of Classification Engine IDs in Table 1, the
proprietary layer 3 Classification Engine ID (PANA-L3) is
2.
A global registry within the enterprise specifies that the
"foo" protocol has the value 90:
Protocol Protocol Id
foo 90
So, in the case of the layer 3 protocol foo specified by
this enterprise, the Classification Engine ID is 2, and the
Selector ID has the value of 90.
Therefore the Application Id 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 Id has the value of 602. The format
'2..90' is used for simplicity in the examples below.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 21]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
The Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application
Id. For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- ipDiffServCodePoint (key field)
- applicationId (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,
applicationId='2..90',
octetTotalCount=123456 }
Along with this Flow Record, a new Options Template Record
would be exported, as shown in Section 6.8.
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 (PANA-L3) is 3.
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 Id is encoded as:
0 1
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 | 161 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 22]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
So the Application Id has the value of 196769. The format
'3..161' is used for simplicity in the examples below.
The Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application
Id. For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- protocol (key field)
- ipDiffServCodePoint (key field)
- applicationId (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,
applicationId='3..161',
octetTotalCount=123456 }
The Collector has all the required information to determine
that the application is SNMP, because the Application Id
uses a global and well know registry, ie the IANA L4
protocol number.
6.5. Example 5: Layer 7 Application
In this example, the Metering Process has observed some
Webex traffic.
From the list of Classification Engine IDs in Table 1, the
layer 7 unique Classification Engine ID (PANA-L7) is 13.
Suppose that the Metering Process returns the ID 10000 for
Webex traffic.
So, in the case of this Webex application, the
Classification Engine ID is 13 and the Selector ID has the
value of 10000.
Therefore the Application Id is encoded as:
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 23]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
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 Id has the value of 218113808. The
format '13..10000' is used for simplicity in the examples
below.
The Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application
Id. For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- ipDiffServCodePoint (key field)
- applicationId (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,
applicationId='13..10000',
octetTotalCount=123456 }
The 10000 value is globally unique for the enterprise, so
that the Collector can determine which application is
represented by the Application Id 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.8.
6.6. Example 6: Layer 7 Application with Private Enterprise
Number (PEN)
In this example, the layer 7 Webex traffic from Example 5
above have been classified by enterprise X. The exported
records have been received by enterprise Y's mediation
device, which wishes to forward them to a top level
Collector.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 24]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
In order for the top level Collector to know that the
records were classified by enterprise X, the enterprise Y
mediation device must report the records using the
PANA-L7-PEN Classification Engine ID with enterprise X's
Private Enterprise Number.
The PANA-L7-PEN Classification Engine ID is 20, and
enterprise X's Selector ID for Webex traffic has the value
of 10000.
Therefore the Application Id 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 20 | enterprise ID = X ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|...Ent.ID.contd| 10000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format '20..X..10000' is used for simplicity in the
examples below.
The Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application
Id. For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- ipDiffServCodePoint (key field)
- applicationId (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,
applicationId='20..X..10000',
octetTotalCount=123456 }
The 10000 value is globally unique for enterprise X, so
that the Collector can determine which application is
represented by the Application Id by loading the registry
out of band.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 25]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
Along with this Flow Record, a new Options Template Record
would be exported, as shown in Section 6.8.
6.7. Example: port Obfuscation
For example, an HTTP server might run on 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 Id representation must contain HTTP. However,
if the reporting application wants to determine whether the
default HTTP port 80 or 8080 was used, the destination port
(destinationTransportPort at [IANA-IPFIX]) must also be
exported in the corresponding IPFIX record.
In the case of a standardized IANA layer 4 port, the
Classification Engine ID (PANA-L4) is 3, and the Selector
ID has the value of 80 for HTTP (see [IANA-PORTS]).
Therefore the Application Id 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Exporting Process creates a Template Record with a few
Information Elements: amongst other things, the Application
Id. For example:
- sourceIPv4Address (key field)
- destinationIPv4Address (key field)
- protocol (key field)
- destinationTransportPort (key field)
- applicationId (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,
applicationId='3..80',
octetTotalCount=123456 }
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 26]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
The Collector has all the required information to determine
that the application is HTTP, but runs on port 23.
6.8. Example: Application Name Mapping Options Template
Along with the Flow Records shown in the above examples, a
new Options Template Record should be exported to express
the Application Name and Application Description associated
with each Application Id.
The Options Template Record contains the following
Information Elements:
1. Scope = applicationId.
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=applicationId='2..90',
applicationName="foo",
applicationDescription="The foo protocol",
scope=applicationId='13..10000',
applicationName="webex",
applicationDescription="Webex application" }
scope=applicationId='20..X..10000',
applicationName="webex",
applicationDescription="Webex application" }
When combined with the example Flow Records above, these
Options Template Records tell the Collector:
1. A flow of 123456 bytes exists from sourceIPv4Address
192.0.2.1 to destinationIPv4address 192.0.2.2 with an
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 27]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
applicationId 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 an
Application Id of '13..10000', which maps to the "Webex"
application.
3. A flow of 123456 bytes exists from sourceIPv4Address
192.0.2.1 to destinationIPv4address 192.0.2.2 with an
Application Id of '20..PEN..10000', which maps to the
"Webex" application, according to the application registry
from the entrerprise X.
6.9. 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 Ids.
The Options Template Record would contain the following
Information Elements:
1. Scope = applicationId.
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
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 28]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
The Options Data Record associated with the examples above
would contain, for example:
{ scope=applicationId='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 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 applicationId of '12..90', which maps to
the "foo" application. This application can be
characterized by the relevant attributes values.
7. IANA Considerations
7.1. New Information Elements
This document specifies 10 new IPFIX Information Elements:
the applicationDescription, applicationId, 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: RFC5102, which explains the IANA
considerations for assigning new Information Elements
mentions. "The value of these identifiers is in the range of
1-32767. Within this range, Information Element identifier
values in the sub-range of 1-127 are compatible with field
types used by NetFlow version 9 [RFC3954].". This is the
reason why some Information Elements have already an assigned
ElementId in the range 1-127, instead of <TBD>. These
Information Elements should anyway follow the IANA
Considerations from RFC5102, i.e. " New assignments for IPFIX
Information Elements will be administered by IANA through
Expert Review review". The reviewer is Nevil Brownlee.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 29]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
EDITOR'S NOTE: the XML specification in Appendix A must be
updated with the elementID values allocated below.
RFC-EDITOR/IANA-EDITOR: some entries are already present in
IPFIX-IANA. However, those must be updated with the current
content.
7.1.1. applicationDescription
Name: applicationDescription
Description:
Specifies the description of an application.
Abstract Data Type: string
Data Type Semantics:
ElementId: 94
Status: current
7.1.2. applicationId
Name: applicationId
Description:
Specifies an Application Id.
Abstract Data Type: octetArray
Data Type Semantics: identifier
Reference: See section 4. of [EDITORS NOTE: this document]
for the applicationId Information Element Specification.
ElementId: 95
Status: current
7.1.3. applicationName
Name: applicationName
Description:
Specifies the name of an application.
Abstract Data Type: string
Data Type Semantics:
ElementId: 96
Status: current
7.1.4. classificationEngineId
Name: classificationEngineId
Description:
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 30]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
A unique identifier for the engine which determined the
Selector ID. Thus the Classification Engine ID defines
the context for the Selector ID. The Classification
Engine can be considered as a specific registry for
application assignments.
Initial values for this field are listed below. Further
values may be assigned by IANA in the Classification
Engine Ids registry.
0 Invalid.
1 IANA-L3: The Assigned Internet Protocol Number
(layer 3 (L3)) is exported in the Selector ID. See
http://www.iana.org/assignments/protocol-numbers.
2 PANA-L3: Proprietary layer 3 definition. An
enterprise can export its own layer 3 protocol
numbers. The Selector ID has a global significance
for all devices from the same enterprise.
3 IANA-L4: The IANA layer 4 (L4) well-known port
number is exported in the Selector ID. See [IANA-
PORTS]. Note: as an IPFIX flow is unidirectional,
it contains the destination port in a flow from
the client to the server.
4 PANA-L4: Proprietary layer 4 definition. An
enterprise can export its own layer 4 port
numbers. The Selector ID has global significance
for devices from the same enterprise. Example:
IPFIX had the port 4739 pre-assigned in the IETF
draft for years. While waiting for the RFC and its
associated IANA registration, the Selector ID 4739
was used with this PANA-L4.
5 Reserved
6 USER-Defined: The Selector ID represents
applications defined by the user (using CLI, GUI,
etc.) based on the methods described in section 2.
The Selector ID has a local significance per
device.
7 Reserved
8 Reserved
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 31]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
9 Reserved
10 Reserved
11 Reserved
12 PANA-L2: Proprietary layer 2 (L2) definition. An
enterprise can export its own layer 2 identifiers.
The Selector ID represents the enterprise's unique
global layer 2 applications. The Selector ID has a
global significance for all devices from the same
enterprise. Examples include Cisco Subnetwork
Access Protocol (SNAP).
13 PANA-L7: Proprietary layer 7 definition. The
Selector ID represents the enterprise's unique
global ID for the layer 7 applications. The
Selector ID has a global significance for all
devices from the same enterprise. This
Classification Engine Id is used when the
application registry is owned by the Exporter
manufacturer (referred to as the "enterprise" in
this document).
14 Reserved
15 Reserved
16 Reserved
17 Reserved
18 ETHERTYPE: 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.
19 LLC: 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.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 32]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
20 PANA-L7-PEN: Proprietary layer 7 definition,
including a Private Enterprise Number (PEN) [PEN]
to identify that the application registry being
used is not owned by the Exporter manufacturer
(referred to as the "enterprise" in this document,
and identified by the PEN), or to identify the
original enterprise in the case of a mediator or
3rd party device. The Selector ID represents the
enterprise unique global ID for the layer 7
applications. The Selector ID has a global
significance for all devices from the same
enterprise.
Some values (5, 7, 8, 9, 10, 11, 14, 15, 16, and 17),
are reserved to be compliant with existing
implementations already using the
classificationEngineId.
Abstract Data Type: unsigned8
Data Type Semantics: identifier
ElementId: 101
Status: current
7.1.5. applicationCategoryName
Name: applicationCategoryName
Description:
An attribute that provides a first level categorization for
each Application Id.
Abstract Data Type: string
Data Type Semantics:
ElementId: <to be assigned>
Status: current
7.1.6. applicationSubCategoryName
Name: applicationSubCategoryName
Description:
An attribute that provides a second level categorization
for each Application Id.
Abstract Data Type: string
Data Type Semantics:
ElementId: <to be assigned>
Status: current
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 33]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
7.1.7. applicationGroupName
Name: applicationGroupName
Description:
An attribute that groups multiple Application Ids that
belong to the same networking application.
Abstract Data Type: string
Data Type Semantics:
ElementId: <to be assigned>
Status: current
7.1.8. p2pTechnology
Name: p2pTechnology
Description:
Specifies if the Application Id is based on peer-to-peer
technology. Possible values are: { "yes", "y", 1 },
{ "no", "n", 2 } and { "unassigned" , "u", 0 }.
Abstract Data Type: string
Data Type Semantics:
ElementId: 288
Status: current
7.1.9. tunnelTechnology
Name: tunnelTechnology
Description:
Specifies if the Application Id is used as a tunnel
technology.
Possible values are: { "yes", "y", 1 }, { "no", "n", 2 }
and
{ "unassigned" , "u", 0 }.
Abstract Data Type: string
Data Type Semantics:
ElementId: 289
Status: current
7.1.10. encryptedTechnology
Name: encryptedTechnology
Description:
Specifies if the Application Id is an encrypted networking
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 34]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
protocol. Possible values are: { "yes", "y", 1 },
{ "no", "n", 2 } and { "unassigned" , "u", 0 }.
Abstract Data Type: string
Data Type Semantics:
ElementId: 290
Status: current
7.2. Classification Engine Ids Registry
The Information Element #101, named classificationEngineId,
carries information about the context for the Selector ID,
and can be considered as a specific registry for application
assignments. For ensuring extensibility of this information,
IANA has created a new registry for Classification Engine Ids
and filled it with the initial list from the description
Information Element #101, classificationEngineId.
New assignments for Classification Engine Ids will be
administered by IANA through Expert Review [RFC5226], i.e.,
review by one of a group of experts designated by an IETF
Area Director. The group of experts must double check the
new definitions with already defined Classification Engine
Ids for completeness, accuracy, and redundancy. The
specification of Classification Engine Ids MUST be published
using a well-established and persistent publication medium.
RFC-EDITOR: this should be assigned similarly to
mplsTopLabelType subregistry at
http://www.iana.org/assignments/ipfix/ipfix.xml
8. Security Considerations
The same security considerations as for the IPFIX Protocol
[RFC5101] apply.
As mentioned in Section 2.1. , the application knowledge is
useful in security based applications. Security applications
may impose supplementary requirements on the export of
application information, and these need to be examined on a
case by case basis.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 35]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
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.
[RFC5226] Narten, T., and H. Alverstrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
RFC 5226, May 2008
[ETHERTYPE]
http://standards.ieee.org/develop/regauth/ethertype
/eth.txt
[IANA-PORTS] http://www.iana.org/assignments/port-numbers
[IANA-PROTO] http://www.iana.org/assignments/protocol-
numbers
[LLC]
http://standards.ieee.org/develop/regauth/llc/publi
c.html.
[PEN] http://www.iana.org/assignments/enterprise-numbers
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.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 36]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
[RFC3954] B. Claise, "Cisco Systems NetFlow Services Export
Version 9", RFC 3954, 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.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dresslet F.,
and G. Carle, "Information Model for Packet
Sampling Exports", RFC 5477, March 2009.
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K.
Ishibashi, "IP Flow Information Export (IPFIX)
Mediation: Framework", RFC6183, April 2011
[RFC6313] Claise, B., Dhandapani, G. Aitken, P., and S.
Yates, "Export of Structured Data in IP Flow
Information Export (IPFIX)", RFC6313, July 2011
[LLDP] "IEEE Std 802.1AB-2005, Standard for Local and
metropolitan area networks - Station and Media
Access Control Connectivity Discovery", IEEE Std
802.1AB-2005 IEEE Std, 2005.
[IANA-IPFIX]
http://www.iana.org/assignments/ipfix/ipfix.xml
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 37]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
[CISCO-APPLICATION-REGISTRY]
http://www.cisco.com/go/application_registry
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 Jan 8 2013 [Page 38]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
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
Appendix A. Additions to XML Specification of IPFIX
Information Elements (non normative)
This appendix A 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].
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 39]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
<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="applicationId"
dataType="octetArray"
group="application"
dataTypeSemantics="identifier"
elementId="95" applicability="all"
status="current">
<description>
<paragraph>
Specifies an Application Id.
</paragraph>
</description>
<reference>
<paragraph>
See section 4. of [EDITORS NOTE: this document]
for the applicationId Information Element
Specification.
</paragraph>
</reference>
</field>
<field name="applicationName"
dataType="string"
group="application"
elementId="96" applicability="all"
status="current">
<description>
<paragraph>
Specifies the name of an application.
</paragraph>
</description>
</field>
<field name="classificationEngineId"
dataType="unsigned8"
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 40]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
group="application"
dataTypeSemantics="identifier"
elementId="101" applicability="all"
status="current">
<description>
<paragraph>
0 Invalid.
1 IANA-L3: The Assigned Internet Protocol Number
(layer 3 (L3)) is exported in the Selector ID.
See http://www.iana.org/assignments/protocol-
numbers.
2 PANA-L3: Proprietary layer 3 definition. An
enterprise can export its own layer 3 protocol
numbers. The Selector ID has a global
significance for all devices from the same
enterprise.
3 IANA-L4: The IANA layer 4 (L4) well-known port
number is exported in the Selector ID. See
[IANA-PORTS]. Note: as an IPFIX flow is
unidirectional, it contains the destination
port in a flow from the client to the server.
4 PANA-L4: Proprietary layer 4 definition. An
enterprise can export its own layer 4 port
numbers. The Selector ID has global
significance for devices from the same
enterprise. Example: IPFIX had the port 4739
pre-assigned in the IETF draft for years.
While waiting for the RFC and its associated
IANA registration, the Selector ID 4739 was
used with this PANA-L4.
5 Reserved
6 USER-Defined: The Selector ID represents
applications defined by the user (using CLI,
GUI, etc.) based on the methods described in
section 2. The Selector ID has a local
significance per device.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 41]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
7 Reserved
8 Reserved
9 Reserved
10 Reserved
11 Reserved
12 PANA-L2: Proprietary layer 2 (L2) definition.
An enterprise can export its own layer 2
identifiers. The Selector ID represents the
enterprise's unique global layer 2
applications. The Selector ID has a global
significance for all devices from the same
enterprise. Examples include Cisco Subnetwork
Access Protocol (SNAP).
13 PANA-L7: Proprietary layer 7 definition. The
Selector ID represents the enterprise's unique
global ID for the layer 7 applications. The
Selector ID has a global significance for all
devices from the same enterprise. This
Classification Engine Id is used when the
application registry is owned by the Exporter
manufacturer (referred to as the "enterprise"
in this document).
14 Reserved
15 Reserved
16 Reserved
17 Reserved
18 ETHERTYPE: The Selector ID represents the
well-known Ethertype. See [ETHERTYPE]. Note
that the Ethertype is usually expressed in
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 42]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
hexadecimal. However, the corresponding
decimal value is used in this Selector ID.
19 LLC: 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 PANA-L7-PEN: Proprietary layer 7 definition,
including a Private Enterprise Number (PEN)
[PEN] to identify that the application
registry being used is not owned by the
Exporter manufacturer (referred to as the
"enterprise" in this document, and identified
by the PEN), or to identify the original
enterprise in the case of a mediator or 3rd
party device. The Selector ID represents the
enterprise unique global ID for the layer 7
applications. The Selector ID has a global
significance for all devices from the same
enterprise.
</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 Id.
</paragraph>
</description>
</field>
<field name="applicationSubCategoryName"
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 43]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
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 Id.
</paragraph>
</description>
</field>
<field name="applicationGroupName"
dataType="string"
group="application"
elementId="<to be assigned>"
applicability="all"
status="current">
<description>
<paragraph>
An attribute that groups multiple Application Ids
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 Id is based on peer-
to-peer technology. Possible values are:
{ "yes", "y", 1 }, { "no", "n", 2 } and
{ "unassigned" , "u", 0 }.
</paragraph>
</description>
</field>
<field name="tunnelTechnology"
dataType="string"
group="application"
elementId="289"
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 44]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
applicability="all"
status="current">
<description>
<paragraph>
Specifies if the Application Id is used as a
tunnel technology. Possible values are:
{ "yes", "y", 1 }, { "no", "n", 2 } and
{ "unassigned" , "u", 0 }.
</paragraph>
</description>
</field>
<field name="encryptedTechnology"
dataType="string"
group="application"
elementId="290"
applicability="all"
status="current">
<description>
<paragraph>
Specifies if the Application Id is an encrypted
networking protocol. Possible values are:
{ "yes", "y", 1 }, { "no", "n", 2 } and
{ "unassigned" , "u", 0 }.
</paragraph>
</description>
</field>
Appendix B. Port Collisions Tables (non normative)
The following table lists the 10 ports that have different
protocols assigned for TCP and UDP (at the time of writing
this document):
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
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 45]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
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"
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
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 46]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
acmaint_transd 775/udp
busboy 998/tcp
puparp 998/udp
garcon 999/tcp
applix 999/udp Applix ac
Table 4: Different Protocols on UDP and TCP
The following table lists the 19 ports that have different
protocols assigned for TCP and SCTP (at the time of writing
this document):
# 3097/tcp Reserved
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
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 47]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
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
<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>
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 48]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
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
# 36444/tcp <not assigned>
m3ap 36444/sctp M3 Application Part
Dario S. Tonesi
<dario.tonesi&nsn.com>
07 February 2011
Table 5: Different Protocols on SCTP and TCP
Appendix C. Application Registry Example (non normative)
A reference to the Cisco Systems assigned numbers for the
Application Id and the different attribute assignments can
be found at [CISCO-APPLICATION-REGISTRY].
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 49]
Internet-Draft <Export of App. Info. in IPFIX > July 2012
RFC-EDITOR NOTE: at the time of publication, if [CISCO-
APPLICATION-REGISTRY] is not available, this appendix, and
the [CISCO-APPLICATION-REGISTRY] reference must be removed.
<Claise, Aitken, Ben-Dvora> Expires Jan 8 2013 [Page 50]
