RFC 6759
Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)
RFC 6759: Cisco Systems Export of Application Information in IPFIX 💖
Okay bestie, this one is from November 2012 and it's written by B. Claise, P. Aitken, and N. Ben-Dvora from Cisco Systems, Inc. 🎀 It's an Informational doc (ISSN 2070-1721), which means it's published for information and isn't a Standards Track spec ✨. The header doesn't list anything it obsoletes or updates, so it stands on its own 🦋. Its whole job is to describe a Cisco extension to the IPFIX information model from RFC 5102 so that application info can be exported 💅.
Table of Contents
1. Introduction ....................................................3
1.1. Application Information Use Cases ..........................5
1.2. Conventions Used in This Document ..........................5
2. IPFIX Documents Overview ........................................5
3. Terminology .....................................................6
3.1. New Terminology ............................................6
4. applicationId Information Element Specification .................6
4.1. Existing Classification Engine IDs .........................7
4.2. Selector ID Length per Classification ID ..................11
4.3. Application Name Options Template Record ..................12
4.4. Resolving IANA L4 Port Discrepancies ......................13
5. Grouping Applications with Attributes ..........................13
5.1. Options Template Record for Attribute Values ..............15
6. Application ID Examples ........................................15
6.1. Example 1: Layer 2 Protocol ...............................15
6.2. Example 2: Standardized IANA Layer 3 Protocol .............16
6.3. Example 3: Proprietary Layer 3 Protocol ...................17
6.4. Example 4: Standardized IANA Layer 4 Port .................18
6.5. Example 5: Layer 7 Application ............................19
6.6. Example 6: Layer 7 Application with Private
Enterprise Number (PEN) ...................................21
6.7. Example: Port Obfuscation .................................22
6.8. Example: Application Name Mapping Options Template ........23
6.9. Example: Attributes Values Options Template Record ........24
7. IANA Considerations ............................................25
7.1. New Information Elements ..................................25
7.1.1. applicationDescription .............................25
7.1.2. applicationId ......................................26
7.1.3. applicationName ....................................26
7.1.4. classificationEngineId .............................26
7.1.5. applicationCategoryName ............................29
7.1.6. applicationSubCategoryName .........................29
7.1.7. applicationGroupName ...............................29
7.1.8. p2pTechnology ......................................29
7.1.9. tunnelTechnology ...................................30
7.1.10. encryptedTechnology ...............................30
7.2. Classification Engine ID Registry .........................30
8. Security Considerations ........................................30
9. References .....................................................31
9.1. Normative References ......................................31
9.2. Informative References ....................................32
10. Acknowledgements ..............................................33
Appendix A. Additions to XML Specification of IPFIX Information
(Non-normative) .......................................34
Appendix B. Port Collisions Tables (Non-normative) ................39
Appendix C. Application Registry Example (Non-normative) ..........43
List of Figures
Figure 1: applicationId Information Element .......................7
Figure 2: Selector ID Encoding ...................................12
List of Tables
Table 1: Existing Classification Engine IDs .......................7
Table 2: Selector ID Default Length per Classification
Engine ID ...............................................11
Table 3: Application ID Static Attributes ........................13
Table 4: Different Protocols on UDP and TCP ......................39
Table 5: Different Protocols on SCTP and TCP .....................40Abstract
This doc is all about a Cisco Systems extension to the IPFIX information model (the one in RFC 5102) so you can export application information 🌸 It's giving "here's how to tell the network what app is actually running" 💅
Status of This Memo
Okay, the vibe here: this is not an Internet Standards Track spec ✨ It's published purely for info 🎀
This doc is a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 Not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the deets 🧚
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6759 🦋
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 💜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the publication date 🫶 Please read these carefully because they spell out your rights and restrictions for this doc 📜 Any Code Components pulled out of this doc have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 💅
1. Introduction ✨
Okay so, service providers and network admins don't just want to see packet headers anymore. They want to see what's inside the packets 👀 Some network devices' Metering Processes inspect packet content and figure out which applications are using the traffic 🔥 In this context, an application is a networking protocol used by networking processes that swap packets between them, like web apps, peer-to-peer apps, file transfer, e-mail apps, and so on 💖 Apps can also be described by other stuff, some of it app-specific. For example: a web app going to a specific domain, per-user traffic, or a video app using a specific codec 🎀
Application identification is based on several different methods, or even a mix of methods 🧚
- L2 (Layer 2) protocols (such as ARP (Address Resolution Protocol), PPP (Point-to-Point Protocol), LLDP (Link Layer Discovery Protocol))
- IP protocols (such as ICMP (Internet Control Message Protocol), IGMP (Internet Group Management Protocol), GRE (Generic Routing Encapsulation)
- TCP or UDP ports (such as HTTP, Telnet, FTP)
- Application layer header (of the application to be identified)
- Packet data content
- Packets and traffic behavior
The exact identification methods are part of the Metering Process internals, which aim for accurate identification and try to keep false identifications low 🌸 It's a sophisticated job, because protocols don't always behave in a standard way 💀
- Applications use port obfuscation where the application runs on a different port than the IANA assigned one. For example, an HTTP server might run on TCP port 23 (assigned to telnet in [IANA-PORTS]).
- 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.
- The application behavior and identification logic become more and more complex.
So these Metering Processes usually detect apps using multiple mechanisms in parallel 🦋 Detection that only does port matching might wrongly identify the app 😭 If a Metering Process can detect apps more accurately, it's considered stronger and more accurate 👑
Same energy for a reporting mechanism that only uses L4 port-based apps, like L4:<known port>. It runs into the same issues 🙈 The reporting system should be able to report apps classified with all kinds of mechanisms, especially apps with no IANA port definition 💅 A mechanism to export application info should be defined, but the L4 port in use must be exported using the destination port (destinationTransportPort at [IANA-IPFIX]) in the corresponding IPFIX record 🎀
Apps can be identified at different OSI layers, from layer 2 up to layer 7 🌈 For example, the Link Layer Distribution Protocol (LLDP) [LLDP] can be identified at layer 2, ICMP at layer 3 [IANA-PROTO], HTTP at layer 4 [IANA-PORTS], and Webex at layer 7 💖
An ideal solution would be an IANA registry for apps above (or inside the payload of) the well-known ports [IANA-PORTS], but that isn't always possible 😭 The specs for some payload-embedded apps just aren't available. Managing an IANA registry for these would need some reverse engineering and a ubiquitous language for app identification, and those are blocking factors, clearly 🙃
This doc specifies the Cisco Systems application information encoding (described in Section 4) for exporting app info with the IPFIX protocol [RFC5101] ✨ Heads up though: layer 7 application registry values are out of scope for this doc 🫶
1.1. Application Information Use Cases
There are several use cases for application information 💜
- Application Visibility
This is one of the main cases for using application information. Network administrators use application visibility to understand the main network consumers, network trends, and user behavior.
- Security Functions
Application knowledge is sometimes used in security functions to provide comprehensive features such as application-based firewall, URL filtering, parental control, intrusion detection, etc.
Honestly, all of the above use cases need application information exported, either to provide the network function itself or to log how it operated 🔥
1.2. Conventions Used in This Document
Here's the important bit about the key words 📜 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] 🎀
2. IPFIX Documents Overview ✨
okay so IPFIX has a whole family of documents, and this section is basically the tour guide 💅. The IPFIX protocol [RFC5101] is the main thing that gives network admins access to IP Flow information 🧚
The architecture for exporting measured IP Flow information from an IPFIX Exporting Process to a Collecting Process is defined in the IPFIX Architecture [RFC5470], following the requirements in RFC 3917 [RFC3917]. 🎀
The IPFIX Architecture [RFC5470] is also where you learn how IPFIX Data Records and Templates get carried over a congestion-aware transport protocol, from Exporting Processes to Collecting Processes. It's giving logistics, honestly 🚚✨
IPFIX also has a formal description of its Information Elements, covering their names, types, and extra semantic info. That's specified in the IPFIX information model [RFC5102] 📚
If you want confidence in an IPFIX implementation, and you want to check conformity, robustness, and interoperability, the Guidelines for IPFIX Testing [RFC5471] has a list of tests for implementers of compliant Exporting Processes and Collecting Processes. Main character testing energy 🧪💖
The Bidirectional Flow Export [RFC5103] describes how to export bidirectional flow (biflow) information using the IPFIX protocol, with each biflow represented by a single Flow Record 🦋
Then there's "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473]. It's a bandwidth-saving method for exporting Flow or packet info. It separates the information that several Flow Records share from the info specific to one Flow Record, so the common Flow information only gets exported once. Lowkey genius 🧠🌸
3. Terminology
IPFIX-specific terminology used in this document is defined in Section 2 of the IPFIX protocol specification [RFC5101]. Just like in [RFC5101], these IPFIX-specific terms get a capitalized first letter whenever they show up 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. Iconic, the most specific version of the app gets the crown 👑
4. applicationId Information Element Specification
This document specifies the applicationId Information Element. It's a single field made of two parts, and I'm obsessed with how it's split up 🫶
- 8 bits of Classification Engine ID. The Classification Engine can be considered as a specific registry for application assignments. 📋
- n bits of Selector ID. The Selector ID length varies depending on the Classification Engine ID. Not me thinking the length changes based on the engine 🙈
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 ElementClassification Engine ID
A unique identifier for the engine that determined the Selector ID. So the Classification Engine ID is what gives the Selector ID its context 🧭
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. (Yes, we are still on this. It matters 💅)
The Selector ID term is a similar concept to the selectorId Information Element, specified in the PSAMP Protocol [RFC5476][RFC5477]. Same energy, different vibe 🦋
4.1. Existing Classification Engine IDs
The following Classification Engine IDs have been allocated. Here's the whole lineup 💖
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.
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
same enterprise. Example: IPFIX was
pre-assigned the port 4739 using the IANA
early allocation process [RFC4020] years
before the document was published as an RFC.
While waiting for the RFC and its associated
IANA registration, 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
1. 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
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.
ETHERTYPE 18 The Selector ID represents the
well-known Ethertype. See
[ETHERTYPE].
LLC 19 The Selector ID represents the
well-known IEEE 802.2 Link Layer
Control (LLC) Destination Service
Access Point (DSAP). See [LLC].
PANA-L7- 20 Proprietary layer 7 definition,
PEN including a Private Enterprise
Number (PEN) [IANA-PEN] to identify
that the application registry
being used is not owned by the
Exporter manufacturer 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.
21 to
255 Available (255 is the maximum
Engine ID)
Table 1: Existing Classification Engine IDs"PANA = Proprietary Assigned Number Authority". In other words, it's an enterprise-specific version of IANA for internal IDs. Basically IANA's bestie just for one company 🏢🎀
The PANA-L7 Classification Engine ID SHOULD be used when the application registry is owned by the Exporter manufacturer. Even if the application registry is owned by the Exporter manufacturer, the PANA-L7-PEN MAY be used, specifying the manufacturer. Two options, both valid, pick your fighter 🥊💜
For example, if Exporter A (from enterprise-A) wants to export its enterprise-A L7 registry, then it uses the PANA-L7 Classification Engine ID. If Exporter B (from enterprise-B) wants to export its enterprise-B L7 registry, then it also uses the PANA-L7 Classification Engine ID. Same engine, different companies, no drama 🌈
The mechanism for the Collector to know about the Exporter PEN is out of scope of this document. Possible tracks are SNMP polling, an Options Template exporting the privateEnterpriseNumber Information Element [IANA-IPFIX], hardcoded value, etc. Not this doc's problem, but good to know the options 🧚✨
An Exporter may classify the application according to another vendor's application registry. For example, an IPFIX Mediator [RFC6183] may need to re-export applications received from different Exporters using different PANA-L7 application registries. For example, if Exporter C (from enterprise-C) wants to reuse enterprise-D's application registry, then it uses PANA-L7-PEN with enterprise-D's PEN. Borrowing someone else's registry with credit? Iykyk 🫶
When reporting application information from multiple Exporters from different enterprises (different PENs), the PANA-L7-PEN Classification Engine MUST be used in exported Flow Records, which allows the original enterprise ID to be reported. This one is a must, no cap 🚨 The ID of the enterprise that defined the Application ID is identified by the enterprise's PEN. For example, an IPFIX Mediator aggregates traffic from some Exporters which report enterprise-E applications and other Exporters that report enterprise-F applications. Giving credit where credit is due 👑
An example is displayed in Section 6.6. 🎀
Note that the PANA-L7 Classification Engine ID is also used for resolving IANA L4 port Discrepancies (see Section 4.4). Multitasking queen 🙌
The list in Table 1 is maintained by IANA through the registry within the classificationEngineId Information Element. See the IANA Considerations section. The 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. It's giving "planned ahead for later," and I respect it 💅🌸
4.2. Selector ID Length per Classification ID ✨
okay so the Selector ID part of the Application ID is variable 🦋 because it depends on the Classification Engine ID value, which is literally why the applicationId SHOULD be encoded in a variable-length Information Element [RFC5101] for IPFIX export 💅
here's the Selector ID default length for each Classification Engine ID 💖
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 are an extra 4 bytes for the PEN 🌸 but the PEN is not considered part of the Selector ID, so don't count it there 🙈
now the legacy drama 😭 if you're using a legacy protocol like NetFlow version 9 [RFC3954] and it doesn't support variable-length Information Elements, then either you make multiple Template Records (one per applicationId length), or you make a single Template Record sized for the maximum applicationId, and that one MUST be used 🔥
Application IDs MAY be encoded in a smaller number of bytes, following the same rules as for 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 that 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 Encoding4.3. Application Name Options Template Record 🎀
okay this one's important bestie 🫶 for Classification Engines that specify locally unique Application IDs (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 that specify globally unique Application IDs, an Options Template Record MAY be used to export that same correspondence between the Application ID, the Application Name and the Application Description 💜 the only exception is when 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 ✨
enterprises can assign company-wide Application ID values for the PANA-L7 Classification Engine 🏢 and in that case a possible optimization for the Collector is to keep the mappings between the Application IDs and the Application Names per enterprise, instead of per Exporter. so chic 💅
4.4. Resolving IANA L4 Port Discrepancies 🍓
even though IANA L4 ports usually point to the same protocols for UDP, TCP, or other transport types, there are some exceptions, as mentioned in 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 (even though the transport protocol is already a 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 looking up IANA, it goes with 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 the Datagram Congestion Control Protocol (DCCP) ✨ no drama, no cap 🙌
5. Grouping Applications with Attributes 💜
there are so many different Application IDs that they MAY be categorized into groups 🌈 this makes reporting and action way easier, like for QoS policies. honestly most applications with the same characteristics should be treated the same way, like all video traffic 📺 iykyk
attributes are statically assigned per Application ID and are independent of the traffic 🦋 here are the attributes:
Name Description
Category An attribute that provides a first-
level categorization for each
Application ID. Examples include
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 contains
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.
Table 3: Application ID Static Attributesevery application gets assigned to one applicationCategoryName, one applicationSubCategoryName, one applicationGroupName, and it has one p2pTechnology, one tunnelTechnology, and one encryptedTechnology 🎀 these new Information Elements are specified in the IANA Considerations section (Section 7.1) ✨
maintaining the attribute values in IANA seems impossible to pull off 😭 so the attribute values per application are enterprise specific 💅
5.1. Options Template Record for Attribute Values 🧚
an Options Template Record (see [RFC5101]) SHOULD be used to export the correspondence between each Application ID and its related Attribute values 💖 another 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 has the application ID 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 can conveniently be exported using a subTemplateList per [RFC6313] 🦋 and an example is given in Section 6.9 ✨
6. Application ID Examples 🔥
these examples are created solely to illustrate how the extensions proposed in this document are encoded 🙈 no real-world vibes here, just vibes for learning 🧚
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 35020so for LLDP, the Classification Engine ID is 18 (LLC) 🫶 wait, that's the ETHERTYPE one, but the text says 18 (LLC) here, so we keep it exact as the original says, and the Selector ID is 35020 ✨
per Section 4, the applicationId Information Element is a single field made of 8 bits of Classification Engine ID, followed by n bits of Selector ID 🌸 from Table 2, the Selector ID length n is 2 for the ETHERTYPE Engine ID 💖
so 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 show those 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)
and a Flow Record matching that Template Record might look like this 🦋
{ applicationId='18..35020',
octetTotalCount=123456 }the Collector has all the required information to figure out 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 that Application ID represents by loading the registry out of band ✨ main character energy for this registry lookup 👑
6.2. Example 2: Standardized IANA Layer 3 Protocol 💖
okay so, from Table 1 the IANA layer 3 Classification Engine ID (IANA-L3) is 1 ✨, and from Table 2 the Selector ID length is 1 for the IANA-L3 Engine ID 🎀
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]
Messageso for the standardized IANA layer 3 protocol ICMP, the Classification Engine ID is 1 and the Selector ID is 1 💅
the Application ID is encoded like this 🧚
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, and the Application ID is one of them. for example:
sourceIPv4Address(key field)destinationIPv4Address(key field)ipDiffServCodePoint(key field)applicationId(key field)octetTotalCount(non-key field)
a Flow Record matching that Template Record might look like this 👑
{ 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 figure out the application is ICMP, because the Application ID uses a global and well-known registry, i.e., the IANA L3 protocol number 😭🫶
6.3. Example 3: Proprietary Layer 3 Protocol 🌈
picture this: an enterprise has specified a new layer 3 protocol called "foo" 👀
from Table 1, the proprietary layer 3 Classification Engine ID (PANA-L3) is 2, and from Table 2 the Selector ID length is 1 for the PANA-L3 Engine ID 💜
a global registry inside the enterprise says the "foo" protocol has the value 90 🍓
Protocol Protocol ID
foo 90so for the layer 3 protocol foo specified by this enterprise, the Classification Engine ID is 2 and the Selector ID has the value of 90 ✨
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 🦋
the Exporting Process creates a Template Record with a few Information Elements, and the Application ID is one of them. for example:
sourceIPv4Address(key field)destinationIPv4Address(key field)ipDiffServCodePoint(key field)applicationId(key field)octetTotalCount(non-key field)
a Flow Record matching that Template Record might look like this 🌸
{ 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 Table 1, the IANA layer 4 Classification Engine ID (IANA-L4) is 3, and from Table 2 the Selector ID length is 2 for the IANA-L4 Engine ID 💖
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 SNMPso for the standardized IANA layer 4 SNMP port, the Classification Engine ID is 3 and the Selector ID has the value of 161 👑
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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, and the Application ID is one of them. for example:
sourceIPv4Address(key field)destinationIPv4Address(key field)protocol(key field)ipDiffServCodePoint(key field)applicationId(key field)octetTotalCount(non-key field)
a Flow Record matching that Template Record might look like this 💅
{ 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 figure out the application is SNMP, because the Application ID uses a global and well-known registry, i.e., the IANA L4 protocol number 🫶✨
6.5. Example 5: Layer 7 Application 🦋
in this example, the Metering Process has spotted some Webex traffic 👀
from Table 1, the layer 7 unique Classification Engine ID (PANA-L7) is 13, and from Table 2 the Selector ID length is 3 for the PANA-L7 Engine ID 💜
suppose the Metering Process returns the ID 10000 for Webex traffic 🎀
so for this Webex application, the Classification Engine ID is 13 and the Selector ID has the value of 10000 🔥
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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, and the Application ID is one of them. for example:
sourceIPv4Address(key field)destinationIPv4Address(key field)ipDiffServCodePoint(key field)applicationId(key field)octetTotalCount(non-key field)
a Flow Record matching that Template Record might look like this ✨
{ 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 the Collector can work out which application the Application ID represents 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 has been classified by enterprise X 🧚 the exported records were received by enterprise Y's mediation device, which wants to forward them to a top-level Collector 👀
so the top-level Collector knows the records were classified by enterprise X, the enterprise Y mediation device must report the records using the PANA-L7-PEN Classification Engine ID together 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 🔥 from Table 2 the Selector ID length is 3 for the PANA-L7-PEN Engine ID 💅
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, and the Application ID is one of them. for example:
sourceIPv4Address(key field)destinationIPv4Address(key field)ipDiffServCodePoint(key field)applicationId(key field)octetTotalCount(non-key field)
a Flow Record matching that Template Record might look like this 🌸
{ 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 the Collector can work out which application the Application ID represents 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.7. Example: Port Obfuscation 🙈
for example, an HTTP server might run on TCP port 23 (assigned to telnet in [IANA-PORTS]) 😭 if the Metering Process is capable of detecting HTTP in that same case, the Application ID representation must contain HTTP 🫶 however, if the reporting application wants to know whether the default HTTP port 80 or 8080 was used, the transport ports (sourceTransportPort and 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]) 🌈 from Table 2 the Selector ID length is 2 for the PANA-L4 Engine ID 💜
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 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the Exporting Process creates a Template Record with a few Information Elements, and the Application ID is one of them. for example:
sourceIPv4Address(key field)destinationIPv4Address(key field)protocol(key field)destinationTransportPort(key field)applicationId(key field)octetTotalCount(non-key field)
a Flow Record matching that Template Record might look like this 🍓
{ sourceIPv4Address=192.0.2.1,
destinationIPv4Address=192.0.2.2,
protocol=17,
destinationTransportPort=23,
applicationId='3..80',
octetTotalCount=123456 }the Collector has all the required information to figure out the application is HTTP, but it runs on port 23 🎀✨
6.8. Example: Application Name Mapping Options Template ✨
Okay bestie, along with the Flow Records from the examples above, we should also export a new Options Template Record 💅 It's the one that spills the tea on the Application Name and Application Description for each Application ID 🫶
The Options Template Record contains these Information Elements:
- 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.
- applicationName.
- applicationDescription.
The Options Data Record for the examples above would look something like this 🎀
{ 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 you combine this with the Flow Records from before, 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 an applicationId of
'12..90', which maps to the "foo" application. - 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. - 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 enterprise X 🔥
6.9. Example: Attributes Values Options Template Record
So along with the Flow Records from the examples above, we also export a new Options Template Record that tells us the values of the different attributes related to the Application IDs 🦋
The Options Template Record contains these Information Elements:
- 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.
- applicationCategoryName.
- applicationSubCategoryName.
- applicationGroupName
- p2pTechnology
- tunnelTechnology
- encryptedTechnology
The Options Data Record for the examples above would look something like this 🌸
{ scope=applicationId='2..90',
applicationCategoryName="foo-category",
applicationSubCategoryName="foo-subcategory",
applicationGroupName="foo-group",
p2pTechnology=NO
tunnelTechnology=YES
encryptedTechnology=NOWhen you combine this with the Flow Records from before, 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
Okay so this document specifies 10 new IPFIX Information Elements: applicationDescription, applicationId, applicationName, classificationEngineId, applicationCategoryName, applicationSubCategoryName, applicationGroupName, p2pTechnology, tunnelTechnology, and encryptedTechnology 🎀
The new Information Elements below have been added to the IPFIX Information Element registry at [IANA-IPFIX] ✨
7.1.1. applicationDescription
Name: applicationDescription
Description:
Specifies the description of an application.
Abstract Data Type: string
Data Type Semantics:
ElementId: 94
Status: current7.1.2. applicationId
Name: applicationId
Description:
Specifies an Application ID.
Abstract Data Type: octetArray
Data Type Semantics: identifier
Reference: See Section 4 of [RFC6759]
for the applicationId Information Element Specification.
ElementId: 95
Status: current7.1.3. applicationName
Name: applicationName
Description:
Specifies the name of an application.
Abstract Data Type: string
Data Type Semantics:
ElementId: 96
Status: current7.1.4. classificationEngineId
This one is the main character 👑 Here's the full record, with all the engine IDs, verbatim:
Name: classificationEngineId
Description:
A unique identifier for the engine that 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 per Section 7.2.
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.
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 was pre-assigned port 4739 using the IANA
early allocation process [RFC4020] years before the
document was published as an RFC. While waiting for
the RFC and it associated IANA registration,
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
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 the Cisco Subnetwork
Access Protocol (SNAP).
13 PANA-L7: Proprietary layer 7 definition. The
Selector ID represents the enterprise's unique
global ID for 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].
19 LLC: The Selector ID represents the well-known
IEEE 802.2 Link Layer Control (LLC) Destination
Service Access Point (DSAP). See [LLC].
20 PANA-L7-PEN: Proprietary layer 7 definition,
including a Private Enterprise Number (PEN) [IANA-PEN]
to identify that the application registry being
used is not owned by the Exporter manufacturer 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 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: current7.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: 372
Status: current7.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: 373
Status: current7.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: 374
Status: current7.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: current7.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: current7.1.10. encryptedTechnology
Name: encryptedTechnology
Description:
Specifies if the Application ID is an encrypted networking
protocol. Possible values are { "yes", "y", 1 },
{ "no", "n", 2 }, and { "unassigned", "u", 0 }.
Abstract Data Type: string
Data Type Semantics:
ElementId: 290
Status: current7.2. Classification Engine ID Registry
Okay so the Information Element #101, named classificationEngineId, carries information about the context for the Selector ID, and it can be considered as a specific registry for application assignments 🦋 To keep this extensible, IANA made a brand new registry for Classification Engine IDs and filled it with the initial list from the classificationEngineId description (Information Element #101), along with their respective default lengths (Table 2 in this document) 💖
New assignments for Classification Engine IDs will be administered by IANA through Expert Review [RFC5226], which means review by one of a group of experts designated by an IETF Area Director 🧚 That group of experts must double-check the new definitions against the 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 🔥
8. Security Considerations 🔒✨
Okay bestie, security time, so pay attention 🫶 The same security considerations as for the IPFIX protocol [RFC5101] apply. This extension lets you figure out which applications are running on the network. That means you can tell what apps the users are using, and that could seriously mess with their privacy if it isn't handled with great care 😭🔒
As mentioned in Section 1.1, application knowledge is super useful in security-based applications 💜 Security apps might put extra requirements on how application info gets exported, and those need to be checked case by case 🧐
9. References 📚
9.1. Normative References 💖
- [ETHERTYPE] IEEE,
http://standards.ieee.org/develop/regauth/ethertype/eth.txt. - [IANA-PEN] IANA, "PRIVATE ENTERPRISE NUMBERS",
http://www.iana.org/assignments/enterprise-numbers. - [IANA-PORTS] IANA, "Service Name and Transport Protocol Port Number Registry",
http://www.iana.org/assignments/port-numbers. - [IANA-PROTO] IANA, "Protocol Numbers",
http://www.iana.org/assignments/protocol-numbers. - [LLC] IEEE, "LOGICAL LINK CONTROL (LLC) PUBLIC LISTING",
http://standards.ieee.org /develop/regauth/llc /public.html. - [RFC2119] Bradner, S., "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. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
9.2. Informative References 🌸
- [CISCO-APPLICATION-REGISTRY] Cisco, "Application Registry",
http://www.cisco.com/go/application_registry. - [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities",
http://www.iana.org/assignments/ipfix. - [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.
- [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
- [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
- [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
- [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.
- [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., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
- [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
- [RFC5353] Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)", RFC 5353, September 2008.
- [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol", RFC 5811, March 2010.
- [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011.
- [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011.
10. Acknowledgements 🫶
The authors want to give a huge thank you to their many colleagues across Cisco Systems, who made all of this possible 🌈 Special shoutout to Patrick Wildi for his time and expertise 👑💖
Appendix A. Additions to XML Specification of IPFIX Information Elements (Non-normative) ✨
okay so this is the appendix, bestie 🎀 It's a list of new fields getting added to the IPFIX information model, the big XML catalogue from [RFC5102] that defines the Information Elements. Heads up: this appendix is only informational 💅 The text in Section 7 is the normative one, and it gets generated from this appendix, so that's where the real rules live 🫶
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="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 [RFC6759]
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>Next up is classificationEngineId, which is the one with the big list of engine types 🔥 Each value gets its own little description, so read carefully 👑
<field name="classificationEngineId"
dataType="unsigned8"
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.
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 was pre-assigned
port 4739 using the IANA early allocation
process [RFC4020] years before the document was
published as an RFC. While waiting for the
RFC and its associated IANA registration,
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
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 the Cisco Subnetwork
Access Protocol (SNAP).
13 PANA-L7: Proprietary layer 7 definition. The
Selector ID represents the enterprise's unique
global ID for 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].
19 LLC: The Selector ID represents the well-known
IEEE 802.2 Link Layer Control (LLC)
Destination Service Access Point (DSAP). See
[LLC].
20 PANA-L7-PEN: Proprietary layer 7 definition,
including a Private Enterprise Number (PEN)
[IANA-PEN] to identify that the application
registry being used is not owned by the
Exporter manufacturer 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 layer 7
applications. The Selector ID has a global
significance for all devices from the same
enterprise.
</paragraph>
</description>
</field>Now the application categorization fields, which are all pretty chill and string-based 🌸 Each one just adds a little more context about an application 🧚
<field name="applicationCategoryName"
dataType="string"
group="application"
elementId="372"
applicability="all"
status="current">
<description>
<paragraph>
An attribute that provides a first-level categorization
for each Application Id.
</paragraph>
</description>
</field>
<field name="applicationSubCategoryName"
dataType="string"
group="application"
elementId="373"
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="374"
applicability="all"
status="current">
<description>
<paragraph>
An attribute that groups multiple Application IDs
that belong to the same networking application.
</paragraph>
</description>
</field>And the last three are the yes/no-style technology flags 🍓 Each one takes "yes", "y", or 1 for yes, "no", "n", or 2 for no, and "unassigned", "u", or 0 for unassigned 💜
<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"
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) 🎀
okay so this part is the appendix era 🧚 Appendix B is basically a gossip column about ports that got double-booked. It's non-normative, so it's just for vibes and context, not rules. The actual rules live in the main body 💅
Here are the 10 ports that have different protocols assigned for TCP and UDP (as of when this doc was written) 🌸
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 [sic] 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>
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 4: Different Protocols on UDP and TCPNext up, the 19 ports that have different protocols assigned for TCP and SCTP (as of when this doc was written) 🦋 the drama is real here, lots of # "Reserved" and "<not assigned>" vibes 💀
# 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
# 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>
# 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>
# 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)
Kimmo Kymalainen
<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 TCPAppendix C. Application Registry Example (Non-normative) 🍓
Last appendix, bestie! ✨ This one just points you to Cisco's assigned numbers for the Application ID and the different attribute assignments, which you can find at [CISCO-APPLICATION-REGISTRY]. Non-normative, so it's a helpful pointer, not a rule 🫶
Authors' Addresses 💜
Here's who wrote this beast, with their addresses and contact info, all verbatim 🧚
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📦 where this page comes from
- ietf: rfc6759 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms