Network Working Group                                       G. Sadasivan
Request for Comments: 5470                                Rohati Systems
Category: Informational                                      N. Brownlee
                                      CAIDA | The University of Auckland
                                                               B. Claise
                                                     Cisco Systems, Inc.
                                                              J. Quittek
                                                              March 2009
              Architecture for IP Flow Information Export

Status of This Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document ( Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

この文書では、BCP 78と、この文書(の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.




This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector.


Table of Contents


   1. Introduction ....................................................3
      1.1. Document Scope .............................................3
      1.2. IPFIX Documents Overview ...................................3
   2. Terminology .....................................................4
   3. Examples of Flows ...............................................8
   4. IPFIX Reference Model ..........................................10
   5. IPFIX Functional and Logical Blocks ............................12
      5.1. Metering Process ..........................................12
           5.1.1. Flow Expiration ....................................12
           5.1.2. Flow Export ........................................13
      5.2. Observation Point .........................................13
      5.3. Selection Criteria for Packets ............................13
           5.3.1. Sampling Functions, Si .............................14
           5.3.2. Filter Functions, Fi ...............................15
      5.4. Observation Domain ........................................15
      5.5. Exporting Process .........................................15
      5.6. Collecting Process ........................................16
      5.7. Summary ...................................................17
   6. Overview of the IPFIX Protocol .................................18
      6.1. Information Model Overview ................................19
      6.2. Flow Records ..............................................19
      6.3. Control Information .......................................20
      6.4. Reporting Responsibilities ................................21
   7. IPFIX Protocol Details .........................................21
      7.1. The IPFIX Basis Protocol ..................................21
      7.2. IPFIX Protocol on the Collecting Process ..................22
      7.3. Support for Applications ..................................22
   8. Export Models ..................................................23
      8.1. Export with Reliable Control Connection ...................23
      8.2. Collector Failure Detection and Recovery ..................23
      8.3. Collector Redundancy ......................................24
   9. IPFIX Flow Collection in Special Situations ....................24
   10. Security Considerations .......................................25
      10.1. Data Security ............................................25
           10.1.1. Host-Based Security ...............................26
           10.1.2. Authentication-Only ...............................26
           10.1.3. Encryption ........................................26
      10.2. IPFIX End-Point Authentication ...........................27
      10.3. IPFIX Overload ...........................................27
           10.3.1. Denial-of-Service (DoS) Attack Prevention .........27
   11. IANA Considerations ...........................................28
      11.1. Numbers Used in the Protocol .............................28
      11.2. Numbers Used in the Information Model ....................29
   12. Acknowledgements ..............................................29
   13. References ....................................................30
      13.1. Normative References .....................................30
      13.2. Informative References ...................................30
1. Introduction
1. はじめに

There are several applications, e.g., usage-based accounting, traffic profiling, traffic engineering, attack/intrusion detection, quality-of-service (QoS) monitoring, that require Flow-based IP traffic measurements. It is therefore important to have a standard way of exporting information related to IP Flows. This document defines an architecture for IP traffic Flow monitoring, measuring, and exporting. It provides a high-level description of an IPFIX Device's key components and their functions.

フローベースのIPトラフィックの測定を必要といくつかのアプリケーション、例えば、使用量ベースのアカウンティング、トラフィックプロファイリング、トラフィックエンジニアリング、攻撃/侵入検知、サービス品質(QoS)の監視があります。 IPフローに関連する情報をエクスポートする標準的な方法を持っていることが重要です。この文書では、IPトラフィックのフローを監視するためのアーキテクチャを定義して測定、およびエクスポート。これは、IPFIXデバイスの主要なコンポーネントとその機能の高レベルの説明を提供します。

1.1. Document Scope
1.1. ドキュメントのスコープ

This document defines the architecture for IPFIX. Its main objectives are to:


o Describe the key IPFIX architectural components, consisting of (at least) IPFIX Devices and Collectors communicating using the IPFIX protocol.

O IPFIXプロトコルを使用して通信(少なくとも)IPFIXデバイスとコレクターからなる、キーIPFIXアーキテクチャコンポーネントを記述する。

o Define the IPFIX architectural requirements, e.g., recovery, security, etc.

O IPFIXアーキテクチャ要件を定義し、例えば、回復、セキュリティなど

o Describe the characteristics of the IPFIX protocol.

O IPFIXプロトコルの特性を記述する。

1.2. IPFIX Documents Overview
1.2. IPFIXドキュメントの概要

The IPFIX protocol provides network administrators with access to IP Flow information. This document specifies the architecture for the export of measured IP Flow information from an IPFIX Exporting Process to a Collecting Process, per the requirements defined in RFC 3917 [1]. The IPFIX protocol document, RFC 5101 [3], specifies how IPFIX data records and templates are carried via a congestion-aware transport protocol, from IPFIX Exporting Process to IPFIX Collecting Process. IPFIX has a formal description of IPFIX information elements (fields), their name, type, and additional semantic information, as specified in RFC 5102 [2]. Finally, RFC 5472 [4] describes what type of applications can use the IPFIX protocol and how they can use the information provided. Furthermore, it shows how the IPFIX framework relates to other architectures and frameworks.

IPFIXプロトコルは、IPフロー情報へのアクセスをネットワーク管理者に提供します。この文書では、[1] RFC 3917で定義された要件に従って、収集プロセスにIPFIXエクスポートプロセスからの測定されたIPフロー情報のエクスポートのためのアーキテクチャを指定します。 IPFIXプロトコル文書、RFC 5101 [3]、IPFIXデータレコードとテンプレートがIPFIXエクスポートプロセスからIPFIX収集プロセスに、渋滞認識トランスポートプロトコルを介して実行される方法を指定します。 IPFIXは、RFC 5102で指定されるように、IPFIX情報要素(フィールド)、それらの名前、タイプ、および追加の意味情報の形式的記述を有している[2]。最後に、RFC 5472 [4] IPFIXプロトコルを使用することができるアプリケーションの種類とそれらが提供する情報を使用する方法について説明します。また、IPFIXフレームワークが他のアーキテクチャおよびフレームワークの関係を示します。

Note that the IPFIX system does not provide for remote configuration of an IPFIX device. Instead, implementors must provide an effective way to configure their IPFIX devices.


2. Terminology

The definitions of basic IPFIX terms such as IP Traffic Flow, Exporting Process, Collecting Process, Observation Point, etc., are semantically identical with those found in the IPFIX requirements document, RFC 3917 [1]. Some of the terms have been expanded for more clarity when defining the protocol. Additional definitions required for the architecture have also been defined. For terms that are defined here and in RFC 5101 [3], the definitions are equivalent in both documents.

等IPトラフィックフロー、エクスポートプロセス、収集処理、観測ポイント、などの基本的なIPFIX用語の定義は、IPFIX要件文書に見られるものと意味的に同じである、RFC 3917 [1]。プロトコルを定義するときの用語のいくつかは、より明確にするために拡張されています。アーキテクチャのために必要な追加の定義はまた、定義されています。ここではとRFC 5101で定義されている用語については、[3]、定義は両方の文書に相当します。

* 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 also be unique per IPFIX Device.

観測ドメインフロー情報は、計量プロセスによって集約することができるの観測ポイントの最大のセットです。それは観測ポイントでそれぞれがいくつかのインタフェースで構成されている場合、例えば、ルータラインカードは、観測ドメインであってもよいです。それが生成するIPFIXメッセージに、観測ドメインは、エクスポートプロセスごとに一意であり、その観測ドメインIDを含みます。その方法は、収集プロセスはIPFIXメッセージを送る輸出業者から特定の観測ドメインを識別することができます。すべての観測点は、観測ドメインに関連付けられています。観測ドメインIDはまた、IPFIX Device単位でユニークであることをお勧めします。

* IP Traffic Flow or Flow

* IPトラフィックフローまたはフロー

There are several definitions of the term 'flow' being used by the Internet community. Within the context of IPFIX we use the following definition:

インターネットコミュニティによって使用されている用語「流れ」のいくつかの定義があります。 IPFIXの文脈の中で、私たちは次の定義を使用します。

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:


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 [5]).


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


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


A packet is defined as belonging 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 that:


1. belongs to the packet header (e.g., destination IP address),
2. is a property of the packet itself (e.g., packet length),

3. is derived from packet treatment (e.g., Autonomous System (AS) number), and


4. is used to define a Flow

is termed a Flow Key.


* Flow Record


A Flow Record contains information about a specific Flow that was observed at an Observation Point. A Flow Record contains measured properties of the Flow (e.g., the total number of bytes for all the Flow's packets) and usually characteristic properties of the Flow (e.g., source IP address).


* Metering Process


The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics observed at an Observation Point, and packet treatment at the Observation Point (for example, the selected output interface).


The Metering Process consists of a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records.


The maintenance of Flow Records may include creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records.


* Exporting Process


The Exporting Process sends Flow Records to one or more Collecting Processes. The Flow Records are generated by one or more Metering Processes.


* Exporter


A device that hosts one or more Exporting Processes is termed an Exporter.


* IPFIX Device

* IPFIXデバイス

An IPFIX Device hosts at least one Exporting Process. It may host further Exporting Processes and arbitrary numbers of Observation Points and Metering Processes.


* 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 that hosts one or more Collecting Processes is termed a Collector.


* Template

* テンプレート

A Template is an 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.


* Control Information, Data Stream


The information that needs to be exported from the IPFIX Device can be classified into the following categories:


Control Information


This includes the Flow definition, selection criteria for packets within the Flow sent by the Exporting Process, and templates describing the data to be exported. Control Information carries all the information needed for the end-points to understand the IPFIX protocol, and specifically for the Collector to understand and interpret the data sent by the sending Exporter.


Data Stream


This includes Flow Records carrying the field values for the various observed Flows at each of the Observation Points.


* IPFIX Message

* IPFIXメッセージ

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.

IPFIXメッセージと宛先収集プロセスであり、このエクスポートプロセスのIPFIXレコードを運ぶエクスポートプロセスで発信メッセージです。 IPFIXメッセージは、トランスポート層でカプセル化されています。

* Information Element


An Information Element is a protocol and encoding-independent description of an attribute that may appear in an IPFIX Record. The IPFIX information model, RFC 5102 [2], 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.

情報要素は、IPFIX記録に現れ得る属性のプロトコル及びエンコーディングに依存しない記述です。 IPFIX情報モデルは、RFC 5102 [2]、IPFIXの情報要素の基本セットを定義します。情報要素に関連付けられているタイプは、それが含まれているかもしれないものの制約を示し、また、IPFIXで使用するための有効なエンコードメカニズムを決定します。

3. Examples of Flows

Some examples of Flows are listed below. In the IPv4 examples, we use interface addresses in three different 26-bit (/26) subnets. In the IPv6 examples, we use 'mac addr-nn' in the low-order 64 bits to indicate the IEEE MAC (Media Access Control) address of host interface nn.

フローのいくつかの例を以下に記載されています。 IPv4の例では、我々は、3つの異なる26ビット(/ 26)サブネットにインタフェースアドレスを使用します。 IPv6の例では、ホスト・インターフェース・NNのIEEE MAC(Media Access Control)アドレスを示すために、下位64ビットでのMAC ADDR-NN 'を使用します。

Example 1: Flow Keys define the different fields by which Flows are distinguished. The different combination of their field values creates unique Flows. If {source IP address, destination IP address, DSCP} are Flow Keys, then all of these are different Flows:

例1:フローキーはフローが区別される異なるフィールドを定義します。そのフィールド値の異なる組み合わせがユニークなフローを作成します。 {送信元IPアドレス、宛先IPアドレス、DSCP}はフローキーである場合、これらの全ては、異なるフローです。

1. {,, 4} 2. {,, 4} 3. {,, 2} 4. {,, 4}

1。 {192。0。2。1、 192。0。2。65、 4} 2。 {192。0。2。23、 192。0。2。67、 4} 3。 {192。0。2。23、 192。0。2。67、 2} 4。 {192。0。2。129、 192。0。2。67、 4}

5. {2001:DB8::0:mac-addr-01, 2001:DB8::1:mac-addr-11, 4} 6. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 4} 7. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 2} 8. {2001:DB8::2:mac-addr-21, 2001:DB8::1:mac-addr-13, 4}

