| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
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 obsoleted 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.
This Internet-Draft will expire on April 19, 2008.
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.
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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
1.
Introduction
1.1.
Motivation
1.2.
Document Scope
1.3.
IPFIX Documents Overview
2.
Terminology
3.
Test Specifications
3.1.
Exporting Process / Collecting Process connectivity
tests
3.1.1.
Connectivity tests between Exporting Process
and Collecting Process
3.2.
Template and Data Record tests
3.2.1.
Transmission of Template with fixed
size Information Elements
3.2.2.
Transmission of Template with
variable length Information Elements
3.2.3.
Set Padding
3.2.4.
Record Padding
3.2.5.
Template Withdrawal Message
3.3.
Information Element tests
3.3.1.
Enterprise-specific Information Elements
3.3.2.
Reduced Size Encoding of Information Elements
3.3.3.
Multiple instances of the same Information
Element in one Template
3.4.
Options Template tests
3.4.1.
Using any Information Elements as Scope
3.4.2.
Using multiple Scopes
3.4.3.
Metering Process Statistics Option
Template
3.4.4.
Metering Process Reliability Statistics
Option Template
3.4.5.
Exporting Process Reliability Statistics
Option Template
3.4.6.
Flow Keys Option Template
3.5.
Stress/Load tests
3.5.1.
Large number of Records for one Template
3.5.2.
Excessive rate of incoming Data Records
3.5.3.
Large Templates
3.5.4.
Many new Templates within Data Template timeout
interval
3.5.5.
Multiple Exporting Processes exporting to one
Collecting Process
3.5.6.
Export from one Exporting Process to multiple
Collecting Processes
3.6.
Error handling
3.6.1.
Temporary network disconnect
3.6.2.
Exporting Process termination and restart
during data transmission
3.6.3.
Collecting Process termination and restart
during data transmission
3.6.4.
Incorrect Template Records
3.6.5.
Incorrect Data Record
3.6.6.
Export of non-matching Template and Data
Records
3.6.7.
Incorrect Set IDs
3.6.8.
Re-using Template IDs
3.7.
TLS connectivity and policy selection
3.7.1.
TLS test setup
3.7.2.
TLS over TCP connectivity test
3.7.3.
DTLS over UDP connectivity test
3.7.4.
DTLS over PR-SCTP connectivity test
3.7.5.
TLS bidirectional authentication policy test
3.7.6.
Exporting Process Identity Mismatch TLS Policy
test
3.7.7.
Collecting Process Identity Mismatch TLS Policy
test
4.
Security considerations
5.
IANA considerations
6.
Acknowledgements
7.
References
7.1.
Normative references
7.2.
Informative references
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
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.
The IPFIX architecture [I‑D.ietf‑ipfix‑architecture] (Sadasivan, G., “Architecture for IP Flow Information Export,” September 2006.) 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.
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.
| TOC |
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.
| TOC |
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.
| TOC |
The IPFIX protocol [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.) 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 [I‑D.ietf‑ipfix‑architecture] (Sadasivan, G., “Architecture for IP Flow Information Export,” September 2006.), per the requirements defined in [RFC3917] (Quittek, J., Zseby, T., Claise, B., and S. Zander, “Requirements for IP Flow Information Export (IPFIX),” October 2004.). [I‑D.ietf‑ipfix‑architecture] (Sadasivan, G., “Architecture for IP Flow Information Export,” September 2006.) 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 [I‑D.ietf‑ipfix‑info] (Quittek, J., “Information Model for IP Flow Information Export,” February 2007.). Finally [I‑D.ietf‑ipfix‑as] (Zseby, T., “IPFIX Applicability,” July 2007.) 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.
| TOC |
The terminology used in this document is fully aligned with the terminology defined in [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.) which is reproduced here for reference.
- Observation Point
- 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.
- 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.
- Observation Domain
- 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.
- It is RECOMMENDED that Observation Domain IDs are also unique per IPFIX Device.
- IP Traffic Flow or Flow
- There are several definitions of the term 'flow' being used by the Internet community. Within the context of IPFIX we use the following definition:
- 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:
- 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 [RFC3550] (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.).)
- one or more characteristics of the packet itself (e.g. number of MPLS labels, etc...)
- 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. It includes packets selected by a sampling mechanism.
- Flow Key
- Each of the fields which
and which are used to define a Flow are termed Flow Keys.
- Belong to the packet header (e.g. destination IP address)
- Are a property of the packet itself (e.g. packet length)
- Are derived from packet treatment (e.g. AS number)
- Flow Record
- 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).
- Metering Process
- 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).
- 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.
- 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.
- Exporter
- A device which hosts one or more Exporting Processes is termed an Exporter.
- IPFIX Device
- An IPFIX Device hosts at least one Exporting Process. It may host further Exporting processes and arbitrary numbers of Observation Points and Metering Process.
- Collecting Process
- 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.
- Collector
- A device which hosts one or more Collecting Processes is termed a Collector.
- Template
- 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.
- IPFIX Message
- 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.
- 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 Data Record.
- Data Record
- A Data Record is a record that contains values of the parameters corresponding to a Template Record.
- Options Template Record
- 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.
- Set
- 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.
- There are three different types of Sets: Template Set, Options Template Set, and Data Set.
- Template Set
- A Template Set is a collection of one or more Template Records that have been grouped together in an IPFIX Message.
- Options Template Set
- An Options Template Set is a collection of one or more Options Template Records that have been grouped together in an IPFIX Message.
- Data Set
- 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.
- Information Element
- An Information Element is a protocol and encoding independent description of an attribute which may appear in an IPFIX Record. The IPFIX information model [I‑D.ietf‑ipfix‑info] (Quittek, J., “Information Model for IP Flow Information Export,” February 2007.) 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.
- Transport Session
- In SCTP, the transport session is known as the SCTP association, which is uniquely identified by the SCTP endpoints [RFC2960] (Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, “Stream Control Transmission Protocol,” October 2000.); 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.
| TOC |
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.
All tests described in this section MUST be successfully executed for an IPFIX architecture to be compliant with this document.
| TOC |
This section lists the basic tests that MUST succeed as a precondition for the more complex tests defined in later sections of this document.
| TOC |
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.
The tester MUST ensure that an SCTP association (or TCP connection) is established.
The tester MUST ensure that the Transport Session parameters (IP addresses and ports) are correct.
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).
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.
| TOC |
This section lists tests for checking the correct transmission of IPFIX Template Sets and associated Data Sets.
| TOC |
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 Section 3.1 (Exporting Process / Collecting Process connectivity tests).
The tester MUST ensure that the Template and associated Data Records were correctly received and decoded by the Collecting Process.
The tester MUST use various Information Elements in the Template so that each data type specified in [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.) (octet, unsigned16, unsigned32 ...) is used in at least one test.
| TOC |
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 Section 3.1 (Exporting Process / Collecting Process connectivity tests).
The tester MUST ensure that the Template contains:
The tester MUST ensure that the Template and associated Data Records were correctly received and decoded by the Collecting Process.
| TOC |
Section 3.3.1 of [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.) specifies IPFIX Set alignment using padding.
The tester MUST create two Data Sets with padding in between consisting of zero valued octets, as shown in Figure 1, 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.
+--------------------------------------------------+ | Set Header #1 | +--------------------------------------------------+ | Data Record | +--------------------------------------------------+ | Data Record | +--------------------------------------------------+ ... +--------------------------------------------------+ | Data Record | +--------------------------------------------------+ | Padding with 0 valued octets | +--------------------------------------------------+ | Set Header #2 | +--------------------------------------------------+ | Data Record | +--------------------------------------------------+
| Figure 1 |
| TOC |
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 Section 3.1 (Exporting Process / Collecting Process connectivity tests).
The tester MUST repeat the test with various padding sizes, including padding to boundaries other than 4 or 8 octets.
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). Figure 2 depicts such a Template, while Figure 3 depicts a Data Record conforming to that Template.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 2 |
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 3 |
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).
| TOC |
IPFIX Template management and Template Withdrawal are defined in chapter 8 of [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.).
| TOC |
The tester MUST create an IPFIX Template and cause that Template to be exported to an IPFIX Collector over a reliable transport.
The tester MUST ensure that the Template was correctly received and decoded by the Collecting Process.
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.
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.
| TOC |
The tester MUST create, export and withdraw an IPFIX Template as described in Section 3.2.5.1 (Withdrawal of a previously sent Template).
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.
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.
| TOC |
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.
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.
| TOC |
The tester MUST create several IPFIX Templates and cause them to be exported to an IPFIX Collector over a reliable transport.
The tester MUST ensure that the Templates were correctly received and decoded by the Collecting Process.
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.
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.
| TOC |
The tester MUST create several IPFIX Option Templates and cause them to be exported to an IPFIX Collector over a reliable transport.
The tester MUST ensure that the Option Templates were correctly received and decoded by the Collecting Process.
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.
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.
| TOC |
This section lists the tests that cover the use of Information Elements.
| TOC |
The tester MUST cause the export of a Template and associated Data Record that makes use of Enterprise-specific Information Elements as defined in [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.).
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.
| TOC |
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 [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.).
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 [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.), and not only the length used for its transmission.
| TOC |
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.
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.
| TOC |
This section lists the tests that cover the correct transfer of IPFIX Options Templates.
| TOC |
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 [I‑D.ietf‑ipfix‑info] (Quittek, J., “Information Model for IP Flow Information Export,” February 2007.).
The tester MUST cause the export of Options Template Records containing various different Information Elements of each data type specified in [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.) (octet, unsigned16, unsigned32 ...) in their scope fields, and MUST export a Data Record using each Template.
The tester MUST ensure that the Templates and the associated Data Records are correctly received and decoded by the Collecting Process.
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.
The tester MUST ensure that the Collecting Process accepts an Enterprise specific Information Element in the scope field.
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.
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.
| TOC |
[I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.) 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."
The tester MUST cause the export of an Options Template Record containing multiple scope fields, and a Data Record conforming to that Template.
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.
| TOC |
The tester MUST create a Metering Process Statistics Option Templates as defined in section 4.1 of [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.), and MUST cause the Option Template and an associated Data Record to be exported.
The tester MUST ensure that the Collecting Process correctly receives and decodes the Option Template and associated Data Record.
The tester MUST also check that the optional meteringProcessId Scope Field is supported by the Collecting Process implementation.
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.
| TOC |
The tester MUST create a Metering Process Reliability Statistics Option Template as defined in section 4.2 of [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.), and MUST cause the Option Template and an associated Data Record to be exported.
The tester MUST ensure that the Collecting Process correctly receives and decodes the Option Template and associated Data Record.
The tester MUST also check that the optional meteringProcessId Scope Field is supported by the Collecting Process implementation.
| TOC |
The tester MUST create an Exporting Process Reliability Statistics Option Template as defined in section 4.3 of [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.), and MUST cause the Option Template and an associated Data Record to be exported.
The tester MUST ensure that the Collecting Process correctly receives and decodes the Option Template and associated Data Record.
| TOC |
The tester MUST create a Flow Keys Option Template, as defined in section 4.4 of [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.), where the templateId refers to an existing Template, and MUST cause the Option Template and an associated Data Record to be exported.
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.
The tester MUST create another Flow Keys Data Record to be exported where the associated templateId has insufficient fields to satisfy the flowKeyIndicator.
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.
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.
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.
| TOC |
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.
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.
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.
| TOC |
The tester MUST export many Data Records to the Collecting Process, all conforming to the same Template.
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.
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.
| TOC |
The tester MUST cause Data Records to be exported to the Collecting Process with an increasing export rate.
For TCP or SCTP in reliable mode, the tester MUST ensure that export stalls the Exporting Process once the Collecting Process becomes fully loaded.
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.
| TOC |
The tester MUST create Templates with the maximum possible number of Information Elements, and cause these to be exported to the Collecting Process.
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.
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.
The tester MUST ensure that the Collecting Process correctly receives and decodes the Template and associated Data Records.
| TOC |
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.
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.
| TOC |
The tester MUST configure multiple Exporting Processes to export Templates and associated Data Records to the same Collecting Process at the same time.
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.
| TOC |
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.
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.
| TOC |
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.
| TOC |
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.
The IPFIX Exporting Process and Collecting Process behavior MUST be checked upon such interruptions of data transmission.
The tester MUST configure continuous export over all applicable combinations of transports and protocols in Section 3.1 (Exporting Process / Collecting Process connectivity tests) in turn.
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.
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 [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.).
| TOC |
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.
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.
The tester MUST configure continuous export over all applicable combinations of SCTP and TCP transports and protocols in Section 3.1 (Exporting Process / Collecting Process connectivity tests) in turn. For each combination, the tester MUST establish export, then kill the active Exporting Process.
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.
The tester MUST Ensure that the Collecting Process discards the Template(s) received on the killed transport session.
The tester MUST restart the Exporting Process again, and MUST ensure that the Exporting Process exports the Templates again.
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.
| TOC |
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.
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 Section 3.1 (Exporting Process / Collecting Process connectivity tests) in turn. Via UDP the restart of the Collecting Process will be invisible to the Exporting Process and have no effect.
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.
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.
The tester MUST ensure that the new Collecting Process correctly receives and decodes the IPFIX Data Records again.
| TOC |
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 [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.) that the scope field count may not be zero.
These tests verify the Collecting Process's operation when it receives a Template Record with an invalid message length.
Consider the example Template Record shown in Figure 4. 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.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 4 |
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 Section 3.1 (Exporting Process / Collecting Process connectivity tests).
(a) The tester MUST create the IPFIX Template shown in Figure 4 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.
(b) Consider the IPFIX Template shown in Figure 4, 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.
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.
(c) Consider the IPFIX Template shown in Figure 4, 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.
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.
(d) Consider the IPFIX Template shown in Figure 4, 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.
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.
Finally when the IPFIX Template shown in Figure 4 is extended with the data shown in Figure 5, it becomes a correct IPFIX Template.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Info Element Identifier = 12| Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 5 |
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.
The example Template record shown in Figure 6 must be dropped because the scope field count = 0.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Figure 6 |
The tester MUST create the Template shown in Figure 6 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.
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.
| TOC |
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 Section 3.1 (Exporting Process / Collecting Process connectivity tests).
The tester MUST ensure that the Collecting Process discards the IPFIX Message and shuts down the SCTP association or closes the TCP connection.
| TOC |
The tester MUST create Templates and associated Data Records that fail to conform to those Templates in the following ways:
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 Section 3.1 (Exporting Process / Collecting Process connectivity tests).
The tester MUST ensure that the Collecting Process discards the IPFIX Message and shuts down the SCTP association or closes the TCP connection.
| TOC |
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 Section 3.1 (Exporting Process / Collecting Process connectivity tests).
Per [I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.) only the Set ID values 2 and 3 denote valid sets.
The tester MUST ensure that the Collecting Process discards the IPFIX Message and shuts down the SCTP association or closes the TCP connection.
| TOC |
| TOC |
| TOC |
The tester MUST create an IPFIX Template and cause it to be exported to a Collecting Process over SCTP transport.
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.
The tester MUST create and export another IPFIX Template to a Collecting Process over SCTP transport.
The tester MUST modify the Template contents while retaining the same Template ID.
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.
The tester MUST check that an error was logged.
| TOC |
The tester MUST create an IPFIX Template and cause it to be exported to a Collecting Process over TCP transport.
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.
The tester MUST create and export another IPFIX Template to a Collecting Process over TCP transport.
The tester MUST modify the Template contents while retaining the same Template ID.
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.
The tester MUST check that an error was logged.
| TOC |
The tester MUST create an IPFIX Template and cause it to be exported to a Collecting Process over UDP transport.
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.
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.
The tester MUST ensure that the Collecting Process does not reject the new Template, and MUST check that an error is logged.
| TOC |
| TOC |
The tester MUST create an IPFIX Template and cause it to be exported to a Collecting Process over SCTP transport.
The tester MUST ensure that the Template was correctly received and decoded by the Collecting Process.
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.
The tester MUST create Data Records conforming to the Template and cause them to be exported to the Collecting Process.
The tester MUST ensure that the Collecting Process discards the Data Records.
The tester MUST check that the Collecting Process logs a warning.
The tester MUST cause the Template to be exported again to the same Collecting Process over SCTP transport.
The tester MUST ensure that the Template was correctly received and decoded by the Collecting Process.
| TOC |
The tester MUST create an IPFIX Template and cause it to be exported to a Collecting Process over TCP transport.
The tester MUST ensure that the Template was correctly received and decoded by the Collecting Process.
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.
The tester MUST create Data Records conforming to the Template and cause them to be exported to the Collecting Process.
The tester MUST ensure that the Collecting Process discards the Data Records.
The tester MUST check that the Collecting Process logs a warning.
The tester MUST cause the Template to be exported again to the same Collecting Process over TCP transport.
The tester MUST ensure that the Template was correctly received and decoded by the Collecting Process.
| TOC |
The tester MUST create an IPFIX Template and cause it to be exported to a Collecting Process over UDP transport.
The tester MUST ensure that the Template was correctly received and decoded by the Collecting Process.
The tester MUST allow the received Template to expire on the Collecting Process.
The tester MUST create Data Records conforming to the Template and cause them to be exported to the Collecting Process.
The tester MUST ensure that the Collecting Process discards the Data Records.
The tester MUST check that the Collecting Process logs a warning.
The tester MUST cause the Template to be exported again to the same Collecting Process over UDP transport.
The tester MUST ensure that the Template was correctly received and decoded by the Collecting Process.
| TOC |
[I‑D.ietf‑ipfix‑protocol] (Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” September 2007.) states in section 8 that a Template must not be sent more than once during the lifetime of an SCTP association.
The tester MUST create an IPFIX Template and cause it to be exported to the Collecting Process multiple times over an SCTP association.
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.
| TOC |
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.
| TOC |
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.
The tester MUST configure the following certificates:
1. A Certificate Authority (CA) certificate and associated private key for signing the following certificates.
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.
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.
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.
The tester MUST ensure that the Exporting Process and Collecting Process are on different hosts.
| TOC |
The tester MUST set up certificates and DNS as in Section 3.7.1 (TLS test setup).
The tester MUST configure one Exporting Process and one Collecting Process with their appropriate certificates to transfer IPFIX Messages over TLS over TCP.
The tester MUST create an IPFIX Template and associated Data Record, and cause them to be exported over the TCP connection.
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.
| TOC |
The tester MUST set up certificates and DNS as in Section 3.7.1 (TLS test setup).
The tester MUST configure one Exporting Process and one Collecting Process with their appropriate certificates to transfer IPFIX Messages over DTLS over UDP.
The tester MUST create an IPFIX Template and associated Data Record, and cause them to be exported over the UDP connection.
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.
| TOC |
The tester MUST set up certificates and DNS as in Section 3.7.1 (TLS test setup).
The tester MUST configure one Exporting Process and one Collecting Process with their appropriate certificates to transfer IPFIX Messages over DTLS over PR-SCTP.
The tester MUST create an IPFIX Template and associated Data Record, and cause them to be exported over the SCTP association.
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.
| TOC |
This is an optional test for Collecting Processes only; it requires the modification of an Exporting Process to NOT present a certificate.
The tester MUST modify an Exporting Process to NOT present a certificate.
The tester MUST perform the connectivity tests in Section 3.7.2 (TLS over TCP connectivity test), Section 3.7.3 (DTLS over UDP connectivity test), and Section 3.7.4 (DTLS over PR-SCTP connectivity test).
The tester MUST ensure that the Collecting Process rejects the TLS or DTLS connection establishment.
| TOC |
The tester MUST set up certificates and DNS as in Section 3.7.1 (TLS test setup).
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.
The tester MUST Perform the connectivity tests in Section 3.7.2 (TLS over TCP connectivity test), Section 3.7.3 (DTLS over UDP connectivity test), and Section 3.7.4 (DTLS over PR-SCTP connectivity test).
The tester MUST ensure that the Collecting Process rejects the TLS or DTLS connection establishment.
| TOC |
The tester MUST set up certificates and DNS as in Section 3.7.1 (TLS test setup).
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.
The tester MUST perform the connectivity tests in Section 3.7.2 (TLS over TCP connectivity test), Section 3.7.3 (DTLS over UDP connectivity test), and Section 3.7.4 (DTLS over PR-SCTP connectivity test).
The tester MUST ensure that the Exporting Process rejects the TLS or DTLS connection establishment.
| TOC |
This memo raises no security issues.
| TOC |
This memo raises no IANA considerations.
| TOC |
The authors wish to thank Brian Trammell for contributing the initial text for Section 3.7 (TLS connectivity and policy selection).
| TOC |
| TOC |
| [I-D.ietf-ipfix-architecture] | Sadasivan, G., “Architecture for IP Flow Information Export,” draft-ietf-ipfix-architecture-12 (work in progress), September 2006 (TXT). |
| [I-D.ietf-ipfix-as] | Zseby, T., “IPFIX Applicability,” draft-ietf-ipfix-as-12 (work in progress), July 2007 (TXT). |
| [I-D.ietf-ipfix-info] | Quittek, J., “Information Model for IP Flow Information Export,” draft-ietf-ipfix-info-15 (work in progress), February 2007 (TXT). |
| [I-D.ietf-ipfix-protocol] | Claise, B., “Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information,” draft-ietf-ipfix-protocol-26 (work in progress), September 2007 (TXT). |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3917] | Quittek, J., Zseby, T., Claise, B., and S. Zander, “Requirements for IP Flow Information Export (IPFIX),” RFC 3917, October 2004 (TXT). |
| TOC |
| [RFC2960] | Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, “Stream Control Transmission Protocol,” RFC 2960, October 2000 (TXT). |
| [RFC3550] | Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” STD 64, RFC 3550, July 2003 (TXT, PS, PDF). |
| TOC |
| Carsten Schmoll | |
| Fraunhofer FOKUS | |
| Kaiserin-Augusta-Allee 31 | |
| Berlin D-10589 | |
| Germany | |
| Phone: | +49 30 3463 7136 |
| Email: | carsten.schmoll@fokus.fraunhofer.de |
| URI: | http://www.fokus.fraunhofer.de |
| Paul Aitken | |
| Cisco Systems | |
| 96 Commercial Quay | |
| Edinburgh EH6 6LX | |
| Scotland | |
| Phone: | +44 131 561 3616 |
| Email: | paitken@cisco.com |
| URI: | http://www.cisco.com |
| Benoit Claise | |
| Cisco Systems | |
| De Kleetlaan 6a b1 | |
| 1831 Diegem | |
| Belgium | |
| Phone: | +32 2 704 5622 |
| Email: | bclaise@cisco.com |
| URI: | http://www.cisco.com |
| TOC |
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.