One document matched: draft-ietf-ipfix-testing-02.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc2629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2960 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2960.xml'>
<!ENTITY rfc3550 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml'>
<!ENTITY rfc3917 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3917.xml'>
<!ENTITY ietf-ipfix-architecture PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ipfix-architecture.xml'>
<!ENTITY ietf-ipfix-as PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ipfix-as.xml'>
<!ENTITY ietf-ipfix-info PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ipfix-info.xml'>
<!ENTITY ietf-ipfix-protocol PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ipfix-protocol.xml'>
]>
<rfc category="info" ipr="full3978" docName="draft-ietf-ipfix-testing-02.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="IPFIX Test Recommendations">
IP Flow Information eXport (IPFIX) Testing
</title>
<author initials="C.S." surname="Schmoll"
fullname="Carsten Schmoll">
<organization>Fraunhofer FOKUS</organization>
<address>
<postal>
<street>Kaiserin-Augusta-Allee 31</street>
<city>Berlin</city>
<code>D-10589</code>
<country>Germany</country>
</postal>
<phone>+49 30 3463 7136</phone>
<email>carsten.schmoll@fokus.fraunhofer.de</email>
<uri>http://www.fokus.fraunhofer.de</uri>
</address>
</author>
<author initials="P.A." surname="Aitken"
fullname="Paul Aitken">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>96 Commercial Quay</street>
<city>Edinburgh</city>
<code>EH6 6LX</code>
<country>Scotland</country>
</postal>
<phone>+44 131 561 3616</phone>
<email>paitken@cisco.com</email>
<uri>http://www.cisco.com</uri>
</address>
</author>
<author initials="B.C." surname="Claise"
fullname="Benoit Claise">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>De Kleetlaan 6a b1</street>
<city>1831 Diegem</city>
<country>Belgium</country>
</postal>
<phone>+32 2 704 5622</phone>
<email>bclaise@cisco.com</email>
<uri>http://www.cisco.com</uri>
</address>
</author>
<date month="October" year="2007" />
<area>Transport</area>
<workgroup>IPFIX Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>IPFIX</keyword>
<keyword>IP Flow Information Export</keyword>
<keyword>Test Specification</keyword>
<abstract>
<t>
This document presents a list of tests that implementers of IP
Flow Information Export (IPFIX) compliant Exporting Processes
and Collecting Processes should perform on their IPFIX
Exporting Process and/or Collecting Process. This document has
been created to help implementers test the functionality of
their IPFIX Exporting Process and/or Collecting Process. The
goal of these tests is to ensure that all important functions
are covered by tests and thereby to gain a level of confidence
in the Exporting Process and Collecting Process that allows the
implementer to perform interoperability or plug tests with
other IPFIX Exporting Processes and Collecting Processes.
</t>
</abstract>
<note title="Conventions used in this document">
<t>
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 <xref target="RFC2119"/>.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
The IPFIX protocol has been developed for the purpose
of exporting IP Flow information from devices such as
routers or measurement stations to mediation,
accounting, and network management systems. It is
intended for the purposes of QoS and traffic
measurement, attack and intrusion detection reporting,
accounting, billing and Internet research.
</t>
<t>
The IPFIX architecture
<xref target="I-D.ietf-ipfix-architecture"/> defines the
different components that are involved in the data export
process. For a testable IPFIX software toolkit one needs at
least one IPFIX Exporting Process and one IPFIX Collecting
Process. The Exporting Process communicates information
regarding Flows from the Metering Process to the Collecting
Process via SCTP, TCP, or UDP transports. The Collecting
Process may then e.g., store the Data Record into a database
or transfer it directly to an application for further
processing.
</t>
<t>
An implementation of these IPFIX components in
software, firmware, or hardware needs to be tested
thoroughly in order to check its robustness and the
conformity to the IPFIX documents it is based on. This
document specifies tests that should be run in order
to check the IPFIX Exporting Process and Collecting Process and
to gain a high confidence in the conformity, robustness, and
correct behavior of such implementation.
</t>
<section title="Motivation">
<t>
The main driving force for preparing this document is the
observation that protocols for data exchange often fail to
work properly when implementations from different companies
or organizations are in use together. This happens even
more often when testing binary protocols. In many cases
this even holds true when tests had previously been
performed successfully using an Exporting Process and
Collecting Process from a single implementer. The tests
listed here can form a valuable common basis for
implementers involved in interoperability testing when all
of them use these tests to check their own Exporting
Process and Collecting Process implementation first.
</t>
</section>
<section title="Document Scope">
<t>
This document lists tests intended to be performed between
an implementation of an IPFIX Exporting Process and an
IPFIX Collecting Process. For some tests multiple instances
of each of those components (Observation Points, Metering
Process, Exporting Process, Collecting Process) are
involved. The tests range from basic transport connectivity
to export of Template and associated Data Records, high
load on the Collecting Process, and error condition
situations.
</t>
</section>
<section title="IPFIX Documents Overview">
<t>
The IPFIX protocol <xref target="I-D.ietf-ipfix-protocol"/>
provides network administrators with access to IP Flow
information. The architecture for the export of measured
IP Flow information out of an IPFIX Exporting Process to a
Collecting Process is defined in <xref
target="I-D.ietf-ipfix-architecture"/>, per the
requirements defined in <xref target="RFC3917"/>. <xref
target="I-D.ietf-ipfix-architecture"/> specifies how IPFIX
data records and Templates are carried via a
congestion-aware transport protocol from IPFIX Exporting
Processes to IPFIX Collecting Process. IPFIX has a formal
description of IPFIX Information Elements, their name, type
and additional semantic information, as specified in <xref
target="I-D.ietf-ipfix-info"/>. Finally <xref
target="I-D.ietf-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.
</t>
</section>
</section> <!-- Introduction -->
<section title="Terminology">
<t>
The terminology used in this document is fully aligned
with the terminology defined in
<xref target="I-D.ietf-ipfix-protocol"/> which is reproduced
here for reference.
</t>
<t>
<list style='hanging'>
<t hangText="Observation Point"/>
<t>
An Observation Point is a location in the network
where IP packets can be observed. Examples
include: 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.
</t>
<t>
Note that every Observation Point is associated
with an Observation Domain (defined below), and
that one Observation Point may be a superset of
several other Observation Points. For example one
Observation Point can be an entire line card. That
would be the superset of the individual Observation
Points at the line card's interfaces.
</t>
<t hangText="Observation Domain"/>
<t>
An Observation Domain is the largest set of
Observation Points for which Flow information can
be aggregated by a Metering Process. For example,
a router line card may be an Observation Domain if
it is composed of several interfaces, each of which
is an Observation Point. In the IPFIX Message it
generates, the Observation Domain includes its
Observation Domain ID, which is unique per
Exporting Process. That way, the Collecting
Process can identify the specific Observation
Domain from the Exporter that sends the IPFIX
Messages. Every Observation Point is associated
with an Observation Domain.
</t>
<t>
It is RECOMMENDED that Observation Domain IDs are
also unique per IPFIX Device.
</t>
<t hangText="IP Traffic Flow or Flow"/>
<t>
There are several definitions of the term 'flow'
being used by the Internet community. Within the
context of IPFIX we use the following definition:
</t>
<t>
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:
<list style='numbers'>
<t>
one or more packet header fields (e.g.
destination IP address), transport
header fields (e.g. destination port
number), or application header
fields (e.g. RTP header fields <xref
target="RFC3550"/>.)
</t>
<t>
one or more characteristics of the packet
itself (e.g. number of MPLS labels, etc...)
</t>
<t>
one or more of fields derived from packet
treatment (e.g. next hop IP address, the
output interface, etc...)
</t>
</list>
</t>
<t>
A packet is defined to belong to a Flow if it
completely satisfies all the defined properties of
the Flow.
</t>
<t>
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. It includes
packets selected by a sampling mechanism.
</t>
<t hangText="Flow Key"/>
<t>
Each of the fields which
<list style='numbers'>
<t>
Belong to the packet header (e.g.
destination IP address)
</t>
<t>
Are a property of the packet itself (e.g.
packet length)
</t>
<t>
Are derived from packet treatment (e.g. AS
number)
</t>
</list>
and which are used to define a Flow are termed Flow
Keys.
</t>
<t hangText="Flow Record"/>
<t>
A Flow Record contains information about a specific
Flow that was observed at an Observation Point. A
Flow Record contains measured properties of the
Flow (e.g. the total number of bytes for all the
Flow's packets) and usually characteristic
properties of the Flow (e.g. source IP address).
</t>
<t hangText="Metering Process"/>
<t>
The Metering Process generates Flow Records.
Inputs to the process are packet headers and
characteristics observed at an Observation Point,
and packet treatment at the Observation Point (for
example the selected output interface).
</t>
<t>
The Metering Process consists of a set of functions
that includes packet header capturing,
timestamping, sampling, classifying, and
maintaining Flow Records.
</t>
<t>
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.
</t>
<t hangText="Exporting Process"/>
<t>
The Exporting Process sends Flow Records to one or
more Collecting Processes. The Flow Records are
generated by one or more Metering Processes.
</t>
<t hangText="Exporter"/>
<t>
A device which hosts one or more Exporting
Processes is termed an Exporter.
</t>
<t hangText="IPFIX Device"/>
<t>
An IPFIX Device hosts at least one Exporting
Process. It may host further Exporting processes
and arbitrary numbers of Observation Points and
Metering Process.
</t>
<t hangText="Collecting Process"/>
<t>
A Collecting Process receives Flow Records from one
or more Exporting Processes. The Collecting
Process might process or store received Flow
Records, but such actions are out of scope for this
document.
</t>
<t hangText="Collector"/>
<t>
A device which hosts one or more Collecting
Processes is termed a Collector.
</t>
<t hangText="Template"/>
<t>
Template is a ordered sequence of {type, length}
pairs, used to completely specify the structure and
semantics of a particular set of information that
needs to be communicated from an IPFIX Device to a
Collector. Each Template is uniquely identifiable
by means of a Template ID.
</t>
<t hangText="IPFIX Message"/>
<t>
An IPFIX Message is a message originating at the
Exporting Process that carries the IPFIX records of
this Exporting Process and whose destination is a
Collecting Process. An IPFIX Message is
encapsulated at the transport layer.
</t>
<t hangText="Message Header"/>
<t>
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.
</t>
<t hangText="Template Record"/>
<t>
A Template Record defines the structure and
interpretation of fields in a Data Record.
</t>
<t hangText="Data Record"/>
<t>
A Data Record is a record that contains values of
the parameters corresponding to a Template Record.
</t>
<t hangText="Options Template Record"/>
<t>
An Options Template Record is a Template Record
that defines the structure and interpretation of
fields in a Data Record, including defining how to
scope the applicability of the Data Record.
</t>
<t hangText="Set"/>
<t>
Set is a generic term for a collection of records
that have a similar structure. In an IPFIX
Message, one or more Sets follow the Message
Header.
</t>
<t>
There are three different types of Sets: Template
Set, Options Template Set, and Data Set.
</t>
<t hangText="Template Set"/>
<t>
A Template Set is a collection of one or more
Template Records that have been grouped together in
an IPFIX Message.
</t>
<t hangText="Options Template Set"/>
<t>
An Options Template Set is a collection of one or
more Options Template Records that have been
grouped together in an IPFIX Message.
</t>
<t hangText="Data Set"/>
<t>
A Data Set is one or more Data Records, of the same
type, that are grouped together in an IPFIX
Message. Each Data Record is previously defined by
a Template Record or an Options Template Record.
</t>
<t hangText="Information Element"/>
<t>
An Information Element is a protocol and encoding
independent description of an attribute which may
appear in an IPFIX Record. The IPFIX information model
<xref target="I-D.ietf-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 determines
the valid encoding mechanisms for use in IPFIX.
</t>
<t hangText="Transport Session"/>
<t>
In SCTP, the transport session is known as the SCTP
association, which is uniquely identified by the
SCTP endpoints <xref target="RFC2960"/>; in TCP,
the transport session is known as the TCP
connection, which is uniquely identified by the
combination of IP addresses and TCP ports used; In
UDP, the transport session is known as the UDP
session, which is uniquely identified by the
combination of IP addresses and UDP ports used.
</t>
</list>
</t>
</section> <!-- Terminology -->
<section title="Test Specifications">
<t>
The tests described in this section MAY be performed using
an IPFIX Exporting Process on one host and an IPFIX Collecting
Process on a different host. The configuration of the
Observation Point, Metering Process, Exporting Process, and
Collection Process SHOULD be recorded for every test along with
the test results.
</t>
<t>
All tests described in this section MUST be successfully
executed for an IPFIX architecture to be compliant with this
document.
</t>
<section title="Exporting Process / Collecting Process connectivity
tests" anchor="connectivity">
<t>
This section lists the basic tests that MUST succeed as a
precondition for the more complex tests defined in later
sections of this document.
</t>
<section title="Connectivity tests between Exporting Process
and Collecting Process">
<t>
The tester MUST set one Exporting Process and one
Collecting Process, MUST configure the Exporting
Process to export at least one Template Set and
associated Data Records to the Collecting Process, and
MUST cause the Exporting Process to initiate the
export.
</t>
<t>
The tester MUST ensure that an SCTP association (or TCP
connection) is established.
</t>
<t>
The tester MUST ensure that the Transport Session
parameters (IP addresses and ports) are correct.
</t>
<t>
The tester MUST ensure that the Data Records are
actually exported. The transmitted data might be
observed on-line with an appropriate tool such as
Wireshark (www.wireshark.org).
</t>
<t>
The tester MUST record which combinations of IPv4 and
IPv6 transports, and UDP, SCTP, and TCP transmission
protocols are supported, and MUST perform the test for
all the supported combinations.
</t>
</section>
</section> <!-- Exporting Process / Collecting Process Connectivity tests -->
<section title="Template and Data Record tests">
<t>
This section lists tests for checking the correct
transmission of IPFIX Template Sets and associated Data
Sets.
</t>
<section title="Transmission of Template with fixed
size Information Elements">
<t>
The tester MUST create a Template with a few fixed-size
Information Elements, and cause the Template and
associated Data Records to be exported over all
applicable combinations of transports and protocols in
<xref target="connectivity"/>.
</t>
<t>
The tester MUST ensure that the Template and associated
Data Records were correctly received and decoded by the
Collecting Process.
</t>
<t>
The tester MUST use various Information Elements in the
Template so that each data type specified in
<xref target="I-D.ietf-ipfix-protocol"/>
(octet, unsigned16, unsigned32 ...)
is used in at least one test.
</t>
</section>
<section title="Transmission of Template with
variable length Information Elements">
<t>
The tester MUST create a Template with a mixture of
fixed-sized and variable length Information Elements,
and cause the Template and associated Data Records to
be exported over all applicable combinations of
transports and protocols in
<xref target="connectivity"/>.
</t>
<t>
The tester MUST ensure that the Template contains:
<list style='symbols'>
<t>
a single variable length Information Element
</t>
<t>
a single variable length Information Element
followed by a fixed length Information Element
</t>
<t>
a fixed length Information Element followed by
a variable length Information Element
</t>
<t>
multiple variable length Information Elements
</t>
</list>
</t>
<t>
The tester MUST ensure that the Template and associated
Data Records were correctly received and decoded by the
Collecting Process.
</t>
</section>
<section title="Set Padding">
<t>
Section 3.3.1 of
<xref target="I-D.ietf-ipfix-protocol"/>
specifies IPFIX Set alignment using padding.
</t>
<t>
The tester MUST create two Data Sets with padding
in between consisting of zero valued octets, as shown
in <xref target="zero-padding"/>, MUST cause them to be
exported to the Collecting Process, and MUST ensure
that both Data Sets and all the Data Records were
correctly received and decoded by the Collecting
Process.
</t>
<figure anchor="zero-padding">
<artwork>
+--------------------------------------------------+
| Set Header #1 |
+--------------------------------------------------+
| Data Record |
+--------------------------------------------------+
| Data Record |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Data Record |
+--------------------------------------------------+
| Padding with 0 valued octets |
+--------------------------------------------------+
| Set Header #2 |
+--------------------------------------------------+
| Data Record |
+--------------------------------------------------+
</artwork>
</figure>
</section>
<section title="Record Padding">
<t>
The tester MUST create a Template that contains the
padding Information Element (i.e. paddingOctets), and
cause the Template and associated Data Records to be
exported over all applicable combinations of transports
and protocols in <xref target="connectivity"/>.
</t>
<t>
The tester MUST repeat the test with various padding
sizes, including padding to boundaries other than 4 or
8 octets.
</t>
<t>
The tester MUST ensure the Collecting Process correctly
interprets case where the Data Records are so short
that the padding is equal to or longer than the length
of the record, so the padding might otherwise be
interpreted as another record (e.g. 1 bytes TOS plus 3
bytes of padding).
<xref target="paddingTemplate"/> depicts such a
Template, while <xref target="paddingDataRecord"/>
depicts a Data Record conforming to that Template.
</t>
<figure anchor="paddingTemplate">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipDiffServCodePoint = 195 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| paddingOctets = 210 | Field Length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<figure anchor="paddingDataRecord">
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The tester MUST test fixed-size padding (e.g. 12 bytes
of data plus 2 bytes of padding) and variable length
padding (e.g. export a string and a variable number of
padding bytes afterwards to align the next Information
Element to a 4 byte boundary).
</t>
</section> <!-- Record Padding -->
<section title="Template Withdrawal Message">
<t>
IPFIX Template management and Template Withdrawal are
defined in chapter 8 of <xref target="I-D.ietf-ipfix-protocol"/>.
</t>
<section title="Withdrawal of a previously sent Template" anchor="TWM">
<t>
The tester MUST create an IPFIX Template and cause
that Template to be exported to an IPFIX Collector
over a reliable transport.
</t>
<t>
The tester MUST ensure that the Template was
correctly received and decoded by the Collecting
Process.
</t>
<t>
The tester MUST cause the Exporting Process to send
an IPFIX Template Withdrawal Message to the
Collector in respect of the Template. The Template
Withdrawal Message must be sent over the same
Transport Session as the Template.
</t>
<t>
The tester MUST ensure that the Template Withdrawal
Message was correctly received and decoded by the
Collecting Process, and that the previously sent
Template was discarded by the Collecting Process.
</t>
</section>
<section title="Withdrawal of a previously withdrawn Template">
<t>
The tester MUST create, export and withdraw an
IPFIX Template as described in <xref target="TWM"/>.
</t>
<t>
The tester MUST cause the Exporting Process to send
a second IPFIX Template Withdrawal Message to the
Collector in respect of the same Template.
The Template Withdrawal Message must be sent over
the same Transport Session as the Template.
</t>
<t>
The tester MUST ensure that the Collecting Process
discards the IPFIX Message and shuts down the SCTP
association or closes the TCP connection. The tester
MUST check that the Collecting Process logged the
error.
</t>
</section>
<section title="Withdrawal of a previously unsent Template">
<t>
The tester MUST cause the Exporting Process to send
an IPFIX Template Withdrawal Message to the
Collector in respect of a Template which has not
yet been exported. The Template Withdrawal Message
must be sent over a reliable transport.
</t>
<t>
The tester MUST ensure that the Collecting Process
discards the IPFIX Message and shuts down the SCTP
association or closes the TCP connection. The tester
MUST check that the Collecting Process logged the
error.
</t>
</section>
<section title="Withdrawing all Data Templates">
<t>
The tester MUST create several IPFIX Templates and
cause them to be exported to an IPFIX Collector
over a reliable transport.
</t>
<t>
The tester MUST ensure that the Templates were
correctly received and decoded by the Collecting
Process.
</t>
<t>
The tester MUST cause the Exporting Process to send
an IPFIX All Data Templates Withdrawal Message to the
Collector over the same Transport Session as the Templates.
</t>
<t>
The tester MUST ensure that the All Data Templates
Withdrawal Message was correctly received and
decoded by the Collecting Process, and that all the
previously sent Templates were discarded by the
Collecting Process.
</t>
</section>
<section title="Withdrawing all Option Templates">
<t>
The tester MUST create several IPFIX Option Templates and
cause them to be exported to an IPFIX Collector
over a reliable transport.
</t>
<t>
The tester MUST ensure that the Option Templates were
correctly received and decoded by the Collecting
Process.
</t>
<t>
The tester MUST cause the Exporting Process to send
an IPFIX All Option Templates Withdrawal Message to the
Collector over the same Transport Session as the Templates.
</t>
<t>
The tester MUST ensure that the All Option Templates
Withdrawal Message was correctly received and
decoded by the Collecting Process, and that all the
previously sent Option Templates were discarded by the
Collecting Process.
</t>
</section>
</section> <!-- Template Withdrawal Message -->
</section> <!-- Template and Data Record tests -->
<section title="Information Element tests">
<t>
This section lists the tests that cover the use of
Information Elements.
</t>
<section title="Enterprise-specific Information Elements">
<t>
The tester MUST cause the export of a Template and
associated Data Record that makes use of
Enterprise-specific Information Elements as defined in
<xref target="I-D.ietf-ipfix-protocol"/>.
</t>
<t>
The tester MUST ensure that the Template and associated
Data Record are correctly received and decoded by the
Collecting Process, and that Information Elements that
are unknown to the Collecting Process are not silently
discarded.
</t>
</section>
<section title="Reduced Size Encoding of Information Elements">
<t>
The tester MUST cause the export of a Template and
associated Data Record containing Information Elements
using reduced-size encoding as defined in section 6.2
of <xref target="I-D.ietf-ipfix-protocol"/>.
</t>
<t>
The tester MUST ensure that in the case of Information
Elements transmitted using Reduced Size Encoding, the
Collecting Process is aware of the real size of each
Information Element as defined in
<xref target="I-D.ietf-ipfix-protocol"/>,
and not only the length used for its transmission.
</t>
</section>
<section title="Multiple instances of the same Information
Element in one Template">
<t>
The tester MUST cause the export of a Template and
associated Data Record containing containing multiple
instances of the same Information Element, either
consecutively or with other Information Elements in
between.
</t>
<t>
The tester MUST ensure that the Collecting Process is
able to parse the IPFIX Message, and stores all values
received for all the Information Elements that appeared
multiple times in the Template definition.
</t>
</section>
</section> <!-- Information Element tests -->
<section title="Options Template tests">
<t>
This section lists the tests that cover the correct
transfer of IPFIX Options Templates.
</t>
<section title="Using any Information Elements as Scope">
<t>
Options Templates contain scope fields that give the
context of the reported Information Elements in the
corresponding Data Records. Scope fields are an
Information Elements specified in
<xref target="I-D.ietf-ipfix-info"/>.
</t>
<t>
The tester MUST cause the export of
Options Template Records containing various different
Information Elements of each data type specified in
<xref target="I-D.ietf-ipfix-protocol"/>
(octet, unsigned16, unsigned32 ...) in their
scope fields, and MUST export a Data Record using
each Template.
</t>
<t>
The tester MUST ensure that the Templates and the
associated Data Records are correctly received and
decoded by the Collecting Process.
</t>
<t>
The tester MUST ensure that the Collecting Process
accepts Information Elements in the scope field
other than IPFIX Information Elements which have been
recorded by IANA.
</t>
<t>
The tester MUST ensure that the Collecting Process
accepts an Enterprise specific Information Element in
the scope field.
</t>
<t>
The Scope Field Count MUST NOT be zero. The tester MUST
cause the export of an Options Template Record
containing a Scope Field Count of zero.
</t>
<t>
The tester MUST ensure that the Collecting Process
shuts down the SCTP association and discards the IPFIX
Message. The tester MUST check that the Collecting
Process logged the error.
</t>
</section>
<section title="Using multiple Scopes">
<t>
<xref target="I-D.ietf-ipfix-protocol"/> specifies:
"Multiple scope fields MAY be present in the Options
Template Record, in which case, the composite scope is
the combination of the scopes. If the order of the
scope fields in the Options Template Record is
relevant, the order of the scope fields MUST be used."
</t>
<t>
The tester MUST cause the export of an Options Template
Record containing multiple scope fields, and a Data
Record conforming to that Template.
</t>
<t>
The tester MUST ensure that the Collecting Process
reports the Information Elements in the same order as
they were specified in the Options Template Record.
</t>
</section>
<section title="Metering Process Statistics Option
Template">
<t>
The tester MUST create a Metering Process Statistics
Option Templates as defined in section 4.1 of <xref
target="I-D.ietf-ipfix-protocol"/>, and MUST cause the
Option Template and an associated Data Record to be
exported.
</t>
<t>
The tester MUST ensure that the Collecting Process
correctly receives and decodes the Option Template and
associated Data Record.
</t>
<t>
The tester MUST also check that the optional
meteringProcessId Scope Field is supported by the
Collecting Process implementation.
</t>
<t>
If several Metering Processes are available on the
Exporter Observation Domain,
the tester MUST create a Metering Process
Statistics Option Template containing multiple scopes
and an associated Data Record, MUST cause the Option
Template and associated Data Record to be exported, and
MUST ensure that the Collecting Process correctly
receives and decodes the Option Template and associated
Data Record.
</t>
</section>
<section title="Metering Process Reliability Statistics
Option Template">
<t>
The tester MUST create a Metering Process Reliability
Statistics Option Template as defined in section 4.2 of
<xref target="I-D.ietf-ipfix-protocol"/>, and MUST
cause the Option Template and an associated Data Record
to be exported.
</t>
<t>
The tester MUST ensure that the Collecting Process
correctly receives and decodes the Option Template and
associated Data Record.
</t>
<t>
The tester MUST also check that the optional
meteringProcessId Scope Field is supported by the
Collecting Process implementation.
</t>
</section>
<section title="Exporting Process Reliability Statistics
Option Template">
<t>
The tester MUST create an Exporting Process Reliability
Statistics Option Template as defined in section 4.3 of
<xref target="I-D.ietf-ipfix-protocol"/>, and MUST
cause the Option Template and an associated Data Record
to be exported.
</t>
<t>
The tester MUST ensure that the Collecting Process
correctly receives and decodes the Option Template and
associated Data Record.
</t>
</section>
<section title="Flow Keys Option Template">
<t>
The tester MUST create a Flow Keys Option Template, as
defined in section 4.4 of <xref
target="I-D.ietf-ipfix-protocol"/>, where the
templateId refers to an existing Template, and MUST
cause the Option Template and an associated Data Record
to be exported.
</t>
<t>
The tester MUST ensure that the Collecting Process
correctly receives and decodes the Option Template and
associated Data Record, and that the Collecting
Process associates the Flow Keys with the right Data
Record Information Elements.
</t>
<t>
The tester MUST create another Flow Keys Data Record
to be exported where the associated templateId has
insufficient fields to satisfy the flowKeyIndicator.
</t>
<t>
The tester MUST ensure that the Collecting Process
discards the IPFIX Message and shuts down the SCTP
association or closes the TCP connection. The tester
MUST check that the Collecting Process logged the
error.
</t>
<t>
The tester MUST create another Flow Keys Option
Template, where the templateId refers to a non-existing
Template, and MUST cause the Option Template and an
associated Data Record to be exported.
</t>
<t>
The tester MUST ensure that the Collecting Process
shuts down the SCTP association and discards the IPFIX
Message. The tester MUST check that the
Collecting Process logged the error.
</t>
</section>
</section> <!-- Options Template tests -->
<section title="Stress/Load tests">
<t>
Stress tests are used to check correct behavior and
robustness of an IPFIX Collecting Process implementation
when a number of Data Records arrive very quickly. This is
especially important when IPFIX over UDP is used, since in
that case a slow Collecting Process cannot block the IPFIX
Exporting Processes from exporting, since UDP is not
congestion aware.
</t>
<t>
The tests may be dependent upon the hardware and transports
technology in use. Therefore the tests may need to be
scaled up or down to meet the needs of the particular
implementation. However, the implementer MUST ensure that
the implementation is stable under excessive traffic
conditions, for whatever definition of "excessive" applies
at their intended installation.
</t>
<t>
The implementer MUST ensure the correct operation of the
Exporting Process and/or Collecting Process when the
Collecting Process is incapable of processing records at
the rate that they are received.
</t>
<section title="Large number of Records for one Template">
<t>
The tester MUST export many Data Records to the
Collecting Process, all conforming to the same
Template.
</t>
<t>
Depending on what that the Collecting Process does
(save to file, store to database, analyze the data) the
Collecting Process may use up a lot of memory.
</t>
<t>
The tester MUST ensure that if the Collecting Process
runs out of memory, it shuts down the specific SCTP
association or closes the TCP connection but remains
available to receive data on other open Transport
Sessions and stays available for future Transport
Sessions.
</t>
</section>
<section title="Excessive rate of incoming Data Records">
<t>
The tester MUST cause Data Records to be exported to
the Collecting Process with an increasing export rate.
</t>
<t>
For TCP or SCTP in reliable mode, the tester MUST
ensure that export stalls the Exporting Process once
the Collecting Process becomes fully loaded.
</t>
<t>
For UDP export, the tester MUST ensure that the
Collecting Process drops records as it becomes
overloaded, and MUST check that the Collecting
Process logs a warning.
</t>
</section>
<section title="Large Templates">
<t>
The tester MUST create Templates with the maximum
possible number of Information Elements, and cause
these to be exported to the Collecting Process.
</t>
<t>
The total length field in the IP header is 16 bits,
allowing a length up to 65535 octets. 20 octets are
required for a minimal IPv4 header, 16 octets for the
IPFIX header, 4 octets for the Set header and 4 octets
for the Template header, so the Template definition may
be up to (65535 - 20 - 16 - 4 - 4) = 65491 octets long.
The minimum IPFIX Information Element specification
requires 4 octets: two for the Information Element ID
and two for the field length. Therefore, the maximum
number of IPFIX Information Elements in a single
Template is 65491 / 4 = 16372. With this many
Information Elements, the Template will be 65488 octets
long while the entire packet will be 65532 octets long.
</t>
<t>
The tester MUST create Data Records conforming to this
Template, and cause them to be exported. Note that,
for the implementation, the associated Data Records
might be smaller or larger than the Template Records
depending on the length of the Information Elements
defined by the Template and on the presence of
variable length Information Elements.
</t>
<t>
The tester MUST ensure that the Collecting Process
correctly receives and decodes the Template and
associated Data Records.
</t>
</section>
<section title="Many new Templates within Data Template timeout
interval">
<t>
The tester MUST create a large number of different
Templates and cause them to be exported to the
Collecting Process to stress test the Collecting
Process's memory consumption.
</t>
<t>
The tester MUST ensure that the Collecting Process
gracefully discards Templates if it's running out of
memory resources, and MUST check that warnings are
logged.
</t>
</section>
<section title="Multiple Exporting Processes exporting to one
Collecting Process">
<t>
The tester MUST configure multiple Exporting Processes
to export Templates and associated Data Records to the
same Collecting Process at the same time.
</t>
<t>
The tester MUST ensure that all the Templates and
associated Data Records are correctly received and
decoded at the Collecting Process, and that no
Exporting Process stalls or disconnects completely
unless the Collecting Process runs out of memory.
</t>
</section>
<section title="Export from one Exporting Process to multiple
Collecting Processes">
<t>
If the Exporting Process supports multiple simultaneous
export destinations, the tester MUST configure the
Exporting Process to export Data Records in parallel to
different Collecting Processes.
</t>
<t>
The tester MUST configure the use of a mixture of
simple and complex Templates and ensure they are all
correctly received and decoded by all the Collecting
Processes.
</t>
</section>
</section> <!-- Stress/Load tests -->
<section title="Error handling">
<t>
This section lists and describes a number of problems that
might occur in either the network or data transmission or
related to wrong information encoding, and which the IPFIX
Exporting Process and Collecting Process must be capable of
handling in a graceful way. It is intended to test the
robustness and fault tolerance of the IPFIX Processes.
</t>
<section title="Temporary network disconnect">
<t>
Due to network failures (either physical or logical,
e.g. defective routing) the connectivity between an
IPFIX Exporting Process and Collecting Process might be
disrupted. The IPFIX Exporting Process and Collecting
Process must be able to handle such events in a
deterministic and graceful way if they should occur
during an IPFIX export. When connection oriented
transmission protocols (TCP/SCTP) are in use, such a
failure may or may not be signaled to the Exporting
Process and Collecting Process by the operating system
depending on the type of network adapter, driver
software and operating system in use. The effect might
be the direct signaling of an error when IP packet
read/write system functions are invoked (signaling
connection reset by peer) or there might be an
OS-dependent connection timeout.
</t>
<t>
The IPFIX Exporting Process and Collecting Process
behavior MUST be checked upon such interruptions of
data transmission.
</t>
<t>
The tester MUST configure continuous export over all
applicable combinations of transports and protocols in
<xref target="connectivity"/> in turn.
</t>
<t>
For SCTP-based associations and TCP-based connections,
the tester MUST create a short disconnect between the
Exporting Process and the Collecting Process (e.g. by
momentarily interrupting the network connection) and
MUST ensure that export continues after the connection
is repaired. The tester MUST then create a longer
disconnection between the Exporting Process and
Collecting Process, and MUST ensure that export
continues after the connection is repaired.
</t>
<t>
For UDP-based data export there is no noticeable
connection loss, but data received with non-consecutive
sequence numbers indicates data loss. The tester MUST
create a short disconnect between the Exporting Process
and Collecting Process, and MUST ensure that this is
recognized and reported by the Collecting Process per
section 3.1 of <xref target="I-D.ietf-ipfix-protocol"/>.
</t>
</section>
<section title="Exporting Process termination and restart
during data transmission">
<t>
An IPFIX Collecting Process might be confronted with a
faulty Exporting Process implementation that suddenly
crashes, dropping any open connections. The Exporting
Process may be restarted again soon after the crash.
</t>
<t>
Such an event will only be visible to the Collecting
Process when the IPFIX Messages (Templates and
associated Data Records) are carried over TCP or SCTP.
For export via UDP no such test is available due to the
connection-less nature of the transport.
</t>
<t>
The tester MUST configure continuous export over all
applicable combinations of SCTP and TCP transports and
protocols in <xref target="connectivity"/> in turn.
For each combination, the tester MUST establish export,
then kill the active Exporting Process.
</t>
<t>
The tester MUST ensure that the associated Collecting
Process shuts down SCTP associations and closes TCP
connections associated with that export after a
suitable timeout period.
</t>
<t>
The tester MUST Ensure that the Collecting Process
discards the Template(s) received on the killed
transport session.
</t>
<t>
The tester MUST restart the Exporting Process again,
and MUST ensure that the Exporting Process exports the
Templates again.
</t>
<t>
The tester MUST ensure that the Collecting Process
receives and accepts both Templates and associated Data
Records from the new Exporting Process running
at the same source host.
</t>
</section>
<section title="Collecting Process termination and restart
during data transmission">
<t>
An IPFIX Exporting Process might be confronted with a
faulty Collecting Process implementation that suddenly
crashes, dropping any open Transport Sessions. The
Collecting Process may be restarted again soon after
the crash.
</t>
<t>
The tester MUST set up an Exporting Process and
Collecting Process and cause IPFIX Templates and
associated Data Records to be exported over all
applicable combinations of SCTP and TCP transports and
protocols in <xref target="connectivity"/> in turn.
Via UDP the restart of the Collecting Process will be
invisible to the Exporting Process and have no effect.
</t>
<t>
The tester MUST terminate the Collecting Process while
the export is in progress, and MUST ensure that the
Exporting Process shuts down SCTP associations and
closes TCP connections associated with that Collecting
Process.
</t>
<t>
The tester MUST restart the Collecting Process and
ensure that the Exporting Process connects to the
Collecting Process again and that it exports the IPFIX
Templates again.
</t>
<t>
The tester MUST ensure that the new Collecting Process
correctly receives and decodes the IPFIX Data Records
again.
</t>
</section>
<section title="Incorrect Template Records">
<t>
IPFIX Template Records contain a message length field,
an overall field count and a scope field count. The
field count is the number of all fields in the Template
Record, including the scope fields if present.
Recall from section 3.4.2.1 of
<xref target="I-D.ietf-ipfix-protocol"/>
that the scope field count may not be zero.
</t>
<t>
These tests verify the Collecting Process's operation
when it receives a Template Record with an invalid
message length.
</t>
<t>
Consider the example Template Record shown in
<xref target="invalid-template"/>. This Template
record is missing one Information Element ID and one
Information Element length field. There is insufficient
data in the set for the specified set length, and the
overall record is four octets too short for the
specified total length. Therefore the Template must be
dropped by the IPFIX Collecting Process, and the SCTP
association must be shut down or TCP connection closed.
</t>
<figure anchor="invalid-template">
<artwork>
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 = 10 | Total Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 1155202151 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 0x12345678 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 0x33334444 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Set Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Info Element Identifier = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The tester MUST create and cause the Exporting Process
to export the following IPFIX Templates, and MUST
ensure the correct Collecting Process behaviour for
each of the transports and protocols in
<xref target="connectivity"/>.
<list style='symbols'>
<t>
For SCTP transport, ensure that the Collecting
Process discards the IPFIX Message and shuts down
the SCTP association, and check that it logs the
error.
</t>
<t>
For TCP transport, ensure that the Collecting
Process discards the IPFIX Message, closes the
TCP connection, and check that it logs the error.
</t>
<t>
For UDP transport, ensure that the Collecting
Process discards the IPFIX Message, and check
that it logs the error.
</t>
</list>
</t>
<t>
(a) The tester MUST create the IPFIX Template shown in
<xref target="invalid-template"/> and cause the
Exporting Process to export it.
The tester MUST ensure that the Collecting Process's
behaviour is as specified above for each transport type.
</t>
<t>
(b) Consider the IPFIX Template shown in <xref
target="invalid-template"/>, modified with total length
= 28. In this case the IPFIX Message has to be
rejected because field count = 2 and there is no second
Information Element record present in the Set. The
available data is exhausted after reading the first
Information Element record.
</t>
<t>
The tester MUST create the modified Template and cause
the Exporting Process to export it. The tester MUST
ensure that the Collecting Process's behaviour is as
specified above for each transport type.
</t>
<t>
(c) Consider the IPFIX Template shown in <xref
target="invalid-template"/>, modified with total length
= 26. In this case the IPFIX Message has to be
rejected because the IPFIX Message length is too short.
After the first Information Element the IPFIX Message
data is exhausted according to the total length
information.
</t>
<t>
The tester MUST create the modified Template and cause
the Exporting Process to export it. The tester MUST
ensure that the Collecting Process's behaviour is as
specified above for each transport type.
</t>
<t>
(d) Consider the IPFIX Template shown in <xref
target="invalid-template"/>, modified with field count
= 1. In this case the IPFIX Message must be rejected
because total length is too large and does not match
the amount of data available.
</t>
<t>
The tester MUST create the modified Template and cause
the Exporting Process to export it. The tester MUST
ensure that the Collecting Process's behaviour is as
specified above for each transport type.
</t>
<t>
Finally when the IPFIX Template shown in <xref
target="invalid-template"/> is extended with the data
shown in <xref target="make-template-valid"/>, it
becomes a correct IPFIX Template.
</t>
<figure anchor="make-template-valid">
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Info Element Identifier = 12| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The tester MUST create the modified Template and cause
the Exporting Process to export it. The tester MUST
ensure that the Template is accepted by the Collecting
Process for each transport type.
</t>
<t>
The example Template record shown in <xref
target="invalid-scope-template"/> must be dropped
because the scope field count = 0.
</t>
<figure anchor="invalid-scope-template">
<artwork>
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 = 10 | Total Length = 30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 1155202151 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 0x12345678 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 0x33334444 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Set Length = 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 0 |0| Info Element Identifier = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The tester MUST create the Template shown in <xref
target="invalid-scope-template"/> and cause the
Exporting Process to export it. The tester MUST ensure
that the IPFIX Message is discarded by the Collecting
Process for each transport type, and MUST check that
the Collecting Process logs an error. The tester MUST
ensure that the Collecting Process also shuts down the
SCTP association or closes the TCP connection.
</t>
<t>
The tester MUST create an IPFIX Options Template where
the field count is less than the scope field count, and
cause the Exporting Process to export it. Use the above
IPFIX Options Template with scope field count = 2. The
tester MUST ensure that the Template is discarded by
the Collecting Process for each transport type, and
MUST check that the Collecting Process logs an error.
The tester MUST ensure that the Collecting Process
shuts down the SCTP association or closes the TCP
connection.
</t>
</section>
<section title="Incorrect Data Record">
<t>
The tester MUST create the following invalid Data
Records and cause them to be exported to the Collecting
Process over all applicable combinations of transports
and protocols in <xref target="connectivity"/>.
</t>
<t>
<list style='symbols'>
<t>
IPFIX Message too short.
</t>
<t>
Illegal use of reduced size encoding/
</t>
<t>
Invalid length specification in case of
variable length Information Elements.
</t>
</list>
</t>
<t>
The tester MUST ensure that the Collecting Process
discards the IPFIX Message and shuts down the SCTP
association or closes the TCP connection.
</t>
</section>
<section title="Export of non-matching Template and Data
Records">
<t>
The tester MUST create Templates and associated Data
Records that fail to conform to those Templates in the
following ways:
</t>
<t>
<list style='symbols'>
<t>
too few Information Elements in Data Record
</t>
<t>
too many Information Elements in Data Record
</t>
</list>
</t>
<t>
The tester MUST cause the Templates and associated
Data Records to be exported to the Collecting Process
over all applicable combinations of transports and
protocols in <xref target="connectivity"/>.
</t>
<t>
The tester MUST ensure that the Collecting Process
discards the IPFIX Message and shuts down the SCTP
association or closes the TCP connection.
</t>
</section>
<section title="Incorrect Set IDs">
<t>
The tester MUST create Template sets, Option Template
sets, and associated Data sets with an incorrect Set
ID, and cause these to be exported to the Collecting
Process over all applicable combinations of transports
and protocols in <xref target="connectivity"/>.
</t>
<t>
Per <xref target="I-D.ietf-ipfix-protocol"/>
only the Set ID values 2 and 3 denote valid sets.
</t>
<t>
The tester MUST ensure that the Collecting Process
discards the IPFIX Message and shuts down the SCTP
association or closes the TCP connection.
</t>
</section>
<section title="Re-using Template IDs">
<section title="Re-using the same Template ID inside the
Template expiry time">
<section title="Using SCTP transport.">
<t>
The tester MUST create an IPFIX Template
and cause it to be exported to a Collecting
Process over SCTP transport.
</t>
<t>
The tester MUST cause the same Template to
be exported to the same Collecting Process
again, and MUST ensure that the Collecting
Process discards the IPFIX Message and
shuts down the SCTP association.
</t>
<t>
The tester MUST create and export another
IPFIX Template to a Collecting Process over
SCTP transport.
</t>
<t>
The tester MUST modify the Template
contents while retaining the same Template
ID.
</t>
<t>
The tester MUST cause the modified Template
to be exported to the Collecting Process,
and MUST ensure that the Collecting Process
discards the IPFIX Message and shuts down
the SCTP association.
</t>
<t>
The tester MUST check that an error was
logged.
</t>
</section>
<section title="Using TCP transport.">
<t>
The tester MUST create an IPFIX Template
and cause it to be exported to a Collecting
Process over TCP transport.
</t>
<t>
The tester MUST cause the same Template to
be exported to the same Collecting Process
again, and MUST ensure that the Collecting
Process resets the TCP connection and
discards the IPFIX Message.
</t>
<t>
The tester MUST create and export another
IPFIX Template to a Collecting Process over
TCP transport.
</t>
<t>
The tester MUST modify the Template
contents while retaining the same Template
ID.
</t>
<t>
The tester MUST cause the modified Template
to be exported to the Collecting Process,
and MUST ensure that the Collecting Process
resets the TCP connection and discards the
IPFIX Message.
</t>
<t>
The tester MUST check that an error was
logged.
</t>
</section>
<section title="Using UDP transport.">
<t>
The tester MUST create an IPFIX Template
and cause it to be exported to a Collecting
Process over UDP transport.
</t>
<t>
Before the Template times out on the
Collecting Process, the tester MUST cause
the same Template to be exported again and
MUST ensure that the Collecting Process
accepts the Template.
</t>
<t>
The tester MUST create a different Template
with the same ID and MUST cause this to be
exported to the Collecting Process before
the original Template times out.
</t>
<t>
The tester MUST ensure that the Collecting
Process does not reject the new Template,
and MUST check that an error is logged.
</t>
</section>
</section> <!-- Re-using the same Template ID inside the Template expiry time -->
<section title="Re-using the same Template ID after the
Template expiry time">
<section title="Using SCTP transport.">
<t>
The tester MUST create an IPFIX Template
and cause it to be exported to a Collecting
Process over SCTP transport.
</t>
<t>
The tester MUST ensure that the Template was
correctly received and decoded by
the Collecting Process.
</t>
<t>
The tester MUST cause a Template Withdrawal
Message for the Template to be sent to the
Collecting Process, and MUST ensure that
the Template has been removed from the
Collecting Process.
</t>
<t>
The tester MUST create Data Records
conforming to the Template and cause them
to be exported to the Collecting Process.
</t>
<t>
The tester MUST ensure that the Collecting
Process discards the Data Records.
</t>
<t>
The tester MUST check that the
Collecting Process logs a warning.
</t>
<t>
The tester MUST cause the Template to be
exported again to the same Collecting
Process over SCTP transport.
</t>
<t>
The tester MUST ensure that the Template was
correctly received and decoded by
the Collecting Process.
</t>
</section>
<section title="Using TCP transport.">
<t>
The tester MUST create an IPFIX Template
and cause it to be exported to a Collecting
Process over TCP transport.
</t>
<t>
The tester MUST ensure that the Template was
correctly received and decoded by
the Collecting Process.
</t>
<t>
The tester MUST cause a Template Withdrawal
Message for the Template to be sent to the
Collecting Process, and MUST ensure that
the Template has been removed from the
Collecting Process.
</t>
<t>
The tester MUST create Data Records
conforming to the Template and cause them
to be exported to the Collecting Process.
</t>
<t>
The tester MUST ensure that the Collecting
Process discards the Data Records.
</t>
<t>
The tester MUST check that the
Collecting Process logs a warning.
</t>
<t>
The tester MUST cause the Template to be
exported again to the same Collecting
Process over TCP transport.
</t>
<t>
The tester MUST ensure that the Template was
correctly received and decoded by
the Collecting Process.
</t>
</section>
<section title="Using UDP transport.">
<t>
The tester MUST create an IPFIX Template
and cause it to be exported to a Collecting
Process over UDP transport.
</t>
<t>
The tester MUST ensure that the Template was
correctly received and decoded by
the Collecting Process.
</t>
<t>
The tester MUST allow the received Template
to expire on the Collecting Process.
</t>
<t>
The tester MUST create Data Records
conforming to the Template and cause them
to be exported to the Collecting Process.
</t>
<t>
The tester MUST ensure that the Collecting
Process discards the Data Records.
</t>
<t>
The tester MUST check that the
Collecting Process logs a warning.
</t>
<t>
The tester MUST cause the Template to be
exported again to the same Collecting
Process over UDP transport.
</t>
<t>
The tester MUST ensure that the Template was
correctly received and decoded by
the Collecting Process.
</t>
</section>
</section> <!-- Re-using the same Template ID after the Template expiry time -->
<section title="Re-exporting an existing Template ID without
withdrawal">
<t>
<xref target="I-D.ietf-ipfix-protocol"/> states in
section 8 that a Template must not be sent more than
once during the lifetime of an SCTP association.
</t>
<t>
The tester MUST create an IPFIX Template and cause it
to be exported to the Collecting Process multiple
times over an SCTP association.
</t>
<t>
The tester MUST ensure that the Collecting Process
discards the IPFIX Message containing the duplicate
Templates and shuts down the SCTP association. The
tester MUST check that the Collecting Process logs a
warning.
</t>
</section>
</section>
</section> <!-- Error handling -->
<section title="TLS connectivity and policy selection"
anchor="tls-connectivity">
<t>
This section lists tests that verify
connectivity over TLS and DTLS, and proper
selection of TLS policies as specified in the
IPFIX Protocol. It specifically does NOT purport
to test the security of IPFIX Message transport
over TLS or DTLS, as evaluating the security of a
transport session is really a test of the TLS or
DTLS implementation over which a given IPFIX
implementation runs, and as such is out of scope
for this document.
</t>
<section title="TLS test setup" anchor="tls-setup">
<t>
Setting up for TLS connectivity and policy
testing requires the creation of appropriate
X.509 certificates and private keys for a test
environment, and the configuration of a DNS
server to answer with consistent information
for the hosts used in the test.
</t>
<t>
The tester MUST configure the following certificates:
<list>
<t>
1. A Certificate Authority (CA) certificate and
associated private key for signing the
following certificates.
</t>
<t>
2. One certificate and associated private key,
with a CN (Common Name) or subjectAltName
extension of type dNSName containing the fully
qualified domain name of the host, signed by
the CA certificate in 1, for each IPFIX
Exporting Process in the test.
</t>
<t>
3. One certificate and associated private key,
with a CN (common name) or subjectAltName
extension of type dNSName containing the fully
qualified domain name of the host, signed by
the CA certificate in 1, for each IPFIX
Collecting Process in the test.
</t>
</list>
</t>
<t>
The tester MUST configure consistent forward (A, AAAA)
and reverse (PTR) DNS records for each host in the test
on a DNS server used by the hosts for name resolution.
</t>
<t>
The tester MUST ensure that the Exporting Process and
Collecting Process are on different hosts.
</t>
</section>
<section title="TLS over TCP connectivity test"
anchor="tls-tcp-connectivity">
<t>
The tester MUST set up certificates and DNS as in
<xref target="tls-setup"/>.
</t>
<t>
The tester MUST configure one Exporting Process and one
Collecting Process with their appropriate certificates
to transfer IPFIX Messages over TLS over TCP.
</t>
<t>
The tester MUST create an IPFIX Template and associated
Data Record, and cause them to be exported over the TCP
connection.
</t>
<t>
The tester MUST ensure that a TCP connection and a TLS
connection were established, MUST ensure that data was
exchanged, and MUST ensure that the data received at
the Collecting Process is correct.
</t>
</section>
<section title="DTLS over UDP connectivity test"
anchor="tls-udp-connectivity">
<t>
The tester MUST set up certificates and DNS as in
<xref target="tls-setup"/>.
</t>
<t>
The tester MUST configure one Exporting Process and one
Collecting Process with their appropriate certificates
to transfer IPFIX Messages over DTLS over UDP.
</t>
<t>
The tester MUST create an IPFIX Template and associated
Data Record, and cause them to be exported over the UDP
connection.
</t>
<t>
The tester MUST ensure that UDP packets were sent and a
DTLS connection was established, MUST ensure that data
was exchanged, and MUST ensure that the data received
at the Collecting Process is correct.
</t>
</section>
<section title="DTLS over PR-SCTP connectivity test"
anchor="tls-sctp-connectivity">
<t>
The tester MUST set up certificates and DNS as in
<xref target="tls-setup"/>.
</t>
<t>
The tester MUST configure one Exporting Process and one
Collecting Process with their appropriate certificates
to transfer IPFIX Messages over DTLS over PR-SCTP.
</t>
<t>
The tester MUST create an IPFIX Template and associated
Data Record, and cause them to be exported over the
SCTP association.
</t>
<t>
The tester MUST ensure that an SCTP association and a
DTLS connection were established, MUST ensure that data
was exchanged, and MUST ensure that the data received
at the Collecting Process is correct.
</t>
</section>
<section title="TLS bidirectional authentication policy test">
<t>
This is an optional test for Collecting
Processes only; it requires the modification
of an Exporting Process to NOT present a
certificate.
</t>
<t>
The tester MUST modify an Exporting Process to NOT
present a certificate.
</t>
<t>
The tester MUST perform the connectivity tests in
<xref target="tls-tcp-connectivity"/>,
<xref target="tls-udp-connectivity"/>, and
<xref target="tls-sctp-connectivity"/>.
</t>
<t>
The tester MUST ensure that the Collecting Process
rejects the TLS or DTLS connection establishment.
</t>
</section>
<section title="Exporting Process Identity Mismatch TLS Policy
test">
<t>
The tester MUST set up certificates and DNS as in
<xref target="tls-setup"/>.
</t>
<t>
The tester MUST use a certificate for the Exporting
Process that does NOT match the fully qualified domain
name of the host on which the Exporting Process runs.
</t>
<t>
The tester MUST Perform the connectivity tests in
<xref target="tls-tcp-connectivity"/>,
<xref target="tls-udp-connectivity"/>, and
<xref target="tls-sctp-connectivity"/>.
</t>
<t>
The tester MUST ensure that the Collecting Process
rejects the TLS or DTLS connection establishment.
</t>
</section>
<section title="Collecting Process Identity Mismatch TLS Policy
test">
<t>
The tester MUST set up certificates and DNS as in <xref
target="tls-setup"/>.
</t>
<t>
The tester MUST use a certificate for the Collecting
Process that does NOT match the fully qualified domain
name of the host on which the Collecting Process runs.
</t>
<t>
The tester MUST perform the connectivity tests in
<xref target="tls-tcp-connectivity"/>,
<xref target="tls-udp-connectivity"/>, and
<xref target="tls-sctp-connectivity"/>.
</t>
<t>
The tester MUST ensure that the Exporting Process
rejects the TLS or DTLS connection establishment.
</t>
</section>
</section> <!-- TLS connectivity and policy selection -->
</section> <!-- Test Specifications -->
<section title="Security considerations">
<t>
This memo raises no security issues.
</t>
</section>
<section title="IANA considerations">
<t>
This memo raises no IANA considerations.
</t>
</section>
<section title="Acknowledgements">
<t>
The authors wish to thank Brian Trammell for contributing the
initial text for <xref target="tls-connectivity"/>.
</t>
</section>
</middle>
<back>
<references title='Normative references'>
&rfc2119;
&rfc3917;
&ietf-ipfix-architecture;
&ietf-ipfix-as;
&ietf-ipfix-info;
&ietf-ipfix-protocol;
</references>
<references title='Informative references'>
&rfc2960;
&rfc3550;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:17:44 |