5. {2001:DB8 :: 0:MAC-ADDR-01、2001:DB8 :: 1:MAC-ADDR-11、4} 6 {2001:DB8 :: 0:MAC-ADDR-02、2001:DB8 :: 1:MAC-ADDR-13、4} 7. {2001:DB8 :: 0:MAC-ADDR-02、2001:DB8 :: 1:MAC-ADDR-13、2} 8. {2001:DB8: :2:MAC-ADDR-21、2001:DB8 :: 1:MAC-ADDR-13、4}

Example 2: A mask function can be applied to all the packets that pass through an Observation Point, in order to aggregate some values. This could be done by defining the set of Flow Keys as {source IP address, destination IP address, DSCP} as in Example 1 above, and applying functions that mask out the source and destination IP addresses (least significant 6 bits for IPv4, 64 bits for IPv6). The eight Flows from Example 1 would now be aggregated into six Flows by merging the Flows 1+2 and 5+6 into single Flows:

実施例2:マスク機能は、いくつかの値を集計するために、観測ポイントを通過するすべてのパケットに適用することができます。これは64、上記実施例1と同様に、{送信元IPアドレス、宛先IPアドレス、DSCP}としてフローキーのセットを定義する、ソースおよび宛先IPアドレスIPv4の(最下位の6ビットをマスク関数を適用することによって行うことができますIPv6のためのビット)。実施例1から8のフローは今、フロー1 + 2及び単一フローに5 + 6をマージし6つの流れに集約されることになります。

1. {,, 4} 2. {,, 2} 3. {,, 4}

1。 {192。0。2。0/26、 192。0。2。64/26、 4} 2。 {192。0。2。0/26、 192。0。2。64/26、 2} 3。 {192。0。2。128/26、 192。0。2。64/26、 4}

4. {2001:DB8::0/64, 2001:DB8::1/64, 4} 5. {2001:DB8::0/64, 2001:DB8::1/64, 2} 6. {2001:DB8::2/64, 2001:DB8::1/64, 4}

4. {2001:DB8 :: 0/64、2001:DB8 :: 1/64、4} 5. {2001:DB8 :: 0/64、2001:DB8 :: 1/64、2} 6 {2001 :DB8 :: 2/64、2001:DB8 :: 1/64、4}

