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
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 (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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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.
フローベースのIPトラフィックの測定を必要といくつかのアプリケーション、例えば、使用量ベースのアカウンティング、トラフィックプロファイリング、トラフィックエンジニアリング、攻撃/侵入検知、サービス品質（QoS）の監視があります。 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フロー情報へのアクセスをネットワーク管理者に提供します。この文書では、[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.
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 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:
フローは、特定の時間間隔の間、ネットワーク内の観測点を通過する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.一つ以上のパケットヘッダフィールド（例えば、宛先IPアドレス）、トランスポートヘッダフィールド（例えば、宛先ポート番号）、またはアプリケーションヘッダフィールド（例えば、RTPヘッダフィールド[5]）。
2. one or more characteristics of the packet itself (e.g., number of MPLS labels)
パケット自体の2.一つ以上の特性（例えば、MPLSラベルの数）
3. one or more fields derived from packet treatment (e.g., next hop IP address, output interface)
パケット処理に由来する前記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
*フローキー
Each of the fields that:
そのフィールドの各：
3. is derived from packet treatment (e.g., Autonomous System (AS) number), and
3.パケット処理（例えば、自律システム（AS）番号）から導出され、そして
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.
エクスポートプロセスは、一の以上の収集プロセスにフローレコードを送信します。フローレコードは、一つ以上の計量プロセスによって生成されます。
* 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.
IPFIXデバイスのホストは、少なくとも一つのエクスポートプロセス。さらに、エクスポートプロセスと観測ポイントと計量プロセスの任意の数をホストすることができます。
* 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.
テンプレートは、完全コレクタに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.
これは、エクスポートプロセスによって送信されたフロー内のパケット、およびエクスポートするデータを記述するテンプレートの選択基準をフロー定義を含みます。制御情報は、エンドポイントが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の例では、ホスト・インターフェース・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. {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. {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.
実施例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}.
4のDSCP値を持つ別の顧客ネットワーク192.0.2.64/26に顧客ネットワーク192.0.2.0/26から行くすべてのパケットは、フローを定義します。他のすべての組み合わせは、フローを定義しないと考慮されません。実施例2からの3つのフローは、現在フィルタリングによってつの流れに還元されるのみフロー1、{192.0.2.0/26、192.0.2.64/26、4}を残し、2及び3が流れます。
Similarly, for the IPv6 packets in the examples above, one could filter out Flows 5 and 6 to leave Flow 4.
同様に、上記実施例におけるIPv6パケットのために、一つはフロー4を残すようにフロー5,6を除外できました。
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:
上記の例は、入力{送信元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アドレス、192.0.2.0戦の最下位6ビットをマスク。
2. Mask out the least significant 6 bits of destination IP address, match against 192.0.2.64.
2.宛先IPアドレスの最下位6ビット、192.0.2.64戦をマスク。
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.
IPFIXデバイス内のすべての観測ポイントは、流量測定に参加し、少なくとも1つの計量プロセスに関連しなければなりません。観察ポイントに入ってくるすべてのパケットを観察ポイントに関連付けられた計量プロセスのそれぞれに入ります。概して、各計量プロセスは、観測ポイントを通過するパケットを観測するタイムスタンプを行い、そして選択基準に基づいて、フロー（S）にパケットを分類します。
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。これは、新しいフローレコードを作成し、既存のものを更新し、フローレコードの統計情報を計算し、さらに流動特性を導出し、パケット処理（などの数字、ルータの状態、ASのようないくつかの例では、フィールド）に基づく非フロー固有の情報を追加することが含ま
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フィルタリング、等を選択することができることに留意されたい、又はこれらの工程の一つ以上の後。これは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}.
例：フィルタを定義するフィールドで/マッチマスク。フィルタは、{プロトコル== 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がエクスポート関数のパラメータとして送信する必要があることに注意してください。そのユニークな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コレクターにデータを送信する機能ブロックです。一方の側に、計量プロセス（ES）とエクスポートプロセスインタフェースは、フローレコードを取得します。反対側にいる間、それはコレクタ（複数可）上に収集プロセスと対話します。
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.他のすべての（すなわち、サンプリングレート2における1）宛先IPアドレス一致するフローレコード{192.0.11.30}。
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.
収集プロセスは、フローレコードの情報要素と解釈するフローレコードのテンプレート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.
、識別受け入れ、異なる<エクスポートプロセス、観測ドメイン>ペアからIPFIXメッセージを復号O。
o Storing the Control Information and Flow Records received from an IPFIX Device.
制御情報およびフローレコードを格納するoをIPFIXデバイスから受け取りました。
At a high level, the Collecting Process:
高いレベルで、収集プロセス：
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デバイスは、次のタスクを実行します。
2. Encodes packets observed at the Observation Points into Flow Records.
2.フローレコードへの観測点で観測されたパケットをエンコードします。
3. Packetises the selected Templates and Flow Records into IPFIX Messages.
3. Packetises選択テンプレートとフローレコード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に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.
情報モデルは、すべての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 5102で指定されるように[2]）エクスポートプロセス[3] RFC 5101で規定符号化規格に基づいて、所定の情報要素を符号化します。
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.
例えば、同じサンプリングアルゴリズムを使用してサンプリングし、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およびフローレコードを解釈します。
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プロトコルの基礎として、候補の一つを選択しました。評価プロセスの詳細については、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:
収集プロセスは責任があります：
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.
UDP O：唯一の信頼性のないトランスポートを提供します。ネットワークオペレータは、独自の管理ドメイン内のトラフィックを維持することによって輻輳を回避する必要があります。例えば、一つは輸出業者からのCollectorに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デバイスは、十分に低い値にキープアライブ（TCPの場合には、例えば、キープアライブタイムアウト、SCTPの場合のハートビート間隔）を設定すべきです。非常に短いキープアライブ間隔が間違って混雑の過渡期間中の接続を中止することができている、しかし、注意してください。彼らはまた、それ以外のアイドル期間中に追加のネットワーク負荷のいくつかのレベルを引き起こす可能性があります。
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デバイスで検出されます。トランスポートプロトコルに応じて、接続タイムアウトメカニズムが異なります。単一コレクタのシナリオにキープアライブタイムアウトを検出すると、IPFIXデバイスは、Collectorにフローレコードの送信を停止し、トランスポート接続を再確立しようとする必要があります。収集処理のフェイルオーバーがエクスポートプロセスによってサポートされている場合、バックアップセッション（複数可）は、事前に開かれてもよく、制御情報は、フェイルオーバー収集プロセスに送られます。
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デバイスは、生成、受信、および/または以下に記載されているトラフィックの二つの特別なタイプを変更することができます。
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:
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
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データ転送にオーバーヘッドが追加されます。これは、輸出業者が原因暗号化を実行するためのリソース要件に、Collectorにそのフローレコードをレポートすることができますレートを制限することがあります。
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のための潜在的な使用法の一つは、侵入検知のためにあるので、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.
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で定義されています。
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]。
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.
複数の徹底的なレビューのためのデーブ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.ザンダー、 "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月。
[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それ
EMail: gsadasiv@rohati.com
メールアドレス：gsadasiv@rohati.com
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: n.brownlee@auckland.ac.nz
電話：+64 9 373 7599 x88941メール：n.brownlee@auckland.ac.nz
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
ブノワClaiseシスコシステムズ、株式会社デKleetlaan 6aはB1 1831ディーゲムベルギー
Phone: +32 2 704 5622 EMail: bclaise@cisco.com
電話：+32 2 704 5622 Eメール：bclaise@cisco.com
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: quittek@nw.neclab.eu URI: http://www.neclab.eu/
電話：+49 6221 4342-115電子メール：quittek@nw.neclab.eu URI：http://www.neclab.eu/