[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-schmoll-ipfix-testing) 00 01 02 03 04 05 RFC 5471

IPFIX Working Group                                           C. Schmoll
Internet-Draft                                          Fraunhofer FOKUS
Intended status: Informational                                 P. Aitken
Expires: May 21, 2008                                          B. Claise
                                                           Cisco Systems
                                                       November 18, 2007


               IP Flow Information eXport (IPFIX) Testing
                    draft-ietf-ipfix-testing-03.txt

Status of this Memo

   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 May 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Schmoll, et al.           Expires May 21, 2008                  [Page 1]

Internet-Draft         IPFIX Test Recommendations          November 2007


Abstract

   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.







































Schmoll, et al.           Expires May 21, 2008                  [Page 2]

Internet-Draft         IPFIX Test Recommendations          November 2007


Conventions used in this document

   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].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Document Scope . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  IPFIX Documents Overview . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Test Specifications  . . . . . . . . . . . . . . . . . . . . . 12
     3.1.  Exporting Process / Collecting Process connectivity
           tests  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
       3.1.1.  Connectivity tests between Exporting Process and
               Collecting Process . . . . . . . . . . . . . . . . . . 12
     3.2.  Template and Data Record tests . . . . . . . . . . . . . . 13
       3.2.1.  Transmission of Template with fixed size
               Information Elements . . . . . . . . . . . . . . . . . 13
       3.2.2.  Transmission of Template with variable length
               Information Elements . . . . . . . . . . . . . . . . . 13
       3.2.3.  Set Padding  . . . . . . . . . . . . . . . . . . . . . 13
       3.2.4.  Record Padding . . . . . . . . . . . . . . . . . . . . 14
       3.2.5.  Template Withdrawal Message  . . . . . . . . . . . . . 15
     3.3.  Information Element tests  . . . . . . . . . . . . . . . . 17
       3.3.1.  Enterprise-specific Information Elements . . . . . . . 17
       3.3.2.  Reduced Size Encoding of Information Elements  . . . . 17
       3.3.3.  Multiple instances of the same Information Element
               in one Template  . . . . . . . . . . . . . . . . . . . 18
     3.4.  Options Template tests . . . . . . . . . . . . . . . . . . 18
       3.4.1.  Using any Information Elements as Scope  . . . . . . . 18
       3.4.2.  Using multiple Scopes  . . . . . . . . . . . . . . . . 19
       3.4.3.  Metering Process Statistics Option Template  . . . . . 19
       3.4.4.  Metering Process Reliability Statistics Option
               Template . . . . . . . . . . . . . . . . . . . . . . . 20
       3.4.5.  Exporting Process Reliability Statistics Option
               Template . . . . . . . . . . . . . . . . . . . . . . . 20
       3.4.6.  Flow Keys Option Template  . . . . . . . . . . . . . . 20
     3.5.  Stress/Load tests  . . . . . . . . . . . . . . . . . . . . 21
       3.5.1.  Large number of Records for one Template . . . . . . . 21
       3.5.2.  Excessive rate of incoming Data Records  . . . . . . . 21
       3.5.3.  Large Templates  . . . . . . . . . . . . . . . . . . . 22
       3.5.4.  Many new Templates within Data Template timeout
               interval . . . . . . . . . . . . . . . . . . . . . . . 22
       3.5.5.  Multiple Exporting Processes exporting to one



Schmoll, et al.           Expires May 21, 2008                  [Page 3]

