11.  Security Considerations

   The security considerations for the IPFIX protocol have been derived
   from an analysis of potential security threats, as discussed in the
   "Security Considerations" section of IPFIX requirements [RFC3917].
   The requirements for IPFIX security are as follows:

   1. IPFIX must provide a mechanism to ensure the confidentiality of
      IPFIX data transferred from an Exporting Process to a Collecting
      Process, in order to prevent disclosure of Flow Records
      transported via IPFIX.

   2. IPFIX must provide a mechanism to ensure the integrity of IPFIX
      data transferred from an Exporting Process to a Collecting
      Process, in order to prevent the injection of incorrect data or
      control information (e.g., Templates) into an IPFIX Message
      stream.

   3. IPFIX must provide a mechanism to authenticate IPFIX Collecting
      and Exporting Processes, to prevent the collection of data from an
      unauthorized Exporting Process or the export of data to an
      unauthorized Collecting Process.

   Because IPFIX can be used to collect information for network
   forensics and billing purposes, attacks designed to confuse, disable,
   or take information from an IPFIX collection system may be seen as a
   prime objective during a sophisticated network attack.

   An attacker in a position to inject false messages into an IPFIX
   Message stream can either affect the application using IPFIX (by
   falsifying data), or the IPFIX Collecting Process itself (by
   modifying or revoking Templates, or changing options); for this
   reason, IPFIX Message integrity is important.

   The IPFIX Messages themselves may also contain information of value
   to an attacker, including information about the configuration of the
   network as well as end-user traffic and payload data, so care must be
   taken to confine their visibility to authorized users.  When an
   Information Element containing end-user payload information is
   exported, it SHOULD be transmitted to the Collecting Process using a
   means that secures its contents against eavesdropping.  Suitable
   mechanisms include the use of either a direct point-to-point
   connection or the use of an encryption mechanism.  It is the

   responsibility of the Collecting Process to provide a satisfactory
   degree of security for this collected data, including, if necessary,
   anonymization of any reported data.

11.1.  Applicability of TLS and DTLS

   Transport Layer Security (TLS) [RFC4346] and Datagram Transport Layer
   Security (DTLS) [RFC4347] were designed to provide the
   confidentiality, integrity, and authentication assurances required by
   the IPFIX protocol, without the need for pre-shared keys.

   With the mandatory SCTP and PR-SCTP transport protocols for IPFIX,
   DTLS [RFC4347] MUST be implemented.  If UDP is selected as the IPFIX
   transport protocol, DTLS [RFC4347] MUST be implemented.  If TCP is
   selected as the IPFIX transport protocol, TLS [RFC4346] MUST be
   implemented.

   Note that DTLS is selected as the security mechanism for SCTP and
   PR-SCTP.  Though TLS bindings to SCTP are defined in [RFC3436], they
   require all communication to be over reliable, bidirectional streams,
   and require one TLS connection per stream.  This arrangement is not
   compatible with the rationale behind the choice of SCTP as an IPFIX
   transport protocol.

   Note that using DTLS [RFC4347] has a vulnerability, i.e., a true man
   in the middle may attempt to take data out of an association and fool
   the sender into thinking that the data was actually received by the
   peer.  In generic TLS for SCTP (and/or TCP), this is not possible.
   This means that the removal of a message may become hidden from the
   sender or receiver.  Another vulnerability of using PR-SCTP with DTLS
   is that someone could inject SCTP control information to shut down
   the SCTP association, effectively generating a loss of IPFIX Messages
   if those are buffered outside of the SCTP association.  In the
   future, techniques such as [dtls-for-sctp] could be used to overcome
   these vulnerabilities.

   When using DTLS over SCTP, the Exporting Process MUST ensure that
   each IPFIX Message is sent over the same SCTP stream that would be
   used when sending the same IPFIX Message directly over SCTP.  Note
   that DTLS may send its own control messages on stream 0 with full
   reliability; however, this will not interfere with the processing of
   stream 0 IPFIX Messages at the Collecting Process, because DTLS
   consumes its own control messages before passing IPFIX Messages up to
   the application layer.

