IPFIX working group
Internet Draft EDITORS: B. Claise
draft-ietf-ipfix-protocol-02.txt Cisco Systems
Expires: July 2004 Mark Fullmer
OARnet
Paul Calato
Riverstone Networks
Reinaldo Penno
Nortel Networks
January 2003
IPFIX Protocol Specifications
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document discusses the IPFIX protocol that provides network
administrators with access to IP flows information. This document
focuses on how IPFIX flow record data, options record data and
control information is carried (via a congestion-aware transport
protocol) from IPFIX exporting process to IPFIX collecting process.
Conventions used in this document
Claise, et. al Standard Track [Page 1]
IPFIX Protocol Specifications January 2004
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Table of Contents
1. Points of Discussion.........................................3
1.1 Open Issues................................................3
1.2 Action Items...............................................5
2. Introduction.................................................5
2.1 Overview...................................................5
3. Terminology..................................................6
3.1 Terminology Summary Table.................................10
4. The Metering Process........................................11
4.1 Flow Expiration...........................................11
5. Transport Protocol..........................................12
5.1 TCP.......................................................12
5.2 STCP......................................................12
5.2.1 Congestion Avoidance...................................12
5.2.2 Reliability............................................12
5.2.3 Exporting Process......................................13
5.2.3.1 MTU size..............................................13
5.2.3.2 Source ID.............................................13
5.2.3.3 Association...........................................13
5.2.3.4 Stream................................................14
5.2.3.5 Template..............................................14
5.2.4 Collecting Process.....................................14
5.2.5 SCTP Partially Reliable................................15
6. Failover....................................................16
6.1 Simple Failover based on the transport protocol...........16
6.2 Something else?...........................................16
7. Message Layout..............................................16
8. IPFIX Message Format........................................18
8.1 Header Format.............................................18
8.2 Field Type Format.........................................19
8.3 Template FlowSet Format...................................20
8.3.1 IETF Exclusive Template FlowSet Format.................20
8.3.2 Vendor Specified Template FlowSet Format...............22
8.4 Data FlowSet Format.......................................24
9. Options.....................................................25
9.1 Options Template FlowSet Format...........................25
9.1.1 IETF Exclusive Options Template FlowSet Format.........25
9.1.2 Vendor Specified Options Template FlowSet Format.......27
9.2 Options Data Record Format................................29
9.3 Specific IPFIX Options Templates..........................30
9.3.1 The Metering Process Statistics Option Template........31
10. Export Packet UNIX Secs Computation and Flow Record Times..31
10.1 Microsecond Precision....................................31
10.2 Millisecond Precision....................................32
Claise, et. al Standard Track [Page 2]
IPFIX Protocol Specifications January 2004
10.3 Nanosecond Precision.....................................33
10.4 Multiple Precisions......................................33
11. Linkage with the Information Model.........................33
11.1 Boolean..................................................33
11.2 Byte.....................................................34
11.3 UnsignedByte.............................................34
11.4 Short....................................................34
11.5 Reduced Size Encoding of Integral Types..................34
12. Variable Length Data Type..................................35
13. Template Management........................................36
14. The Collecting Process's Side..............................37
15. Security Considerations....................................39
16. IANA Considerations........................................43
17. Examples...................................................43
17.1 Message Header Example...................................44
17.2 Template FlowSet Example.................................44
17.3 Data FlowSet Example.....................................45
17.4 Options Template FlowSet Example.........................46
17.5 Data FlowSet with Options Data Records Example...........46
18. References.................................................47
18.1 Normative References.....................................47
18.2 Informative References...................................47
19. Acknowledgments............................................48
1. Points of Discussion
1.1 Open Issues
This section covers the open issues, still to be resolved/updated in
this draft:
- The proposal on the table is to send a IPFIX Sync (this would be
an Options Data Records) message periodically (periodicity is
configurable), with the following information (aside the standard
IPFix header)
* Number of flow records sent (for each template?)
* Packets and bytes sent (for each template?)
Question: Per observation domain?
Question: Do we need a specific FlowSet ID?
- Template don't need lifetimes with connection oriented protocol.
We guess this is the consensus from the Working Group.
The section 11 "Template Management" will have to updated according
to the transport protocol. For example, the point 2 of the section
11 "Template Management"
Claise, et. al Standard Track [Page 3]
IPFIX Protocol Specifications January 2004
- No periodic retransmission of templates is needed, with a reliable
transport protocol.
Remark: the template management will vary with TCP, SCTP, etcà
Must have both sections updated: transport updated and template
management sections (BTW, this is the same for the failover
section).
- Export ID (ie IP address of exporter) sent to the collector. This
can be done once with an options template.
- Metering process stats: for example packets / flows dropped at the
metering process due to resource exhaustion, etcà This can be done
with an options template.
- Error recovery, for example what to do if a collector receives a
message it can't decode. Per protocol issue, ie TCP reset the
session because it's a stream protocol and can't recover.
- If we tackle reliability a state diagram is needed.
- Talk a little bit about extensibility, for example make some
decisions now about the reserved template ID's 2-254 for future
work.
- Abstract. This document "specifies" + expand it
- Must develop a Security Section
- IANA considerations section to be expanded.
- Potentially some discrepancies between data types, field type and
Information Element terminology.
- Need an example with the Vendor Specified Information Element
- Review the requirements draft to see what we miss, once it's an I-
RFC
- Templates identified by FLowset IDs, 0 => 'template,' 1 =>
'options template,' [2,255] => reserved, [256 ) => 'data template.'
Need to specify this (and mechanism for defined other 'well-known'
values in IANA Considerations section (not yet written).
- Section 5.2.3.3, Association: What happens if the Exporter gets no
response from any Collector? I think we should specify a (not-too-
aggressive) retry algorithm.
- æætransport protocolÆÆ section to be updated.
Note: each transport protocol (TCP/SCTP) should have at least the
following subsections: Reliability, Failover, Template Management
Bert Wijnen is currently working on this issue:
http://
ipfix.doit
.wisc.edu/archive/2336.html
- Nevil comment: Section 10: Variable Length Data Type: Surely this
really belongs in the Info Model I-D? The Info Model I-D defines the
'string' data type as "finite length string of valid characters .."
It needs to say something about whether the length is fixed or
Claise, et. al Standard Track [Page 4]
IPFIX Protocol Specifications January 2004
variable. Seems to me that making all strings be variable-length
would be fine.
- IANI considerations section to be updated: have a look at RFC
2434, which sets out guidelines for IANA Considerations. Also,
searching the RFCs for 'IANA Considerations' brings up quite a few
RFCs to look at as models.
- Flow Sampling. This is mentioned in both the Requirements I-D and
the AS I-D. We need to decide how it should be covered in the IPFIX
drafts.
- Section 11.4 must be completed with type used in [IPFIX-INFO]
- Protocol Extensions must be discussed in the draft
- Need a consensus/discussion on section 9.3.1 "The Metering Process
Statistics Option Template". The [IPFIX-INFO] needs also the
appropriate data types
1.2 Action Items
This section covers the action items for this draft
- 4.1 Flow Expiration -> add the notion of integers versus
counters, after minneapolis WG consensus
- Use of MUST/SHOULD vs must/should: this is a Standards Track
draft, there are lots of places I think RFC 2119 (upper case) would
be more appropriate, starting with section 5.2.3.1. (Most of these
would be simple 'editing' changes).
- 9.2 Options Data Record Format
The Options Data Records are sent in Data FlowSets, on a regular
basis, but not with every Flow Data Record. How frequently these
Options Data Records are exported is configurable. See the Templates
Management" section for more details.
-> not the right section + expand
- check the examples with the information model
- I received the comment to number all the figures
2. Introduction
2.1 Overview
The IPFIX protocol provides network administrators with access to IP
flows information. The architecture for the export of measured IP
flow information out of an IPFIX exporting process to a collecting
processing is defined in [IPFIX-ARCH], per the requirements defined
in [IPFIX-REQ]. [IPFIX-PROTO] specifies how IPFIX flow record data,
options record data and control information is carried via a
Claise, et. al Standard Track [Page 5]
IPFIX Protocol Specifications January 2004
congestion-aware transport protocol from IPFIX exporting process to
IPFIX collecting process. IPFIX has a formal description of IPFIX
information elements (fields), their name, type and additional
semantic information, as specified in [IPFIX-INFO]. Finally [IPFIX-
AS] describes what type of applications can use the IPFIX protocol
and how they can use the information provided. It furthermore shows
how the IPFIX framework relates to other architectures and
frameworks.
3. Terminology
The definitions of IP Traffic Flow, Metering Process, Exporting
Process and Collecting Process are the definitions as found in the
IPFIX requirement document [IPFIX-REQ]. Note nevertheless that,
even if the Observation Point definition has been also been
completely copied over from the IPFIX requirement document [IPFIX-
REQ], this definition has been expanded.
The terminology summary table in Section 3.1 gives a quick overview
of the relationships between some of the different terms defined.
Observation Point
The Observation Point is a location in the network where IP packets
can be observed. Examples are a line to which a probe is attached,
a shared medium such as an Ethernet-based LAN, a single port of a
router, or a set of interfaces (physical or logical) of a router.
An Observation Domain is associated with every Observation Point.
Note that one Observation Point may be a superset of several
other Observation Points. For example one Observation Point can be
an entire line card. This would be the superset of the
individual Observation Points at the line card's interfaces.
Observation Domain
The set of Observation Points, which is the largest aggregatable set
of Flow information at the Metering Process is termed an Observation
Domain. Each Observation Domain presents itself as a unique ID to
the Collecting Process for identifying the IPFIX Messages it
generates.
For example, a router line card composed of several interfaces with
each interface being an Observation Point.
Claise, et. al Standard Track [Page 6]
IPFIX Protocol Specifications January 2004
IP Traffic Flow or Flow
There are several definitions of the term 'flow' being used by the
Internet community. Within this document we use the following one:
A Flow is defined as a set of IP packets passing an Observation
Point in the network during a certain time interval. All packets
belonging to a particular Flow have a set of common properties. Each
property is defined as the result of applying a function to the
values of:
1. one or more packet header field (e.g. destination IP
address), transport header field (e.g. destination port
number), or application header field (e.g. RTP header fields
[RFC1889])
2. one or more characteristics of the packet itself (e.g.
number of MPLS labels, etc...)
3. one or more of fields derived from packet treatment (e.g.
next hop IP address, the output interface, etc...)
A packet is defined to belong to a Flow if it completely satisfies
all the defined properties of the Flow.
This definition covers the range from a Flow containing all packets
observed at a network interface to a Flow consisting of just a
single packet between two applications with a specific sequence
number. Please note that the Flow definition does not necessarily
match a general application-level end-to-end stream. However, an
application may derive properties of application-level streams by
processing measured Flow data. Also, please note that although
packet properties may depend on application headers, there is no
requirement defined in this document related to application headers.
Flow Record
A Flow Record provides information about an IP Traffic Flow observed
at an Observation Point.
Metering Process
The Metering Process generates Flow Records. Input to the process
are packet headers observed at an Observation Point and packet
Claise, et. al Standard Track [Page 7]
IPFIX Protocol Specifications January 2004
treatment at the Observation Point, for example the selected output
interface.
The Metering Process consists of a set of functions that includes
packet header capturing, timestamping, sampling, classifying, and
maintaining Flow Records.
The maintenance of Flow Records may include creating new records,
updating existing ones, computing Flow statistics, deriving further
Flow properties, detecting Flow expiration, passing Flow Records to
the Exporting Process, and deleting Flow Records.
The sampling function and the classifying function may be applied
more than once with different parameters. Figure 1 shows the
sequence in which the functions are applied. Sampling is not
illustrated in the figure, it may be applied before any other
function.
packet header capturing
|
timestamping
|
v
+----->+
| |
| classifying
| |
+------+
|
maintaining Flow Records
|
v
Figure 1: Functions of the Metering Process
Exporting Process
The Exporting Process sends Flow Records to one or more Collecting
Processes. The Flow Records are generated by one or more Metering
Processes.
Collecting Process
Claise, et. al Standard Track [Page 8]
IPFIX Protocol Specifications January 2004
The Collecting Process receives Flow Records from one or more
Exporting Processes. The Collecting Process might store received
Flow Records or further process them, but these actions are out of
the scope of this document.
IPFIX Message
An IPFIX Message is a message originating at the Exporting Process
that carries the Flow Records of this Exporting Process and whose
destination is the Collecting Process.
Message Header
The Message Header is the first part of an IPFIX Message, which
provides basic information about the message such as the IPFIX
version, length of the message, message sequence number, etc.
Template Record
A Template Record defines the structure and interpretation of fields
in a Flow Data Record.
Flow Data Record
A Flow Data Record is a data record that contains values of the Flow
parameters corresponding to a Template Record. In this document, the
Flow Data Record is also referred to as Flow Record.
Options Template Record
An Options Template Record defines the structure and interpretation
of fields in an Options Data Record, including defining how to scope
the applicability of the Options Data Record.
Options Data Record
The Options Data Record is a data record that contains values and
scope information of the Flow measurement parameters, corresponding
to an Options Template Record.
FlowSet
Claise, et. al Standard Track [Page 9]
IPFIX Protocol Specifications January 2004
FlowSet is a generic term for a collection of records that have a
similar structure. In an IPFIX Message, one or more FlowSets follow
the Message Header.
There are three different types of FlowSets: Template FlowSet,
Options Template FlowSet, and Data FlowSet.
Template FlowSet
A Template FlowSet is a collection of one or more Template Records
that have been grouped together in an IPFIX Message.
Options Template FlowSet
An Options Template FlowSet is a collection of one or more Options
Template Records that have been grouped together in an IPFIX
Message.
Data FlowSet
A Data FlowSet is one or more records, of the same type, that are
grouped together in an IPFIX Message. Each record is either a Flow
Data Record or an Options Data Record previously defined by a
Template Record or an Options Template Record.
Information Element
An Information Element is a protocol and encoding independent
description of an attribute which may appear in an IPFIX flow
record. The IPFIX information model [IPFIX-INFO] defines the base
set of Information Elements for IPFIX. The type associated with an
Information Element indicates constraints on what it may contain and
also determine the valid encoding mechanisms for use in IPFIX.
3.1 Terminology Summary Table
FlowSet Template Record Data Record
+----------------------------------------------------------------+
| | | Flow Data Record(s) |
| Data FlowSet | / | or |
| | | Options Data Record(s) |
+----------------------------------------------------------------+
| Template FlowSet | Template Record(s) | / |
Claise, et. al Standard Track [Page 10]
IPFIX Protocol Specifications January 2004
+----------------------------------------------------------------+
| Options Template | Options Template | / |
| FlowSet | Record(s) | |
+----------------------------------------------------------------+
A Data FlowSet is composed of an Options Data Record(s) or Flow Data
Record(s). No Template Record is included. A Template Record defines
the Flow Data Record, and an Options Template Record defines the
Options Data Record.
A Template FlowSet is composed of Template Record(s). No Flow or
Options Data Record is included.
An Options Template FlowSet is composed of Options Template
Record(s). No Flow or Options Data Record is included.
4. The Metering Process
The description of the Metering Process (for example, sampled or
not, aggregation or not), which is the way in which Flows are
created from the observed IP packets, is beyond the scope of this
document. Nevertheless, some aspects of the Metering Process have
some influences on the IPFIX protocol
4.1 Flow Expiration
A Flow is considered to be inactive if no packets belonging to the
Flow have been observed at the Observation Point for a given
timeout. If any packet is seen within the timeout, the flow is
considered an active Flow.
A Flow can be exported under the following conditions:
1. If the Metering Process can detect the end of a Flow. For
example, if the FIN or RST bit is detected in a TCP [TCP]
connection, the Flow Record is exported.
2. If the Flow has been inactive for a certain period of time.
This inactivity timeout SHOULD be configurable at the Metering
Process, with a minimum value of 0 for an immediate expiration.
3. For long-lasting Flows, the Exporting Process SHOULD export
the Flow Records on a regular basis. This timeout SHOULD be
configurable at the Metering Process.
Claise, et. al Standard Track [Page 11]
IPFIX Protocol Specifications January 2004
4. If the Metering Process experiences internal constraints, a
Flow MAY be forced to expire prematurely; for example, counters
wrapping or low memory.
5. Transport Protocol
The IPFIX Protocol Specifications have been designed to be transport
protocol independent. It can operate over congestion-aware protocols
such as TCP [TCP] or SCTP [RFC2960].
Note that the Exporter can export to multiple Collecting Processes,
using independent transport protocols.
5.1 TCP
To be completed.
TCP [TCP]
5.2 STCP
This section describes how IPFIX can be transported over SCTP
[RFC2960] using traditional reliable mode.
IPFIX can also be transported over the partial reliable or
unreliable mode [PR-SCTP]. These last 2 modes will be briefly
discussed, while waiting for [PR-SCTP] to become a standard.
5.2.1 Congestion Avoidance
The SCTP transport protocol provides the required level of
congestion avoidance by design.
5.2.2 Reliability
The SCTP transport protocol is by default reliable, but has the
capability to operate in unreliable and partially reliable modes
[PR-SCTP].
Using reliable SCTP streams (referred to hereafter as "streams") for
the IPFIX export is not in itself a guarantee that all records are
delivered. If there is congestion on the link from the exporter to
the collector, or if a significant
Claise, et. al Standard Track [Page 12]
IPFIX Protocol Specifications January 2004
amount of retransmissions are needed, the send queues on the
Exporting Process may fill up. In that case it's up to the Exporting
Process to decide what to do. It may either halt export (buffer the
data until there is space in the send queues again) or discard IPFIX
Messages away instead of inserting them into the send queue. If any
data is not inserted into the send queues, the sequence numbers used
for export must reflect the loss of data.
5.2.3 Exporting Process
5.2.3.1 MTU size
Each IPFIX Message should be equal to or less than the local MTU in
size. When an IPFIX Message is transmitted over a network with an
MTU smaller than the local MTU, IP fragmentation may be used.
5.2.3.2 Source ID
The IPFIX Message must contain a Message Header, which includes a
source id (SID). The SID indicates from which Observation Domain the
data is being exported, and should be kept unique for each such
Observation Domain.
If a Metering Process consists of a single Observation Domain, a
single SID value must be used for all IPFIX Messages. The Exporting
Process will typically open one association to the collector, but
more are possible, in which one or more streams can be used. The
Exporting Process has the choice of transmitting parts of the export
data in separate streams or all data in one stream.
If a Metering Process consists of multiple Observation Domains, one
SID value for each Observation Domain must be used. The Exporting
Process will typically open one association, but more are possible,
in which at least one stream per Observation Domain is used.
The Exporting Process has the choice of using more than one stream
per Observation Domain, but data from multiple Observation Domains
should not be transmitted over the same stream.
5.2.3.3 Association
The Exporting Process may create one or more associations
Claise, et. al Standard Track [Page 13]
IPFIX Protocol Specifications January 2004
(connection "bundle" in SCTP terminology) to the Collecting Process.
The Collecting Process may not initiate the connection. Inside each
association one or more streams may be requested by the Exporting
Process. If the Collecting Process can not support the requested
number of streams, it may choose to refuse the connection and the
Exporting Process should try to reduce, if possible, the number of
streams needed to perform the export.
5.2.3.4 Stream
An Observation Domain must use at least one stream, but may use
multiple streams, to export data records. The Observation Domain
must use the same SID value for all streams used.
An Exporting Process must not transmit messages with different SID
values in one stream, the Collecting Process should however verify
that the SID values are the expected values.
5.2.3.5 Template
Since the SCTP association is connection oriented the available
Template Records must be transmitted from each Observation Domain to
the Collecting Process immediately after the association is
established.
As a minimum the Template Records must be transmitted immediately
after they start to exist on the Metering Process and should
preferably be transmitted before any data, using the new Template
Record, have been transmitted. The Collecting Process should however
accept data without a Template Record.
When using a reliable mode for Template Record export, or if the
exporter knows that the IPFIX Message containing the templates was
positively acknowledged by the SCTP layer, it is not necessary to
periodically export the Template Records.
5.2.4 Collecting Process
The Collecting Process should listen for a new association request
from the Exporting Process. The Exporting Process will request a
number of streams to use for export. If the Collecting Process
doesn't support the number of streams inside the association, the
Claise, et. al Standard Track [Page 14]
IPFIX Protocol Specifications January 2004
Collecting Process must refuse the connection and continue listen
for a new request.
When data is received from an association, the Collecting Process
must correlate data, with the same SID (Source ID) value, from
multiple streams into one export Flow from an Observation Domain.
This allows the Observation Domain to use separate streams for
different types of
information.
The Collecting Process should verify that the received IPFIX
Messages inside one stream does not have differing SID values. The
Exporting Process must not transmit messages inside one stream with
multiple SID values. The correlated Flow Records are then treated
like a normal export Flow.
5.2.5 SCTP Partially Reliable
This mode will not be discussed any further until [PR-SCTP] becomes
a standard, even if this mode offers a few advantages:
freedom to use SCTP as a reliable, single stream transport, as well
as multiple streams with different properties, for example in terms
of reliability, carrying different data types dependant on their
importance for the system.
Unreliable or partial reliability may be chosen for one or more
streams inside an association. Unreliable transport may be preferred
where large amount of data is to be exported and keeping send queues
is either an unnecessary overhead or impractical. Partial
reliability may be chosen where a small amount of queuing is
possible.
Naturally it is better to send templates over a reliable stream and
send the data on an unreliable (or partial reliable) stream. When an
exporter handles data with different properties it might even be
preferable to send them over different streams according to those
properties.
Example: an Exporting Process can use two streams per Observation
Domain. A reliable stream could be used for exporting templates, to
reduce the likelihood of loss and to remove the need for blind
retransmissions, and a partial or unreliable stream for data, to
avoid buffering of large amounts of data.
Claise, et. al Standard Track [Page 15]
IPFIX Protocol Specifications January 2004
6. Failover
When to fail over?
How to fail back?
How to ensure stability of the failover mechanism (prevent
oscillations)?
Does the exporter open connections to all the potential collectors
and keep them primed with template info?
6.1 Simple Failover based on the transport protocol
In case the transport protocol is connection oriented.
So in case of TCP [TCP] or SCTP [RFC2960].
To be completed.
6.2 Something else?
Potentially based on some application level ACK from the exporter?
7. Message Layout
An IPFIX Message consists of a Message Header followed by one or
more FlowSets. The FlowSets can be any of the possible three types:
Template, Data, or Options Template.
IPFIX Message:
+--------+-------------------------------------------+
| | +----------+ +---------+ +----------+ |
|Message | | Template | | Data | | Options | |
| Header | | FlowSet | | FlowSet | | Template | ... |
| | | | | | | FlowSet | |
| | +----------+ +---------+ +----------+ |
+--------+-------------------------------------------+
A FlowSet ID is used to distinguish the different types of FlowSets.
FlowSet IDs lower than 256 are reserved for special FlowSets, such
as the Template FlowSet (ID 0) and the Options Template FlowSet (ID
1). The Data FlowSets have a FlowSet ID greater than 255.
The format of the Template, Data, and Options Template FlowSets will
be discussed later in this document. The Exporter MUST code all
fields of the different FlowSets in network byte order (big-endian).
Claise, et. al Standard Track [Page 16]
IPFIX Protocol Specifications January 2004
Following are some examples of IPFIX Messages:
1. An IPFIX Message consisting of interleaved Template, Data, and
Options Template FlowSets-A newly created Template is exported as
soon as possible. So if there is already an IPFIX Message with a
Data FlowSet that is being prepared for export, the Template and
Option FlowSets are also interleaved with this information, subject
to availability of space.
IPFIX Message:
+--------+--------------------------------------------------------+
| | +----------+ +---------+ +-----------+ +---------+ |
|Message | | Template | | Data | | Options | | Data | |
| Header | | FlowSet | | FlowSet | ... | Template | | FlowSet | |
| | | | | | | FlowSet | | | |
| | +----------+ +---------+ +-----------+ +---------+ |
+--------+--------------------------------------------------------+
2. An IPFIX Message consisting entirely of Data FlowSets-After the
appropriate Template Records have been defined and transmitted to
the Collecting Process, the majority of IPFIX Messages consists
solely of Data FlowSets.
IPFIX Message:
+--------+----------------------------------------------+
| | +---------+ +---------+ +---------+ |
|Message | | Data | ... | Data | ... | Data | |
| Header | | FlowSet | ... | FlowSet | ... | FlowSet | |
| | +---------+ +---------+ +---------+ |
+--------+----------------------------------------------+
3. An IPFIX Message consisting entirely of Template and Options
Template FlowSets-The Exporter MAY transmit a message containing
Template and Options Template FlowSets periodically to help ensure
that the Collecting Process has the correct Template Records and
Options Template Records when the corresponding Flow Data records
are received.
IPFIX Message:
+--------+-------------------------------------------------+
| | +----------+ +----------+ +----------+ |
|Message | | Template | | Template | | Options | |
| Header | | FlowSet | ... | FlowSet | ... | Template | |
Claise, et. al Standard Track [Page 17]
IPFIX Protocol Specifications January 2004
| | | | | | | FlowSet | |
| | +----------+ +----------+ +----------+ |
+--------+-------------------------------------------------+
8. IPFIX Message Format
8.1 Header Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sysUpTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIX Secs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Header Field Descriptions
Version
Version of Flow Record format exported in this message. The
value of this field is 0x000a for the current version.
Length
Total Length is the length of the IPFIX message, measured in
octets, including message Header and FlowSet(s).
sysUpTime
Time in milliseconds since this device was first booted.
UNIX Secs
Time in seconds since 0000 UTC 1970, at which the Export
Packet leaves the Exporter.
Sequence Number
Incremental sequence counter of all IPFIX Messages sent from
the current Observation Domain by the Exporting Process.
This value MUST be cumulative, and SHOULD be used by the
Claise, et. al Standard Track [Page 18]
IPFIX Protocol Specifications January 2004
Collector to identify whether any IPFIX Messages have been
missed.
Source ID
A 32-bit value that identifies the Exporter Process
Observation Domain. Collecting Process SHOULD use the
combination of the source IP address and the Source ID field
to separate different export streams originating from the
same Exporting Process.
8.2 Field Type Format
This section describes the Field Type format for both IETF specified
Information Elements [IPFIX-INFO] and Vendor Specified Information
Elements. Vendors need the ability to define proprietary Information
Elements, because, for example, they are delivering pre-standards
product, or the Information Element is in some way commercially
sensitive.
The Field Ids used to identify Information Elements are divided into
two non-overlapping ranges: the IETF specified range and the vendor
specified range. This partitioning of the identifiers into two
ranges allows the Collecting Process to discriminate between an IETF
specified Information Element and a Vendor Specified Information
Element. The vendor specified range is shared by all vendors, and
thus needs an accompanying vendor identifier to uniquely identify
it.
The format of an IETF defined Field Type is shown in Fig A.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig A: IETF defined Field Type
Where:
Field Type
A numeric value that represents the type of the field. Refer
Claise, et. al Standard Track [Page 19]
IPFIX Protocol Specifications January 2004
to [IPFIX-INFO].
Field Length
The length of the corresponding Field Type, in bytes. Refer
to [IPFIX-INFO].
The format of the Vendor Specified Field Type is shown in Fig B.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig B: Vendor Specified Field Type
Where:
Field Type
A numeric value that represents the type of the field. Refer
to [IPFIX-INFO].
Field Length
The length of the corresponding Field Type, in bytes. Refer
to [IPFIX-INFO].
Enterprise Number
IANA enterprise number [PEN] of the authority defining the
field type in this template record.
8.3 Template FlowSet Format
One of the essential elements in the IPFIX format is the Template
FlowSet. Templates greatly enhance the flexibility of the Flow
Record format because they allow the Collecting Process to process
Flow Records without necessarily knowing the interpretation of all
the data in the Flow Record.
8.3.1 IETF Exclusive Template FlowSet Format
Claise, et. al Standard Track [Page 20]
IPFIX Protocol Specifications January 2004
The IETF exclusive Template FlowSet MAY be used when the template
contains only IETF defined Information Elements. This format is
provided for backwards compatibility [NETFLOW9]. The format of the
IETF exclusive Template FlowSet is shown in Figure C.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 1 | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 1 | Field Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 2 | Field Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type N | Field Length N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 2 | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 1 | Field Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 2 | Field Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type M | Field Length M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID K | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure C: IETF Exclusive Template FlowSet Format
Field Descriptions
FlowSet ID
FlowSet ID value of 0 is reserved for the Template FlowSet.
Claise, et. al Standard Track [Page 21]
IPFIX Protocol Specifications January 2004
Length
Total length of this FlowSet. Because an individual Template
FlowSet MAY contain multiple Template Records, the Length
value MUST be used to determine the position of the next
FlowSet record, which could be any type of FlowSet. Length
is the sum of the lengths of the FlowSet ID, the Length
itself, and all Template Records within this FlowSet.
Template ID
Each of the newly generated Template Records is given a
unique Template ID. This uniqueness is local to the
Observation Domain that generated the Template ID.
Template IDs 0-255 are reserved for Template FlowSets,
Options FlowSets, and other reserved FlowSets yet to be
created. Template IDs of Data FlowSets are numbered from 256
to 65535.
Field Count
Number of fields in this Template Record. Because a Template
FlowSet usually contains multiple Template Records, this
field allows the Collecting Process to determine the end of
the current Template Record and the start of the next.
Field Type
A numeric value that represents the type of the field. Refer
to [IPFIX-INFO].
Field Length
The length of the corresponding Field Type, in bytes. Refer
to [IPFIX-INFO].
8.3.2 Vendor Specified Template FlowSet Format
A vendor specified Template FlowSet MUST be used when the template
contains one or more Vendor Specified Information Elements. A vendor
specified template MAY exclusively contain IETF defined Field Types.
A vendor specified template MAY contain Vendor Specified Information
Elements from multiple vendors.
The format of the Vendor Specified Template FlowSet is shown in
Figure D.
0 1 2 3
Claise, et. al Standard Track [Page 22]
IPFIX Protocol Specifications January 2004
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 1 | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 1 | Field Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 2 | Field Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type N | Field Length N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 2 | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 1 | Field Length 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type 2 | Field Length 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type M | Field Length M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure D: Vendor Specified Template Flowset
The definition of the fields in the Vendor Specified Template
FlowSet is identical to those described IETF exclusive Template
FlowSet Format Field Descriptions except:
FlowSet ID
FlowSet ID value of 2 is reserved for the Vendor Specified
Template FlowSet
Claise, et. al Standard Track [Page 23]
IPFIX Protocol Specifications January 2004
Enterprise Number
IANA enterprise number [PEN] of the authority defining the
field type in this template record.
8.4 Data FlowSet Format
The format of the Data FlowSet is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = Template ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 1 | Record 1 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 1 | Record 2 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data FlowSet Field Descriptions
FlowSet ID = Template ID
Each Data FlowSet is associated with a FlowSet ID. The
FlowSet ID maps to a (previously generated) Template ID. The
Collecting Process MUST use the FlowSet ID to find the
corresponding Template Record and decode the Flow Records
from the FlowSet.
Length
The length of this FlowSet.
Length is the sum total of lengths of FlowSet ID, Length
itself, all Flow Records within this FlowSet, and the
padding bytes, if any.
Record N - Field Value M
Claise, et. al Standard Track [Page 24]
IPFIX Protocol Specifications January 2004
The remainder of the Data FlowSet is a collection of Flow
Data Record(s), each containing a set of field types and
values. The Type and Length of the fields have been
previously defined in the Template Record referenced by the
FlowSet ID or Template ID.
Padding
The Exporting Process SHOULD insert some padding bytes so
that the subsequent FlowSet starts at a 4-byte aligned
boundary. It is important to note that the Length field
includes the padding bits.
Interpretation of the Data FlowSet format can be done only if the
Template FlowSet corresponding to the Template ID is available at
the Collecting Process.
9. Options
9.1 Options Template FlowSet Format
The Options Template Record (and its corresponding Options Data
Record) is used to supply information about the Metering Process
configuration or Metering Process specific data, rather than
supplying information about IP Flows.
For example, the Options Template FlowSet can report the sample rate
of a specific interface, if sampling is supported, along with the
sampling method used.
9.1.1 IETF Exclusive Options Template FlowSet Format
The IETF exclusive Options Template FlowSet Format MAY be used
when the template contains only IETF defined options. This format
is provided for backwards compatibility [NETFLOW9]. The format of
the IETF exclusive Options Template FlowSet Format is shown in
Figure E.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Option Scope Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Claise, et. al Standard Track [Page 25]
IPFIX Protocol Specifications January 2004
| Option Length | Scope 1 Field Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope N Field Length | Option 1 Field Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option 1 Field Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option M Field Length | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure E: IETF Exclusive Options Template FlowSet
The IETF Exclusive Options Template FlowSet Field Definitions are
as follows:
FlowSet ID = 1
A FlowSet ID value of 1 is reserved for the Options
Template.
Length
Total length of this FlowSet. Each Options Template FlowSet
MAY contain multiple Options Template Records. Thus, the
Length value MUST be used to determine the position of the
next FlowSet record, which could be either a Template
FlowSet or Data FlowSet.
Length is the sum total of lengths of FlowSet ID, the Length
itself, and all Options Template Records within this FlowSet
Template ID.
Template ID
Template ID of this Options Template. This value is greater
than 255.
Option Scope Length
The length in bytes of any Scope fields definition contained
in the Options Template Record (The use of "Scope" is
described below).
Option Length
The length (in bytes) of any options field definitions
contained in this Options Template Record.
Claise, et. al Standard Track [Page 26]
IPFIX Protocol Specifications January 2004
Scope 1 Field Type
The relevant portion of the Exporting Process/Metering
Process to which the Options Template Record refers.
Currently defined values are:
1 System
2 Interface
3 Line Card
4 Cache
5 Template
For example, the Metering Process can be implemented on a
per-interface basis, so if the Options Template Record were
reporting on how the Metering Process is configured, the
Scope for the report would be 2 (interface). The associated
interface ID would then be carried in the associated Options
Data FlowSet. The Scope can be limited further by listing
multiple scopes that all must match at the same time. Note
that the Scope fields always precede the Option fields.
Scope 1 Field Length
The length (in bytes) of the Scope field, as it would appear
in an Options Data Record.
Option 1 Field Type
A numeric value that represents the type of field that would
appear in the Options Template Record. Refer to [IPFIX-
INFO].
Option 1 Field Length
The length (in bytes) of the Option Field.
Padding
The Exporting Process SHOULD insert some padding bytes so
that the subsequent FlowSet starts at a 4-byte aligned
boundary. It is important to note that the Length field
includes the padding bits.
9.1.2 Vendor Specified Options Template FlowSet Format
A vendor specified Options Template MUST be used when the template
contains one or more vendor specified options. A vendor specified
Options Template MAY exclusively contain IETF defined Field Types. A
vendor specified template MAY contain Vendor Specified Information
Elements from multiple vendors.
Claise, et. al Standard Track [Page 27]
IPFIX Protocol Specifications January 2004
The format of the Vendor Specified Options Template FlowSet is shown
in Figure E.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID | Option Scope Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Reserved must be zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Type | Scope 1 Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope N Field Type | Scope N Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope N Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option 1 Field Type | Option 1 Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option 1 Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option N Field Type | Option N Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure E: Vendor Specified Option Template FlowSet
The definition of the fields in the vendor specified Options
Template FlowSet is identical to those described IETF Exclusive
Options Template FlowSet Format Field Descriptions except:
FlowSet ID = 3
A FlowSet ID value of 3 is reserved for a VI Qualified
Options Template.
Scope N Enterprise Number
IANA enterprise number [PEN] of the authority defining
Scope N.
Claise, et. al Standard Track [Page 28]
IPFIX Protocol Specifications January 2004
Option N Enterprise Number
IANA enterprise number [PEN] of the authority defining the
Option N field type.
9.2 Options Data Record Format
The Options Data Records are sent in Data FlowSets, on a regular
basis, but not with every Flow Data Record. How frequently these
Options Data Records are exported is configurable. See the Templates
Management" section for more details.
The format of the Data FlowSet containing Options Data Records
follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = Template ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Scope 1 Value |Record 1 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 1 - Option Field 2 Value| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Scope 1 Value |Record 2 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 2 - Option Field 2 Value| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Scope 1 Value |Record 3 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 3 - Option Field 2 Value| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Options Data Records of the Data FlowSet Field Descriptions
FlowSet ID = Template ID
A FlowSet ID precedes each group of Options Data Records
within a Data FlowSet. The FlowSet ID maps to a previously
generated Template ID corresponding to this Options Template
Record. The Collecting Process MUST use the FlowSet ID to
Claise, et. al Standard Track [Page 29]
IPFIX Protocol Specifications January 2004
map the appropriate type and length to any field values that
follow.
Length
The length of this FlowSet.
Length is the sum of the lengths of the FlowSet ID, Length
itself, all the Options Data Records within this FlowSet,
and the padding bytes, if any.
Record N - Option Field M Value
The remainder of the Data FlowSet is a collection of Flow
Records, each containing a set of scope and field values.
The type and length of the fields were previously defined in
the Options Template Record referenced by the FlowSet ID or
Template ID.
Padding
The Exporting Process SHOULD insert some padding bytes so
that the subsequent FlowSet starts at a 4-byte aligned
boundary. It is important to note that the Length field
includes the padding bits.
The Data FlowSet format can be interpreted only if the Options
Template FlowSet corresponding to the Template ID is available at
the Collecting Process.
9.3 Specific IPFIX Options Templates
Some specific Options Templates and Options Templates Records are
necessary to provide extra information about the Flow Records and
about the Metering Process.
The ipfixOption [IPFIX-INFO], always included in these specific
Options Templates, defines the type of information sent in the Option
Template / Option Template Record pair. For example, if the
ipfixOption [IPFIX-INFO] value is METER_STATS, then the Option
Template will specify information about the Metering Process
statistics. The ipfixOption [IPFIX-INFO] MUST always be the first Data
Type in the Option Template so that the Collector could quickly
determine whether or not a specific Option Template is described. And
if the ipfixOption [IPFIX-INFO] is present, which specific Option
Template type it defines.
Claise, et. al Standard Track [Page 30]
IPFIX Protocol Specifications January 2004
The minimum set of Data Types is always specified in these Specific
IPFIX Options Templates. Nevertheless, extra Data Types MAY be used in
these specific Options Templates.
9.3.1 The Metering Process Statistics Option Template
The Metering Process Statistics Option Template defines the Metering
Process Statistics with the export of the following Data Types [IPFIX-
INFO]:
ipfixOption The value MUST be METER_STATS
observationDomain Source ID
lostFlows flows not exported due to resource
starvation(**)
lostFlowsPacket Packets in the lost flows (**)
lostFlowsBytes Bytes in the lost flows (**)
droppedPacketCount Packets dropped by Metering Process
at the Observation Point
droppedByteCount Bytes dropped by Metering Process at the
Observation Domain
time; When this record was generated
The minimum set of Data Type in the Metering Process Statistics Option
Template is: ipfixOption, observationDomain, lostFlows, time
10. Export Packet UNIX Secs Computation and Flow Record Times
10.1 Microsecond Precision
For a Data FlowSet with Flow Records requiring microsecond
precision, the Export Packet UNIX Secs field MUST be calculated so
that each Flow Records flowStartUsec
[IPFIX-INFO] and flowEndUsec [IPFIX-INFO] would contain a 32 bit
signed microsecond offset from the UNIX Secs base timestamp.
Hereafter some pseudo code to calculate the UNIX Secs in one pass,
which would return an absolute duration of 35 minutes for all Flow
Records contained in the Data FlowSet. Flow Records MUST be exported
in different Export Packet if the absolute duration can not fit in
those 35 minutes.
// pseudo code for microsecond offset in IPFIX encoded Flow Records.
//
struct flow{
Claise, et. al Standard Track [Page 31]
IPFIX Protocol Specifications January 2004
uint32 tv_sec;
uint32 tv_usec;
uint32 numbytes;
... // other information elements...
};
struct flow flowtable [MAX_TABLE_SIZE];
int lastflowindex = -1;
writeflows() {
if (lastflowindex < 0) return;
// simply take the second field from the first available flow
// and make this the base time for this collection of flows.
uint32 base_sec = flowtable[0].tv_sec;
writeheaderToSocket(base_sec); // put 32-bit second value in header
for (int i=0; i<=lastflowindex; i++){
int32 offset = (flowtable[i].tv_sec - base_sec) * 1000000 +
flowtable[i].tv_usec;
writeint32ToSocket(offset); // put the 32-bit time offset in the
record.
// write other information elements...
}
}
A two pass approach calculation for the optimum (center) UNIX Secs
base timestamp would allow an absolute duration of 71 minutes for
all Flow Records contained in the Data FlowSet. The two pass
approach MAY be used.
The UNIX Secs base timestamp calculation requires that at the Export
Packet exporting time the Exporting Process MUST run down the list
of Flow Records in the Data FlowSet message and adjust the Flow
start and Flow end timestamps.
10.2 Millisecond Precision
For a Data FlowSet with Flow Records requiring a millisecond
precision, the same principles as in section 9.1 "Microsecond
Precision" will be used.
The only difference will be that the Flow start and the Flow end
SHOULD now be represented respectively by the flowStartMsec [IPFIX-
INFO] and flowEndMsec [IPFIX-INFO]. As a consequence of the
Claise, et. al Standard Track [Page 32]
IPFIX Protocol Specifications January 2004
millisecond precision, the absolute duration of all Flow Records is
now of about 49 days. The Export Header UNIX Secs base time SHOULD
be calculated with the algorithm described in the Section 9.1
"Microsecond Precision". In order to reduce the load on the
Exporter, the Export Header UNIX Secs MAY be the time in seconds
since 0000 UTC 1970 at which the Export Packet leaves the Exporter
and not the calculated optimum value anymore as described in section
9.1 "Microsecond Precision".
Alternatively, for a Data FlowSet with Flow Records requiring a
millisecond precision, the microsecond mechanism as described in
section 9.1 MAY be used as such. The Flow Record MAY use the
flowStartUsec [IPFIX-INFO] and flowEndUsec [IPFIX-INFO] rounded at a
millisecond precision.
10.3 Nanosecond Precision
For a Data FlowSet with Flow Records requiring a nanosecond
precision, all Flow Records will contain Flow start flowStartNsec
[IPFIX-INFO] and flowEndNsec [IPFIX-INFO]. The Export Header UNIX
Secs will be of no use on the Collector side in this case as
the flowStartNsec [IPFIX-INFO] and flowEndNsec [IPFIX-INFO] both
have a nanosecond precision already. Both flowStartNsec [IPFIX-INFO]
and flowEndNsec [IPFIX-INFO] use the NTP time format which is
represented as a 64-bit value which contains a 32-bit specification
of seconds since 1900 and a 32-bit "fraction" field. Refer to the
NTP specification, RFC1305, section 3.1 "Data Formats".
10.4 Multiple Precisions
When Flow Records requiring different precisions must be exported,
the Exporting Process SHOULD split the Flow Records in different
Data FlowSet according to the precision: millisecond, microsecond
or nanosecond.
11. Linkage with the Information Model
The information model associates each IPFIX Data Type with a well
defined type, such as hexBinary, long, unsignedInt, etc.
This document defines how fields of a given type are encoded.
11.1 Boolean
Claise, et. al Standard Track [Page 33]
IPFIX Protocol Specifications January 2004
A boolean field shall be encoded in a single byte with the value of
0 indicating false and any other value indicating true.
11.2 Byte
A byte value shall be encoded as a single byte representing a value
between -128 and 127. The value is represented in two's complement
notation.
11.3 UnsignedByte
An unsigned byte value shall be encoded as a single byte
representing a value between 0 and 255.
11.4 Short
A short is a 16-bit datum that encodes an integer in the range [-
32768,32767]. The short is represented in two's complement
notation. The most and least significant bytes are 0 and 1,
respectively
EDITOR NOTE: this section 11 must be completed with types used in
[IPFIX-INFO], taking the descriptions from XDR RFC1832, sections 3.x
11.5 Reduced Size Encoding of Integral Types
Information Elements containing integral types in the information
model MAY be encoded using fewer bytes than those implied by their
type in the information model definition [IPFIX-INFO], based on the
assumption that the smaller type is sufficient to carry any value
the Exporter may need to deliver. This reduces the network bandwidth
requirement between the Exporter and the Collector. Note that the
information model Data Types definition [IPFIX-INFO] will always
define the maximum encoding size for each Data Type.
For instance the information model [IPFIX-INFO] defines byteCount as
an unsignedLong type, which would require 64-bits. However if the
exporter will never locally encounter the need to send a value
larger than 4294967295, it may chose to send the value instead as an
unsignedInt. For example, a core router would require an
unsignedLong byteCount while an unsignedInt might be sufficient for
Claise, et. al Standard Track [Page 34]
IPFIX Protocol Specifications January 2004
an access router.
This behavior is indicated by the exporter by specifying a type size
smaller than that associated with the assigned type of the field. In
the example above the exporter would place a length of 4 vs. 8 in
the template.
Reduced sizing MAY only be applied to the following integral types:
short, unsignedShort, int, unsignedInt, long, unsignedLong. In each
case the downcasting must be to a smaller integral type which MUST
have the same signed vs. unsigned properties.
Specifically unsignedLong may be downcast to unsignedInt,
unsignedShort or unsignedByte. A long may be downcast to an int a
short or a byte. The other downcasts follow the same pattern.
12. Variable Length Data Type
The IPFIX template mechanism is optimized for fixed length
Information Elements [IPFIX-INFO]. Where an Information Element has
a variable length the following mechanism is used to carry the
length information.
In the Template FlowSet the length is recorded as 65535. This
reserved length value notifies the Collecting Process that length of
the Information Element will be carried in the Information Element
itself.
In most cases the length of the Information Element will be less
than 256 bytes. The following length encoding mechanism optimizes
the overhead of carrying the Information Element length in this
majority case.
If the length of the Information Element is less than 255 bytes, the
length is carried in the first byte of the Information Element. This
is shown on Figure A.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| Information element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
Claise, et. al Standard Track [Page 35]
IPFIX Protocol Specifications January 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A: Variable Length Information Element (length < 255 bytes)
If the length of the Information Element is greater or equal than
256 bytes, the first byte of the Information Element is 255, and the
length is carried in the second and third bytes of the Information
Element. This is shown in Figure B.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Length (256 to 65535) | IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure B: Variable Length Information Element
(length 256 to 65535) bytes
13. Template Management
Flow Data records that correspond to a Template Record MAY appear in
the same and/or subsequent IPFIX Messages. The Template Record is
not necessarily carried in every IPFIX Message. As such, the
Collecting Process MUST store the Template Record to interpret the
corresponding Flow Data Records that are received in subsequent data
messages.
A Collecting Process that receives IPFIX Messages from several
Observation Domains from the same Exporter MUST be aware that the
uniqueness of the Template ID is not guaranteed across Observation
Domains.
The Template IDs must remain constant for the life of the Metering
Process and the Exporting Process. If the Exporting Process or the
Metering Process restarts for any reason, all information about
Templates will be lost and new Template IDs will be created.
Template IDs are thus not guaranteed to be consistent across an
Exporting Process or Metering Process restart.
A newly created Template record is assigned an unused Template ID
from the Exporter. If the template configuration is changed, the
Claise, et. al Standard Track [Page 36]
IPFIX Protocol Specifications January 2004
current Template ID is abandoned and SHOULD NOT be reused until the
Metering Process. If a Collecting Process should receive a new
definition for an already existing Template ID, it MUST discard the
previous template definition and use the new one.
If a configured Template Record on the Exporting Process is deleted,
and re-configured with exactly the same parameters, the same
Template ID COULD be reused.
The Exporting Process sends the Template FlowSet and Options
Template FlowSet under the following conditions:
1. After a Metering Process restarts, the Exporting Process MUST
NOT send any Data FlowSet without sending the corresponding
Template FlowSet and the required Options Template FlowSet in a
previous message or including it in the same IPFIX Message. It
MAY transmit the Template FlowSet and Options Template FlowSet,
without any Data FlowSets, in advance to help ensure that the
Collector will have the correct Template Record before receiving
the first Flow or Options Data Record.
2. In the event of configuration changes, the Exporting Process
SHOULD send the new template definitions at an accelerated rate.
In such a case, it MAY transmit the changed Template Record(s)
and Options Template Record(s), without any data, in advance to
help ensure that the Collector will have the correct template
information before receiving the first data.
3. On a regular basis, the Exporting Process MUST send all the
Template Records and Options Template Records to refresh the
Collecting Process. Template IDs have a limited lifetime at the
Collecting Process and MUST be periodically refreshed.
Two approaches are taken to make sure that Templates get
refreshed at the Collecting Process:
* Every N number of IPFIX Messages.
* On a time basis, so every N number of minutes.
Both options MUST be configurable by the user on the Exporting
Porcess.
When one of these expiry conditions is met, the Exporting
Process MUST send the Template FlowSet and Options Template.
14. The Collecting Process's Side
Claise, et. al Standard Track [Page 37]
IPFIX Protocol Specifications January 2004
The Collecting Process receives Template Records from the Exporting
Process, normally before receiving Flow Data Records (or Options
Data Records). The Flow Data Records (or Options Data Records) can
then be decoded and stored locally on the devices. If the Template
Records have not been received at the time Flow Data Records (or
Options Data Records) are received, the Collecting Process SHOULD
store the Flow Data Records (or Options Data Records) and decode
them after the Template Records are received. A Collecting Process
device MUST NOT assume that the Data FlowSet and the associated
Template FlowSet (or Options Template FlowSet) are exported in the
same IPFIX Message.
The Collecting Process MUST NOT assume that one and only one
Template FlowSet is present in an IPFIX Message.
The life of a template at the Collecting Process is limited to a
fixed refresh timeout. Templates not refreshed from the Exporting
Process within the timeout are expired at the Collecting Process.
The Collecting Process MUST NOT attempt to decode the Flow or
Options Data Records with an expired Template. At any given time the
Collecting Process SHOULD maintain the following for all the current
Template Records and Options Template Records: <Exporting Process,
Observation Domain, Template ID, Template Definition, Last Received>
Note that the Observation Domain is identified by the Source ID
field from the IPFIX Message.
Template IDs are unique per Exporting Process and per Observation
Domain.
If the Collecting Process receives a new Template Record (for
example, in the case of an Exporter restart) it MUST immediately
override the existing Template Record.
The Collecting Process MUST note the Field ID of any Information
Element that it does not understand and MAY discard the Information
Element from the Flow Record. The Collecting Process MUST note the
size and position of any Vendor Specified Information Element that
it does not understand and discard the Information Element from the
Flow Record.
The Collector MUST accept padding in the Data FlowSet and Options
Template FlowSet, which means for the Flow Data Records, the Options
Data Records and the Template Records.
Claise, et. al Standard Track [Page 38]
IPFIX Protocol Specifications January 2004
Refer to the terminology summary table in Section 3.1.
The IPFIX protocol has a sequence number field in the Export Header
which increases with each message. A Collector may detect out of
sequence, dropped, or duplicate messages by tracking the sequence
number. A collector SHOULD provide a logging mechanism for tracking
out of sequence messages. Such out of sequence messages may be due
to congestion on the network link between the
Exporter and Collector, Collector resource exhaustion where it can
not process the IPFIX messages at their arrival rate, Exporter
resource exhaustion where it can not transmit messages at their
creation rate, out of order packet reception, duplicate packet
reception, an Exporting Process reset, or an attacker injecting
false messages.
15. Security Considerations
Because IPFIX can be used to collect billing information and network
forensics, confusing or blinding IPFIX must be seen as a prime
objective during a sophisticated network attack.
If an attacker is in a position to inject false messages into an
IPFIX message stream this will allow them to send forged flow
records, options, or templates. Forged templates may impair the
Collectors ability to process any further Flow Records. Forged Flow
Records would have a direct effect on the application using the
Flows, for example a billing system may generate incorrect billing
information. Forged options may be able to alter the meaning of flow
records, for example if the sample rate is changed.
The IPFIX messages themselves may contain information of value to an
attacker, and thus care must be taken to confine their visibility to
authorized users.
The IPFIX protocol runs over IP and hence the messages sent to the
collector by the exporter may be secured using IPsec. However this
does not address all of the security issues in an IPsec deployment.
15.1 IPsec Profile
To secure messages between the Exporter and the Collector an IPFIX
implementation MAY use IPsec. To ensure interworking between
Exporters and Collectors from different vendors, the following IPsec
profile MUST be supported. This profile is derived from [USEIPSEC].
Claise, et. al Standard Track [Page 39]
IPFIX Protocol Specifications January 2004
15.1.1 Selectors
IPFIX runs between manually configured pairs of hosts on the
following transport ports (TBD). The appropriate selector would be
Exporter Collector pairs and port number
Note that if the Exporter is a router a non-interface ("loopback")
address should be used.
15.1.2 Mode
IPsec MUST be run in transport mode.
The Authentication Header (AH) [RFC2402] MUST be used if
authentication is required. The Security Protocol (ESP) [RFC2406]
must be used if the is a threat to the IPFIX message content, or if
it is confidential.
Normally in situations where the ESP was required the AH would also
be required. If ESP is used, the sender's IP address MUST be checked
against the IP address asserted in the key management exchange.
The AH MUST be supported by an IPFIX implementation of IPsec.
15.1.3 Key Management
In many networks, manual key management will be sufficient, and
reduces the complexity of the Exporter, albeit at a cost of greater
configuration complexity. Manual key management MUST be supported. If
a replay attack is considered likely, an automated key management the
IKE key management system SHOULD be used.
15.1.4 Security Policy
Connections should be accepted only from the designated peer.
15.1.5 Authentication
Given the number of IPFIX capable Exporters are likely to be deployed
by a large ISPs, there will be circumstances where shared key
mechanisms are not adequate. Where an automated key management
system is used, certificate-based IKE SHOULD be supported.
Claise, et. al Standard Track [Page 40]
IPFIX Protocol Specifications January 2004
15.1.6 Availability
It is accepted that IPsec will not be universally available in IPFIX
Exporters, and that where it is available, there may be issues of
throughput, which may itself raise security issues. In such
circumstances the other security measures described in this draft
provide some threat mitigation.
15.2 Network Architecture
Ideally messages from the IPFIX Exporter to the IPFIX Collector
should travel over a dedicated network such as a dedicated point to
point link. In all cases, useful protection is gained by allocating
Exporter and Collector IP addresses from ranges that are excluded
from use for user traffic. By sending the IPFIX messages over a
dedicated network, message IPFIX message loss induced by user traffic
congestion is minimized. However an attacker may trigger the
generation of excessive IPFIX messages, and to avoid information loss
during such an attack the IPFIX network must be adequately sized.
The use of a dedicated network also prevents the IPFIX messages from
being inspected by an attacker.
15.3 When IPsec is not an option
When IPsec is not an option, perhaps due to performance issues, but
some level of protection against an insertion attack is required, it
is recommended that a 64 bit cookie [L2TPv3] be included as a
mandatory element within all messages.
Without IPsec the IPFIX Collector has no means to authenticate an
exporter other than the Exporters Source IP address. Where large
numbers of exporters, proxies and collectors are used in a network,
it may be tempting for the administrator to not impose source IP
address restrictions, this leaves the Collector open to reception of
invalid flows. The use proxies using an open collector is therefore
to be deprecated.
15.4 Transport Issues
Some IPFIX security issues are dependent on the transport. For
example with UDP unsolicited messages may be received and not
detected, with a modern implementation of TCP with good ISN
randomization [XXX-REFERENCE] or SCTP these types of attacks are much
more difficult without an attacker with access to snoop the packet
flow [XXX-SCTP-BLIND-SPOOFING-REFERENCE]. Randomization of the IPFIX
sequence number might mitigate the in case of UDP problem. However in
all these cases, the sequence number space is relatively small giving
Claise, et. al Standard Track [Page 41]
IPFIX Protocol Specifications January 2004
limited protection.
An attacker may take advantage of the pathology of the transport
protocol or its common implementations to mount and attack on IPFIX.
This might be either as an assault on IPFIX in its own right or
intended to blind IPFIX to prevent the recording of network forensics
as part of another attack.
Under conditions where the attacker saturated IPFIX, for example by
initiating the generating enormous numbers of short lived flows, the
behavior of the IPFIX transport would determine the amount of
evidence that was recorded.
If the transport protocol were UDP, then under network overload
conditions IPFIX would reduce to some sort of sampling. This means
that the attacked could never be quite sure that IPFIX was blinded,
and that they may hence be leaving forensics.
If the transport were TCP, then the flow to the collector would back
off due to congestion discard and eventually stall blinding the IPFIX
system. An attack could then proceed without further observation. The
extent and duration of the blindness would depend on the detail of
the TCP implementation.
SCTP-PR will have a different pathology under such a saturation
attack. Stale data at the head of the queue will get flushed giving
some visibility of the attack.
Whilst the use of a congestion aware transport protocol is highly
desirable to protect the network from overload by excessive IPFIX
traffic, this is exactly wrong behavior when IPFIX is being to
diagnose a DoS attack, or an attack proceeding under cover of a DoS
attack. Under these circumstance you want the IPFIX transport needs
to be congestion neutral (as is UDP), or congestion aggressive.
15.5 Logging an IPFIX Attack
The IPFIX protocol has a sequence number field in the Export Header
which increases with each message. A Collector may detect out of
sequence, dropped, or duplicate messages by tracking the sequence
number. A Collector SHOULD provide a logging mechanism for tracking
out of sequence messages. Such out of sequence messages may be due
to congestion on the network link between the Exporter and
Collector, Collector resource exhaustion where it can not process
the IPFIX messages at their arrival rate, Exporter resource
exhaustion where it can not transmit messages at their creation
rate, out of order packet reception, duplicate packet reception, an
Exporting Process reset, or an attacker injecting false messages.
Claise, et. al Standard Track [Page 42]
IPFIX Protocol Specifications January 2004
Note that an attacker may be able to exploit the behavior of the
Collector when it receives an out of sequence message. For example a
Collector that simply reset the expected sequence number upon
receipt of a later message would easily be temporarily blinded by
deliberately injecting messages with a much larger sequence number.
16. IANA Considerations
IANA will need to set up a registry of Flowset IDs, field types,
scope and option codepoints.
In compiling the registry of field types IANA must set asside a
range value for vendor use. It is proposed that the range <0..32767>
be administered by IANA for IETF defined IEs, and that the range
<32768..65535> be allocated for private use by vendors.
Similarly the scope and option codepoints need to be split between
IANA administered and private ranges.
17. Examples
Let's consider the example of an IPFIX Message composed of a
Template FlowSet, a Data FlowSet (which contains three Flow Data
Records), an Options Template FlowSet and a Data FlowSet (which
contains 2 Options Data Records).
IPFIX Message:
+--------+---------------------------------------------. . .
| | +--------------+ +-----------------------+
|Message | | Template | | Data |
| Header | | FlowSet | | FlowSet | . . .
| | | (1 Template) | | (3 Flow Data Records) |
| | +--------------+ +-----------------------+
+--------+---------------------------------------------. . .
. . .+-------------------------------------------------+
+------------------+ +--------------------------+ |
| Options | | Data | |
. . .| Template FlowSet | | FlowSet | |
| (1 Template) | | (2 Options Data Records) | |
+------------------+ +--------------------------+ |
. . .--------------------------------------------------+
Claise, et. al Standard Track [Page 43]
IPFIX Protocol Specifications January 2004
17.1 Message Header Example
The Message Header is composed of:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0x0009 | Length = 152 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UNIX Secs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17.2 Template FlowSet Example
We want to report the following Field Types:
- The source IP address (IPv4), so the length is 4
- The destination IP address (IPv4), so the length is 4
- The next-hop IP address (IPv4), so the length is 4
- The number of bytes of the Flow
- The number of packets of the Flow
Therefore, the Template FlowSet will be composed of the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 0 | Length = 28 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP_SRC_ADDR = 0x0008 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP_DST_ADDR = 0x000C | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP_NEXT_HOP = 0x000F | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_PKTS = 0x0002 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IN_BYTES = 0x0001 | Field Length = 4 |
Claise, et. al Standard Track [Page 44]
IPFIX Protocol Specifications January 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17.3 Data FlowSet Example
In this example, we report the following three Flow records:
Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Bytes
| | | Number | Number
---------------------------------------------------------------
198.168.1.12 | 10.5.12.254 | 192.168.1.1 | 5009 | 5344385
192.168.1.27 | 10.5.12.23 | 192.168.1.1 | 748 | 388934
192.168.1.56 | 10.5.12.65 | 192.168.1.1 | 5 | 6534
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 256 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 198.168.1.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10.5.12.254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.168.1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5344385 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.168.1.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10.5.12.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.168.1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 748 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 388934 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.168.1.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10.5.12.65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.168.1.1 |
Claise, et. al Standard Track [Page 45]
IPFIX Protocol Specifications January 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6534 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that padding was not necessary in this example.
17.4 Options Template FlowSet Example
Per line card (the router being composed of two line cards), we want
to report the following Field Types:
- Total number of IPFIX Messages
- Total number of exported Flows
The format of the Options Template FlowSet is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 1 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 257 | Option Scope Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length = 8 | Scope 1 Field Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 2 | TOTAL_EXP_PKTS_SENT = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | TOTAL_FLOWS_EXP = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17.5 Data FlowSet with Options Data Records Example
In this example, we report the following two records:
Line Card ID | IPFIX Message| Export Flow
------------------------------------------
Line Card 1 | 345 | 10201
Line Card 2 | 690 | 20402
0 1 2 3
Claise, et. al Standard Track [Page 46]
IPFIX Protocol Specifications January 2004
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowSet ID = 257 | Length = 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 345 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10201 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 690 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 20402 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18. References
18.1 Normative References
[IPFIX-ARCH] Sadasivan, G, Brownlee, N. "Architecture Model for IP
Flow Information Export" draft-ietf-ipfix-arch-01.txt", June 2003
[IPFIX-INFO] Calato, P, Meyer, J, Quittek, J, "Information Model for
IP Flow Information Export" draft-ietf-ipfix-info-02, August 2003
[IPFIX-AS] Claise, B, Fullmer, M, Calato, P, Penno, R, "IPFIX
Protocol Specifications", draft-ietf-ipfix-protocol-00.txt, June
2003
[TCP] "TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION" RFC 793, September 1981
[RFC2960] Stewart, R. (ed.) "Stream Control Transmission Protocol",
RFC 2960, October 2000
[PR-SCTP] Stewart, R, Ramalho, M, Xie, Q, Tuexen, M, Conrad, P.
"SCTP Partial Reliability Extension", draft-ietf-tswg-prsctp-02.txt
[NETFLOW9] Claise, B, et al "Cisco Systems NetFlow Services Export
Version 9", draft-claise-netflow-9-06.txt, October 2003
18.2 Informative References
Claise, et. al Standard Track [Page 47]
IPFIX Protocol Specifications January 2004
[IPFIX-REQ] Quittek, J, Zseby, T, Claise, B, Zander, S,
"Requirements for IP Flow Information Export" draft-ietf-ipfix-reqs-
10.txt, June 2003
[IPFIX-AS] Zseby, T, Penno, R, Brownlee, N, Claise, B, "IPFIX
Applicability", draft-ietf-ipfix-as-01.txt, October 2003
[IPFIX-EVAL] Leinen, S, "Evaluation of Candidate Protocols for IP
Flow Information Export (IPFIX)", draft-leinen-ipfix-eval-contrib-
01.txt, June 2003
[NETFLOW9] Claise, B, et al "Cisco Systems NetFlow Services Export
Version 9", draft-claise-netflow-9-06.txt, October 2003
[PEN] IANA Private Enterprise Numbers registry
http://www.iana.org/assignments/enterprise-numbers
[USEIPSEC] S. Bellovin, Guidelines for Mandating the Use of IPsec,
draft-bellovin-useipsec-02.txt, October 2003, work
in progress.
[L2TPv3] J. Lau et al. Layer Two Tunneling Protocol (Version 3)
draft-ietf-l2tpext-l2tp-base-11.txt, October 2003, work
in progress.
[XXX-REFERENCE]
[XXX-SCTP-BLIND-SPOOFING-REFERENCE]
19. Acknowledgments
To be completed.
Authors Addresses
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
E-mail: bclaise@cisco.com
Claise, et. al Standard Track [Page 48]
IPFIX Protocol Specifications January 2004
Mark Fullmer
OARnet
2455 North Star Rd.
Columbus, Ohio 43221
Phone: +1 (614) 728-8100
Email: maf@eng.oar.net
Reinaldo Penno
Nortel Networks
2305 Mission College Blvd
Santa Clara, CA 95054
Phone: +1 408.565.3023
Email: rpenno@nortelnetworks.com
Paul Calato
Riverstone Networks, Inc.
5200 Great America Parkway
Santa Clara, CA 95054 USA
Phone: +1 (603) 557-6913
Email: calato@riverstonenet.com
Ganesh Sadasivan
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134
USA
Phone: +1 (408) 527-0251
Email: gsadasiv@cisco.com
Stewart Bryant
Cisco Systems, Inc.
250, Longwater,
Green Park,
Reading, RG2 6GB,
United Kingdom
Phone: +44 (0)20 8824-8828
Email: stbryant@cisco.com
Claise, et. al Standard Track [Page 49]