Example 3: A filter defined by some Flow Key values can be applied on all packets that pass the Observation Point, in order to select only certain Flows. The filter is defined by choosing fixed values for specific Keys from the packet.


All the packets that go from a customer network to another customer network with DSCP value of 4 define a Flow. All other combinations don't define a Flow and are not taken into account. The three Flows from Example 2 would now be reduced to one Flow by filtering out Flows 2 and 3, leaving only Flow 1, {,, 4}.


Similarly, for the IPv6 packets in the examples above, one could filter out Flows 5 and 6 to leave Flow 4.


The above examples can be thought of as a function F() taking as input {source IP address, destination IP address, DSCP}. The function selects only the packets that satisfy all three of the following conditions:


1. Mask out the least significant 6 bits of source IP address, match against


2. Mask out the least significant 6 bits of destination IP address, match against


3. Only accept DSCP value equal to 4.

Depending on the values of {source IP address, destination IP address, DSCP} of the different observed packets, the Metering Process function F() would choose/filter/aggregate different sets of packets, which would create different Flows. For example, for various combinations of values of {source IP address, destination IP address, DSCP}, F(source IP address, destination IP address, DSCP) would result in the definition of one or more Flows.


4. IPFIX Reference Model
4. IPFIX参照モデル

The figure below shows the reference model for IPFIX. This figure covers the various possible scenarios that can exist in an IPFIX system.


                             +----------------+     +----------------+
                             |[*Application 1]| ... |[*Application n]|
                             +--------+-------+     +-------+--------+
                                      ^                     ^
                                      |                     |
                                      + = = = = -+- = = = = +
   +------------------------+            +-------+------------------+
   |IPFIX Exporter          |            | Collector(1)             |
   |[Exporting Process(es)] |<---------->| [Collecting Process(es)] |
   +------------------------+            +--------------------------+
           ....                                  ....
   +------------------------+           +---------------------------+
   |IPFIX Device(i)         |           | Collector(j)              |
   |[Observation Point(s)]  |<--------->| [Collecting Process(es)]  |
   |[Metering Process(es)]  |     +---->| [*Application(s)]         |
   |[Exporting Process(es)] |     |     +---------------------------+
   +------------------------+     .
          ....                    .              ....
   +------------------------+     |     +--------------------------+
   |IPFIX Device(m)         |     |     | Collector(n)             |
   |[Observation Point(s)]  |<----+---->| [Collecting Process(es)] |
   |[Metering Process(es)]  |           | [*Application(s)]        |
   |[Exporting Process(es)] |           +--------------------------+
   The various functional components are indicated within brackets [].
   The functional components within [*] are not part of the IPFIX
   architecture.  The interfaces shown by "<----->" are defined by the
   IPFIX architecture, but those shown by "<= = = =>" are not.

Figure 1: IPFIX Reference Model


The figure below shows a typical IPFIX Device where the IPFIX components are shown in rectangular boxes.


           |                 IPFIX Device                     |
           |                                          +-----+ |
           |        +------- ... ------------+--------->    | |
           |        |                        |        |     | |
           |   +----+----+              +----+----+   |     | |
           |   |Metering |              |Metering |   |  E  | |
           |   |Process 1|              |Process N|   |  x  | |
           |   +---------+              +---------+   |  p  | |
           |        ^                        ^        |  o  | |
           | +------+--------+     +---------+------+ |  r  | |
           | | Obsv Domain 1 |     | Obsv Domain N  | |  t  | |
           | |+-----+-------+|     |+-------+------+| |  i  | |
           | ||Obsv Pt 1..j || ... ||Obsv Pt j+1..M|| |  n  | |
           | |+-------------+|     |+--------------+| |  g  | | Export
   Packets | +------^--------+     +---------^------+ |     | | packets
   --->----+--------+---------- ... ---------+        |     | |   to
      In   |                                          |     +--------->
           |        . . . . .                         |     | |Collector
           |                                          |     | |
           |        +------ ... -------------+--------->    | |
           |        |                        |        |     | |
           |   +----+----+              +----+----+   |  P  | |
           |   |Metering |              |Metering |   |  r  | |
           |   |Process 1|              |Process N|   |  o  | |
           |   +---------+              +---------+   |  c  | |
           |        ^                        ^        |  e  | |
           | +------+--------+     +---------+------+ |  s  | |
           | | Obsv Domain 1 |     | Obsv Domain N  | |  s  | |
           | |+-----+-------+|     |+-------+------+| |     | |
           | ||Obsv Pt 1..k || ... ||Obsv Pt k+1..M|| |     | |
           | |+-------------+|     |+--------------+| |     | |
   Packets | +------^--------+     +---------^------+ +-----+ |
   --->----+--------+---------- ... ---------+                |
      In   |                                                  |

Figure 2: IPFIX Device


5. IPFIX Functional and Logical Blocks
5. IPFIX機能と論理ブロック
5.1. Metering Process
5.1. 計量プロセス

Every Observation Point in an IPFIX Device, participating in Flow measurements, must be associated with at least one Metering Process. Every packet coming into an Observation Point goes into each of the Metering Processes associated with the Observation Point. Broadly, each Metering Process observes the packets that pass an Observation Point, does timestamping, and classifies the packets into Flow(s) based on the selection criteria.


The Metering Process is a functional block that manages all the Flows generated from an Observation Domain. The typical functions of a Metering Process may include:


o Maintaining database(s) of all the Flow Records from an Observation Domain. This includes creating new Flow Records, updating existing ones, computing Flow Records statistics, deriving further Flow properties, and adding non-Flow-specific information based on the packet treatment (in some cases, fields like AS numbers, router state, etc.)


o Maintaining statistics about the Metering Process itself, such as Flow Records generated, packets observed, etc.


5.1.1. Flow Expiration
5.1.1. フローの有効期限

A Flow is considered to have expired under the following conditions:


1. If no packets belonging to the Flow have been observed for a certain period of time. This time period should be configurable at the Metering Process, with a minimum value of 0 seconds for immediate expiration. Note that a zero timeout would report a Flow as a sequence of single-packet Flows.


2. If the IPFIX Device experiences resource constraints, a Flow may be prematurely expired (e.g., lack of memory to store Flow Records).

2. IPFIXデバイスは、リソースの制約が発生した場合、フローは途中で期限切れにすることができる(例えば、フローレコードを格納するメモリの不足)。

3. For long-running Flows, the Metering Process should expire the Flow on a regular basis or based on some expiration policy. This periodicity or expiration policy should be configurable at the Metering Process. When a long-running Flow is expired, its Flow Record may still be maintained by the Metering Process so that the Metering Process does not need to create a new Flow Record for further observed packets of the same Flow.


5.1.2. Flow Export
5.1.2. フローのエクスポート

The Exporting Process decides when and whether to export an expired Flow. A Flow can be exported because it expired for any of the reasons mentioned in Section 5.1.1, "Flow Expiration". For example: the Exporting Process exports a portion of the expired Flows every 'x' seconds.


For long-lasting Flows, the Exporting Process should export the Flow Records on a regular basis or based on some export policy. This periodicity or export policy should be configurable at the Exporting Process.


5.2. Observation Point
5.2. 観測点