Internet-Draft         IPFIX Test Recommendations          November 2007


               Collecting Process . . . . . . . . . . . . . . . . . . 22
       3.5.6.  Export from one Exporting Process to multiple
               Collecting Processes . . . . . . . . . . . . . . . . . 23
     3.6.  Error handling . . . . . . . . . . . . . . . . . . . . . . 23
       3.6.1.  Temporary network disconnect . . . . . . . . . . . . . 23
       3.6.2.  Exporting Process termination and restart during
               data transmission  . . . . . . . . . . . . . . . . . . 24
       3.6.3.  Collecting Process termination and restart during
               data transmission  . . . . . . . . . . . . . . . . . . 25
       3.6.4.  Incorrect Template Records . . . . . . . . . . . . . . 25
       3.6.5.  Incorrect Data Record  . . . . . . . . . . . . . . . . 28
       3.6.6.  Export of non-matching Template and Data Records . . . 29
       3.6.7.  Incorrect Set IDs  . . . . . . . . . . . . . . . . . . 29
       3.6.8.  Re-using Template IDs  . . . . . . . . . . . . . . . . 29
     3.7.  TLS connectivity and policy selection  . . . . . . . . . . 33
       3.7.1.  TLS test setup . . . . . . . . . . . . . . . . . . . . 33
       3.7.2.  TLS over TCP connectivity test . . . . . . . . . . . . 33
       3.7.3.  DTLS over UDP connectivity test  . . . . . . . . . . . 34
       3.7.4.  DTLS over PR-SCTP connectivity test  . . . . . . . . . 34
       3.7.5.  TLS bidirectional authentication policy test . . . . . 34
       3.7.6.  Exporting Process Identity Mismatch TLS Policy test  . 35
       3.7.7.  Collecting Process Identity Mismatch TLS Policy
               test . . . . . . . . . . . . . . . . . . . . . . . . . 35
   4.  Security considerations  . . . . . . . . . . . . . . . . . . . 36
   5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 37
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
     7.1.  Normative references . . . . . . . . . . . . . . . . . . . 39
     7.2.  Informative references . . . . . . . . . . . . . . . . . . 39
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
   Intellectual Property and Copyright Statements . . . . . . . . . . 41




















Schmoll, et al.           Expires May 21, 2008                  [Page 4]

Internet-Draft         IPFIX Test Recommendations          November 2007


1.  Introduction

   An IPFIX implementation, whether 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.

   For a testable IPFIX software toolkit one needs at least one IPFIX
   Exporting Process and one IPFIX Collecting Process.

   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.

1.1.  Motivation

   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.

1.2.  Document Scope

   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.

1.3.  IPFIX Documents Overview

   The IPFIX protocol [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
   [I-D.ietf-ipfix-architecture], per the requirements defined in
   [RFC3917].  [I-D.ietf-ipfix-architecture] specifies how IPFIX data
   records and Templates are carried via a congestion-aware transport



Schmoll, et al.           Expires May 21, 2008                  [Page 5]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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].  Finally [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.












































Schmoll, et al.           Expires May 21, 2008                  [Page 6]

Internet-Draft         IPFIX Test Recommendations          November 2007


2.  Terminology

   The terminology used in this document is fully aligned with the
   terminology defined in [I-D.ietf-ipfix-protocol] 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:



Schmoll, et al.           Expires May 21, 2008                  [Page 7]

Internet-Draft         IPFIX Test Recommendations          November 2007


      1.  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].)

      2.  one or more characteristics of the packet itself (e.g. number
          of MPLS labels, etc...)

      3.  one or more of fields derived from packet treatment (e.g. next
          hop IP address, the output interface, etc...)

      A packet is defined to belong to a Flow if it completely satisfies
      all the defined properties of the Flow.

      This definition covers the range from a Flow containing all
      packets observed at a network interface to a Flow consisting of
      just a single packet between two applications.  It includes
      packets selected by a sampling mechanism.

   Flow Key

      Each of the fields which

      1.  Belong to the packet header (e.g. destination IP address)

      2.  Are a property of the packet itself (e.g. packet length)

      3.  Are derived from packet treatment (e.g.  AS number)

      and which are used to define a Flow are termed Flow Keys.

   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).






Schmoll, et al.           Expires May 21, 2008                  [Page 8]

Internet-Draft         IPFIX Test Recommendations          November 2007


      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.






Schmoll, et al.           Expires May 21, 2008                  [Page 9]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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







Schmoll, et al.           Expires May 21, 2008                 [Page 10]

Internet-Draft         IPFIX Test Recommendations          November 2007


      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] 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]; 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.





















Schmoll, et al.           Expires May 21, 2008                 [Page 11]

Internet-Draft         IPFIX Test Recommendations          November 2007


3.  Test Specifications

   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.

3.1.  Exporting Process / Collecting Process connectivity tests

   This section lists the basic tests that MUST succeed as a
   precondition for the more complex tests defined in later sections of
   this document.

3.1.1.  Connectivity tests between Exporting Process and Collecting
        Process

   The tester MUST create 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.

   When the Exporting Process and Collecting Process are to be connected
   by an SCTP transport, the tester MUST ensure that an SCTP association
   is established.

   When the Exporting Process and Collecting Process are to be connected
   by an TCP transport, the tester MUST ensure that a 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
   packet sniffing 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.







