Exporter

1. Introduction

IP Flow Information Export (IPFIX) is a protocol to convey accounting information from an exporter to a collector. It has been proposed that the protocol operate over the Stream Control Transmission Protocol with the Partial Reliability extension

2 ISSUES

2.1 Handshake

A simple ASCII-based handshake could be used to request TLS.

2.2 TLS

It would make sense to add TLS support even in the absence of a handshake. It would be the responsibility of the collector (connection initiator) to know whether TLS setup is required.

2.3 Directionality

The fact that the connection is initiated by the collector is a departure from the way it is done in the SCTP mapping. Personally I find it more natural this way. There are not very many practical differences anyway. Collector-initiated connections are easier to handle when the collector is behind a NAT or typical firewall, while exporter-initiated connections are easier when the exporter is behind a NAT or firewall. Collector-initiated connections are faster to restart when a collector terminates, exporter-initated connections are faster to restart when an exporter restarts.

One difference is that in the case of multiple observation domains, one may want to establish parallel IPFIX export connections. The current definition makes this difficult. Perhaps the most natural way to do this would be to have the exporter initiate the connection, require the collector to handle multiple connections, and allow the exporter to establish one connection per observation domain.

3. Operation

The following sections describe how an IPFIX-over-TCP connection is created, how IPFIX data is transferred over it, and how a connection is to be terminated. In the following, the term "exporter" refers to an IPFIX exporting process, while a "collector" refers to an IPFIX collecting process.

3.1 Connection Establishment

The IPFIX collector initiates a TCP connection to the exporter. By default, the exporter listens for connections on TCP port XXXX (to be assigned by IANA). It MUST be possible to configure the exporter to listen on a different TCP port.

An exporter MAY support more than one active connection to different collectors (including the case of different collecting processes on the same host).

It MUST be possible to configure, on an exporter, which collector(s) are allowed to establish a connection. It SHOULD be possible to configure this in terms of strong identities such as IKE public-key certificates or pre-shared keys. An exporter SHOULD detect and log unauthorized connection attempts.

3.2 Data Transmission

Once a TCP connection is established, the exporter starts sending IPFIX messages to the collector.

3.2.1 IPFIX Message Encoding

IPFIX Messages are sent over the TCP connection without any special encoding. The LENGTH field in the message header defines the end of each message and thus the start of the next message. This means that IPFIX messages cannot be interleaved.

The 16-bit LENGTH field limits the length of a message to 65536 octets including the header. A collector MUST be able to handle message lengths of up to 65536 octets.

If an exporter exports data from multiple observation domain, it should be careful to choose message lengths appropriately to avoid head-of-line blocking between different observation domains.

3.2.2 Templates

For each template, the exporter SHOULD send the Template Record before exporting Data Records that refer to this template.

A collector MUST record all Template and Option Template Records for the duration of the connection, as an exporter is not required to re-export templates.

3.2.3 Congestion Handling

TCP will detect congestion anywhere in the end-to-end path between the exporter and the collector, and limit the transfer rate accordingly. Every time an IPFIX exporter has flow data to export, but notices that transmission to TCP is temporarily impossible ("would block"), it basically has two possibilities: Either it can wait until sending is possible again, or it can decide to drop the flow export data. In the latter case, the dropped export data MUST be accounted for, so that the amount of dropped export data can later be exported in an option data record.

When an exporter finds that the rate at which flow records should be exported is consistently higher than the rate at which TCP permits to send, it SHOULD adapt the metering process so that it generates a lower amount of data, for example by increasing the sampling interval, or by increasing the amount of aggregation. If it does this, the exporter SHOULD periodically attempt to switch back to the original metering configuration when congestion subsides.

3.3 Connection Release

When an exporter has no more data to send, it SHOULD close the TCP connection normally. When a collector no longer wants to receive IPFIX messages, it SHOULD close its end of the connection. The collector SHOULD continue to read IPFIX messages until the exporter has closed its end.

When an exporter detects that the TCP connection to the collector is broken, it MUST continue to listen for a new connection.

When a collector detects that the TCP connection to the exporter is broken, it SHOULD try to re-establish the connection. Connection timeouts and retry schedules SHOULD be configurable. In the default configuration, a collector MUST NOT attempt to establish a connection more frequently than once per minute.

4. Security Considerations

In the current proposal, there is no handshake protocol once a TCP connection is established, so negotiation-based transport-layer security protocols such as TLS cannot be used in a straightforward manner to ensure authenticity and confidentiality.

Exporters and collectors MUST implement IPSEC with the Authentication Header (AH) to ensure authenticity of the exporter and the collector. Exporters SHOULD implement IPSEC Encapsulating

Security Payload (ESP) to ensure confidentiality of the exported data. The use of AH and ESP MUST be configurable for each exporter/ collector pair.

Exporters and collectors MUST implement the Internet Key Exchange (IKE) protocol with pre-shared keys and public-key certificates. The use of these identities is described in Section 3.1.

5. IANA Considerations

No new registry is required for this specific protocol mapping.

IANA should assign a well-known TCP port number for IPFIX over TCP. It is recommended that the same well-known port number is used as a default for the IPFIX over SCTP and IPFIX over UDP mappings.

-- TomasPeter - 13 Nov 2007