A Flow Record can be better analysed if the Observation Point from which it was measured is known. As such, it is recommended that IPFIX Devices send this information to Collectors. In cases where there is a single Observation Point or where the Observation Point information is not relevant, the Metering Process may choose not to add the Observation Point information to the Flow Records.


5.3. Selection Criteria for Packets
5.3. パケットの選択基準

A Metering Process may define rules so that only certain packets within an incoming stream of packets are chosen for measurement at an Observation Point. This may be done by one of the two methods defined below or a combination of them, in either order. A combination of each of these methods can be adopted to select the packets, i.e., one can define a set of methods {F1, S1, F2, S2, S3} executed in a specified sequence at an Observation Point to select particular Flows.


The figure below shows the operations that may be applied as part of a typical Metering Process.


                 |  packet header capturing  |
                 |       timestamping        |
            +---------------> +
            |                 |
            |                 v
            |    +----------------------------------------------+
            |    |   sampling Si (1:1 in case of no sampling)   |
            |    +----------------------------------------------+
            |                 |
            |                 v
            |    +----------------------------------------------+
            |    |  filtering Fi (select all when no criteria)  |
            |    +----------------------------------------------+
            |                 |
            |                 v
                 |          Flows            |

Figure 3: Selection Criteria for Packets


Note that packets could be selected before or after any IP processing, i.e., before there is any IP checksum validation, IP filtering, etc., or after one or more of these steps. This has an impact on what kinds of traffic (or erroneous conditions) IPFIX can observe. It is recommended that packets are selected after their checksums have been verified.


5.3.1. Sampling Functions, Si
5.3.1. サンプリング機能、Siの

A sampling function determines which packets within a stream of incoming packets are selected for measurement, i.e., packets that satisfy the sampling criteria for this Metering Process.


Example: sample every 100th packet that was received at an Observation Point.


Choosing all the packets is a special case where the sampling rate is 1:1.


5.3.2. Filter Functions, Fi
5.3.2. フィルタ関数は、FI

A Filter Function selects only those incoming packets that satisfy a function on fields defined by the packet header fields, fields obtained while doing the packet processing, or properties of the packet itself.


Example: Mask/Match of the fields that define a filter. A filter might be defined as {Protocol == TCP, Destination Port < 1024}.

例:フィルタを定義するフィールドで/マッチマスク。フィルタは、{プロトコル== TCP、宛先ポート<1024}として定義されるかもしれません。

Several such filters could be used in any sequence to select packets. Note that packets selected by a (sequence of) filter functions may be further classified by other filter functions, i.e., the selected packets may belong to several Flows, any or all of which are exported.


5.4. Observation Domain
5.4. 観測ドメイン

The Observation Domain is a logical block that presents a single identity for a group of Observation Points within an IPFIX Device. Each {Observation Point, Metering Process} pair belongs to a single Observation Domain. An IPFIX Device could have multiple Observation Domains, each of which has a subset of the total set of Observation Points in it. Each Observation Domain must carry a unique ID within the context of an IPFIX Device. Note that in the case of multiple Observation Domains, a unique ID per Observation Domain must be transmitted as a parameter to the Exporting Function. That unique ID is referred to as the IPFIX Observation Domain ID.

観測ドメインは、IPFIXデバイス内の観測ポイントのグループのための単一のアイデンティティを提示する論理ブロックです。各{観測ポイント、計量プロセス}ペアは、単一の観測ドメインに属しています。 IPFIXデバイスは、その中に観測点の合計のセットのサブセットをそれぞれ有する、複数の観測ドメインを有することができます。各観測ドメインは、IPFIXデバイスのコンテキスト内で一意のIDを運ばなければなりません。複数の観測ドメインの場合には、観測ドメインごとに固有のIDがエクスポート関数のパラメータとして送信する必要があることに注意してください。そのユニークなIDはIPFIX観測ドメインのIDと呼ばれています。

5.5. Exporting Process
5.5. エクスポートプロセス

The Exporting Process is the functional block that sends data to one or more IPFIX Collectors using the IPFIX protocol. On one side, the Exporting Process interfaces with Metering Process(es) to get Flow Records; while on the other side, it talks to a Collecting Process on the Collector(s).


There may be additional rules defined within an Observation Domain so that only certain Flow Records are exported. This may be done by either one or a combination of Si and Fi, as described in Section 5.3, "Selection Criteria for Packets".


Example: Only the Flow Records that meet the following selection criteria are exported:


1. All Flow Records whose destination IP address matches {}.


2. Every other (i.e., sampling rate 1 in 2) Flow Record whose destination IP address matches {}.


5.6. Collecting Process
5.6. 収集処理

Collecting Processes use a Flow Record's Template ID to interpret that Flow Record's Information Elements. To allow this, an IPFIX Exporter must ensure that an IPFIX Collector knows the Template ID for each incoming Flow Record. To interpret incoming Flow Records, an IPFIX Collector may also need to know the function F() that was used by the Metering Process for each Flow.


The functions of the Collecting Process must include:


o Identifying, accepting, and decoding the IPFIX Messages from different <Exporting Process, Observation Domain> pairs.


o Storing the Control Information and Flow Records received from an IPFIX Device.


At a high level, the Collecting Process:


1. Receives and stores the Control Information.

2. Decodes and stores the Flow Records using the Control Information.


5.7. Summary
5.7. 概要

The figure below shows the functions performed in sequence by the various functional blocks in an IPFIX Device.


                    Packet(s) coming into Observation Point(s)
                      |                                   |
                      v                                   v
     +----------------+-------------------------+   +-----+-------+
     |          Metering Process on an          |   |             |
     |             Observation Point            |   |             |
     |                                          |   |             |
     |   packet header capturing                |   |             |
     |        |                                 |...| Metering    |
     |   timestamping                           |   | Process N   |
     |        |                                 |   |             |
     | +----->+                                 |   |             |
     | |      |                                 |   |             |
     | |   sampling Si (1:1 in case of no       |   |             |
     | |      |          sampling)              |   |             |
     | |   filtering Fi (select all when        |   |             |
     | |      |          no criteria)           |   |             |
     | +------+                                 |   |             |
     |        |                                 |   |             |
     |        |        Timing out Flows         |   |             |
     |        |    Handle resource overloads    |   |             |
     +--------|---------------------------------+   +-----|-------+
              |                                           |
      Flow Records (identified by Observation Domain)  Flow Records
              |                                           |
   |                    |     Exporting Process                        |
   |+-------------------|-------------------------------------------+  |
   ||                   v       IPFIX Protocol                      |  |
   ||+-----------------------------+  +----------------------------+|  |
   |||Rules for                    |  |Functions                   ||  |
   ||| Picking/sending Templates   |  |-Packetise selected Control ||  |
   ||| Picking/sending Flow Records|->|  & data Information into   ||  |
   ||| Encoding Template & data    |  |  IPFIX export packets.     ||  |
   ||| Selecting Flows to export(*)|  |-Handle export errors       ||  |
   ||+-----------------------------+  +----------------------------+|  |
   |+----------------------------+----------------------------------+  |
   |                             |                                     |
   |                    exported IPFIX Messages                        |
   |                             |                                     |
   |                +------------+-----------------+                   |
   |                |  Anonymise export packet(*)  |                   |
   |                +------------+-----------------+                   |
   |                             |                                     |
   |                +------------+-----------------+                   |
   |                |       Transport  Protocol    |                   |
   |                +------------+-----------------+                   |
   |                             |                                     |
                    IPFIX export packet to Collector