Schmoll, et al.           Expires May 21, 2008                 [Page 12]

Internet-Draft         IPFIX Test Recommendations          November 2007


3.2.  Template and Data Record tests

   This section lists tests for checking the correct transmission of
   IPFIX Template Sets and associated Data Sets.

3.2.1.  Transmission of Template with fixed size Information Elements

   The tester MUST create a Template with a few fixed-size Information
   Elements where each data type defined in [I-D.ietf-ipfix-protocol]
   (octet, unsigned16, unsigned32 ...) is used at least once, and cause
   the Template and associated Data Records to be exported over all
   applicable combinations of transports and protocols in Section 3.1.

   The tester MUST ensure that the Template and associated Data Records
   were correctly received and decoded by the Collecting Process.

3.2.2.  Transmission of Template with variable length Information
        Elements

   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.

   The tester MUST ensure that the Template contains:

   o  a single variable length Information Element

   o  a single variable length Information Element followed by a fixed
      length Information Element

   o  a fixed length Information Element followed by a variable length
      Information Element

   o  multiple variable length Information Elements

   The tester MUST ensure that the Template and associated Data Records
   were correctly received and decoded by the Collecting Process.

3.2.3.  Set Padding

   Section 3.3.1 of [I-D.ietf-ipfix-protocol] 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



Schmoll, et al.           Expires May 21, 2008                 [Page 13]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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

3.2.4.  Record Padding

   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.

   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.













Schmoll, et al.           Expires May 21, 2008                 [Page 14]

Internet-Draft         IPFIX Test Recommendations          November 2007


    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).

3.2.5.  Template Withdrawal Message

   IPFIX Template management and Template Withdrawal are defined in
   chapter 8 of [I-D.ietf-ipfix-protocol].

3.2.5.1.  Withdrawal of a previously sent Template

   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.




Schmoll, et al.           Expires May 21, 2008                 [Page 15]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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.

3.2.5.2.  Withdrawal of a previously withdrawn Template

   The tester MUST create, export and withdraw an IPFIX Template as
   described in Section 3.2.5.1.

   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.

3.2.5.3.  Withdrawal of a previously unsent Template

   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.

3.2.5.4.  Withdrawing all Data Templates

   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.




Schmoll, et al.           Expires May 21, 2008                 [Page 16]

Internet-Draft         IPFIX Test Recommendations          November 2007


3.2.5.5.  Withdrawing all Option Templates

   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.

3.3.  Information Element tests

   This section lists the tests that cover the use of Information
   Elements.

3.3.1.  Enterprise-specific Information Elements

   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].

   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.

3.3.2.  Reduced Size Encoding of Information Elements

   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].

   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], and not only the length used for its
   transmission.







Schmoll, et al.           Expires May 21, 2008                 [Page 17]

Internet-Draft         IPFIX Test Recommendations          November 2007


3.3.3.  Multiple instances of the same Information Element in one
        Template

   The tester MUST cause the export of a Template and associated Data
   Record containing multiple instances of the same Information Element
   consecutively

   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.

   The tester MUST cause the export of another Template and associated
   Data Record containing multiple instances of the same Information
   Element 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.

3.4.  Options Template tests

   This section lists the tests that cover the correct transfer of IPFIX
   Options Templates.

