< draft-claise-export-application-info-in-ipfix-09.txt   draft-claise-export-application-info-in-ipfix-10.txt >
IPFIX Working Group B. Claise IPFIX Working Group B. Claise
Internet-Draft P. Aitken Internet-Draft P. Aitken
Intended Status: Informational N. Ben-Dvora Intended Status: Informational N. Ben-Dvora
Expires: January 8, 2013 Cisco Systems, Inc. Expires: February 8, 2013 Cisco Systems, Inc.
July 9, 2012 August 8, 2012
Cisco Systems Export of Application Information in IPFIX Cisco Systems Export of Application Information in IPFIX
draft-claise-export-application-info-in-ipfix-09 draft-claise-export-application-info-in-ipfix-10
Status of this Memo Status of this Memo
This document is not an Internet Standards Track This document is not an Internet Standards Track
specification; it is published for informational purposes. specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task This document is a product of the Internet Engineering Task
Force (IETF). It represents the consensus of the IETF Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been community. It has received public review and has been
approved for publication by the Internet Engineering approved for publication by the Internet Engineering
skipping to change at page 4, line 7 skipping to change at page 4, line 7
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 [RFC2119]. described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Overview................................................. 5 1. Introduction.......................................... 5
1.1. IPFIX Documents Overview............................ 5 1.1. Application Information Use Cases................... 7
2. Introduction............................................. 6 2. IPFIX Documents Overview.............................. 8
2.1. Application Information Use Cases...................... 8 3. Terminology........................................... 8
3. Terminology.............................................. 8 3.1. New Terminology.................................. 9
3.1. New Terminology..................................... 9 4. applicationId Information Element Specification....... 9
4. applicationId Information Element Specification.......... 9 4.1. Existing Classification Engine IDs.............. 10
4.1. Existing Classification Engine IDs................. 10 4.2. Selector ID Length per Classification IDs....... 14
4.2. Selector ID Length per Classification IDs.......... 14 4.3. Application Name Options Template Record........ 15
4.3. Application Name Options Template Record........... 15 4.4. Resolving IANA L4 Port Discrepancies............ 16
4.4. Resolving IANA L4 Port Discrepancies............... 16 5. Grouping the Applications with the Attributes........ 16
5. Grouping the Applications with the Attributes........... 16 5.1. Options Template Record for the Attribute Values 18
5.1. Options Template Record for the Attribute Values... 18 6. Application Id Examples.............................. 18
6. Application Id Examples................................. 18 6.1. Example 1: Layer 2 Protocol..................... 18
6.1. Example 1: Layer 2 Protocol........................ 19 6.2. Example 2: Standardized IANA Layer 3 Protocol... 20
6.2. Example 2: Standardized IANA Layer 3 Protocol...... 20 6.3. Example 3: Proprietary Layer 3 Protocol......... 21
6.3. Example 3: Proprietary Layer 3 Protocol............ 21 6.4. Example 4: Standardized IANA Layer 4 Port....... 22
6.4. Example 4: Standardized IANA Layer 4 Port.......... 22 6.5. Example 5: Layer 7 Application.................. 23
6.5. Example 5: Layer 7 Application..................... 23
6.6. Example 6: Layer 7 Application with Private 6.6. Example 6: Layer 7 Application with Private
Enterprise Number (PEN)................................. 24 Enterprise Number (PEN).............................. 24
6.7. Example: port Obfuscation.......................... 26 6.7. Example: port Obfuscation....................... 26
6.8. Example: Application Name Mapping Options Template. 27 6.8. Example: Application Name Mapping Options Template27
6.9. Example: Attributes Values Options Template Record. 28 6.9. Example: Attributes Values Options Template Record28
7. IANA Considerations..................................... 29 7. IANA Considerations.................................. 29
7.1. New Information Elements........................... 29 7.1. New Information Elements........................ 29
7.1.1. applicationDescription........................... 30 7.1.1. applicationDescription........................ 30
7.1.2. applicationId.................................... 30 7.1.2. applicationId................................. 30
7.1.3. applicationName.................................. 30 7.1.3. applicationName............................... 30
7.1.4. classificationEngineId........................... 30 7.1.5. applicationCategoryName....................... 33
7.1.5. applicationCategoryName.......................... 33 7.1.6. applicationSubCategoryName.................... 33
7.1.6. applicationSubCategoryName....................... 33 7.1.7. applicationGroupName.......................... 33
7.1.7. applicationGroupName............................. 34 7.1.8. p2pTechnology................................. 34
7.1.8. p2pTechnology.................................... 34 7.1.9. tunnelTechnology.............................. 34
7.1.9. tunnelTechnology................................. 34 7.1.10. encryptedTechnology.......................... 34
7.1.10. encryptedTechnology............................. 34 7.2. Classification Engine Ids Registry.............. 35
7.2. Classification Engine Ids Registry................. 35 8. Security Considerations.............................. 35
8. Security Considerations................................. 35 9. References........................................... 36
9. References.............................................. 36 9.1. Normative References............................ 36
9.1. Normative References............................... 36 9.2. Informative References.......................... 36
9.2. Informative References............................. 36 10. Acknowledgement..................................... 38
10. Acknowledgement........................................ 38 11. Authors' Addresses.................................. 39
11. Authors' Addresses..................................... 39
Appendix A. Additions to XML Specification of IPFIX Appendix A. Additions to XML Specification of IPFIX
Information Elements (non normative)....................... 39 Information Elements (non normative).................... 39
Appendix B. Port Collisions Tables (non normative)........ 45 Appendix B. Port Collisions Tables (non normative)..... 45
Appendix C. Application Registry Example (non Appendix C. Application Registry Example (non normative)49
normative)................................................. 49
List of Figures and Tables List of Figures and Tables
Figure 1: applicationId Information Element .............. 9 Figure 1: applicationId Information Element ............. 9
Table 1: Existing Classification Engine IDs ............. 13 Table 1: Existing Classification Engine IDs ............ 13
Table 2: Selector ID default length per Classification Table 2: Selector ID default length per Classification
Engine ID ............................................ 14 Engine ID ........................................... 14
Table 3: Application Id Static Attributes ............... 18 Table 3: Application Id Static Attributes .............. 17
Table 4: Different Protocols on UDP and TCP ............. 47 Table 4: Different Protocols on UDP and TCP ............ 47
Table 5: Different Protocols on SCTP and TCP ............ 49 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
[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 1. Introduction
Today service providers and network administrators are Today service providers and network administrators are
looking for visibility into the packet content rather than looking for visibility into the packet content rather than
just the packet header. Some network devices Metering just the packet header. Some network devices Metering
Processes inspect the packet content and identify the Processes inspect the packet content and identify the
applications that are utilizing the network traffic. applications that are utilizing the network traffic.
Applications in this context are defined as networking Applications in this context are defined as networking
protocols used by networking processes that exchange protocols used by networking processes that exchange
packets between them (such as web applications, peer to packets between them (such as web applications, peer to
peer applications, file transfer, e-mail applications, peer applications, file transfer, e-mail applications,
skipping to change at page 7, line 4 skipping to change at page 6, line 8
Protocol), PPP (Point-to-Point Protocol), LLDP (Link Protocol), PPP (Point-to-Point Protocol), LLDP (Link
Layer Discovery Protocol)) Layer Discovery Protocol))
2. IP protocols (such as ICMP (Internet Control Message 2. IP protocols (such as ICMP (Internet Control Message
Protocol), IGMP (Internet Group Management Protocol), Protocol), IGMP (Internet Group Management Protocol),
GRE (Generic Routing Encapsulation) GRE (Generic Routing Encapsulation)
3. TCP or UDP ports (such as HTTP, Telnet, FTP) 3. TCP or UDP ports (such as HTTP, Telnet, FTP)
4. Application layer header (of the application to be 4. Application layer header (of the application to be
identified) identified)
5. Packet data content 5. Packet data content
6. Packets and traffic behavior 6. Packets and traffic behavior
The exact application identification methods are part of The exact application identification methods are part of
the Metering Process internals that aim to provide an the Metering Process internals that aim to provide an
accurate identification and minimize false identification. accurate identification and minimize false identification.
This task requires a sophisticated Metering Process since This task requires a sophisticated Metering Process since
the protocols do not behave in a standard manner. the protocols do not behave in a standard manner.
1. Applications use port obfuscation where the 1. Applications use port obfuscation where the
application runs on different port than the IANA application runs on different port than the IANA
assigned one. For example an HTTP server might assigned one. For example an HTTP server might
run a TCP port 23 (assigned to telnet in [IANA- run a TCP port 23 (assigned to telnet in [IANA-
PORTS]) PORTS])
2. IANA port registries do not accurately reflect how 2. IANA port registries do not accurately reflect how
certain ports are "commonly" used today. Some certain ports are "commonly" used today. Some
ports are reserved, but the application either ports are reserved, but the application either
never became prevalent or is not in use today. never became prevalent or is not in use today.
3. The application behavior and identification logic 3. The application behavior and identification logic
become more and more complex become more and more complex
For that reason, such Metering Processes usually detect For that reason, such Metering Processes usually
applications based on multiple mechanisms in parallel. detect applications based on multiple mechanisms in
Detection based only on port matching might wrongly identify parallel. Detection based only on port matching
the application. If the Metering Process is capable of might wrongly identify the application. If the
detecting applications more accurately, it is considered to Metering Process is capable of detecting applications
be stronger and more accurate. more accurately, it is considered to be stronger and
more accurate.
Similarly, a reporting mechanism that uses L4 port based Similarly, a reporting mechanism that uses L4 port based
applications only, such as L4:<known port>, would have applications only, such as L4:<known port>, would have
similar issues. The reporting system should be capable of similar issues. The reporting system should be capable of
reporting the applications classified using all types of reporting the applications classified using all types of
mechanisms. In particular applications that do not have mechanisms. In particular applications that do not have
any IANA port definition. While a mechanism to export any IANA port definition. While a mechanism to export
application information should be defined, the L4 port application information should be defined, the L4 port
being used must be exported using the destination port being used must be exported using the destination port
(destinationTransportPort at [IANA-IPFIX]) in the (destinationTransportPort at [IANA-IPFIX]) in the
skipping to change at page 8, line 23 skipping to change at page 7, line 28
embedded in the payload are not available. Some reverse embedded in the payload are not available. Some reverse
engineering as well as a ubiquitous language for engineering as well as a ubiquitous language for
application identification, would be required conditions to application identification, would be required conditions to
be able to manage an IANA registry for these types of be able to manage an IANA registry for these types of
applications. Clearly, these are blocking factors. applications. Clearly, these are blocking factors.
This document specifies the Cisco Systems application This document specifies the Cisco Systems application
information encoding. However, the layer 7 application information encoding. However, the layer 7 application
registry values are out of scope of this document. registry values are out of scope of this document.
2.1. Application Information Use Cases 1.1. Application Information Use Cases
There are several use cases for application information: There are several use cases for application information:
1. Application Visibility 1. Application Visibility
This is one of the main cases for using the application This is one of the main cases for using the application
information. Network administrators are using information. Network administrators are using
application visibility to understand the main network application visibility to understand the main network
consumers, network trends and user behavior. consumers, network trends and user behavior.
skipping to change at page 8, line 45 skipping to change at page 8, line 5
Application knowledge is sometimes used in security Application knowledge is sometimes used in security
functions in order to provide comprehensive functions functions in order to provide comprehensive functions
such as Application based firewall, URL filtering, such as Application based firewall, URL filtering,
parental control, intrusion detection, etc. parental control, intrusion detection, etc.
All of the above use cases require exporting application All of the above use cases require exporting application
information to provide the network function itself or to information to provide the network function itself or to
log the network function operation. log the network function operation.
2. IPFIX Documents Overview
The IPFIX Protocol [RFC5101] provides network administrators
with access to IP Flow information.
The architecture for the export of measured IP Flow
information out of an IPFIX Exporting Process to a Collecting
Process is defined in the IPFIX Architecture [RFC5470], per
the requirements defined in RFC 3917 [RFC3917].
The IPFIX Architecture [RFC5470] specifies how IPFIX Data
Records and Templates are carried via a congestion-aware
transport protocol from IPFIX Exporting Processes to IPFIX
Collecting Processes.
IPFIX has a formal description of IPFIX Information Elements,
their name, type and additional semantic information, as
specified in the IPFIX information model [RFC5102].
In order to gain a level of confidence in the IPFIX
implementation, probe the conformity and robustness, and
allow interoperability, the Guidelines for IPFIX Testing
[RFC5471] presents a list of tests for implementers of
compliant Exporting Processes and Collecting Processes.
The Bidirectional Flow Export [RFC5103] specifies a method
for exporting bidirectional flow (biflow) information using
the IP Flow Information Export (IPFIX) protocol, representing
each Biflow using a single Flow Record.
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.
3. Terminology 3. Terminology
IPFIX-specific terminology used in this document is defined IPFIX-specific terminology used in this document is defined
in Section 2 of the IPFIX protocol specification [RFC5101]. in Section 2 of the IPFIX protocol specification [RFC5101].
As in [RFC5101], these IPFIX-specific terms have the first As in [RFC5101], these IPFIX-specific terms have the first
letter of a word capitalized when used in this document. letter of a word capitalized when used in this document.
3.1. New Terminology 3.1. New Terminology
Application Id Application Id
A unique identifier for an application. A unique identifier for an application.
When an application is detected, the most granular When an application is detected, the most granular
skipping to change at page 11, line 18 skipping to change at page 11, line 11
associated IANA registration, the associated IANA registration, the
Selector ID 4739 was used with Selector ID 4739 was used with
this PANA-L4. this PANA-L4.
5 Reserved. 5 Reserved.
USER- 6 The Selector ID represents USER- 6 The Selector ID represents
Defined applications defined by the user Defined applications defined by the user
(using CLI, GUI, etc.) based on (using CLI, GUI, etc.) based on
the methods described in section the methods described in section
2. The Selector ID has a local 1. The Selector ID has a local
significance per device. significance per device.
7 Reserved. 7 Reserved.
8 Reserved. 8 Reserved.
9 Reserved. 9 Reserved.
10 Reserved. 10 Reserved.
skipping to change at page 35, line 37 skipping to change at page 35, line 34
specification of Classification Engine Ids MUST be published specification of Classification Engine Ids MUST be published
using a well-established and persistent publication medium. using a well-established and persistent publication medium.
RFC-EDITOR: this should be assigned similarly to RFC-EDITOR: this should be assigned similarly to
mplsTopLabelType subregistry at mplsTopLabelType subregistry at
http://www.iana.org/assignments/ipfix/ipfix.xml http://www.iana.org/assignments/ipfix/ipfix.xml
8. Security Considerations 8. Security Considerations
The same security considerations as for the IPFIX Protocol The same security considerations as for the IPFIX Protocol
[RFC5101] apply. [RFC5101] apply. The IPFIX extension specified in this memo
allows to identify what applications are used on the network.
Consequently, it is possible to identify what applications
are being used by the users, potentially threatening the
privacy of those users, if not handled with great care.
As mentioned in Section 2.1. , the application knowledge is As mentioned in Section 1.1. , the application knowledge is
useful in security based applications. Security applications useful in security based applications. Security applications
may impose supplementary requirements on the export of may impose supplementary requirements on the export of
application information, and these need to be examined on a application information, and these need to be examined on a
case by case basis. case by case basis.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
 End of changes. 16 change blocks. 
108 lines changed or deleted 107 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/