(*) indicates that the block is optional.


Figure 4: IPFIX Device functional blocks


6. Overview of the IPFIX Protocol

An IPFIX Device consists of a set of cooperating processes that implement the functional blocks described in the previous section. Alternatively, an IPFIX Device can be viewed simply as a network entity that implements the IPFIX protocol. At the IPFIX Device, the protocol functionality resides in the Exporting Process. The IPFIX Exporting Process gets Flow Records from a Metering Process, and sends them to the Collector(s).

IPFIXデバイスは、前のセクションで説明した機能ブロックを実現するプロセスを協働のセットからなります。あるいは、IPFIXデバイスは、単に、IPFIXプロトコルを実装するネットワークエンティティと見なすことができます。 IPFIXデバイスにおいて、プロトコル機能は、エクスポートプロセスに存在します。 IPFIXエクスポートプロセスは、計量プロセスからのフローレコードを取得し、コレクタ(複数可)に送信します。

At a high level, an IPFIX Device performs the following tasks:


1. Encodes Control Information into Templates.

2. Encodes packets observed at the Observation Points into Flow Records.


3. Packetises the selected Templates and Flow Records into IPFIX Messages.

3. Packetises選択テンプレートとフローレコードIPFIXメッセージに。

4. Sends IPFIX Messages to the Collector.
4. CollectorにIPFIXメッセージを送信します。

The IPFIX protocol communicates information from an IPFIX Exporter to an IPFIX Collector. That information includes not only Flow Records, but also information about the Metering Process. Such information (referred to as Control Information) includes details of the data fields in Flow Records. It may also include statistics from the Metering Process, such as the number of packets lost (i.e., not metered).

IPFIXプロトコルはIPFIXコレクタへIPFIX輸出業者からの情報を通信します。この情報だけでなく、フローレコードでなく、計量プロセスに関する情報が含まれています。 (制御情報と称する)、このような情報は、フローレコードのデータフィールドの詳細を含みます。また、そのようなパケットの数(すなわち、計量ではない)失われたとして計量プロセスからの統計を含むことができます。

For details of the IPFIX protocol, please refer to RFC 5101 [3].

IPFIXプロトコルの詳細については、RFC 5101 [3]を参照してください。

6.1. Information Model Overview
6.1. 情報モデルの概要

The IP Flow Information eXport (IPFIX) protocol serves for transmitting information related to measured IP traffic over the Internet. The protocol specification in RFC 5101 [3] defines how Information Elements are transmitted. For Information Elements, it specifies the encoding of a set of basic data types. However, the list of fields that can be transmitted by the protocol, such as Flow attributes (source IP address, number of packets, etc.) and information about the Metering and Exporting Process (packet Observation Point, sampling rate, Flow timeout interval, etc.), is not specified in RFC 5101 [3]. Instead, it is defined in the IPFIX information model in RFC 5102 [2].

IPフロー情報エクスポート(IPFIX)プロトコルは、インターネット上で測定されたIPトラフィックに関連する情報を送信するのに役立ちます。 RFC 5101のプロトコル仕様は、[3]の情報要素を送信する方法を定義します。情報要素の場合は、基本データ型のセットのエンコーディングを指定します。しかしながら、そのようなフローなどのプロトコルによって送信可能なフィールドのリストは、計量およびエクスポートプロセス(パケット観測ポイント、サンプリングレート、フロータイムアウト間隔について(送信元IPアドレス、パケット数、等)と情報の属性、等)、RFC 5101で指定されていない[3]。その代わりに、それはRFC 5102にIPFIX情報モデルで定義されている[2]。

The information model provides a complete description of the properties of every IPFIX Information Element. It does this by specifying each element's name, Field Type, data type, etc., and providing a description of each element. Element descriptions give the semantics of the element, i.e., say how it is derived from a Flow or other information available within an IPFIX Device.


6.2. Flow Records
6.2. フローレコード

The following rules provide guidelines to be followed while encoding the Flow Records information:


A Flow Record contains enough information so that the Collecting Process can identify the corresponding <Per-Flow Control Information, Configuration Control Information>.


The Exporting Process encodes a given Information Element (as specified in RFC 5102 [2]), based on the encoding standards prescribed by RFC 5101 [3].

(RFC 5102で指定されるように[2])エクスポートプロセス[3] RFC 5101で規定符号化規格に基づいて、所定の情報要素を符号化します。

6.3. Control Information
6.3. 制御情報

The following rules provide guidelines to be followed while encoding the Control Information:


o Per-Flow Control Information should be encoded such that the Collecting Process can capture the structure and semantics of the corresponding Flow data for each of the Flow Records exported by the IPFIX Device.


o Configuration Control Information is conveyed to a Collector so that its Collecting Process can capture the structure and semantics of the corresponding configuration data. The configuration data, which is also Control Information, should carry additional information on the Observation Domain within which the configuration takes effect.


For example, sampling using the same sampling algorithm, say 1 in 100 packets, is configured on two Observation Points O1 and O2. The configuration in this case may be encoded as {ID, observation points (O1,O2), sampling algorithm, interval (1 in 100)}, where ID is the Observation Domain ID for the domain containing O1 and O2. The Observation Domain ID uniquely identifies this configuration, and must be sent within the Flow Records in order to be able to match the right configuration control information.

例えば、同じサンプリングアルゴリズムを使用してサンプリングし、1 100内のパケットは、2観測点O1とO2に設定されていると言います。 IDは、O1及びO2を含むドメインの観測ドメインIDである場合、この場合の構成は、{アルゴリズム、間隔(100 1)をサンプリングし、ID、観測点(O1、O2)}として符号化することができます。観測ドメインIDは一意にこの構成を識別し、右構成制御情報と一致することができるようにするために、フローレコード内で送信されなければなりません。

The Control Information is used by the Collecting Process to:


o Decode and interpret Flow Records.


o Understand the state of the Exporting Process.


Sending Control Information from the Exporting Process in a timely and reliable manner is critical to the proper functioning of the IPFIX Collecting Process. The following approaches may be taken for the export of Control Information:


1. Send all the Control Information pertaining to Flow Records prior to sending the Flow Records themselves. This includes any incremental changes to the definition of the Flow Records.


2. Notify, on a near real-time basis, the state of the IPFIX Device to the Collecting Process. This includes all changes such as a configuration change that affects the Flow behaviour, changes to Exporting Process resources that alter export rates, etc., which the Collector needs to be aware of.


3. Since it is vital that a Collecting Process maintains accurate knowledge of the Exporter's state, the export of the Control Information should be done such that it reaches the Collector reliably. One way to achieve this is to send the Control Information over a reliable transport.


6.4. Reporting Responsibilities
6.4. 責任の報告

From time to time, an IPFIX Device may not be able to observe all the packets reaching one of its Observation Points. This could occur if a Metering Process finds itself temporarily short of resources. For example, it might run out of packet buffers for IPFIX export.


