One document matched: draft-claise-ipfix-eval-netflow-04.txt
Differences from draft-claise-ipfix-eval-netflow-03.txt
Internet Draft B. Claise
Document: draft-claise-ipfix-eval-netflow-04.txt Cisco Systems
Expires: August 2003 February 2003
Evaluation Of NetFlow Version 9 Against IPFIX Requirements
<draft-claise-ipfix-eval-netflow-04.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC 2026]. 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 obsolete 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
Distribution of this document is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document provides an evaluation of the applicability of the
NetFlow flow record export protocol version 9 as an IPFIX protocol.
It compares the properties and capabilities of the NetFlow flow
record export protocol version 9 to the IPFIX requirements [IPFIX-
REQ].
Claise Expires û February 2003 [Page 1]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
Table of Contents
1. Introduction...................................................3
2. Architectural Considerations...................................6
2.1 NetFlow Protocol Overview..................................6
2.2 General Applicability......................................7
2.2.1 Flow Definition........................................7
2.2.2 Observation Point......................................7
2.2.3 The Metering Process and the Flow Record...............7
2.2.4 The Exporting Process..................................8
2.2.5 The Collecting Process.................................8
2.3 Architectural Differences..................................8
3. Item Level Compliance Evaluation...............................9
3.1 Terminology (section 2)...................................10
3.1.1 IP Traffic Flow (2.1).................................10
3.1.2 Observation Point (2.2)...............................10
3.1.3 Metering Process (2.3)................................10
3.1.4 Flow Record (2.4).....................................10
3.1.5 Exporting Process (2.5)...............................10
3.1.6 Collecting Process (2.6)..............................10
3.2 Applications Requiring IP Flow Information Export (3).....11
3.3 Distinguishing Flows (4)..................................11
3.3.1 Interface (4.1).......................................11
3.3.2 IP Header Fields (4.2)................................11
3.3.3 Transport Header Fields (4.3).........................11
3.3.4 MPLS (4.4)............................................12
3.3.5 DiffServ Code Point (4.5).............................12
3.3.6 Header Compression and Encryption (4.6)...............12
3.4 Metering Process (5)......................................12
3.4.1 Reliability (5.1).....................................12
3.4.2 Sampling (5.2)........................................12
3.4.3 Overload Behavior (5.3)...............................13
3.4.4 Timestamps (5.4)......................................14
3.4.5 Time Synchronization (5.5)............................14
3.4.6 Flow Expiration (5.6).................................15
3.4.7 Multicast (5.7).......................................15
3.4.8 Packet Fragmentation (5.8)............................15
3.4.9 Ignore Port Copy (5.9)................................15
3.5 Data Export (6)...........................................15
3.5.1 Information Model (6.1)...............................15
3.5.2 Data Model (6.2)......................................17
3.5.3 Data Transfer (6.3)...................................17
3.5.3.1 Congestion Awareness (6.3.1)......................17
3.5.3.2 Reliability (6.3.2)...............................17
3.5.3.3 Security (6.3.3)..................................18
3.5.4 Push and Pull Mode Reporting (6.4)....................18
3.5.5 Regular Reporting Interval (6.5)......................18
3.5.6 Notification on Specific Events (6.6).................19
3.5.7 Anonymization (6.6)...................................19
Claise Expires April 2003 [Page 2]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
3.6 Configuration (7).........................................19
3.6.1 Configuration of the Metering Process (7.1)...........19
3.6.2 Configuration of the Exporting Process (7.2)..........19
3.7 General Requirements Compliance (8).......................20
3.7.1 Openness (8.1)........................................20
3.7.2 Number of Exporting Processes (8.2)...................20
3.7.3 Several Collecting Processes (8.3)....................20
3.8 Compliance Summary........................................20
4. Security Considerations.......................................24
5. References....................................................24
6. Acknowledgments...............................................25
1. Introduction
This document provides an evaluation of the applicability of the
NetFlow flow record export protocol version 9 as an IPFIX protocol.
First, the general NetFlow architecture is introduced. Its
application to the communication between an IPFIX exporting process
and an IPFIX collecting process is discussed in Section 2. Section 3
discusses in detail, to which degree requirements stated in [IPFIX-
REQ] are met.
This document uses the terminology defined in [IPFIX-REQ].
Note that the generic term NetFlow refers to multiple different
notions: the metering process, the exporting process and the export
protocol, as defined in the IPFIX terminology section of [IPFIX-
REQ].
Even if the metering process and exporting process form a single
NetFlow process on the Cisco Systems devices, this document will
sometimes refer to NetFlow metering process and NetFlow exporting
process for the sake of clarity. But the export protocol will always
be referred to as the NetFlow flow record export protocol version 9.
- How and where is it documented?
All documentation related to NetFlow can be found at:
http://www.cisco.com/go/netflow
More specifically, the ôNetFlow Services Solutions Guideö covers a
NetFlow overview, the basic and advanced concepts, the explanation
of the different versions along with the data types exported, some
configuration examples, etc. For reference, see:
Claise Expires April 2003 [Page 3]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/n
fwhite.htm
The new flexible and extensible NetFlow flow record export version 9
is described in the IETF draft "Cisco Systems NetFlow Services
Export Version 9" [NETFLOW9-1], as well as in the following
documents:
1.http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/tflow_wp.htm
2.http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1829/pro
ducts_feature_guide09186a00801341b2.html
- Are there concrete plans for standardizing it?
The way to standardize NetFlow is via the IETF IPFIX Working Group.
In parallel, Cisco Systems intention is to produce an Information
RFC out of the next version of [NETFLOW9-1].
- Is standardization already in progress?
No other standardization than the participation to the IETF IPFIX
Working Group is currently taking place.
- Is it proprietary to a certain company?
NetFlow is a proprietary protocol from Cisco Systems.
- Does it include any technology protected by patents?
NetFlow is protected by the following patent:
United States Patent 6,243,667 Kerr, et al. June 5, 2001
Abstract:
The invention provides a method and system for switching in networks
responsive to message flow patterns. A message "flow" is defined to
comprise a set of packets to be transmitted between a particular
source and a particular destination. When routers in a network
identify a new message flow, they determine the proper processing
for packets in that message flow and cache that information for that
message flow. Thereafter, when routers in a network identify a
packet which is part of that message flow, they process that packet
according to the proper processing for packets in that message flow.
The proper processing may include a determination of a destination
port for routing those packets and a determination of whether access
Claise Expires April 2003 [Page 4]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
control permits routing those packets to their indicated
destination.
Nevertheless, Cisco Systems has no intention to use this patent to
prevent other vendors to implement a NetFlow-like solution.
An Intellectual Property Right message has been sent to the IETF
rfc-editor team to post a similar message at
http://www.ietf.org/ipr.html
- Is it already implemented?
Yes, the NetFlow flow record export protocol version 9 code is
already implemented and available on the Cisco web site since the
Cisco Systems IOS version 12.0(24)S. Note that the NetFlow flow
record export versions 1, 5, 7 and 8 have been implemented for many
years now.
- Is it already in commercial use?
Yes. Cisco Systems developed its own NetFlow Collector (the correct
term is ôcollecting processö according to [IPFIX-REQ]), that already
supports the NetFlow flow record export protocol version 9. For more
details, see
http://www.cisco.com/en/US/products/sw/netmgtsw/ps1964/index.html
Some Cisco Systems partners are currently developing NetFlow
Collectors able to receive NetFlow version 9 flow records.
Note that many different companies or organizations have already
implemented NetFlow Collectors for the previous NetFlow flow record
export protocols versions. Ex: Concord Communications, Hewlett
Packard, Narus, Xacct, Portal, Apogee Networks, Infovista, etc. to
name just a few.
- Is it available from more than one source?
As the inventor of NetFlow, Cisco Systems is the only company
implementing this new version 9 on its devices. But, if we speak of
the previous NetFlow flow record export protocol versions, then the
majority of our competitors implemented those versions.
- Is it already widely used?
Claise Expires April 2003 [Page 5]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
The NetFlow flow record export protocol version 9 has been beta
tested by some of our customers for some time now. Since its
official availability, it is currently under test at some other
customer sites as well. Note that the previous NetFlow flow record
export versions have been implemented by our competitors. As a
consequence, yes, NetFlow is widely used through out the industry.
2. Architectural Considerations
This section introduces the architecture of NetFlow and suggests a
way of applying it to the communication between an IPFIX exporting
process and an IPFIX collecting process.
2.1 NetFlow Protocol Overview
This section discusses the most recent evolution of the NetFlow flow
record export protocol, which is known as Version 9. The
distinguishing feature of the NetFlow Version 9 format compared to
the previous versions, is that it is template based. Template is a
collection of fields along with the description of their structure
and semantics.
This approach gives the following advantages:
- The template mechanism being flexible, allows the export of the
required fields alone from the IP Flows to the collecting process.
This helps to reduce the exported flow data volume, and generates
possible memory savings at the metering process and collecting
process. Sending the required information only, reduces the network
load too.
- Using the template mechanism, new fields can be added to NetFlow
export records without changing the structure of export record
format. With the previous NetFlow flow record export versions,
adding a new field in the flow record implied a new version of the
export protocol format and a new version of the collecting process
that supports the parsing of this new export protocol format.
- Templates which are sent to the collecting process contains the
structural information about the exported Flow Records fields. So,
even if the collecting process does not understand the semantics of
new fields, it can still interpret the Flow Record.
Claise Expires April 2003 [Page 6]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
- Even if the NetFlow flow record export protocol version 9 has been
created with a IP flow record background in mind, note that the
Information Model can be extended with any data types and could
potentially serve any reporting purposes. e.g. the NetFlow metering
process configuration.
2.2 General Applicability
2.2.1 Flow Definition
A NetFlow flow is identified as a unidirectional stream of packets
between a given source and destination, both defined by a network-
layer IP addresses and transport-layer port numbers. Typically in
case of ingress NetFlow, a flow is identified as the combination of
the following seven key fields: source IP address, destination IP
address, source port number, destination port number, layer 3
protocol type, ToS byte, input logical interface (ifIndex). In case
of egress NetFlow, a flow is identified as the combination of the
following seven key fields: source IP address, destination IP
address, source port number, destination port number, layer 3
protocol type, ToS byte, output logical interface (ifIndex).
These seven key fields define a unique flow. If a new observed
packet contains a different set of these seven key fields, then this
packet will create a new flow. Note that a flow contains other
accounting fields (such as the number of packets, number of bytes,
the BGP AS, etc).
2.2.2 Observation Point
NetFlow can be enabled per interface (physical/logical) per linecard
or per system. However implementation restrictions apply on a
platform basis.
2.2.3 The Metering Process and the Flow Record
NetFlow operates by creating a NetFlow cache that contains the
information for all active flows. A flow record is maintained within
the NetFlow cache for all active flows. Each flow record in the
NetFlow cache contains key fields that can be later used for
exporting to a collecting process.
Claise Expires April 2003 [Page 7]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
2.2.4 The Exporting Process
The NetFlow enabled platform checks the NetFlow cache on regular
basis and expires the flows if no more traffic of these flows is
observed. Once expired, the flow records are directly exported to
the collecting process.
To achieve efficiency in terms of processing at the Exporter while
handling high volume of export, the NetFlow export packet is
encapsulated into UDP [UDP] datagrams for export to the collecting
process. Nevertheless NetFlow flow record export protocol version 9
has been designed to be transport protocol independent. Hence, it
can also operate over congestion aware protocols like TCP [TCP] or
SCTP [SCTP].
Note that the UDP port to which the NetFlow flow records are
exported is configurable.
2.2.5 The Collecting Process
The NetFlow Collector (the collecting process) provides the data
collection from multiple export devices exporting NetFlow flow
records. It will process and store the flow records. Some extra
actions on these flow records could be executed on the collecting
process but per [IPFIX-REQ], these actions are out of the scope of
the IPFIX work.
2.3 Architectural Differences
+----------------+ +----------------+
|[*Application 1]| ..|[*Application n]|
+--------+-------+ +-------+--------+
^ ^
~ ~
+~~~~~~~~~~+~~~~~~~~+
!
v
+----------------------+ +------------------+
|Device(i) | | Collector(j) |
|[Obsv Point(s)] |--------------->| [*Application(s)]|
|[Metering Process(es)]| +---->| |
|[Export Process] | | +------------------+
+----------------------+ .
.... .
+----------------------+ |
|Device(m) | |
|[Obsv Point(s)] |----------+
Claise Expires April 2003 [Page 8]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
|[Metering Process(es)]|
|[Export Process] |
+----------------------+
Except the terminology difference again described below, there is no
difference between the NetFlow and IPFIX architecture.
Note that the generic term NetFlow refers to multiple different
notions: the metering process, the exporting process and the export
protocol, as defined in the IPFIX terminology section of [IPFIX-
REQ].
Even if the metering process and exporting process form a single
NetFlow process on the Cisco Systems devices, this document will
sometimes refer to NetFlow metering process and NetFlow exporting
process for the sake of clarity. But the export protocol will always
be referred to as the NetFlow flow record export protocol version 9.
3. Item Level Compliance Evaluation
This section evaluates the compliance of the NetFlow protocol with
the IPFIX requirements item by item. Requirements are addressed by
their section numbers and item numbers in [IPFIX-REQ]. For each
requirement it is explained to what degree protocol NetFlow flow
export version 9 meets the requirement and how this is achieved. The
degree of compliancy is explicitly stated using five grades:
-T Total compliance: The requirement is met completely by the
protocol specification without any extensions required.
-E Extension required for total compliance: The protocol is
prepared to be extended and it is possible to extend it in a
way that it meets the requirement. This grade is only
applicable to protocols that are explicitly open to externally
defined extensions, such as SNMP is extended by MIB modules or
DIAMETER is extended by application modules. It is not
applicable to protocols, where the protocol specification
itself needs to be extended in order to comply with the
requirement.
-P Partial compliance: The requirement is met partially by the
protocol specification.
-U Upcoming compliance: The requirement is not met or met
partially by the protocol specification, but there is a
concrete plan for an upcoming version of the protocol.
Claise Expires April 2003 [Page 9]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
-F Failed compliance: The requirement is not met by the protocol
specification.
3.1 Terminology (section 2)
3.1.1 IP Traffic Flow (2.1)
Total Compliance of NetFlow Flow definition with the IPFIX IP
Traffic Flow definition.
3.1.2 Observation Point (2.2)
Total Compliance of NetFlow Observation Point definition with the
IPFIX Observation Point definition. NetFlow is enabled by interface
or per subinterface. NetFlow can be enable on multiple interfaces
at the same time, e.g. all interfaces belonging to one line card, or
all the interfaces from the device. On specific device, NetFlow is
enabled for the entire platform.
3.1.3 Metering Process (2.3)
Total Compliance of NetFlow with the IPFIX Metering Process
definition, for all aspects: packet header capturing, timestamping,
sampling, classifying, and maintaining flow records.
3.1.4 Flow Record (2.4)
Total Compliance of NetFlow Flow Record definition with the IPFIX
Flow Record definition.
3.1.5 Exporting Process (2.5)
Total Compliance of NetFlow Exporting Process with the IPFIX
Exporting Process definition. The NetFlow Exporting Process may send
the flow records to 2 different collecting processes.
3.1.6 Collecting Process (2.6)
Claise Expires April 2003 [Page 10]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
Total Compliance of NetFlow Collector with the IPFIX collecting
process definition.
3.2 Applications Requiring IP Flow Information Export (3)
Total Compliance of NetFlow regarding the different applications
described in [IPFIX-REQ] which require IP flow information export,
i.e. Usage-based Accounting, Traffic Profiling, Traffic Engineering,
Attack/Intrusion Detection and QoS Monitoring. Actually, the
Information Model associated with NetFlow flow record export version
9 [NETFLOW9-1] contains all the data types needed to satisfy the
requirements of the different applications described in the section
ôApplications Requiring IP Flow Information Exportö from [IPFIX-
REQ].
3.3 Distinguishing Flows (4)
ôBut anyway, it MUST be ensured that a collecting process is able to
clearly identify for each received flow record which set of
properties was used for distinguishing this flow from other ones.ö,
as defined in [IPFIX-REQ]ô.
From the Template ID and the Observation Domain we can find back the
set of properties used to distinguish the flow. Total Compliance
3.3.1 Interface (4.1)
Total Compliance of the interface as a flow distinguisher.
In case of ingress NetFlow, a flow is identified, amongst other
fields, by the input logical interface (ifIndex). In case of egress
NetFlow, a flow is identified, amongst other fields by output
logical interface (ifIndex). All flow records will report both the
input and output ifIndexes.
3.3.2 IP Header Fields (4.2)
source IP address (MUST): Total Compliance
destination IP address (MUST): Total Compliance
protocol type (TCP,UDP,ICMP,...) (MUST): Total Compliance
IP version number (SHOULD): Upcoming Compliance
3.3.3 Transport Header Fields (4.3)
Claise Expires April 2003 [Page 11]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
Total Compliance of the port numbers of the transport header as a
flow distinguishers.
3.3.4 MPLS (4.4)
Total Compliance of the MPLS label as a flow distinguisher, if the
observation point is located at a device supporting Multiprotocol
Label Switching.
3.3.5 DiffServ Code Point (4.5)
Total Compliance, as NetFlow distinguishes flow by the TOS byte
(DiffServ Code Point).
3.3.6 Header Compression and Encryption (4.6)
Total Compliance.
3.4 Metering Process (5)
3.4.1 Reliability (5.1)
The metering process is reliable on most of the Cisco network
elements. Total Compliance.
On the network elements where the metering process could not meter
some flow records due to some overload, an Options Template with the
number of missed flows could be sent to the collector. Note that the
counters are available in the network elements. Nevertheless,
Extension required for total compliance.
3.4.2 Sampling (5.2)
ôThe metering process MAY support packet sampling.ö, as defined in
[IPFIX-REQ]ô. Total Compliance. NetFlow supports packet sampling.
ôIf sampling is supported the sampling configuration MUST be well
defined. The sampling configuration includes the sampling method and
all its parameters.ö, as defined in [IPFIX-REQ]. Total Compliance.
See the Options Template from [NETFLOW9-1]: a template that
describes the format of the Flow measurement parameters (like the
sampling algorithm, sampling interval) done at the metering process.
öIf the sampling configuration is changed during operation, the new
Claise Expires April 2003 [Page 12]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
sampling configuration with its parameters MUST be indicated to all
collecting processes receiving the affected flow records. Changing
the sampling configuration includes: adding a sampling function to
the metering process, removing a sampling function from the metering
process, change sampling method, and change sampling parameter(s).ö
as defined in [IPFIX-REQ]ô.
Adding a sampling function to the metering process: Total Compliance
Removing a sampling function from the metering process: Total
Compliance
Change sampling method: Total Compliance
Change sampling parameter: Total Compliance
Example: If the metering process starts NetFlow sampling, a new
Option Template will be sent to the collecting process; it will
contain the sampling parameters. If the sampling method or sampling
parameters are changed, a new Option Template [NETFLOW9-1] with the
new method/parameters and with a new Template ID [NETFLOW9-1] will
be sent to the collecting process; it will contain the same Source
ID [NETFLOW9-1] so that the collecting process can deduce that the
previous Template ID is not active anymore. Now in case of removing
a sampling function from the metering process, i.e. going back to
full NetFlow, the same process will apply: a new Option Template
[NETFLOW9-1] with the same Source ID [NETFLOW9-1], with the new
method/parameters and with a new Template ID [NETFLOW9-1] will be
sent to the collecting process so that the collecting process can
deduce that the NetFlow sampling is stopped.
In conclusion: Total Compliance for this entire section
3.4.3 Overload Behavior (5.3)
ôIn case of an overload, for example lack of memory or processing
power, the metering process MAY change its behavior in order to cope
with the lack of resources.ö, as defined in [IPFIX-REQ].
Total Compliance.
ôFor some flows, the change of behavior might have an impact on the
data that would be stored in the associated flow records after the
change, for example if the packet classification is changed or the
sampling rate. These flows MUST be considered as terminated and the
associated flow records MUST be exported separately from new ones
generated after the behavior change. ö, as defined in [IPFIX-REQ].
ôThe terminated flow records and new ones generated after the
behavior change MUST NOT be merged by the metering process.ö, as
defined in [IPFIX-REQ].
Claise Expires April 2003 [Page 13]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
ôThe collecting process MUST be able to distinguish the affected
flow records generated before and after the change of behavior.ö, as
defined in [IPFIX-REQ].
Let me address the 3 requirements above together.
If the metering process configuration is changed, then Total
Compliance. A new Template ID for the new template configuration
will be generated and the collecting process will be able to
distinguish the new flow records from the old ones.
In case of memory, flow records or CPU overload, Total Compliance.
Overload of memory: not possible because NetFlow allocates the
entire cache memory at initialization.
Overload of flow records: not possible because in case the NetFlow
cache becomes full, the flow records will be expired with a smaller
timeout! This change in the exporting process behavior doesnÆt need
to be reported: anyway the flow records contain the absolute amps.
Overload of CPU: the throughput will be lowered in order for NetFlow
to account all traffic.
In case of cpu overload, in order to avoid a lower throughput, some
new automatic actions (like new template with sampling NetFlow
instead of full NetFlow or new template with higher sampling rate
etcà) could be implemented without much effort.
Note that in both examples above, a new Template ID for the new
template configuration will be generated and the collecting process
will be able to distinguish the new flow records from the old ones.
3.4.4 Timestamps (5.4)
TOTAL Compliance.
3.4.5 Time Synchronization (5.5)
The flow records contain both the flow start and the flow end
sysUpTime. See FIRST_SWITCHED and LAST_SWITCHED in [NETFLOW9-1]. The
exporter could periodically send an Option Template [NETFLOW9-1]
containing a time synchronization pair composed of a sysUpTime and a
unix_msecs (Number of milli seconds since 0000 UTC 1970), taken at
the same point in time. The NetFlow collector could deduce the flow
start and flow end UTC time of every single flow record.
TOTAL Compliance.
Claise Expires April 2003 [Page 14]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
3.4.6 Flow Expiration (5.6)
Total Compliance of the NetFlow flow expiration mechanism with the
IPFIX requirements.
The routing device checks the NetFlow cache once per second and
expires the flow in the following instances:
1. Transport is completed (TCP FIN or RST).
2. The flow cache has become full.
3. The inactive timer has expired after 15 seconds of traffic
inactivity. This inactive timer is configurable, with a
minimum value of 0 for a immediate expiration.
4. The active timer has expired after 30 minutes of traffic
activity. This active timer is configurable.
3.4.7 Multicast (5.7)
Total Compliance of the multicast support with the IPFIX
requirements.
3.4.8 Packet Fragmentation (5.8)
ôThe metering process MAY keep state of IP packet fragmentation in
order to map fragments that do not contain sufficient header
information correctly to flows.ö, as defined in [IPFIX-REQ].
Extension Required for Total Compliance.
3.4.9 Ignore Port Copy (5.9)
Total Compliance. The metering process ignores packets that are
generated by a port copy function acting at the device where the
observation point of a flow is located.
3.5 Data Export (6)
3.5.1 Information Model (6.1)
Claise Expires April 2003 [Page 15]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
ôThe exporting process MUST be able to report the following
attributes for each metered flowö, as defined in [IPFIX-REQ]:
1. IP version number: Total Compliance
2. source IP address: Total Compliance
3. destination IP address: Total Compliance
4. IP protocol type (TCP,UDP,ICMP,...) : Total Compliance
5. source TCP/UDP port number: Total Compliance
6. destination TCP/UDP port number: Total Compliance
7. packet counter: Total Compliance
8. byte counter: Total Compliance
9. type of service octet (in case of IPv4), traffic class octet (in
case of IPv6): Total Compliance
10. in case of IPv6, Flow Label: Total Compliance
11. if MPLS is supported at the observation point: the top MPLS
label or the corresponding forwarding equivalence class (FEC,
[RFC3031]) bound to that label. Total Compliance for the top MPLS
label and the corresponding FEC.
12. timestamp of the first packet of the flow: Total Compliance
13. timestamp of the last packet of the flow: Total Compliance
14. if sampling is used, sampling configuration: Total Compliance
15. unique identifier of the observation point: Total Compliance
(the ifIndex)
16. unique identifier of the exporting process: Total Compliance
(the IP address and the Observation Domain Identifier)
ôThe exporting process SHOULD be able to report the following
attributes for each metered flowö, as defined in [IPFIX-REQ]:
17. if protocol type is ICMP, ICMP type and code: Total Compliance
18. input interface (ifIndex): Total Compliance
19. output interface (ifIndex): Total Compliance
20. multicast replication factor. Total Compliance
ôThe exporting process MAY be able to report the following
attributes for each metered flowö, as defined in [IPFIX-REQ]:
21. Time To Live (in case of IPv4) or Hop Limit (in case of IPv6):
Extension required for Total Compliance
22. IP header flags: Extension required for Total Compliance
23. TCP header flags: Total Compliance
24. dropped packet counter at the observation point: Extension
required for Total Compliance
25. fragmented packet counter: Extension Required for Total
Compliance
26. Next hop IP address: Total Compliance
In addition, the exporting process MAY be able to report attributes
related to inter-autonomous system routing of a flow, for example by
reporting BGP Autonomous System numbers. Total Compliance
Claise Expires April 2003 [Page 16]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
3.5.2 Data Model (6.2)
ôThe data model MUST be extensibleö, as defined in [IPFIX-REQ].
Total Compliance. While all data types discussed in [NETFLOW9-1]
concern the IP flows and the metering process, nothing prevents
NetFlow version 9 to export whatever type of data. For example, a
MIB variable or the output of a ôshow commandö on the router.
NetFlow version 9 is extensible to whatever data type.
ôThe data model used for exporting flow information MUST be flexible
concerning the flow attributes contained in flow recordsö, as
defined in [IPFIX-REQ].
Total Compliance.
ôThe Data Model SHOULD be independent of the underlying transport
protocol, i.e. the data transferö, as defined in [IPFIX-REQ].
Total Compliance.
3.5.3 Data Transfer (6.3)
3.5.3.1 Congestion Awareness (6.3.1)
ôFor the data transfer, a congestion aware protocol MUST be
supportedö, as defined in [IPFIX-REQ].
Upcoming Compliance with SCTP. For more details on possible
implementations of the NetFlow flow record export protocol version 9
using SCTP, refer to the draft draft-djernaes-netflow-9-transport-
00.
Note that the flow record export protocol version 9 is independent
of the underlying transport protocol.
3.5.3.2 Reliability (6.3.2)
ôLoss of flow records during the data transfer from the exporting
process to the collecting process MUST be indicated at the
collecting process. This indication MUST allow the collecting
process to gauge the number of flow records lost.ö, as defined in
[IPFIX-REQ].
Total Compliance. A sequence ID exists per export packet and per
observation domain [NETFLOW9-1] so that the collecting process would
know if it misses export packets or if packets reordering occurred
in the network.
Claise Expires April 2003 [Page 17]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
ôPlease note that if an unreliable transport protocol is used,
reliability can be provided by higher layers. If reliability is
provided by higher layers, only lack of overall reliability MUST be
indicated. For example reordering could be dealt with by adding a
sequence number to each packet.ö, as defined in [IPFIX-REQ].
Total Compliance.
ôThe data transfer between exporting process and collecting process
MUST be open to reliability extensions including at least
- retransmission of lost flow records,
- detection of disconnection and fail-over, and
- acknowledgement of flow records by the collecting process.ö,
as defined in [IPFIX-REQ].
Upcoming Compliance with SCTP. For more details on possible
implementations of the NetFlow flow record export protocol version 9
using SCTP, refer to the draft draft-djernaes-netflow-9-transport-
00.
3.5.3.3 Security (6.3.3)
Extension Required for total Compliance for confidentiality,
integrity and authenticity for the flow record export protocol
version 9 itself.
But note that exporting the NetFlow flow records from the exporting
process to the metering process over an IPSEC [IPSEC] tunnel would
fulfill all the confidentiality, integrity and authenticity
requirements.
3.5.4 Push and Pull Mode Reporting (6.4)
ôThe exporting process MUST support push mode reporting, it MAY
support pull mode reporting.ö, as defined in [IPFIX-REQ].
NetFlow is a Push Mode Reporting mechanism and doesnÆt support the
Pull Mode.
3.5.5 Regular Reporting Interval (6.5)
Total Compliance. For long aging flows, the exporting process
exports the flow records on regular basis, in order to:
1. report the flow records periodic accounting information
to the collecting process
2. avoid counter wrapping
Claise Expires April 2003 [Page 18]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
This activity timeout is configurable
3.5.6 Notification on Specific Events (6.6)
Failed Compliance.
3.5.7 Anonymization (6.6)
ôThe exporting process MAY be capable of anonymizing source and
destination IP addresses in flow data before exporting them.ö
Total Compliance.
ôThe exporting process MAY support anonymization of port numbers and
other fields.ö
Total Compliance.
Router-based aggregations of flow records can be enabled in order to
aggregate the flow records and as a consequence, anonymize some of
the flow records data types. Typical example: the source and
destination IP addresses will be hidden. Instead the network
prefixes will be reported.
Another solution would simply be not to report the data types we
want to anonymize. Typical example: the network prefixes are
reported instead of the IP addresses but the network prefixes are
meaningful. As a consequence, the template would export none of the
IP addresses and the prefixes.
3.6 Configuration (7)
3.6.1 Configuration of the Metering Process (7.1)
Total Compliance.
3.6.2 Configuration of the Exporting Process (7.2)
Total Compliance.
Claise Expires April 2003 [Page 19]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
3.7 General Requirements Compliance (8)
3.7.1 Openness (8.1)
Total Compliance.
3.7.2 Scalability (8.2)
ôData collection from hundreds of different exporting processes MUST
be supported.ö, as defined in [IPFIX-REQ].
Total Compliance.
ôThe collecting process MUST be able to distinguish several hundred
exporting processes by their identifiers.ö, as defined in [IPFIX-
REQ].
Total Compliance, the identifier being the IP address of the
exporting process and the Observation Domain identifier.
The Observation Domain is defined as:
The set of observation points which is the largest aggregatable set
of flow information at the metering process is termed as an
Observation Domain. The Observation Domain presents itself a unique
identifier to the collecting process for identifying the export
packets generated by it. One or more Observation Domains can
interface with the same export process. Example: The Observation
Domain could be a router line-card, composed of several interfaces
with each interface being an observation point.
3.7.3 Several Collecting Processes (8.3)
Total Compliance. The exporting process is able to export flow
information to two different collecting processes and the flow
records can be identified thanks to a sequence ID, the Observation
Domain and the Exporter IP address.
3.8 Compliance Summary
M: MUST
S: SHOULD
May: MAY
----------------------------------------------.
B: IPFIX Requirement Status |
Claise Expires April 2003 [Page 20]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
----------------------------------------. |
A: NetFlow Version 9 Compliance | |
----------------------------------. | |
| | |
| Sect. | Requirement | | |
|-------+-------------------------+-----+-----|
| 2. | Terminology | T | |
|-------+-------------------------+-----+-----|
| 3. | Applications | T | |
|-------+-------------------------+-----+-----|
| 4. | DISTINGUISHING FLOWS |
|-------+-------------------------+-----+-----|
| 4 | Distinguish set of | | |
| | properties | T | M |
|-------+-------------------------+-----+-----|
| 4.1 | Interfaces | T | M |
|-------+-------------------------+-----+-----|
| 4.2 | Source IP address | T | M |
|-------+-------------------------+-----+-----|
| 4.2 | Destination IP address | T | M |
|-------+-------------------------+-----+-----|
| 4.2 | Protocol Type | T | M |
|-------+-------------------------+-----+-----|
| 4.2 | IP version | U | M |
|-------+-------------------------+-----+-----|
| 4.3 | Transport Header Fields | T | M |
|-------+-------------------------+-----+-----|
| 4.4 | MPLS | T | M |
|-------+-------------------------+-----+-----|
| 4.5 | DiffServ Code Point | T | M |
|-------+-------------------------+-----+-----|
| 4.6 | Header Compres/Encrypt. | T | M |
|-------+-------------------------+-----+-----|
| 5. | METERING PROCESS |
|-------+-------------------------+-----+-----|
| 5.1 | Reliability | T | M |
|-------+-------------------------+-----+-----|
| 5.2 | Sampling | T | May |
|-------+-------------------------+-----+-----|
| 5.3 | Overload Behavior | T | May |
|-------+-------------------------+-----+-----|
| 5.4 | TimeStamps | T | M |
|-------+-------------------------+-----+-----|
| 5.5 | Time Synchronization | T | M |
|-------+-------------------------+-----+-----|
| 5.6 | Flow Expiration | T | M |
|-------+-------------------------+-----+-----|
| 5.7 | Multicast Flows | T | S |
|-------+-------------------------+-----+-----|
| 5.8 | Packet Fragmentation | E | May |
|-------+-------------------------+-----+-----|
Claise Expires April 2003 [Page 21]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
| 5.9 | Ignore Port Copy | T | May |
|-------+-------------------------+-----+-----|
| 6. | DATA EXPORT |
|-------+-------------------------+-----+-----|
| 6.1. | INFORMATION MODEL |
|-------+-------------------------+-----+-----|
| 6.1. | IP Version | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | src IP address | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | dst IP address | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | protocol type | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | src TCP/UDP port | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | dst TCP/UPD port | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | Packet counter | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | Byte counter | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | TOS/Traffic Class | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | Flow Label | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | MPLS label/FEC | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | Timestamps for | T | M |
| | first packet | | |
|-------+-------------------------+-----+-----|
| 6.1. | Timestamps for | T | M |
| | last packet | | |
|-------+-------------------------+-----+-----|
| 6.1. | Sampling configuration | T | M |
|-------+-------------------------+-----+-----|
| 6.1. | observation point | T | M |
| | identifier | | |
|-------+-------------------------+-----+-----|
| 6.1. | export process | T | M |
| | identifier | | |
|-------+-------------------------+-----+-----|
| 6.1. | ICMP type and code | T | S |
|-------+-------------------------+-----+-----|
| 6.1. | Input Interface | T | S |
|-------+-------------------------+-----+-----|
| 6.1. | OutputInterface | T | S |
|-------+-------------------------+-----+-----|
| 6.1. | Multicast Replication | T | S |
|-------+-------------------------+-----+-----|
| 6.1. | Time to Live | E | May |
Claise Expires April 2003 [Page 22]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
|-------+-------------------------+-----+-----|
| 6.1. | IP Header Flags | E | May |
|-------+-------------------------+-----+-----|
| 6.1. | TCP Header Flags | T | May |
|-------+-------------------------+-----+-----|
| 6.1. | Dropped Packet Counter | E | May |
|-------+-------------------------+-----+-----|
| 6.1. | Fragmented Pkt Counter | E | May |
|-------+-------------------------+-----+-----|
| 6.1. | IP Next Hop | T | May |
|-------+-------------------------+-----+-----|
| 6.1. | BGP AS Info | T | May |
|-------+-------------------------+-----+-----|
| 6.2. | DATA MODEL |
|-------+-------------------------+-----+-----|
| 6.2. | Flexibility | T | M |
|-------+-------------------------+-----+-----|
| 6.2. | Extensibility | T | M |
|-------+-------------------------+-----+-----|
| 6.2. | Transport Independant | T | S |
|-------+-------------------------+-----+-----|
| 6.3. | DATA TRANSFER |
|-------+-------------------------+-----+-----|
| 6.3.1.| Congestion aware | U | M |
|-------+-------------------------+-----+-----|
| 6.3.2.| Reliability | T | M |
|-------+-------------------------+-----+-----|
| 6.3.2.| Open to reliability | | |
| | Extensions | U | M |
|-------+-------------------------+-----+-----|
| 6.3.3.| Confidentiality | E | S |
|-------+-------------------------+-----+-----|
| 6.3.4.| Integrity | E | M |
|-------+-------------------------+-----+-----|
| 6.3.5.| Authenticity | E | M |
|-------+-------------------------+-----+-----|
| 6.4. | Push mode | T | M |
|-------+-------------------------+-----+-----|
| 6.4. | Pull mode | F | May |
|-------+-------------------------+-----+-----|
| 6.5 | Regular Interval | T | S |
|-------+-------------------------+-----+-----|
| 6.6. | Notifications | F | May |
|-------+-------------------------+-----+-----|
| 6.7. | Anonymization | T | May |
|-------+-------------------------+-----+-----|
| 7. | CONFIGURATION |
|-------+-------------------------+-----+-----|
| 7. | Config Metering Process | T | M |
|-------+-------------------------+-----+-----|
| 7. | Config Exporting Process| T | S |
Claise Expires April 2003 [Page 23]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
|-------+-------------------------+-----+-----|
| 7. | Config Flow | T | S |
| | Specifications | | |
|-------+-------------------------+-----+-----|
| 7. | Config Flow Timeouts | T | S |
|-------+-------------------------+-----+-----|
| 7. | Config Sampling | T | May |
|-------+-------------------------+-----+-----|
| 7. | Config Report | T | S |
| | Data Format | | |
|-------+-------------------------+-----+-----|
| 7. | Config Notifications | F | May |
|-------+-------------------------+-----+-----|
| 7. | Config Anonymization | T | May |
|-------+-------------------------+-----+-----|
| 8. | GENERAL REQUIREMENTS |
|-------+-------------------------+-----+-----|
| 8.1. | Openness | T | S |
|-------+-------------------------+-----+-----|
| 8.2. | Scalability: | | |
| | data collection | T | M |
| | from hundreds of | | |
| | measurement devices | | |
|-------+-------------------------+-----+-----|
| 8.3. | Several Collectors | T | May |
.-------+-------------------------+-----+-----.
Note that some of the requirements in the table above are not
necessarily applicable for the strict selection of the candidate
protocol. Up to the evaluation team not to consider those.
4. Security Considerations
Security considerations for the IPFIX protocol are covered by the
comparison against the specific Security requirements in the IPFIX
requirements document [IPFIX-REQ] where they are specifically
addressed by sections 6.3.3 and 10.
The NetFlow flow record export protocol could be run on the top of
IPSEC [IPSEC] to assure security.
5. References
[IPFIX-REQ] J. Quittek et al., "Requirements for IP Flow Information
Export", draft-ietf-ipfix-reqs-09.txt, work in progress,
August 2003.
[NETFLOW9-1] B. Claise et al., "Cisco Systems NetFlow Services
Export Version 9", draft-bclaise-netflow-9-01.txt, work
Claise Expires April 2003 [Page 24]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
in progress, October 2002
[UDP] J. Postel, "User Datagram Protocol", RFC 768, August
1980
[TCP] "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION", RFC 793, September 1981
[SCTP] R. Stewart et al, "Stream Control Transmission Protocol",
RFC 2960, October 2000
[IPSEC] Kent, S., "Security Architecture for the Internet
Protocol", RFC 2401, Nov. 1998,
6. Acknowledgments
I would like to thank Ganesh Sadasivan, Vamsidhar Valluri, Martin
Djernaes and Pritam Shah from Cisco Systems for the good technical
feedback on this Internet Draft.
Author's Address
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Claise Expires April 2003 [Page 25]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Oct. 2002
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Claise Expires April 2003 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-23 14:33:39 |