3.4.1.  Using any Information Elements as Scope

   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].

   The tester MUST cause the export of Options Template Records
   containing various different Information Elements of each of the
   abstract data type specified in [I-D.ietf-ipfix-protocol] (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.



Schmoll, et al.           Expires May 21, 2008                 [Page 18]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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.

3.4.2.  Using multiple Scopes

   [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."

   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.

3.4.3.  Metering Process Statistics Option Template

   The tester MUST create a Metering Process Statistics Option Templates
   as defined in section 4.1 of [I-D.ietf-ipfix-protocol], 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.







Schmoll, et al.           Expires May 21, 2008                 [Page 19]

Internet-Draft         IPFIX Test Recommendations          November 2007


3.4.4.  Metering Process Reliability Statistics Option Template

   The tester MUST create a Metering Process Reliability Statistics
   Option Template as defined in section 4.2 of
   [I-D.ietf-ipfix-protocol], 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.

3.4.5.  Exporting Process Reliability Statistics Option Template

   The tester MUST create an Exporting Process Reliability Statistics
   Option Template as defined in section 4.3 of
   [I-D.ietf-ipfix-protocol], 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.

3.4.6.  Flow Keys Option Template

   The tester MUST create a Flow Keys Option Template, as defined in
   section 4.4 of [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.

   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.




Schmoll, et al.           Expires May 21, 2008                 [Page 20]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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.

3.5.  Stress/Load tests

   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.

3.5.1.  Large number of Records for one Template

   The tester MUST export many Data Records to the Collecting Process,
   all conforming to the same Template, in order to put the Collecting
   Process under stress.

   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.

3.5.2.  Excessive rate of incoming Data Records

   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.




Schmoll, et al.           Expires May 21, 2008                 [Page 21]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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.

3.5.3.  Large Templates

   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.

3.5.4.  Many new Templates within Data Template timeout interval

   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.

3.5.5.  Multiple Exporting Processes exporting to one Collecting Process

   The tester MUST configure multiple Exporting Processes to export
   Templates and associated Data Records to the same Collecting Process
   at the same time.




Schmoll, et al.           Expires May 21, 2008                 [Page 22]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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.

3.5.6.  Export from one Exporting Process to multiple Collecting
        Processes

   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.

3.6.  Error handling

   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.

3.6.1.  Temporary network disconnect

   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 in turn.

   For SCTP-based associations and TCP-based connections, the tester



Schmoll, et al.           Expires May 21, 2008                 [Page 23]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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].

3.6.2.  Exporting Process termination and restart during data
        transmission

   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
   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.





Schmoll, et al.           Expires May 21, 2008                 [Page 24]

Internet-Draft         IPFIX Test Recommendations          November 2007


3.6.3.  Collecting Process termination and restart during data
        transmission

   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 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.

3.6.4.  Incorrect Template Records

   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]
   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.








Schmoll, et al.           Expires May 21, 2008                 [Page 25]

Internet-Draft         IPFIX Test Recommendations          November 2007


     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.

   o  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.

   o  For TCP transport, ensure that the Collecting Process discards the
      IPFIX Message, closes the TCP connection, and check that it logs
      the error.  Note that since TCP is a streaming (rather than
      record-based) protocol, template length errors cannot be detected
      and may cause framing to be lost, potentially rendering the
      remainder of the IPFIX stream unintelligible.  Therefore some of
      these tests are not applicable for TCP transport, as indicated.

   o  For UDP transport, ensure that the Collecting Process discards the
      IPFIX Message, and check that it logs the error.

   (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 except for TCP, for which this test is not
   applicable.

   (b) Consider the IPFIX Template shown in Figure 4, modified with
   total length = 28.  In this case the IPFIX Message has to be rejected



Schmoll, et al.           Expires May 21, 2008                 [Page 26]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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.
   The TCP connection used for this test must be manually reset after
   the test.

   (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.
   This test is not applicable for TCP transport.

   (e) 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.






Schmoll, et al.           Expires May 21, 2008                 [Page 27]

Internet-Draft         IPFIX Test Recommendations          November 2007


     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.

3.6.5.  Incorrect Data Record

   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.

   o  IPFIX Message too short.

   o  Illegal use of reduced size encoding.




Schmoll, et al.           Expires May 21, 2008                 [Page 28]

Internet-Draft         IPFIX Test Recommendations          November 2007


   o  Invalid length specification in case of variable length
      Information Elements.

   The tester MUST ensure that the Collecting Process discards the IPFIX
   Message and shuts down the SCTP association or closes the TCP
   connection.

3.6.6.  Export of non-matching Template and Data Records

   The tester MUST create Templates and associated Data Records that
   fail to conform to those Templates in the following ways:

   o  too few Information Elements in Data Record

   o  too many Information Elements in Data Record

   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.

   The tester MUST ensure that the Collecting Process discards the IPFIX
   Message and shuts down the SCTP association or closes the TCP
   connection.

3.6.7.  Incorrect Set IDs

   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.

   Per [I-D.ietf-ipfix-protocol] 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.

3.6.8.  Re-using Template IDs

3.6.8.1.  Re-using the same Template ID inside the Template expiry time

3.6.8.1.1.  Using SCTP transport.

   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



Schmoll, et al.           Expires May 21, 2008                 [Page 29]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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.

3.6.8.1.2.  Using TCP transport.

   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.

3.6.8.1.3.  Using UDP transport.

   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.



Schmoll, et al.           Expires May 21, 2008                 [Page 30]

Internet-Draft         IPFIX Test Recommendations          November 2007


   The tester MUST ensure that the Collecting Process does not reject
   the new Template, and MUST check that an error is logged.

3.6.8.2.  Re-using the same Template ID after the Template expiry time

3.6.8.2.1.  Using SCTP transport.

   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.

3.6.8.2.2.  Using TCP transport.

   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.



Schmoll, et al.           Expires May 21, 2008                 [Page 31]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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.

3.6.8.2.3.  Using UDP transport.

   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.

3.6.8.3.  Re-exporting an existing Template ID without withdrawal

   [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.

   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.





Schmoll, et al.           Expires May 21, 2008                 [Page 32]

Internet-Draft         IPFIX Test Recommendations          November 2007


3.7.  TLS connectivity and policy selection

   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.

3.7.1.  TLS test setup

   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.

3.7.2.  TLS over TCP connectivity test

   The tester MUST set up certificates and DNS as in Section 3.7.1.

   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,



Schmoll, et al.           Expires May 21, 2008                 [Page 33]

Internet-Draft         IPFIX Test Recommendations          November 2007


   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.

3.7.3.  DTLS over UDP connectivity test

   The tester MUST set up certificates and DNS as in Section 3.7.1.

   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.

3.7.4.  DTLS over PR-SCTP connectivity test

   The tester MUST set up certificates and DNS as in Section 3.7.1.

   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.

3.7.5.  TLS bidirectional authentication policy test

   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,
   Section 3.7.3, and Section 3.7.4.



Schmoll, et al.           Expires May 21, 2008                 [Page 34]

Internet-Draft         IPFIX Test Recommendations          November 2007


   The tester MUST ensure that the Collecting Process rejects the TLS or
   DTLS connection establishment.

3.7.6.  Exporting Process Identity Mismatch TLS Policy test

   The tester MUST set up certificates and DNS as in Section 3.7.1.

   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,
   Section 3.7.3, and Section 3.7.4.

   The tester MUST ensure that the Collecting Process rejects the TLS or
   DTLS connection establishment.

3.7.7.  Collecting Process Identity Mismatch TLS Policy test

   The tester MUST set up certificates and DNS as in Section 3.7.1.

   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,
   Section 3.7.3, and Section 3.7.4.

   The tester MUST ensure that the Exporting Process rejects the TLS or
   DTLS connection establishment.





















Schmoll, et al.           Expires May 21, 2008                 [Page 35]

Internet-Draft         IPFIX Test Recommendations          November 2007


4.  Security considerations

   This memo raises no security issues.
















































Schmoll, et al.           Expires May 21, 2008                 [Page 36]

Internet-Draft         IPFIX Test Recommendations          November 2007


5.  IANA considerations

   This memo raises no IANA considerations.
















































Schmoll, et al.           Expires May 21, 2008                 [Page 37]

Internet-Draft         IPFIX Test Recommendations          November 2007


6.  Acknowledgements

   The authors wish to thank Brian Trammell for contributing the initial
   text for Section 3.7.















































Schmoll, et al.           Expires May 21, 2008                 [Page 38]

Internet-Draft         IPFIX Test Recommendations          November 2007


7.  References

7.1.  Normative references

   [I-D.ietf-ipfix-architecture]
              Sadasivan, G., "Architecture for IP Flow Information
              Export", draft-ietf-ipfix-architecture-12 (work in
              progress), September 2006.

   [I-D.ietf-ipfix-as]
              Zseby, T., "IPFIX Applicability", draft-ietf-ipfix-as-12
              (work in progress), July 2007.

   [I-D.ietf-ipfix-info]
              Quittek, J., "Information Model for IP Flow Information
              Export", draft-ietf-ipfix-info-15 (work in progress),
              February 2007.

   [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.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
              "Requirements for IP Flow Information Export (IPFIX)",
              RFC 3917, October 2004.

7.2.  Informative references

   [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.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.










Schmoll, et al.           Expires May 21, 2008                 [Page 39]

Internet-Draft         IPFIX Test Recommendations          November 2007


Authors' Addresses

   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


















Schmoll, et al.           Expires May 21, 2008                 [Page 40]

Internet-Draft         IPFIX Test Recommendations          November 2007


Full Copyright Statement

   Copyright (C) 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Schmoll, et al.           Expires May 21, 2008                 [Page 41]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/