In such situations, the IPFIX Device should attempt to count the number of packet losses that have occurred, and report them to its Collector(s). If it is not possible to count losses accurately, e.g., when transport layer (i.e., non-IPFIX) errors are detected, the IPFIX Device should report this fact, and perhaps indicate the time period during which some packets might not have been observed.


7. IPFIX Protocol Details
7. IPFIXプロトコルの詳細

When the IPFIX Working Group was chartered, there were existing common practices in the area of Flow export, for example, NetFlow, CRANE (Common Reliable Accounting for Network Element), LFAP (Light-weight Flow Admission Protocol), RTFM (Real-time Traffic Flow Measurement), etc. IPFIX's charter required the Working Group to consider those existing practices, and select the one that was the closest fit to the IPFIX requirements in RFC 3917 [1]. Additions or modifications would then be made to the selected protocol to fit it exactly into the IPFIX architecture.

IPFIXワーキンググループをチャーターした場合には、例えば、フロー輸出の分野で一般的な慣行を既存のあった、NetFlowの、CRANE(ネットワーク要素の一般的な信頼性の高い会計)、LFAP(軽量フローアドミッション・プロトコル)、RTFM(リアルタイム交通流計測)などIPFIXのチャーターは、これらの既存の慣行を考慮し、RFC 3917でIPFIX要件に最も近いフィット[1]だったものを選択するワーキンググループを必要としました。追加または変更は、正確にIPFIXアーキテクチャにそれに合うように選択したプロトコルに行われることになります。

7.1. The IPFIX Basis Protocol
7.1. IPFIXの基本プロトコル

The Working Group went through an extensive evaluation of the various existing protocols that were available, weighing the level of compliance with the requirements, and selected one of the candidates as the basis for the IPFIX protocol. For more details of the evaluation process, please see RFC 3955 [6].

ワーキンググループでは、要件の遵守のレベルを計量、利用できた様々な既存のプロトコルの広範な評価を経て、およびIPFIXプロトコルの基礎として、候補の一つを選択しました。評価プロセスの詳細については、RFC 3955 [6]を参照してください。

In the basis protocol, Flow Records are defined by Templates, where a Template is an ordered set of the Information Elements appearing in a Flow Record, together with their field sizes within those records.


This approach provides the following advantages:


o Using the Template mechanism, new fields can be added to IPFIX Flow Records without changing the structure of the export record format.


o Templates that are sent to the Collecting Process carry structural information about the exported Flow Record fields. Therefore, if the Collector does not understand the semantics of new fields, it can ignore them, but still interpret the Flow Record.


o Because the template mechanism is flexible, it allows the export of only the required fields from the Flows to the Collecting Process. This helps to reduce the exported Flow data volume and possibly provide memory savings at the Exporting Process and Collecting Process. Sending only the required information can also reduce network load.


7.2. IPFIX Protocol on the Collecting Process
7.2. 収集プロセスのIPFIXプロトコル

The Collecting Process is responsible for:


1. Receiving and decoding Flow Records from the IPFIX Devices.

2. Reporting on the loss of Flow Records sent to the Collecting Process by an IPFIX Exporting Process.


Complete details of the IPFIX protocol are given in RFC 5101 [3].

IPFIXプロトコルの完全な詳細は、RFC 5101に記載されている[3]。

7.3. Support for Applications
7.3. アプリケーションのサポート

Applications that use the information collected by IPFIX may be Billing or Intrusion Detection sub-systems, etc. These applications may be an integral part of the Collecting Process, or they may be co-located with the Collecting Process. The way by which these applications interface with IPFIX systems to get the desired information is out of scope for this document.

請求又は侵入検知サブシステム、等であってもよいIPFIXによって収集された情報を使用するアプリケーションは、これらのアプリケーションは、収集プロセスの不可欠な部分であってもよく、またはそれらは収集プロセスと同じ場所に配置することができます。 IPFIXシステムと、これらのアプリケーションは、インタフェース目的の情報を取得することにより、方法はこの文書の範囲外です。

8. Export Models
8.1. Export with Reliable Control Connection
8.1. 信頼性の高い制御接続とエクスポート

As mentioned in RFC 3917 [1], an IPFIX Device must be able to transport its Control Information and Data Stream over a congestion-aware transport protocol.

RFC 3917で説明したように[1]、IPFIXデバイスは、渋滞認識トランスポートプロトコルを介してその制御情報およびデータストリームを運ぶことができなければなりません。

If the network in which the IPFIX Device and Collecting Process are located does not guarantee reliability, at least the Control Information should be exported over a reliable transport. The Data Stream may be exported over a reliable or unreliable transport protocol.


Possible transport protocols include:


o SCTP: Supports reliable and unreliable transport.


o TCP: Provides reliable transport only.


o UDP: Provides unreliable transport only. Network operators would need to avoid congestion by keeping traffic within their own administrative domains. For example, one could use a dedicated network (or Ethernet link) to carry IPFIX traffic from Exporter to Collector.

UDP O:唯一の信頼性のないトランスポートを提供します。ネットワークオペレータは、独自の管理ドメイン内のトラフィックを維持することによって輻輳を回避する必要があります。例えば、一つは輸出業者からのCollectorにIPFIXトラフィックを運ぶために、専用のネットワーク(またはイーサネットリンク)を使用することができます。

8.2. Collector Failure Detection and Recovery
8.2. コレクターの障害検出と回復

The transport connection (in the case of a connection-oriented protocol) is pre-configured between the IPFIX Device and the Collector. The IPFIX protocol does not provide any mechanism for configuring the Exporting and Collecting Processes.

(コネクション型プロトコルの場合)、トランスポート接続は、IPFIXデバイスとコレクタとの間に事前に設定されます。 IPFIXプロトコルは、エクスポートおよび収集プロセスを構成するための任意のメカニズムを提供しません。

Once connected, an IPFIX Collector receives Control Information and uses that information to interpret Flow Records. The IPFIX Device should set a keepalive (e.g., the keepalive timeout in the case of TCP, the HEARTBEAT interval in the case of SCTP) to a sufficiently low value so that it can quickly detect a Collector failure. Note, however, that extremely short keepalive intervals can incorrectly abort the connection during transient periods of congestion. They can also cause some level of additional network load during otherwise idle periods.


Collector failure refers to the crash or restart of the Collecting Process or of the Collector itself. A Collector failure is detected at the IPFIX Device by the break in the connection-oriented transport protocol session; depending on the transport protocol, the connection timeout mechanisms differ. On detecting a keepalive timeout in a single Collector scenario, the IPFIX Device should stop sending Flow Records to the Collector and try to reestablish the transport connection. If Collecting Process failover is supported by the Exporting Process, backup session(s) may be opened in advance, and Control Information sent to the failover Collecting Process.


There could be one or more secondary Collectors with priority assigned to them. The primary Collector crash is detected at the IPFIX Device. On detecting loss of connectivity, the IPFIX Device opens a Data Stream with the secondary Collector of the next highest priority. If that secondary was not opened in advance, both the Control Information and Data Stream must be sent to it. That Collector might then become the primary, or the Exporting Process might try to reestablish the original session.


8.3. Collector Redundancy
8.3. コレクタの冗長性

Configuring redundant Collectors is an alternative to configuring backup Collectors. In this model, all Collectors simultaneously receive the Control Information and Data Streams. Multiple {Control Information, Data Stream} pairs could be sent, each to a different Collector, from the same IPFIX Device. Since the IPFIX protocol requires a congestion-aware transport, achieving redundancy using multicast is not an option.

