Internet Draft B. Claise
Document: draft-claise-ipfix-eval-netflow-00.txt Cisco Systems
Expires: Mars 2003 September 2002
Evaluation Of NetFlow Version 9 Against IPFIX Requirements
<draft-claise-ipfix-eval-netflow-00.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].
This document is the first version of the draft and should not be
considered as finished work. Updated version(s) will soon follow with
Claise Expires û February 2003 [Page 1]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
changes introduced by the publication of the new requirement draft version
6 [IPFIX-REQ6], and with the English syntax and grammar corrections.
Table of Contents
1. Introduction...................................................3
2. Architectural Considerations...................................5
2.1 NetFlow Protocol Overview..................................6
2.2 General Applicability......................................6
2.2.1 Flow Definition......................................6
2.2.2 Observation Point....................................7
2.2.3 The Metering Process and the Flow Record.............7
2.2.4 The Exporting Process................................7
2.2.5 The Collecting Process...............................7
2.3 Architectural Differences..................................8
3. Item Level Compliance Evaluation...............................9
3.1 Terminology (section 2)....................................9
3.1.1 IP Traffic Flow (2.1)................................9
3.1.2 Observation Point (2.2)..............................9
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).....10
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)..........................................11
3.3.5 DiffServ Code Point (4.5)...........................11
3.3.6 Header Compression and Encryption (4.6).............11
3.4 Metering Process (5)......................................11
3.4.1 Reliability (5.1)...................................12
3.4.2 Sampling (5.2)......................................12
3.4.3 Overload Behavior (5.3).............................12
3.4.4 Timestamps (5.4)....................................13
3.4.5 Time Synchronization (5.5)..........................13
3.4.6 Flow Expiration (5.6)...............................13
3.4.7 Multicast (5.7).....................................14
3.4.8 Ignore Port Copy (5.8)..............................14
3.5 Data Export (6)...........................................14
3.5.1 Information Model (6.1).............................14
3.5.2 Data Model (6.2)....................................15
3.5.3 Data Transfer (6.3).................................15
3.5.3.1 Congestion Awareness (6.3.1)....................15
3.5.3.2 Reliability (6.3.2).............................15
Claise Expires û Mars 2003 [Page 2]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
3.5.3.3 Security (6.3.3)................................15
3.5.4 Regular Reporting Interval (6.4)....................16
3.5.5 Notification on Specific Events (6.5)...............16
3.5.6 Anonymization (6.6).................................16
3.6 Configuration (7).........................................16
3.6.1 Configuration of the Metering Process (7.1).........16
3.6.2 Configuration of the Exporting Process (7.2)........16
3.7 General Requirements Compliance (8).......................16
3.7.1 Openness (8.1)......................................16
3.7.2 Scalability Concerning the Number of Exporting Processes
(8.2) 16
3.7.3 Several Collecting Processes (8.3)..................17
4. Security Considerations.......................................17
5. References....................................................17
6. Author's Address..............................................18
7. Full Copyright Statement......................................18
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 and 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
Claise Expires û Mars 2003 [Page 3]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
different versions along with the data types exported, some configuration
examples, etc. For reference, see:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/netflsol/nfwhite
.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], as well as in the following document:
http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/ntfo_wp.htm
- 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 [NETFLOW9].
- 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 control permits routing those packets to
their indicated destination.
Claise Expires û Mars 2003 [Page 4]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
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?
The NetFlow flow record export protocol version 9 protocol is currently at
the stage of the Early Field Test, while NetFlow flow record export
versions 1, 5, 7 and 8 have been implemented for years now.
- Is it already in commercial use?
Some Cisco Systems partners are currently developing NetFlow Collectors
(the correct term is ôcollecting processö according to [IPFIX-REQ]) able
to receive NetFlow version 9 flow records.
While 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?
The new NetFlow flow record export protocol version 9 is in Early Field
Test right now, while the previous NetFlow flow record export versions
have been implemented by our competitors. As a consequence, NetFlow is
widely used through out the industry.
2. Architectural Considerations
This section introduces the architecture of the NetFlow and suggests a way
of applying it to the communication between an IPFIX exporting process and
an IPFIX collecting process.
Claise Expires û Mars 2003 [Page 5]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
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 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.
- Even if the NetFlow flow record export protocol version 9 has been
created with a IP flow record background in mind, note that
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 address
Claise Expires û Mars 2003 [Page 6]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
and transport-layer source and destination 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 is enabled in most case per interface (per port), sometimes per
subinterface. On specific device, NetFlow is enabled for the entire
platform.
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.
2.2.4 The Exporting Process
The NetFlow enabled platform checks the NetFlow cache once per second and
expires the flow if no more traffic of that flow 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].
2.2.5 The Collecting Process
Claise Expires û Mars 2003 [Page 7]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
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)] |----------+
|[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.
Claise Expires û Mars 2003 [Page 8]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
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.
-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)
Claise Expires û Mars 2003 [Page 9]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
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)
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] contains all the data types needed to satisfy the
requirements of the different applications described in this
section.
Claise Expires û Mars 2003 [Page 10]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
3.3 Distinguishing Flows (4)
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).
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)
Total Compliance of the port numbers of the transport header as a
flow distinguisher.
3.3.4 MPLS (4.4)
Total Compliance of the MPLS label a flow distinguisher, if the
observation point is located at a device supporting Multiprotocol
Label Switching.
3.3.5 DiffServ Code Point (4.5)
Partial Compliance, as NetFlow distinguish flow by the TOS field.
3.3.6 Header Compression and Encryption (4.6)
Total Compliance.
3.4 Metering Process (5)
Claise Expires û Mars 2003 [Page 11]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
3.4.1 Reliability (5.1)
To be written.
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]: 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
sampling configuration with its parameters MUST be indicated to all
collecting processes receiving the affected flow records. Changing
the sampling configuration includes: start sampling, stop sampling,
change sampling method, and change sampling parameter.ô, as defined
in [IPFIX-REQ]ô. Partial Compliance. NetFlow supports the ôchange
sampling methodö and ôchange sampling parameterö options.
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.
ôBut in case the overload behavior has an impact on the metering
process or the exporting process, the overload behavior MUST be
clearly defined and the collecting process MUST be able to
distinguish the flow records exported before and after the metering
process behavior change:ö, as defined in [IPFIX-REQ].
If the metering process configuration is changed, then Total
Compliance.
But failed compliance in the following situation: in case the
NetFlow cache becomes full, the flow records will be expired with a
smaller timeout! In this specific case, this requirement doesnÆt
make sense.
ôIn case of any change of the meter's behavior, all flow records
metered by the previous behavior MUST be terminated and exported
Claise Expires û Mars 2003 [Page 12]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
according to the configuration of the exporting process.ö, as
defined in [IPFIX-REQ].
Total Compliance.
ôThe metering process MUST not merge the flow records generated with
the new behavior with the flow records generated with the previous
behavior.ö, as defined in [IPFIX-REQ].
If the metering process configuration is changed, then Total
Compliance because a new Template ID for the new configuration will
be generated.
But failed compliance in the following situation: in case the
NetFlow cache becomes full, the flow records will be expired with a
smaller timeout! In this specific case, this requirement doesnÆt
make sense.
3.4.4 Timestamps (5.4)
Total Compliance.
3.4.5 Time Synchronization (5.5)
The compliance is not relevant as the mechanism used for time
synchronization is outside the scope of the IPFIX.
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.
4. The active timer has expired after 30 minutes of traffic activity.
This active timer is configurable.
Claise Expires û Mars 2003 [Page 13]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
3.4.7 Multicast (5.7)
Total Compliance of the multicast support with the IPFIX
requirements.
3.4.8 Ignore Port Copy (5.8)
To be written.
3.5 Data Export (6)
3.5.1 Information Model (6.1)
ôThe exporting process MUST be able to report the following
attributes for each metered flowö, as defined in [IPFIX-REQ]:
1. IP version number: Upcoming Compliance (NetFlow will support
IPV6)
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. input interface (ifIndex): Total Compliance
8. output interface (ifIndex): Total Compliance
9. packet counter: Total Compliance
10. byte counter: Total Compliance
11. in case of IPv4, Type of Service: Total Compliance
12. in case of IPv6, Flow Label: Upcoming Compliance
13. if BGP is supported at the observation point, BGP AS number:
Total Compliance
14. if MPLS is supported at the observation point, MPLS label:
Total Compliance
15. if DiffServ is supported at the observation point, DSCP:
Partial Compliance
16. timestamp of the first packet of the flow: Total Compliance
17. timestamp of the last packet of the flow: Total Compliance
18. if sampling is used, sampling configuration: Total Compliance
19. unique identifier of the observation point: Total Compliance
(the ifIndex)
20. unique identifier of the exporting process: Total Compliance
(the IP address)
ôThe exporting process SHOULD be able to report the following
attributes for each metered flowö, as defined in [IPFIX-REQ]:
Claise Expires û Mars 2003 [Page 14]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
21. 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]:
22. Time To Live: Extension required for total compliance
23. IP header flags: Extension required for total compliance
24. TCP header flags: Total Compliance
25. dropped packet counter at the observation point: Extension
required for total compliance
26. fragmented packet counter: Extension required for total
compliance
3.5.2 Data Model (6.2)
ôThe data model MUST be extensibleö, as defined in [IPFIX-REQ].
Total compliance.
ô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].
To be written.
3.5.3.2 Reliability (6.3.2)
Total Compliance. A sequence ID exists per export packet so that the
collecting process would know if it misses export packets or if
packets reordering occurred in the network.
3.5.3.3 Security (6.3.3)
Failed compliance for confidentiality, integrity and authenticity.
Claise Expires û Mars 2003 [Page 15]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
3.5.4 Regular Reporting Interval (6.4)
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
This activity timeout is configurable
3.5.5 Notification on Specific Events (6.5)
Failed compliance.
3.5.6 Anonymization (6.6)
To be written.
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.
3.7 General Requirements Compliance (8)
3.7.1 Openness (8.1)
Total Compliance.
3.7.2 Scalability Concerning the Number of Exporting Processes (8.2)
Claise Expires û Mars 2003 [Page 16]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
ô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.
3.7.3 Several Collecting Processes (8.3)
Total Compliance. The exporting process is able to export flow
information to two different collecting process.
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-05.txt, work in progress,
July 2002.
[IPFIX-REQ6] J. Quittek et al., "Requirements for IP Flow Information
Export", draft-ietf-ipfix-reqs-06.txt, work in progress,
July 2002.
[NETFLOW9] B. Claise et al., "Cisco Systems NetFlow Services Export
Version 9", draft-bclaise-netflow-9-00.txt, work in progress,
June 2002.
[UDP] J. Postel, "User Datagram Protocol", RFC 768, August
1980
[TCP] "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM
Claise Expires û Mars 2003 [Page 17]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
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. Author's Address
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
Email: bclaise@cisco.com
7. 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
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
Claise Expires û Mars 2003 [Page 18]
Evaluation Of NetFlow Version 9 Against IPFIX Requirements Sept. 2002
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 û Mars 2003 [Page 19]