[要約] RFC 5470は、IPフロー情報のエクスポートのためのアーキテクチャに関するものであり、IPフロー情報の収集、処理、転送、および分析をサポートするためのフレームワークを提供しています。このRFCの目的は、ネットワーク管理者がネットワークトラフィックの状態を把握し、問題を特定し、ネットワークのパフォーマンスを最適化するための手段を提供することです。
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
NEC
March 2009
Architecture for IP Flow Information Export
IPフロー情報エクスポートのアーキテクチャ
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
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.
このメモは、IPフローの選択的監視、およびIPFIXデバイスからコレクターへの測定されたIPフロー情報のエクスポートのためのIPフロー情報エクスポート（IPFIX）アーキテクチャを定義します。
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
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.
いくつかのアプリケーションがあります。たとえば、使用量ベースの会計、トラフィックプロファイリング、トラフィックエンジニアリング、攻撃/侵入検知、サービス品質（QOS）監視など、フローベースのIPトラフィック測定が必要です。したがって、IPフローに関連する情報をエクスポートする標準的な方法を持つことが重要です。このドキュメントでは、IPトラフィックフローの監視、測定、およびエクスポートのアーキテクチャを定義しています。IPFIXデバイスの主要なコンポーネントとその機能の高レベルの説明を提供します。
This document defines the architecture for IPFIX. Its main objectives are to:
このドキュメントでは、IPFIXのアーキテクチャを定義しています。その主な目的は次のとおりです。
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プロトコルの特性を説明してください。
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フロー情報へのアクセスを提供します。このドキュメントは、RFC 3917 [1]で定義されている要件に従って、IPFIXエクスポートプロセスから収集プロセスへの測定されたIPフロー情報のエクスポートのアーキテクチャを指定します。IPFIXプロトコルドキュメントであるRFC 5101 [3]は、IPFIXのエクスポートプロセスからIPFIXの収集プロセスまで、IPFIXデータレコードとテンプレートが渋滞を認識したトランスポートプロトコルを介してどのように運ばれるかを指定します。IPFIXには、RFC 5102 [2]で指定されているように、IPFIX情報要素（フィールド）、その名前、タイプ、および追加のセマンティック情報の正式な説明があります。最後に、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.
IPFIXシステムは、IPFIXデバイスのリモート構成を提供していないことに注意してください。代わりに、実装者はIPFIXデバイスを構成するための効果的な方法を提供する必要があります。
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.
観測点は、IPパケットを観察できるネットワーク内の場所です。例には、プローブが取り付けられる線、イーサネットベースのLAN、ルーターの単一のポート、またはルーターのインターフェイスのセット（物理的または論理）などの共有媒体が含まれます。
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.
すべての観測点は観測ドメイン（以下に定義）に関連付けられており、1つの観測点は他のいくつかの観測点のスーパーセットである可能性があることに注意してください。たとえば、1つの観測点は、ラインカード全体にすることができます。これは、ラインカードのインターフェイスでの個々の観測ポイントのスーパーセットです。
* 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デバイスごとに一意にすることをお勧めします。
* 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: 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:
インターネットコミュニティが使用する「フロー」という用語の定義はいくつかあります。IPFIXのコンテキスト内で、次の定義を使用します。フローは、特定の時間間隔中にネットワーク内の観測点を渡すIPパケットのセットとして定義されます。特定のフローに属するすべてのパケットには、共通のプロパティのセットがあります。各プロパティは、次の値に関数を適用した結果として定義されます。
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]).
1. 1つ以上のパケットヘッダーフィールド（宛先IPアドレスなど）、トランスポートヘッダーフィールド（宛先ポート番号など）、またはアプリケーションヘッダーフィールド（RTPヘッダーフィールド[5]）。
2. one or more characteristics of the packet itself (e.g., number of MPLS labels)
2. パケット自体の1つ以上の特性（例：MPLSラベルの数）
3. one or more fields derived from packet treatment (e.g., next hop IP address, output interface)
3. パケットトリートメントから派生した1つ以上のフィールド（次のホップIPアドレス、出力インターフェイスなど）
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.
この定義は、ネットワークインターフェイスで観察されたすべてのパケットを含むフローから、2つのアプリケーション間の単一のパケットのみで構成されるフローまでの範囲をカバーします。サンプリングメカニズムによって選択されたパケットが含まれています。
* Flow Key
* FlowKey
Each of the fields that:
それぞれのフィールド：
1. belongs to the packet header (e.g., destination IP address),
1. パケットヘッダー（宛先IPアドレスなど）に属し、
2. is a property of the packet itself (e.g., packet length),
2. パケット自体のプロパティ（パケットの長さなど）です。
3. is derived from packet treatment (e.g., Autonomous System (AS) number), and
3. パケット処理（たとえば、自律システム（AS）数）から派生し、
4. is used to define a Flow
4. フローを定義するために使用されます
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).
フローレコードには、観測点で観察された特定のフローに関する情報が含まれています。フローレコードには、フローの測定された特性（たとえば、すべてのフローのパケットのバイトの総数）と、通常、フローの特徴的な特性（例：ソースIPアドレス）が含まれます。
* 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.
エクスポートプロセスは、フローレコードを1つ以上の収集プロセスに送信します。フローレコードは、1つ以上の計量プロセスによって生成されます。
* Exporter
* 輸出業者
A device that hosts one or more Exporting Processes is termed an Exporter.
1つ以上のエクスポートプロセスをホストするデバイスは、輸出者と呼ばれます。
* 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.
IPFIXデバイスは、少なくとも1つのエクスポートプロセスをホストします。さらに、プロセスをさらにエクスポートし、任意の数の観測ポイントと計量プロセスをホストする場合があります。
* 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.
収集プロセスは、1つ以上のエクスポートプロセスからフローレコードを受信します。収集プロセスは受信したフロー記録を処理または保存する可能性がありますが、このようなアクションはこのドキュメントの範囲外です。
* Collector
* コレクタ
A device that hosts one or more Collecting Processes is termed a Collector.
1つ以上の収集プロセスをホストするデバイスは、コレクターと呼ばれます。
* 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.
テンプレートは、IPFIXデバイスからコレクターに伝達する必要がある特定の情報セットの構造とセマンティクスを完全に指定するために使用される<タイプ、長さ>ペアの順序付けられたシーケンスです。各テンプレートは、テンプレートIDを使用して一意に識別できます。
* Control Information, Data Stream
* 制御情報、データストリーム
The information that needs to be exported from the IPFIX Device can be classified into the following categories:
IPFIXデバイスからエクスポートする必要がある情報は、次のカテゴリに分類できます。
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.
これには、フロー定義、エクスポートプロセスによって送信されるフロー内のパケットの選択基準、およびエクスポートするデータを説明するテンプレートが含まれます。コントロール情報は、End-PointsがIPFIXプロトコルを理解するために必要なすべての情報を、特にコレクターが送信輸出国から送信したデータを理解して解釈するために提供されます。
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で使用する有効なエンコーディングメカニズムも決定します。
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の例では、低次の64ビットで「Mac Addr-Nn」を使用して、ホストインターフェイスNNのIEEE Mac（メディアアクセス制御）アドレスを示します。
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. {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}
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：いくつかの値を集約するために、観測点を通過するすべてのパケットにマスク関数を適用できます。これは、上記の例1のように、フローキーのセットを{ソースIPアドレス、宛先IPアドレス、DSCP}として定義し、ソースおよび宛先IPアドレスをマスクする関数を適用することで実行できます（IPv4、64の最低6ビットの最低6ビットIPv6のビット）。例1からの8つのフローは、フロー1 2と5 6を単一のフローに統合することにより、6つのフローに集約されます。
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}
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.
例3：特定のフローのみを選択するために、いくつかのフローキー値によって定義されたフィルターを、観測点を通過するすべてのパケットに適用できます。フィルターは、パケットから特定のキーの固定値を選択することによって定義されます。
All the packets that go from a customer network 192.0.2.0/26 to another customer network 192.0.2.64/26 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, {192.0.2.0/26, 192.0.2.64/26, 4}.
顧客ネットワーク192.0.2.0/26から別のカスタマーネットワーク192.0.2.64/26までのすべてのパケットは、4のDSCP値を定義します。他のすべての組み合わせはフローを定義せず、考慮されません。例2からの3つのフローは、フロー2と3をフィルタリングすることにより1つのフローに縮小され、{192.0.2.0/26、192.0.2.64/26、4}のみが流れ1のみになります。
Similarly, for the IPv6 packets in the examples above, one could filter out Flows 5 and 6 to leave Flow 4.
同様に、上記の例のIPv6パケットの場合、フロー5と6を除外して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:
上記の例は、input {ソースIPアドレス、宛先IPアドレス、DSCP}として関数f（）を取得すると考えることができます。この関数は、次の3つの条件すべてを満たすパケットのみを選択します。
1. Mask out the least significant 6 bits of source IP address, match against 192.0.2.0.
1. ソースIPアドレスの最小6ビットをマスクし、192.0.2.0と一致します。
2. Mask out the least significant 6 bits of destination IP address, match against 192.0.2.64.
2. 192.0.2.64と一致する宛先IPアドレスの6ビットをマスクします。
3. Only accept DSCP value equal to 4.
3. 4に等しいDSCP値のみを受け入れます。
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.
さまざまな観測パケットの{ソースIPアドレス、宛先IPアドレス、DSCP}の値に応じて、メータリングプロセス関数f（）は、異なるフローを作成するパケットの異なるセットを選択/フィルター/集約します。たとえば、{ソースIPアドレス、宛先IPアドレス、DSCP}、F（ソースIPアドレス、宛先IPアドレス、DSCP）の値のさまざまな組み合わせの場合、1つ以上のフローの定義が生じます。
The figure below shows the reference model for IPFIX. This figure covers the various possible scenarios that can exist in an IPFIX system.
以下の図は、IPFIXの参照モデルを示しています。この図は、IPFIXシステムに存在する可能性のあるさまざまなシナリオをカバーしています。
+----------------+ +----------------+
|[*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
図1：IPFIXリファレンスモデル
The figure below shows a typical IPFIX Device where the IPFIX components are shown in rectangular boxes.
以下の図は、IPFIXコンポーネントが長方形のボックスに示されている典型的なIPFIXデバイスを示しています。
+--------------------------------------------------+
| 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
図2：IPFIXデバイス
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.
Flow測定に参加するIPFIXデバイスのすべての観測点は、少なくとも1つのメータープロセスに関連付けられている必要があります。観測点に入るすべてのパケットは、観測点に関連付けられた各計量プロセスに入ります。大まかに、各メータープロセスは、観測点を通過し、タイムスタンプを実行し、選択基準に基づいてパケットをフローに分類するパケットを観察します。
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 すべてのフローレコードのデータベースを観測ドメインから維持します。これには、新しいフローレコードの作成、既存のレコードの更新、フローレコードの計算統計、さらなるフロープロパティの導出、パケット処理に基づいて非流量固有の情報の追加が含まれます（場合によっては、数字、ルーター状態などのフィールド）
o Maintaining statistics about the Metering Process itself, such as Flow Records generated, packets observed, etc.
o 生成されたフローレコード、観察されたパケットなど、計量プロセス自体に関する統計を維持します。
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.
1. 流れに属するパケットが一定期間観察されていない場合。この期間は、計量プロセスで構成可能であり、即時の有効期限のために最小値は0秒である必要があります。ゼロタイムアウトは、フローをシングルパケットフローのシーケンスとして報告することに注意してください。
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.
3. 長期にわたるフローの場合、計量プロセスは定期的に、またはいくつかの有効期限ポリシーに基づいてフローを期限切れにする必要があります。この周期性または有効期限ポリシーは、計量プロセスで構成可能である必要があります。長期にわたる流れが期限切れになった場合、その流れ記録はメータープロセスによって維持される可能性があるため、メータープロセスは、同じフローのさらなる観察されたパケットのために新しいフローレコードを作成する必要がありません。
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.
エクスポートプロセスは、期限切れのフローをいつエクスポートするかを決定します。セクション5.1.1「フローの有効期限」に記載されている理由のいずれかで期限切れになったため、フローをエクスポートできます。たとえば、エクスポートプロセスは、期限切れのフローの一部を「x」秒ごとにエクスポートします。
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.
長期にわたるフローの場合、エクスポートプロセスは、フローレコードを定期的に、または一部の輸出ポリシーに基づいてエクスポートする必要があります。この周期性またはエクスポートポリシーは、エクスポートプロセスで構成可能である必要があります。
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.
測定された観測点がわかっている場合、フローレコードをよりよく分析できます。そのため、IPFIXデバイスがこの情報をコレクターに送信することをお勧めします。単一の観測点がある場合、または観測点情報が関連しない場合、メータープロセスは、観測点情報をフローレコードに追加しないことを選択する場合があります。
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.
計量プロセスは、ルールを定義する場合があります。これにより、観測点での測定用に、着信パケットストリーム内の特定のパケットのみが選択されるようにします。これは、以下に定義されている2つの方法のいずれかまたはそれらの組み合わせによって行われる場合があります。これらの各メソッドの組み合わせを採用してパケットを選択できます。つまり、一連のメソッドを定義できます{f1、s1、f2、s2、s3}は、特定のフローを選択するために、指定されたシーケンスで指定されたシーケンスで実行されます。
The figure below shows the operations that may be applied as part of a typical Metering Process.
以下の図は、典型的な計量プロセスの一部として適用される操作を示しています。
+---------------------------+
| packet header capturing |
+---------------------------+
|
v
+---------------------------+
| timestamping |
+---------------------------+
|
v
+---------------> +
| |
| v
| +----------------------------------------------+
| | sampling Si (1:1 in case of no sampling) |
| +----------------------------------------------+
| |
| v
| +----------------------------------------------+
| | filtering Fi (select all when no criteria) |
| +----------------------------------------------+
| |
| v
+-----------------+
|
v
+---------------------------+
| Flows |
+---------------------------+
Figure 3: Selection Criteria for Packets
図3：パケットの選択基準
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.
IP処理の前または後、つまり、IPチェックサムの検証、IPフィルタリングなどがある前、またはこれらの手順の1つ以上の後にパケットを選択できることに注意してください。これは、IPFIXが観察できるトラフィック（または誤った条件）の種類に影響を与えます。チェックサムが検証された後、パケットを選択することをお勧めします。
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.
例：観測点で受信された100回目のパケットごとにサンプルします。
Choosing all the packets is a special case where the sampling rate is 1:1.
すべてのパケットを選択することは、サンプリングレートが1：1である特別なケースです。
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}.
例：フィルターを定義するフィールドのマスク/マッチ。フィルターは、{protocol == 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.
このようなフィルターをいくつかのシーケンスで使用して、パケットを選択できます。（一連の）フィルター関数によって選択されたパケットは、他のフィルター関数によってさらに分類される可能性があることに注意してください。つまり、選択したパケットはいくつかのフローに属し、その一部またはすべてがエクスポートされる場合があります。
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は、IPFIX観測ドメインIDと呼ばれます。
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).
エクスポートプロセスは、IPFIXプロトコルを使用して1つ以上のIPFIXコレクターにデータを送信する機能ブロックです。一方では、エクスポートプロセスがメータリングプロセスをインターフェースしてフローレコードを取得します。反対側にいる間、それはコレクターの収集プロセスに話しかけます。
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".
特定のフローレコードのみがエクスポートされるように、観測ドメイン内で定義された追加のルールがある場合があります。これは、セクション5.3「パケットの選択基準」で説明されているように、SiとFiの組み合わせによって行われます。
Example: Only the Flow Records that meet the following selection criteria are exported: 1. All Flow Records whose destination IP address matches {192.0.33.5}.
例：次の選択基準を満たすフローレコードのみがエクスポートされます。1。宛先IPアドレスが一致するすべてのフローレコード{192.0.33.5}。
2. Every other (i.e., sampling rate 1 in 2) Flow Record whose destination IP address matches {192.0.11.30}.
2. 宛先IPアドレスが{192.0.11.30}と一致するフローレコードの他のすべて（つまり、サンプリングレート1）。
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.
収集プロセスは、Flow RecordのテンプレートIDを使用して、そのフローレコードの情報要素を解釈します。これを許可するには、IPFIXエクスポートは、IPFIXコレクターが各入っているフローレコードのテンプレートIDを知っていることを確認する必要があります。着信フローレコードを解釈するには、IPFIXコレクターは、各フローの計量プロセスで使用された関数f（）を知る必要がある場合があります。
The functions of the Collecting Process must include:
収集プロセスの関数には以下が含まれている必要があります。
o Identifying, accepting, and decoding the IPFIX Messages from different <Exporting Process, Observation Domain> pairs.
o 異なる<エクスポートプロセス、観測ドメイン>ペアからのIPFIXメッセージの識別、受け入れ、およびデコード。
o Storing the Control Information and Flow Records received from an IPFIX Device.
o IPFIXデバイスから受信した制御情報とフローレコードを保存します。
At a high level, the Collecting Process:
高いレベルでは、収集プロセス：
1. Receives and stores the Control Information.
1. 制御情報を受信して保存します。
2. Decodes and stores the Flow Records using the Control Information.
2. 制御情報を使用してフローレコードをデコードおよび保存します。
The figure below shows the functions performed in sequence by the various functional blocks in an IPFIX Device.
以下の図は、IPFIXデバイスのさまざまな機能ブロックによって順番に実行された関数を示しています。
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 | |
| +------------+-----------------+ |
| | |
+-----------------------------+-------------------------------------+
|
v
IPFIX export packet to Collector
(*) indicates that the block is optional.
（*）ブロックがオプションであることを示します。
Figure 4: IPFIX Device functional blocks
図4：IPFIXデバイス機能ブロック
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:
高いレベルでは、IPFIXデバイスが次のタスクを実行します。
1. Encodes Control Information into Templates.
1. コントロール情報をテンプレートにエンコードします。
2. Encodes packets observed at the Observation Points into Flow Records.
2. 観測ポイントで観察されたパケットをフローレコードにエンコードします。
3. Packetises the selected Templates and Flow Records into IPFIX Messages.
3. 選択したテンプレートとフローレコードをipfixメッセージにパケット化します。
4. Sends IPFIX Messages to the Collector.
4. 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]を参照してください。
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 [2]のIPFIX情報モデルで定義されています。
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.
情報モデルは、すべてのIPFIX情報要素のプロパティの完全な説明を提供します。これは、各要素の名前、フィールドタイプ、データタイプなどを指定し、各要素の説明を提供することにより、これを行います。要素の説明は、要素のセマンティクス、つまり、IPFIXデバイス内で利用可能なフローまたはその他の情報からどのように導き出されるかを示します。
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 5101 [3]で規定されているエンコーディング基準に基づいて、特定の情報要素（RFC 5102 [2]で指定されている）をコードします。
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 収集プロセスがIPFIXデバイスによってエクスポートされる各フローレコードの対応するフローデータの構造とセマンティクスをキャプチャできるように、フローごとの制御情報をエンコードする必要があります。
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.
o 構成制御情報はコレクターに伝えられ、その収集プロセスが対応する構成データの構造とセマンティクスをキャプチャできるようにします。制御情報でもある構成データは、構成が有効になっている観測ドメインに関する追加情報を伝達する必要があります。
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.
たとえば、同じサンプリングアルゴリズムを使用したサンプリング、たとえば100個のパケットの1つを使用して、2つの観測点O1とO2で構成されています。この場合の構成は、{ID、観測ポイント（O1、O2）、サンプリングアルゴリズム、間隔（100）}}としてエンコードできます。ここで、IDはO1とO2を含むドメインの観測ドメインIDです。観測ドメインIDは、この構成を一意に識別し、適切な構成制御情報を一致させるためにフローレコード内で送信する必要があります。
The Control Information is used by the Collecting Process to:
コントロール情報は、収集プロセスによって以下に使用されます。
o Decode and interpret Flow Records.
o フローレコードをデコードして解釈します。
o Understand the state of the Exporting Process.
o 輸出プロセスの状態を理解します。
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:
エクスポートプロセスから制御情報をタイムリーで信頼できる方法で送信することは、IPFIX収集プロセスの適切な機能に不可欠です。制御情報の輸出については、次のアプローチをとることができます。
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.
1. フローレコードを送信する前に、フローレコードに関するすべての制御情報を送信します。これには、フローレコードの定義に対する増分変更が含まれます。
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.
2. ほぼリアルタイムベースで、IPFIXデバイスの状態を収集プロセスに通知します。これには、流れの動作に影響する構成変更、エクスポートレートを変更するプロセスリソースのエクスポートの変更など、コレクターが認識する必要があるすべての変更が含まれます。
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.
3. 収集プロセスが輸出国の状態の正確な知識を維持することが重要であるため、コレクターに確実に到達するように、制御情報の輸出を行う必要があります。これを達成する1つの方法は、信頼できる輸送に関する制御情報を送信することです。
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.
IPFIXデバイスは、観測点の1つに到達するすべてのパケットを観察できない場合があります。これは、計量プロセスが一時的にリソースに足りないことを発見した場合に発生する可能性があります。たとえば、IPFIXエクスポート用のパケットバッファーがなくなる可能性があります。
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.
このような状況では、IPFIXデバイスは、発生したパケット損失の数をカウントし、コレクターに報告しようとする必要があります。損失を正確に数えることができない場合、たとえば、輸送層（つまり、非IPFIX）エラーが検出された場合、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アーキテクチャに正確に適合します。
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プロトコルの基礎として候補者の1つを選択しました。評価プロセスの詳細については、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 テンプレートメカニズムを使用して、エクスポートレコード形式の構造を変更せずに、新しいフィールドをIPFIXフローレコードに追加できます。
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 収集プロセスに送信されるテンプレートには、エクスポートされたフローレコードフィールドに関する構造情報が含まれます。したがって、コレクターが新しいフィールドのセマンティクスを理解していない場合、それらを無視することができますが、それでもフローレコードを解釈します。
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.
o テンプレートメカニズムは柔軟であるため、フローから収集プロセスへの必要なフィールドのみをエクスポートできます。これにより、エクスポートされたフローデータ量を減らし、エクスポートプロセスと収集プロセスでメモリの節約を提供する可能性があります。必要な情報のみを送信すると、ネットワークの負荷も減らすことができます。
The Collecting Process is responsible for:
収集プロセスは次の責任を負います。
1. Receiving and decoding Flow Records from the IPFIX Devices.
1. IPFIXデバイスからフローレコードを受信およびデコードします。
2. Reporting on the loss of Flow Records sent to the Collecting Process by an IPFIX Exporting Process.
2. IPFIXエクスポートプロセスによって収集プロセスに送信されたフロー記録の損失に関する報告。
Complete details of the IPFIX protocol are given in RFC 5101 [3].
IPFIXプロトコルの完全な詳細は、RFC 5101 [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システムとインターフェイスして目的の情報を取得する方法は、このドキュメントの範囲外です。
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.
IPFIXデバイスと収集プロセスが配置されているネットワークが信頼性を保証しない場合、少なくとも制御情報を信頼できる輸送でエクスポートする必要があります。データストリームは、信頼性の高いまたは信頼性の低いトランスポートプロトコルでエクスポートされる場合があります。
Possible transport protocols include:
可能な輸送プロトコルは次のとおりです。
o SCTP: Supports reliable and unreliable transport.
o SCTP：信頼性が高く信頼できない輸送をサポートします。
o TCP: Provides reliable transport only.
o TCP：信頼できる輸送のみを提供します。
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.
o UDP：信頼できない輸送のみを提供します。ネットワークオペレーターは、自分の管理ドメイン内にトラフィックを維持することにより、混雑を避ける必要があります。たとえば、専用のネットワーク（またはイーサネットリンク）を使用して、輸出業者からコレクターにIPFIXトラフィックを運ぶことができます。
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.
接続すると、IPFIXコレクターは制御情報を受信し、その情報を使用してフローレコードを解釈します。IPFIXデバイスは、コレクターの故障を迅速に検出できるように、KeepAlive（たとえば、TCPの場合はTCPの場合のハートビート間隔）を十分に低い値に設定する必要があります。ただし、非常に短いキープアライブ間隔は、過渡期間中に接続を誤って中止する可能性があることに注意してください。また、アイドル期間中にある程度の追加のネットワーク負荷を引き起こす可能性があります。
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.
コレクターの故障とは、収集プロセスまたはコレクター自体のクラッシュまたは再起動を指します。IPFIXデバイスでは、接続指向のトランスポートプロトコルセッションの破損により、コレクターの故障が検出されます。輸送プロトコルによっては、接続タイムアウトメカニズムが異なります。単一のコレクターシナリオでKeepAlive Timeoutを検出すると、IPFIXデバイスはコレクターにフローレコードの送信を停止し、輸送接続を再確立しようとする必要があります。プロセスの収集フェールオーバーがエクスポートプロセスによってサポートされている場合、バックアップセッションが事前に開かれ、制御情報がフェールオーバー収集プロセスに送信される場合があります。
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.
優先順位が割り当てられた1つ以上のセカンダリコレクターがいる可能性があります。プライマリコレクターのクラッシュは、IPFIXデバイスで検出されます。接続性の損失を検出すると、IPFIXデバイスは、次に最優先事項のセカンダリコレクターを備えたデータストリームを開きます。そのセカンダリが事前に開かれていない場合、制御情報とデータストリームの両方を送信する必要があります。そのコレクターがプライマリになるか、エクスポートプロセスが元のセッションを再確立しようとする可能性があります。
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プロトコルにはうっ血を意識する輸送が必要なため、マルチキャストを使用して冗長性を達成することはオプションではありません。
An IPFIX Device can generate, receive, and/or alter two special types of traffic, which are listed below.
IPFIXデバイスは、2つの特別なタイプのトラフィックを生成、受信、および/または変更できます。これらは以下にリストされています。
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デバイスは、一般的なルーティングカプセル化（GRE）[8]、IPINIP [7]、または2つのトンネリングプロトコルバージョン3 [9]トラフィックを処理している可能性があります。
VPN traffic:
VPNトラフィック：
The IPFIX Device could be a provider-edge device that receives traffic from customer sites belonging to different Virtual Private Networks.
IPFIXデバイスは、さまざまな仮想プライベートネットワークに属する顧客サイトからトラフィックを受信するプロバイダーエッジデバイスである可能性があります。
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.
同様に、IPFIXは、次の特別なサービスの1つ以上を実行するデバイスに実装できます。O明示的にドロップパケット。たとえば、ファイアウォールサービスを提供するデバイスは、管理ポリシーに基づいてパケットをドロップします。
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.
o 関心のあるIPFIXフローキーとして使用されるフィールドの値を変更します。たとえば、NATサービスを提供するデバイスは、ソースおよび/または宛先IPアドレスを変更できます。
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 IPFIXデバイスのフローとしてパケットを分類する方法と時期。
o If multiple encapsulations are used to define Flows, how to convey the same fields (e.g., IP address) in different layers.
o 複数のカプセルがフローを定義するために使用される場合、異なる層で同じフィールド（IPアドレスなど）を伝える方法。
o How to differentiate Flows based on different private domains. For example, overlapping IP addresses in Layer-3 VPNs.
o さまざまなプライベートドメインに基づいてフローを区別する方法。たとえば、レイヤー-3 VPNのIPアドレスの重複。
o What extra information needs to be exported so that the Collector can make a clear interpretation of the received Flow Records.
o コレクターが受信したフロー記録の明確な解釈を作成できるように、追加の情報をエクスポートする必要があります。
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.
フロー情報は、使用量ベースの会計、トラフィックプロファイリング、トラフィックエンジニアリング、侵入検知など、さまざまな目的に使用できます。セキュリティ要件は、このようなアプリケーションで大きく異なる場合があります。さまざまなIPFIXユーザーのセキュリティニーズを満たすためには、IPFIXシステムはさまざまなレベルのセキュリティ保護を提供する必要があります。
IPFIX data comprises Control Information and Data Streams generated by the IPFIX Device.
IPFIXデータは、IPFIXデバイスによって生成された制御情報とデータストリームで構成されています。
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.
IPFIXデータは、IPFIXデバイスとコレクターの両方に存在する場合があります。さらに、データは、IPFIXデバイスからコレクターがエクスポートされたときにワイヤ上に転送されます。セキュリティを提供するには、データを一般的なネットワーク攻撃から保護する必要があります。
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.
このドキュメントのエンドシステム（IPFIXデバイスとコレクター）内のIPFIXデータの保護は範囲外です。最終システム演算子は、IPFIXデータに適切なセキュリティを提供すると想定されています。
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.
IPFIXアーキテクチャは、ワイヤー上のIPFIXデータに対してさまざまなレベルの保護を許可する必要があります。セキュリティ機能が必要な場合は、IPFIXデータ保護のセキュリティ要件を正常に満たすことができる場合は、ユーザーがTLSまたはDTLS（データグラムトランスポートレイヤーセキュリティ）を使用して低レイヤーを活用することをお勧めします。
To protect the data on the wire, three levels of granularity should be supported; these are described in the following subsections.
ワイヤー上のデータを保護するには、3つのレベルの粒度をサポートする必要があります。これらは、次のサブセクションで説明されています。
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.
IPFIXデバイスとコレクター間の輸送が安全であると認識されている場合、セキュリティは必要ない場合があります。このオプションにより、プロトコルは余分なオーバーヘッドなしで最も効率的に実行でき、IPFIXシステムはそれをサポートする必要があります。
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 セキュリティペイロードのカプセル化（null暗号化アルゴリズム付き）
o Transport Layer Security (with a null encryption algorithm)
o 輸送層のセキュリティ（ヌル暗号化アルゴリズムを使用）
o IP Authentication Header
o IP認証ヘッダー
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 セキュリティペイロードのカプセル化
o Transport Layer Security Protocol
o トランスポートレイヤーセキュリティプロトコル
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.
データ暗号化オプションは、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.
IPFIXデバイスが、仮面舞台のコレクターではなく「正しい」コレクターと話していることを確認することが重要です。同じロジックは、コレクターの観点からも当てはまります。つまり、「正しい」IPFIXデバイスからフローレコードを収集していることを確認することができます。IPFIXシステムは、IPFIXデバイスとコレクター間で一方向または相互認証を実行できるように、エンドポイント認証機能を可能にする必要があります。
The IPFIX architecture should use any existing transport protection protocols, such as TLS, to fulfil the authentication requirement.
IPFIXアーキテクチャは、TLSなどの既存の輸送保護プロトコルを使用して、認証要件を満たす必要があります。
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デバイスは、さまざまな条件下で過負荷になる可能性があります。これは、流れの生成や輸出に使用される内部リソースの疲労が原因である可能性があります。このような過負荷は、エクスポート帯域幅の不足（おそらく異常に多くの観測されたフローによって引き起こされる）または輸出業者からコレクターへのパスのネットワーク輻輳からのデータの損失を引き起こす可能性があります。
IPFIX Collectors should be able to detect the loss of exported Flow Records, and should at least record the number of lost Flow Records.
IPFIXコレクターは、エクスポートされたフロー記録の損失を検出できるはずであり、少なくとも失われたフロー記録の数を記録する必要があります。
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の潜在的な使用法の1つは侵入検知のためであるため、IPFIXアーキテクチャが何らかのDOS抵抗をサポートすることが重要です。
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システムが過負荷になる場合があります。
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固有ではありません。このようなタイプの攻撃の防止と対応は、このドキュメントの範囲外です。
There are some specific attacks on the IPFIX portion of the IPFIX Device or Collector:
IPFIXデバイスまたはコレクターのIPFIX部分にいくつかの特定の攻撃があります。
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 攻撃者は、スプーフィングされたIPFIXエクスポートパケットでコレクターを圧倒する可能性があります。この問題を解決する1つの方法は、エクスポートと収集プロセスの間のフローレコードのシーケンス番号を定期的に同期することです。
o The attacker could provide false reports to the Collector by sending spoofed packets.
o 攻撃者は、スプーフィングされたパケットを送信することにより、コレクターに誤ったレポートを提供できます。
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.
上記の問題は、コントロールパケットが両方の方法で暗号化されている場合、大部分は解決できます。これにより、コレクターがスプーフィングされたデータパケットを識別および無視するために使用できるより多くの情報を提供します。
The IPFIX Architecture, as set out in this document, has two sets of assigned numbers, as outlined in the following subsections.
このドキュメントに記載されているIPFixアーキテクチャには、次のサブセクションで概説されているように、2セットの割り当てられた番号があります。
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.
RFC 5101 [3]で説明されているIPFIXメッセージは、値が割り当てられた2つのフィールドを使用します。これらはIPFIXバージョン番号であり、IPFIXプロトコルのバージョンがIPFIXメッセージをエクスポートするために使用されたか、IPFIXセットIDを示し、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の値と、それらを割り当てるための考慮事項は、RFC 5101 [3]で定義されています。
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].
IPFIX情報要素IDの値は、それらを割り当てるための考慮事項とともに、RFC 5102 [2]で定義されています。
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
Tanja Zseby Paul Calato Dave Plonka Jeffrey Meyer K.C.Norseth Vamsi Valluri Cliff Wang Ram Gopal JC Martin Cartin Bullard Reinaldo Penno Simon Leinen Kevin Zhang Paul Aitken Brian Trammell
Special thanks to Dave Plonka for the multiple thorough reviews.
複数の徹底的なレビューをしてくれたDave Plonkaに感謝します。
[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. Zander、「IP Flow Information Export（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.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「モデル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.、Boschi、E.、Brownlee、N。、およびB. Claise、「Ipfix Applicability」、RFC 5472、2009年3月。
[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.、Frederick、R。、およびV. Jacobson、「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。、「IPフロー情報エクスポート（IPFIX）の候補プロトコルの評価」、RFC 3955、2004年10月。
[7] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
[7] Simpson、W。、「IP In IP Tunneling」、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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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] Lau、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
Ganesh Sadasivan Rohati Systems 1192 Borregas Ave. Sunnyvale、CA 94089 USA
EMail: gsadasiv@rohati.com
Nevil Brownlee CAIDA | The University of Auckland Private Bag 92019 Auckland 1142 New Zealand
ネビル・ブラウンリー・カイダ|オークランド大学プライベートバッグ92019オークランド1142ニュージーランド
Phone: +64 9 373 7599 x88941
EMail: n.brownlee@auckland.ac.nz
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise Cisco Systems、Inc。De Kleetlaan 6a B1 1831 Diegem Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Juergen Quittek NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany
Juergen Quittek Nec Laboratories Europe、Nec Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115ドイツ
Phone: +49 6221 4342-115
EMail: quittek@nw.neclab.eu
URI: http://www.neclab.eu/