冗長コレクターを設定すると、バックアップ・コレクターを構成するための代替手段です。このモデルでは、すべてのコレクターは同時に制御情報およびデータストリームを受け取ります。複数{制御情報は、データストリーム}ペアが同じIPFIXデバイスから、それぞれ異なるコレクタに、送ることができます。 IPFIXプロトコルは混雑対応の輸送を必要とするので、マルチキャストを使用して冗長性を実現することはオプションではありません。

9. IPFIX Flow Collection in Special Situations
特殊な状況で9 IPFIX流れコレクション

An IPFIX Device can generate, receive, and/or alter two special types of traffic, which are listed below.


Tunnel traffic:


The IPFIX Device could be the head, midpoint, or end-point of a tunnel. In such cases, the IPFIX Device could be handling Generic Routing Encapsulation (GRE) [8], IPinIP [7], or Layer Two Tunneling Protocol version 3 [9] traffic.

IPFIXデバイスは、トンネルの先頭、中間、またはエンドポイントとすることができます。このような場合には、IPFIXデバイスは、[7]、またはレイヤ2トンネリングプロトコルバージョン3 [9]トラフィック、[8]のIPinIPを総称ルーティングカプセル化(GRE)を取り扱うことができます。

VPN traffic:


The IPFIX Device could be a provider-edge device that receives traffic from customer sites belonging to different Virtual Private Networks.


Similarly, IPFIX could be implemented on devices which perform one or more of the following special services: o Explicitly drop packets. For example, a device that provides firewall service drops packets based on some administrative policy.


o Alter the values of fields used as IPFIX Flow Keys of interest. For example, a device that provides NAT service can change the source and/or destination IP address.


In cases such as those listed above, there should be clear guidelines as to:


o How and when to classify the packets as Flows in the IPFIX Device.


o If multiple encapsulations are used to define Flows, how to convey the same fields (e.g., IP address) in different layers.


o How to differentiate Flows based on different private domains. For example, overlapping IP addresses in Layer-3 VPNs.


o What extra information needs to be exported so that the Collector can make a clear interpretation of the received Flow Records.


10. Security Considerations

Flow information can be used for various purposes, such as usage-based accounting, traffic profiling, traffic engineering, and intrusion detection. The security requirements may differ significantly for such applications. To be able to satisfy the security needs of various IPFIX users, an IPFIX system must provide different levels of security protection.


10.1. Data Security
10.1. データセキュリティ

IPFIX data comprises Control Information and Data Streams generated by the IPFIX Device.


The IPFIX data may exist in both the IPFIX Device and the Collector. In addition, the data is also transferred on the wire from the IPFIX Device to the Collector when it is exported. To provide security, the data should be protected from common network attacks.


The protection of IPFIX data within the end system (IPFIX Device and Collector) is out of scope for this document. It is assumed that the end system operator will provide adequate security for the IPFIX data.


The IPFIX architecture must allow different levels of protection to the IPFIX data on the wire. Wherever security functions are required, it is recommended that users should leverage lower layers using either TLS or DTLS (Datagram Transport Layer Security), if these can successfully satisfy the security requirement of IPFIX data protection.


To protect the data on the wire, three levels of granularity should be supported; these are described in the following subsections.


10.1.1. Host-Based Security
10.1.1. ホストベースのセキュリティ

Security may not be required when the transport between the IPFIX Device and the Collector is perceived as safe. This option allows the protocol to run most efficiently without extra overhead, and an IPFIX system must support it.


10.1.2. Authentication-Only
10.1.2. 認証のみ

Authentication-only protection provides IPFIX users with the assurance of data integrity and authenticity. The data exchanged between the IPFIX Device and the Collector is protected by an authentication signature. Any modification of the IPFIX data will be detected by the recipient, resulting in the discarding of the received data. However, the authentication-only option doesn't offer data confidentiality.

認証のみの保護は、データの整合性と信頼性の保証とIPFIXのユーザーに提供します。データは、IPFIXデバイスとの間で交換コレクタは認証署名によって保護されています。 IPFIXデータの任意の変更は、受信データの廃棄をもたらす、受信者によって検出されます。しかし、認証のみのオプションは、データの機密性を提供していません。

The IPFIX user should not use authentication-only when sensitive or confidential information is being exchanged. An IPFIX solution should support this option. The authentication-only option should provide replay attack protection. Some means to achieve this level of security are:

機密情報や機密情報が交換されているとき、IPFIXのユーザーは認証のみ使用すべきではありません。 IPFIXソリューションは、このオプションをサポートする必要があります。認証のみのオプションは、リプレイ攻撃に対する保護を提供する必要があります。このレベルのセキュリティを達成するためのいくつかの手段があります:

o Encapsulating Security Payload (with a null encryption algorithm)


o Transport Layer Security (with a null encryption algorithm)


o IP Authentication Header

O IP認証ヘッダ

10.1.3. Encryption
10.1.3. 暗号化

Data encryption provides the best protection for IPFIX data. The IPFIX data is encrypted at the sender, and only the intended recipient can decrypt and have access to the data. This option must be used when the transport between the IPFIX Device and the Collector is unsafe, and the IPFIX data needs to be protected. It is recommended that the underlying transport layer's security functions be used for this purpose. Some means to achieve this level of security are:

データの暗号化は、IPFIXデータのための最高の保護を提供します。 IPFIXデータは、送信側で暗号化され、目的の受信者だけが解読し、データにアクセスすることができます。 IPFIXデバイスとコレクタ間の輸送は安全ではない、とIPFIXデータを保護する必要がある場合は、このオプションを使用する必要があります。基本的なトランスポート層のセキュリティ機能は、この目的のために使用することをお勧めします。このレベルのセキュリティを達成するためのいくつかの手段があります:

o Encapsulating Security Payload


o Transport Layer Security Protocol


The data encryption option adds overhead to the IPFIX data transfer. It may limit the rate that an Exporter can report its Flow Records to the Collector, due to the resource requirement for running encryption.


10.2. IPFIX End-Point Authentication
10.2. IPFIXエンドポイントの認証

It is important to make sure that the IPFIX Device is talking to the "right" Collector rather than to a masquerading Collector. The same logic also holds true from the Collector's point of view, i.e., it may want to make sure it is collecting the Flow Records from the "right" IPFIX Device. An IPFIX system should allow the end-point authentication capability so that either one-way or mutual authentication can be performed between the IPFIX Device and Collector.


The IPFIX architecture should use any existing transport protection protocols, such as TLS, to fulfil the authentication requirement.


10.3. IPFIX Overload
10.3. IPFIXの過負荷

An IPFIX Device could become overloaded under various conditions. This may be because of exhaustion of internal resources used for Flow generation and/or export. Such overloading may cause loss of data from the Exporting Process, either from lack of export bandwidth (possibly caused by an unusually high number of observed Flows) or from network congestion in the path from Exporter to Collector.


IPFIX Collectors should be able to detect the loss of exported Flow Records, and should at least record the number of lost Flow Records.


10.3.1. Denial-of-Service (DoS) Attack Prevention
10.3.1. サービス拒否(DoS)攻撃の防止