11.2.  Usage

   The IPFIX Exporting Process initiates the communication to the IPFIX
   Collecting Process, and acts as a TLS or DTLS client according to
   [RFC4346] and [RFC4347], while the IPFIX Collecting Process acts as a
   TLS or DTLS server.  The DTLS client opens a secure connection on the
   SCTP port 4740 of the DTLS server if SCTP or PR-SCTP is selected as
   the transport protocol.  The TLS client opens a secure connection on
   the TCP port 4740 of the TLS server if TCP is selected as the
   transport protocol.  The DTLS client opens a secure connection on the
   UDP port 4740 of the DTLS server if UDP is selected as the transport
   protocol.

11.3.  Authentication

   IPFIX Exporting Processes and IPFIX Collecting Processes are
   identified by the fully qualified domain name of the interface on
   which IPFIX Messages are sent or received, for purposes of X.509
   client and server certificates as in [RFC3280].

   To prevent man-in-the-middle attacks from impostor Exporting or
   Collecting Processes, the acceptance of data from an unauthorized
   Exporting Process, or the export of data to an unauthorized
   Collecting Process, strong mutual authentication via asymmetric keys
   MUST be used for both TLS and DTLS.  Each of the IPFIX Exporting and
   Collecting Processes MUST verify the identity of its peer against its
   authorized certificates, and MUST verify that the peer's certificate
   matches its fully qualified domain name, or, in the case of SCTP, the
   fully qualified domain name of one of its endpoints.

   The fully qualified domain name used to identify an IPFIX Collecting
   Process or Exporting Process may be stored either in a subjectAltName
   extension of type dNSName, or in the most specific Common Name field
   of the Subject field of the X.509 certificate.  If both are present,
   the subjectAltName extension is given preference.

   Internationalized domain names (IDN) in either the subjectAltName
   extension of type dNSName or the most specific Common Name field of
   the Subject field of the X.509 certificate MUST be encoded using
   Punycode [RFC3492] as described in Section 4 of [RFC3490],
   "Conversion Operations".

11.4.  Protection against DoS Attacks

   An attacker may mount a denial-of-service (DoS) attack against an
   IPFIX collection system either directly, by sending large amounts of
   traffic to a Collecting Process, or indirectly, by generating large
   amounts of traffic to be measured by a Metering Process.

   Direct denial-of-service attacks can also involve state exhaustion,
   whether at the transport layer (e.g., by creating a large number of
   pending connections), or within the IPFIX Collecting Process itself
   (e.g., by sending Flow Records pending Template or scope information,
   a large amount of Options Template Records, etc.).

   SCTP mandates a cookie-exchange mechanism designed to defend against
   SCTP state exhaustion denial-of-service attacks.  Similarly, TCP
   provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN
   cookies SHOULD be used by any Collecting Process accepting TCP
   connections.  DTLS also provides cookie exchange to protect against
   DTLS server state exhaustion.

   The reader should note that there is no way to prevent fake IPFIX
   Message processing (and state creation) for UDP & SCTP communication.
   The use of TLS and DTLS can obviously prevent the creation of fake
   states, but they are themselves prone to state exhaustion attacks.
   Therefore, Collector rate limiting SHOULD be used to protect TLS &
   DTLS (like limiting the number of new TLS or DTLS session per second
   to a sensible number).

   IPFIX state exhaustion attacks can be mitigated by limiting the rate
   at which new connections or associations will be opened by the
   Collecting Process, the rate at which IPFIX Messages will be accepted
   by the Collecting Process, and adaptively limiting the amount of
   state kept, particularly records waiting on Templates.  These rate
   and state limits MAY be provided by a Collecting Process; if
   provided, the limits SHOULD be user configurable.

   Additionally, an IPFIX Collecting Process can eliminate the risk of
   state exhaustion attacks from untrusted nodes by requiring TLS or
   DTLS mutual authentication, causing the Collecting Process to accept
   IPFIX Messages only from trusted sources.

   With respect to indirect denial of service, the behavior of IPFIX
   under overload conditions depends on the transport protocol in use.
   For IPFIX over TCP, TCP congestion control would cause the flow of
   IPFIX Messages to back off and eventually stall, blinding the IPFIX
   system.  PR-SCTP improves upon this situation somewhat, as some IPFIX
   Messages would continue to be received by the Collecting Process due
   to the avoidance of head-of-line blocking by SCTP's multiple streams
   and partial reliability features, possibly affording some visibility
   of the attack.  The situation is similar with UDP, as some datagrams
   may continue to be received at the Collecting Process, effectively
   applying sampling to the IPFIX Message stream, implying that some
   forensics may be left.

   To minimize IPFIX Message loss under overload conditions, some
   mechanism for service differentiation could be used to prioritize
   IPFIX traffic over other traffic on the same link.  Alternatively,
   IPFIX Messages can be transported over a dedicated network.  In this
   case, care must be taken to ensure that the dedicated network can
   handle the expected peak IPFIX Message traffic.

11.5.  When DTLS or TLS Is Not an Option

   The use of DTLS or TLS might not be possible in some cases due to
   performance issues or other operational concerns.

   Without TLS or DTLS mutual authentication, IPFIX Exporting Processes
   and Collecting Processes can fall back on using IP source addresses
   to authenticate their peers.  A policy of allocating Exporting
   Process and Collecting Process IP addresses from specified address
   ranges, and using ingress filtering to prevent spoofing, can improve
   the usefulness of this approach.  Again, completely segregating IPFIX
   traffic on a dedicated network, where possible, can improve security
   even further.  In any case, the use of open Collecting Processes
   (those that will accept IPFIX Messages from any Exporting Process
   regardless of IP address or identity) is discouraged.

   Modern TCP and SCTP implementations are resistant to blind insertion
   attacks (see [RFC1948], [RFC4960]); however, UDP offers no such
   protection.  For this reason, IPFIX Message traffic transported via
   UDP and not secured via DTLS SHOULD be protected via segregation to a
   dedicated network.

11.6.  Logging an IPFIX Attack

   IPFIX Collecting Processes MUST detect potential IPFIX Message
   insertion or loss conditions by tracking the IPFIX Sequence Number,
   and SHOULD provide a logging mechanism for reporting out-of-sequence
   messages.  Note that an attacker may be able to exploit the handling
   of out-of-sequence messages at the Collecting Process, so care should
   be taken in handling these conditions.  For example, a Collecting
   Process that simply resets the expected Sequence Number upon receipt
   of a later Sequence Number could be temporarily blinded by deliberate
   injection of later Sequence Numbers.

   IPFIX Exporting and Collecting Processes SHOULD log any connection
   attempt that fails due to authentication failure, whether due to
   being presented an unauthorized or mismatched certificate during TLS
   or DTLS mutual authentication, or due to a connection attempt from an
   unauthorized IP address when TLS or DTLS is not in use.

   IPFIX Exporting and Collecting Processes SHOULD detect and log any
   SCTP association reset or TCP connection reset.

11.7.  Securing the Collector

   The security of the Collector and its implementation is important to
   achieve overall security.  However, it is outside the scope of this
   document.

12.  IANA Considerations

   IPFIX Messages use two fields with assigned values.  These are the
   IPFIX Version Number, indicating which version of the IPFIX Protocol
   was used to export an IPFIX Message, and the IPFIX Set ID, indicating
   the type for each set of information within an IPFIX Message.

   The IPFIX Version Number value of 10 is reserved for the IPFIX
   protocol specified in this document.  Set ID values of 0 and 1 are
   not used for historical reasons [RFC3954].  The Set ID value of 2 is
   reserved for the Template Set.  The Set ID value of 3 is reserved for
   the Option Template Set.  All other Set ID values from 4 to 255 are
   reserved for future use.  Set ID values above 255 are used for Data
   Sets.

   New assignments in either IPFIX Version Number or IPFIX Set ID
   assignments require a Standards Action [RFC2434], i.e., they are to
   be made via Standards Track RFCs approved by the IESG.

Appendix A.  IPFIX Encoding Examples

   This appendix, which is a not a normative reference, contains IPFIX
   encoding examples.

   Let's consider the example of an IPFIX Message composed of a Template
   Set, a Data Set (which contains three Data Records), an Options
   Template Set and a Data Set (which contains 2 Data Records related to
   the previous Options Template Record).

   IPFIX Message:

   +--------+------------------------------------------. . .
   |        | +--------------+ +------------------+
   |Message | | Template     | | Data             |
   | Header | | Set          | | Set              |   . . .
   |        | | (1 Template) | | (3 Data Records) |
   |        | +--------------+ +------------------+
   +--------+------------------------------------------. . .

        . . .-------------------------------------------+
              +------------------+ +------------------+ |
              | Options          | | Data             | |
       . . .  | Template Set     | | Set              | |
              | (1 Template)     | | (2 Data Records) | |
              +------------------+ +------------------+ |
        . . .-------------------------------------------+

A.1.  Message Header Example

   The Message Header is composed of:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Version = 0x000a          |         Length = 152          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Export Time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Observation Domain ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.2.  Template Set Examples

A.2.1.  Template Set Using IETF-Specified Information Elements


   We want to report the following Information Elements:

   - The IPv4 source IP address: sourceIPv4Address in [RFC5102],
     with a length of 4 octets

   - The IPv4 destination IP address: destinationIPv4Address in
     [RFC5102], with a length of 4 octets

   - The next-hop IP address (IPv4): ipNextHopIPv4Address in
     [RFC5102], with a length of 4 octets

   - The number of packets of the Flow: inPacketDeltaCount in
     [RFC5102], with a length of 4 octets

   - The number of octets of the Flow: inOctetDeltaCount in
     [RFC5102], with a length of 4 octets

   Therefore, the Template Set will be composed of the following:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Set ID = 2            |      Length = 28 octets       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID 256         |       Field Count = 5         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|    sourceIPv4Address = 8    |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| destinationIPv4Address = 12 |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|  ipNextHopIPv4Address = 15  |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   inPacketDeltaCount = 2    |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   inOctetDeltaCount =  1    |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.2.2.  Template Set Using Enterprise-Specific Information Elements

   We want to report the following Information Elements:

   - The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a
     length of 4 octets

   - The IPv4 destination IP address: destinationIPv4Address in
     [RFC5102], with a length of 4 octets

   - An enterprise-specific Information Element representing proprietary
     information, with a type of 15 and a length of 4

   - The number of packets of the Flow: inPacketDeltaCount in [RFC5102],
     with a length of 4 octets

   - The number of octets of the Flow: inOctetDeltaCount in [RFC5102],
     with a length of 4 octets

   Therefore, the Template Set will be composed of the following:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Set ID = 2            |      Length = 32 octets       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID 257         |       Field Count = 5         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|    sourceIPv4Address = 8    |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0| destinationIPv4Address = 12 |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1| Information Element Id. = 15|       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Enterprise number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   inPacketDeltaCount = 2    |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|   inOctetDeltaCount = 1     |       Field Length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.3.  Data Set Example

   In this example, we report the following three Flow Records:

   Src IP addr. | Dst IP addr.  | Next Hop addr. | Packet | Octets
                |               |                | Number | Number
   ------------------------------------------------------------------
   192.0.2.12   | 192.0.2.254   | 192.0.2.1      | 5009   | 5344385
   192.0.2.27   | 192.0.2.23    | 192.0.2.2      | 748    | 388934
   192.0.2.56   | 192.0.2.65    | 192.0.2.3      | 5      | 6534

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Set ID = 256         |          Length = 64          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.0.2.12                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.0.2.254                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.0.2.1                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             5009                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            5344385                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.0.2.27                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.0.2.23                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.0.2.2                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              748                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             388934                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.0.2.56                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.0.2.65                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          192.0.2.3                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               5                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              6534                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that padding is not necessary in this example.

A.4.  Options Template Set Examples

A.4.1.  Options Template Set Using IETF-Specified Information Elements

   Per line card (the router being composed of two line cards), we want
   to report the following Information Elements:

   - Total number of IPFIX Messages: exportedPacketCount [RFC5102], with
     a length of 2 octets

   - Total number of exported Flows: exportedFlowCount [RFC5102], with a
     length of 2 octets

   The line card, which is represented by the lineCardId Information
   Element [RFC5102], is used as the Scope Field.

   Therefore, the Options Template Set will be:

    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 = 3            |          Length = 24          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Template ID 258         |        Field Count = 3        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Scope Field Count = 1     |0|     lineCardId = 141        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Scope 1 Field Length = 4    |0|  exportedPacketCount = 41   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |0|   exportedFlowCount = 42    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Field Length = 2        |           Padding             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.4.2.  Options Template Set Using Enterprise-Specific Information
        Elements

   Per line card (the router being composed of two line cards), we want
   to report the following Information Elements:

      - Total number of IPFIX Messages: exportedPacketCount [RFC5102],
        with a length of 2 octets

      - An enterprise-specific number of exported Flows, with a type of
        42 and a length of 4 octets

   The line card, which is represented by the lineCardId Information
   Element [RFC5102], is used as the Scope Field.

   The format of the Options Template Set is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Set ID = 3            |          Length = 28          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Template ID 259         |        Field Count = 3        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Scope Field Count = 1     |0|     lineCardId = 141        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Scope 1 Field Length = 4    |0|  exportedPacketCount = 41   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Field Length = 2        |1|Information Element Id. = 42 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Field Length = 4        |       Enterprise number     ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ...      Enterprise number      |           Padding             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.4.3.  Options Template Set Using an Enterprise-Specific Scope

   In this example, we want to export the same information as in the
   example in Section A.4.1:

      - Total number of IPFIX Messages: exportedPacketCount [RFC5102],
        with a length of 2 octets

      - Total number of exported Flows: exportedFlowCount [RFC5102],
        with a length of 2 octets

   But this time, the information pertains to a proprietary scope,
   identified by enterprise-specific Information Element number 123.

   The format of the Options Template Set is now as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Set ID = 3            |          Length = 28          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Template ID 260         |        Field Count = 3        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Scope Field Count = 1     |1|Scope 1 Infor. El. Id. = 123 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Scope 1 Field Length = 4   |       Enterprise Number      ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...       Enterprise Number      |0|  exportedPacketCount = 41   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Field Length = 2        |0|   exportedFlowCount = 42    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Field Length = 2        |           Padding             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.4.4.  Data Set Using an Enterprise-Specific Scope

   In this example, we report the following two Data Records:

   Line Card ID               | IPFIX Message  | Exported Flow Records
   -------------------------------------------------------------------
   Line Card 1 (lineCardId=1) | 345            | 10201
   Line Card 2 (lineCardId=2) | 690            | 20402

    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 = 260             |         Length = 20           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               1                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             345               |            10201              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               2                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             690               |            20402              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.5.  Variable-Length Information Element Examples

A.5.1.  Example of Variable-Length Information Element with Length
        Inferior to 255 Octets

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       5       |          5 octet Information Element          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A.5.2.  Example of Variable-Length Information Element with Length 255
        to 65535 Octets

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      255      |             1000              |    IE ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                1000 octet Information Element                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ... IE            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

References

Normative References

   [RFC1305]       Mills, D., "Network Time Protocol (Version 3)
                   Specification, Implementation and Analysis", RFC
                   1305, March 1992.

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

   [RFC2434]       Narten, T. and H. Alvestrand, "Guidelines for Writing
                   an IANA Considerations Section in RFCs", BCP 26, RFC
                   2434, October 1998.

   [RFC3280]       Housley, R., Polk, W., Ford, W., and D. Solo,
                   "Internet X.509 Public Key Infrastructure Certificate
                   and Certificate Revocation List (CRL) Profile", RFC
                   3280, April 2002.

   [RFC3436]       Jungmaier, A., Rescorla, E., and M. Tuexen,
                   "Transport Layer Security over Stream Control
                   Transmission Protocol", RFC 3436, December 2002.

   [RFC3758]       Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
                   Conrad, "Stream Control Transmission Protocol (SCTP)
                   Partial Reliability Extension", RFC 3758, May 2004.

   [RFC4346]       Dierks, T. and E. Rescorla, "The Transport Layer
                   Security (TLS) Protocol Version 1.1", RFC 4346, April
                   2006.

   [RFC4347]       Rescorla, E. and N. Modadugu, "Datagram Transport
                   Layer Security", RFC 4347, April 2006.

   [RFC3490]       Faltstrom, P., Hoffman, P., and A. Costello,
                   "Internationalizing Domain Names in Applications
                   (IDNA)", RFC 3490, March 2003.

   [RFC3492]       Costello, A., "Punycode: A Bootstring encoding of
                   Unicode for Internationalized Domain Names in
                   Applications (IDNA)", RFC 3492, March 2003.

   [RFC4960]       Stewart, R., Ed., "Stream Control Transmission
                   Protocol", RFC 4960, September 2007.

   [RFC5102]       Quittek, J., Bryant S., Claise, B., Aitken, P., and
                   J. Meyer, "Information Model for IP Flow Information
                   Export", RFC 5102, January 2008.

   [TCP]           Postel, J., "Transmission Control Protocol", STD 7,
                   RFC 793, September 1981.

   [UDP]           Postel, J., "User Datagram Protocol", STD 6, RFC 768,
                   August 1980.

Informative References

   [IPFIX-ARCH]    Sadasivan, G., Brownlee, N., Claise, B., and J.
                   Quittek, "Architecture Model for IP Flow Information
                   Export", Work in Progress, September 2006.

   [IPFIX-AS]      Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
                   "IPFIX Applicability", Work in Progress, June 2007.

   [PEN]           IANA Private Enterprise Numbers registry
                   http://www.iana.org/assignments/enterprise-numbers.

   [RFC1948]       Bellovin, S., "Defending Against Sequence Number
                   Attacks", RFC 1948, May 1996.

   [RFC2579]       McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                   "Textual Conventions for SMIv2", STD 58, RFC 2579,
                   April 1999.

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

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

   [RFC3954]       Claise, B., Ed., "Cisco Systems NetFlow Services
                   Export Version 9", RFC 3954, October 2004.

   [IEEE.754.1985] Institute of Electrical and Electronics Engineers,
                   "Standard for Binary Floating-Point Arithmetic", IEEE
                   Standard 754, August 1985.

   [dtls-for-sctp] Tuexen, M. and E. Rescola, "Datagram Transport Layer
                   Security for Stream Control Transmission Protocol",
                   Work in Progress, November 2007.

Acknowledgments

   We would like to thank the following persons: Ganesh Sadasivan for
   his significant contribution during the initial phases of the
   protocol specification; Juergen Quittek for the coordination job
   within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and
   Andrew Johnson for the thorough reviews; Randall Stewart and Peter
   Lei for their SCTP expertise and contributions; Martin Djernaes for
   the first essay on the SCTP section; Michael Behringer and Eric
   Vyncke for their advice and knowledge in security; Michael Tuexen for
   his help regarding the DTLS section; Elisa Boschi for her
   contribution regarding the improvement of SCTP sections; Mark
   Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter
   Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul
   Calato, and many more, for the technical reviews and feedback.

Authors' Addresses

   Benoit Claise
   Cisco Systems
   De Kleetlaan 6a b1
   1831 Diegem
   Belgium
   Phone: +32 2 704 5622
   EMail: bclaise@cisco.com

   Stewart Bryant
   Cisco Systems, Inc.
   250, Longwater,
   Green Park,
   Reading, RG2 6GB,
   United Kingdom
   Phone: +44 (0)20 8824-8828
   EMail: stbryant@cisco.com

   Simon Leinen
   SWITCH
   Werdstrasse 2
   P.O. Box
   CH-8021 Zurich
   Switzerland
   Phone: +41 44 268 1536
   EMail: simon.leinen@switch.ch

   Thomas Dietz
   NEC Europe Ltd.
   NEC Laboratories Europe
   Network Research Division
   Kurfuersten-Anlage 36
   69115 Heidelberg
   Germany
   Phone: +49 6221 4342-128
   EMail: Thomas.Dietz@nw.neclab.eu

   Brian H. Trammell
   CERT Network Situational Awareness
   Software Engineering Institute
   4500 Fifth Avenue
   Pittsburgh, PA 15213
   United States
   Phone: +1 412 268 9748
   EMail: bht@cert.org

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.