Since one of the potential usages for IPFIX is for intrusion detection, it is important for the IPFIX architecture to support some kind of DoS resistance.

IPFIXのための潜在的な使用法の一つは、侵入検知のためにあるので、IPFIXアーキテクチャは、DoS攻撃耐性のいくつかの種類をサポートすることが重要です。 Network under Attack。攻撃を受けてネットワーク

The network itself may be under attack, resulting in an overwhelming number of IPFIX Messages. An IPFIX system should try to capture as much information as possible. However, when a large number of IPFIX Messages are generated in a short period of time, the IPFIX system may become overloaded.

ネットワーク自体は、IPFIXメッセージの圧倒的な数で、その結果、攻撃を受けてもよいです。 IPFIXシステムは、できるだけ多くの情報をキャプチャしてみてください。 IPFIXメッセージ多数の短時間で生成される場合しかし、IPFIXシステムが過負荷になることができます。 Generic DoS Attack on the IPFIX Device and Collector。 IPFIXデバイスとコレクターのジェネリックのDoS攻撃

The IPFIX Device and Collector may be subject to generic DoS attacks, just as any system on any open network. These types of attacks are not IPFIX specific. Preventing and responding to such types of attacks are out of the scope of this document.

IPFIXデバイスとコレクターはただのオープンなネットワーク上の任意のシステムとして、一般的なDoS攻撃を受ける可能性があります。これらのタイプの攻撃は、IPFIX固有のものではありません。防止や攻撃のようなタイプに応えることは、この文書の範囲外です。 IPFIX-Specific DoS Attack。 IPFIX固有のDoS攻撃

There are some specific attacks on the IPFIX portion of the IPFIX Device or Collector:


o The attacker could overwhelm the Collector with spoofed IPFIX Export packets. One way to solve this problem is to periodically synchronise the sequence numbers of the Flow Records between the Exporting and Collecting Processes.


o The attacker could provide false reports to the Collector by sending spoofed packets.


The problems mentioned above can be solved to a large extent if the control packets are encrypted both ways, thereby providing more information that the Collector could use to identify and ignore spoofed data packets.


11. IANA Considerations
11. IANAの考慮事項

The IPFIX Architecture, as set out in this document, has two sets of assigned numbers, as outlined in the following subsections.


11.1. Numbers Used in the Protocol
11.1. プロトコルで使用される数字

IPFIX Messages, as described in RFC 5101 [3], 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.

IPFIXメッセージは、RFC 5101に記載されているように[3]、割り当てられた値を有する2つのフィールドを使用します。これらは、IPFIXメッセージ内の情報の各セットの型を示す、IPFIXメッセージ、およびIPFIXセットIDをエクスポートするために使用されたIPFIXプロトコルのバージョンを示し、IPFIXバージョン番号です。

Values for the IPFIX Version Number and the IPFIX Set ID, together with the considerations for assigning them, are defined in RFC 5101 [3].

それらを一緒に割り当てるための配慮とIPFIXバージョン番号およびIPFIXセットIDの値は、[3] RFC 5101で定義されています。

11.2. Numbers Used in the Information Model
11.2. 情報モデルで使用される番号

Fields of the IPFIX protocol carry information about traffic measurement. They are modelled as elements of the IPFIX information model RFC 5102 [2]. Each Information Element describes a field that may appear in an IPFIX Message. Within an IPFIX Message, the field type is indicated by its Field Type.

IPFIXプロトコルのフィールドは、トラフィック測定に関する情報を運びます。それらはIPFIX情報モデルRFC 5102の要素としてモデル化されている[2]。各情報要素は、IPFIXメッセージに表示される場合がありますフィールドについて説明します。 IPFIXメッセージ内に、フィールドタイプは、そのフィールドタイプで示されています。

Values for the IPFIX Information Element IDs, together with the considerations for assigning them, are defined in RFC 5102 [2].

それらを一緒に割り当てるための考慮事項と、RFC 5102で定義されてIPFIX情報エレメントIDの値は、[2]。

12. Acknowledgements

The document editors wish to thank all the people contributing to the discussion of this document on the mailing list, and the design teams for many valuable comments. In particular, the following made significant contributions:


Tanja Zseby Paul Calato Dave Plonka Jeffrey Meyer K.C.Norseth Vamsi Valluri Cliff Wang Ram Gopal Jc Martin Carter Bullard Reinaldo Penno Simon Leinen Kevin Zhang Paul Aitken Brian Trammell

ターニャZsebyポールCalatoデイブPlonkaジェフリー・マイヤーK.C.Norseth Vamsi Valluriクリフ王ラムゴパルJcのマーティン・カーターブラードレイナルドPennoサイモンLeinenケビン・チャンポール・エイトケンブライアン・トラメル

Special thanks to Dave Plonka for the multiple thorough reviews.


13. References
13.1. Normative References
13.1. 引用規格

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

[1] Quittek、J.、Zseby、T.、Claise、B.、およびS.ザンダー、 "IPフロー情報エクスポート(IPFIX)のための要件"、RFC 3917、2004年10月。

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

[2] Quittek、J.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "モデルIPフロー情報エクスポートするための情報"、RFC 5102、2008年1月。

[3] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.

[3] Claise、B.、 "IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート(IPFIX)プロトコルの仕様"、RFC 5101、2008年1月。

[4] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", RFC 5472, March 2009.

[4] Zseby、T.、ボスキ、E.、ブラウンリー、N.、およびB. Claise、 "IPFIX適用"、RFC 5472、2009年3月。

13.2. Informative References
13.2. 参考文献

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

[5] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、 "RTP:リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年7月。

[6] Leinen, S., "Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)", RFC 3955, October 2004.

[6] Leinen、S.、RFC 3955、2004年10月 "IPフロー情報のエクスポート(IPFIX)の候補プロトコルの評価"。

[7] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.

[7]シンプソン、W.、 "IPトンネリングでIP"、RFC 1853、1995年10月。

[8] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.

[8]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化(GRE)"、RFC 2784、2000年3月。

[9] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

[9]ラウ、J.、Townsley、M.、およびI. Goyret、 "レイヤ2トンネリングプロトコル - バージョン3(L2TPv3の)"、RFC 3931、2005年3月。

Authors' Addresses


Ganesh Sadasivan Rohati Systems 1192 Borregas Ave. Sunnyvale, CA 94089 USA

ガネーシュSadashivn Rohtiシステムズ1192 Boarrigesイチイ。サニーベール、94089それ



Nevil Brownlee CAIDA | The University of Auckland Private Bag 92019 Auckland 1142 New Zealand

NevilブラウンリーCAIDA |オークランド大学プライベートバッグの92019オークランド1142ニュージーランド

Phone: +64 9 373 7599 x88941 EMail:

電話:+64 9 373 7599 x88941メール

Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium

ブノワClaiseシスコシステムズ、株式会社デKleetlaan 6aはB1 1831ディーゲムベルギー

Phone: +32 2 704 5622 EMail:

電話:+32 2 704 5622 Eメール

Juergen Quittek NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany

ユルゲンQuittek NEC欧州研究所、NECヨーロッパ社Kurfuerstenコンディショニング36 69115ハイデルベルクドイツ

Phone: +49 6221 4342-115 EMail: URI:

電話:+49 6221 4342-115電子メール URI: