[要約] RFC 3955は、IP Flow情報のエクスポート（IPFIX）のための候補プロトコルの評価に関するものです。このRFCの目的は、IPFIXの実装に使用するプロトコルの選択を支援することです。
Network Working Group S. Leinen
Request for Comments: 3955 SWITCH
Category: Informational October 2004
Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)
IP フロー情報エクスポート (IPFIX) の候補プロトコルの評価
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) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
Abstract
概要
This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification.
この文書には、IPFIX ワーキング グループによって作成された要件文書に基づいた、IP フロー情報エクスポート (IPFIX) プロトコルの 5 つの候補プロトコルの評価が含まれています。プロトコルは特徴づけられ、幅広いカテゴリに分類され、特定の要件に照らして評価されます。最後に、IPFIX 仕様の基礎として NetFlow v9 プロトコルを選択することが推奨されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Summaries . . . . . . . . . . . . . . . . . . . . . . 2
2.1. CRANE. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Diameter . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. LFAP . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. NetFlow v9 . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Streaming IPDR . . . . . . . . . . . . . . . . . . . . . 6
3. Broad Classification of Candidate Protocols . . . . . . . . . 7
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Data Representation. . . . . . . . . . . . . . . . . . . 8
3.3. Protocol Flow. . . . . . . . . . . . . . . . . . . . . . 9
4. Item-Level Compliance Evaluation . . . . . . . . . . . . . . . 10
4.1. Meter Reliability (5.1). . . . . . . . . . . . . . . . . 10
4.2. Sampling (5.2) . . . . . . . . . . . . . . . . . . . . . 11
4.3. Overload Behavior (5.3). . . . . . . . . . . . . . . . . 12
4.4. Timestamps (5.4) . . . . . . . . . . . . . . . . . . . . 12
4.5. Time Synchronization (5.5) . . . . . . . . . . . . . . . 12
4.6. Flow Expiration (5.6). . . . . . . . . . . . . . . . . . 13
4.7. Ignore Port Copy (5.9) . . . . . . . . . . . . . . . . . 13
4.8. Information Model (6.1). . . . . . . . . . . . . . . . . 13
4.9. Data Model (6.2) . . . . . . . . . . . . . . . . . . . . 13
4.10. Data Transfer (6.3). . . . . . . . . . . . . . . . . . . 14
5. Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Recommendation . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix. A Note on References to the Candidate Protocol
Documents. . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 23
The IP Flow Information Export (IPFIX) Working Group has been chartered to select a protocol for the export of flow information from traffic-observing devices (such as routers or dedicated probes). To this end, an evaluation team was formed to evaluate submitted protocols. Each protocol was represented by an advocate, who submitted a specific evaluation document for the respective protocol against the requirements document [1]. The specification of each protocol was itself available as one or several Internet-Drafts, sometimes referring normatively to documents from outside the IETF.
IP フロー情報エクスポート (IPFIX) ワーキング グループは、トラフィック監視デバイス (ルーターや専用プローブなど) からフロー情報をエクスポートするためのプロトコルを選択するために設立されました。この目的を達成するために、提出されたプロトコルを評価する評価チームが結成されました。各プロトコルは提唱者によって代表され、要件文書 [1] に対して各プロトコルの特定の評価文書を提出しました。各プロトコルの仕様自体は、1 つまたは複数のインターネット ドラフトとして入手可能であり、場合によっては IETF 外部の文書を規範的に参照しています。
This document contains an evaluation of the submitted protocols with respect to the requirements document, and on a more general level, to the working group charter.
この文書には、要件文書、およびより一般的なレベルでの作業グループ憲章に関して、提出されたプロトコルの評価が含まれています。
The following IPFIX candidate protocol submissions were evaluated:
次の IPFIX 候補プロトコルの提出が評価されました。
o CRANE [7], [8] o Diameter [9], [10] o LFAP [11], [12], [13] o NetFlow v9 [2], [15], [16] o Streaming IPDR [17], [18]
o CRANE [7]、[8] o 直径 [9]、[10] o LFAP [11]、[12]、[13] o NetFlow v9 [2]、[15]、[16] o ストリーミング IPDR [17]、[18]
This document uses terminology defined in [1] intermixed with that from submissions to explain the mapping between the two.
この文書では、[1] で定義された用語と提出された用語を混ぜて使用し、この 2 つの間のマッピングを説明します。
In the following, each candidate protocol is described briefly, highlighting its specific distinguishing features.
以下では、各候補プロトコルについて簡単に説明し、その特有の特徴を強調します。
XACCT's Common Reliable Accounting for Network Element Protocol Version 1.0 [7][8] is described as a protocol for the transmission of accounting information from "Network Elements" to "mediation" and "business support systems".
XACCT の Common Reliable Accounting for Network Element Protocol バージョン 1.0 [7][8] は、「ネットワーク要素」から「仲介」および「ビジネス サポート システム」へのアカウンティング情報の送信のためのプロトコルとして説明されています。
The exporting side is the CRANE client, the collecting side is the CRANE server. Note that it is the server that is responsible for initiating the connection to the client. A client can have multiple simultaneous connections to different servers for robustness. Each server has an associated priority. A client only exports to the server with the highest priority that is perceived operational.
エクスポート側は CRANE クライアント、収集側は CRANE サーバーです。クライアントへの接続を開始するのはサーバーであることに注意してください。クライアントは、堅牢性を高めるために、異なるサーバーに複数の同時接続を行うことができます。各サーバーには優先順位が関連付けられています。クライアントは、動作していると認識される最高の優先順位を持つサーバーにのみエクスポートします。
Clients and servers exchange messages over a reliable protocol such as TCP [3] or (preferably) the Stream Control Transmission Protocol (SCTP) [5]. The protocol uses application-layer acknowledgements as an indication of successful processing by the server. Strong authentication or data confidentiality aren't supported by the protocol, but can be supported by lower-layer mechanisms such as IPsec [20] or TLS [21].
クライアントとサーバーは、TCP [3] または (できれば) Stream Control Transmission Protocol (SCTP) [5] などの信頼できるプロトコルを介してメッセージを交換します。このプロトコルは、サーバーによる処理の成功を示すものとしてアプリケーション層の確認応答を使用します。強力な認証やデータの機密性はこのプロトコルではサポートされていませんが、IPsec [20] や TLS [21] などの下位層メカニズムではサポートできます。
The protocol is bidirectional over the entire duration of a session. There are 20 different message types. The protocol supports template negotiation, not only at startup but also later on in a session, as well as general status inquiries. There is a separate version negotiation protocol defined over UDP.
このプロトコルは、セッションの全期間にわたって双方向です。20 種類のメッセージ タイプがあります。このプロトコルは、起動時だけでなくセッション後のテンプレート ネゴシエーションや、一般的なステータスの問い合わせもサポートしています。UDP 上で定義された別のバージョンのネゴシエーション プロトコルがあります。
Data encoding is based on templates. Templates contain "keys" representing items in data records. Clients (exporters) publish templates to servers (collectors). Servers can then select the subset of fields in a template that they are interested in. The client will suppress keys that haven't been selected by the server.
データのエンコードはテンプレートに基づいて行われます。テンプレートには、データ レコード内の項目を表す「キー」が含まれています。クライアント (エクスポーター) はテンプレートをサーバー (コレクター) に公開します。その後、サーバーは、関心のあるテンプレート内のフィールドのサブセットを選択できます。クライアントは、サーバーによって選択されていないキーを抑制します。
Data records contain references to template and configuration instances. They also carry sequence numbers (DSNs for Data Sequence Numbers). These sequence numbers can be used to de-duplicate data records that have been delivered multiple times during failover/fail-back in redundant configurations. A "duplicate" bit is set in these situations as a hint for the de-duplication process.
データ レコードには、テンプレートと構成インスタンスへの参照が含まれています。また、シーケンス番号 (データ シーケンス番号の DSN) も保持します。これらのシーケンス番号を使用して、冗長構成でのフェイルオーバー/フェイルバック中に複数回配信されたデータ レコードの重複を排除できます。このような状況では、重複排除プロセスのヒントとして「重複」ビットが設定されます。
The encoding of (flow information) data records themselves is very compact. The client (exporter) can choose to send data in big-endian (network byte order) or little-endian format. There are eighteen fixed-size key types, as well as five variable-length string and binary data (BLOB) types.
(フロー情報) データ レコード自体のエンコードは非常にコンパクトです。クライアント (エクスポーター) は、データをビッグ エンディアン (ネットワーク バイト オーダー) 形式で送信するか、リトル エンディアン形式で送信するかを選択できます。18 個の固定サイズのキー タイプと、5 個の可変長文字列およびバイナリ データ (BLOB) タイプがあります。
Diameter [9][10] is an evolution of the Remote Authentication Dial In User Service (RADIUS) protocol [22]. RADIUS is widely used to outsource authentication and authorization in dialup access environments. Diameter is a generalized and extensible protocol intended to support Authentication, Authorization and Accounting (AAA) requirements of different applications. Dialup and Mobile IPv4 are examples of such applications defined in the IETF.
Diameter [9][10] は、Remote Authentication Dial In User Service (RADIUS) プロトコル [22] の進化版です。RADIUS は、ダイヤルアップ アクセス環境での認証と認可をアウトソーシングするために広く使用されています。Diameter は、さまざまなアプリケーションの認証、認可、およびアカウンティング (AAA) 要件をサポートすることを目的とした、汎用化された拡張可能なプロトコルです。ダイヤルアップとモバイル IPv4 は、IETF で定義されているこのようなアプリケーションの例です。
Diameter is a peer-to-peer protocol. The base protocol defines fourteen command codes, organized as seven request/response command pairs. Presumably, only a subset of these would be used in a pure IPFIX application. Diameter includes capability negotiation and error notifications. Diameter operates over TCP or (preferred) SCTP. There is a framework for end-to-end security, the mechanisms for which are defined in a separate document. IPsec or TLS can be used to provide authentication or encryption at the underlying layers.
Diameter はピアツーピア プロトコルです。基本プロトコルは、7 つの要求/応答コマンド ペアとして編成された 14 個のコマンド コードを定義します。おそらく、純粋な IPFIX アプリケーションでは、これらのサブセットのみが使用されます。Diameter には、機能ネゴシエーションとエラー通知が含まれます。Diameter は、TCP または (推奨) SCTP 上で動作します。エンドツーエンドのセキュリティのためのフレームワークがあり、そのメカニズムは別のドキュメントで定義されています。IPsec または TLS を使用して、基礎となる層で認証または暗号化を行うことができます。
Diameter conveys data in the form of attribute/value pairs (AVPs). An AVP consists of eight bytes of header plus the space to store the data, which depends on the data format. There are numerous predefined AVP data formats, including signed and unsigned integer types, each in 32 and 64 bit variants, IPv4 and IPv6 addresses, as well as others. The advocacy document [10] suggests that the predefined data formats IPFilterRule and/or QoSFilterRule could be extended to represent IP Flow Information. Such rules are represented as readable UTF-8 strings. Alternatively, new AVPs could be defined to represent flow information.
Diameter は、属性/値ペア (AVP) の形式でデータを伝達します。AVP は、8 バイトのヘッダーと、データを保存するためのスペースで構成されます。これはデータ形式に応じて異なります。AVP データ形式には、それぞれ 32 ビットと 64 ビットの符号付き整数型と符号なし整数型、IPv4 アドレスと IPv6 アドレスなどを含む多数の定義済みデータ形式があります。擁護文書 [10] は、事前定義されたデータ形式 IPFilterRule および/または QoSFilterRule を拡張して IP フロー情報を表すことができることを示唆しています。このようなルールは、読み取り可能な UTF-8 文字列として表されます。あるいは、フロー情報を表すために新しい AVP を定義することもできます。
LFAP [11][12][13] started out as the "Lightweight Flow Admission Protocol" and was used to outsource shortcut creation decisions on flow-based routers, as well as to provide per-flow statistics. Later versions removed the admission function and changed the name to "Lightweight Flow Accounting Protocol".
LFAP [11][12][13] は、「軽量フロー アドミッション プロトコル」として始まり、フローベースのルーターでのショートカット作成の決定をアウトソーシングし、フローごとの統計を提供するために使用されました。後のバージョンではアドミッション機能が削除され、名前が「Lightweight Flow Accounting Protocol」に変更されました。
The exporter in LFAP is called the Connection Control Entity (CCE), and the collector is the Flow Accounting Server (FAS). These entities communicate with each other over a TCP connection. LFAP knows thirteen message types, including operations for connection management, version negotiation, flow information messages and administrative requests. Authentication and encryption can be provided by IPsec or TLS at lower layers. Additionally, the LFAP protocol itself supports four levels of security using HMAC-MD5 authentication and DES-CBC encryption. Note that DES is now widely regarded as not adequately secure, because its small key size makes brute-force attacks viable.
LFAP のエクスポーターは接続制御エンティティ (CCE) と呼ばれ、コレクターはフロー アカウンティング サーバー (FAS) です。これらのエンティティは、TCP 接続を介して相互に通信します。LFAP は、接続管理、バージョン ネゴシエーション、フロー情報メッセージ、管理要求の操作を含む 13 のメッセージ タイプを認識します。認証と暗号化は、下位層の IPsec または TLS によって提供できます。さらに、LFAP プロトコル自体は、HMAC-MD5 認証と DES-CBC 暗号化を使用した 4 つのレベルのセキュリティをサポートしています。DES は、キー サイズが小さいため、ブルート フォース攻撃が可能になるため、現在では十分に安全ではないと広く考えられていることに注意してください。
A distinguishing feature is that LFAP has two different message types for flow information: A Flow Accounting Request (FAR) message is sent when a new flow is identified at the CCE (meter/exporter). Accounting information is sent later in one or multiple Flow Update Notification (FUN) messages. A collector must match each FUN to a Flow ID previously sent in a FAR.
際立った機能は、LFAP にはフロー情報に関して 2 つの異なるメッセージ タイプがあることです。 Flow Accounting Request (FAR) メッセージは、新しいフローが CCE (メーター/エクスポーター) で識別されると送信されます。アカウンティング情報は、1 つまたは複数のフロー更新通知 (FUN) メッセージで後で送信されます。コレクターは、各 FUN を FAR で以前に送信されたフロー ID と照合する必要があります。
The LFAP document also defines a set of useful statistics about the accounting process. A separate MIB document [14] is provided for management of LFAP entities using SNMP.
LFAP 文書では、会計プロセスに関する一連の有用な統計も定義されています。SNMP を使用した LFAP エンティティの管理には、別個の MIB ドキュメント [14] が提供されています。
LFAP encodes data in a Type/Length/Value format with four bytes of overhead per data item (two bytes for the type and two bytes for the length field).
LFAP は、データ項目ごとに 4 バイトのオーバーヘッド (タイプに 2 バイト、長さフィールドに 2 バイト) を使用して、タイプ/長さ/値形式でデータをエンコードします。
NetFlow v9 [2][15] is a generalized version of Cisco's NetFlow protocol. Previous versions of NetFlow, in particular version 5, have been widely implemented and used for the exporting and collecting of IP flow information.
NetFlow v9 [2][15] は、Cisco の NetFlow プロトコルの汎用バージョンです。NetFlow の以前のバージョン、特にバージョン 5 は広く実装され、IP フロー情報のエクスポートと収集に使用されてきました。
NetFlow uses a very simple protocol, with the exporter sending template, options, and data "FlowSets" to the collector. FlowSets are sequences of data records of similar format. NetFlow is the only one of the candidate protocols that works over UDP [4]. Because of the simple unidirectional nature of the protocol, it should be relatively straightforward to add mappings to other transport protocols such as SCTP or TCP.
NetFlow は非常に単純なプロトコルを使用し、エクスポータがテンプレート、オプション、データ「FlowSet」をコレクタに送信します。フローセットは、同様の形式のデータ レコードのシーケンスです。NetFlow は、候補プロトコルの中で UDP 上で動作する唯一のプロトコルです [4]。このプロトコルは単純な一方向性であるため、SCTP や TCP などの他のトランスポート プロトコルにマッピングを追加するのは比較的簡単です。
The use of SCTP to transport NetFlow v9 has been suggested in [16]. The suggested mapping describes how control and data can be mapped to different streams within a single SCTP connection, and suggests that the Partial Reliability extension [23] be used on data streams. In the proposed mapping, the exporter would initiate the connection.
NetFlow v9 を転送するために SCTP を使用することは、[16] で提案されています。提案されたマッピングは、単一の SCTP 接続内の異なるストリームに制御とデータをどのようにマッピングできるかを説明し、部分信頼性拡張 [23] をデータ ストリームで使用することを提案しています。提案されたマッピングでは、エクスポーターが接続を開始します。
NetFlow v9 uses a template facility to describe exported data. The data itself is represented in a compact way using network byte order.
NetFlow v9 は、テンプレート機能を使用してエクスポートされたデータを記述します。データ自体は、ネットワーク バイト オーダーを使用してコンパクトな方法で表現されます。
Streaming IPDR [17][18] is an application of the Network Data Management-Usage (NDM-U) for IP Services specification version 3.1 [19]. It has been developed by the Internet Protocol Detail Record Organization (IPDR, Inc. or ipdr.org). The terminology used is similar to CRANE's, talking about Service Elements (SEs), mediation systems and Business Support Systems (BSS).
ストリーミング IPDR [17][18] は、IP サービス仕様バージョン 3.1 [19] のネットワーク データ管理使用法 (NDM-U) のアプリケーションです。これは、Internet Protocol Detail Record Organization (IPDR, Inc. または ipdr.org) によって開発されました。使用される用語は CRANE のものと似ており、サービス要素 (SE)、仲介システム、ビジネス サポート システム (BSS) について話しています。
Streaming IPDR operates over TCP. There is a "Trivial TCP Delivery" mode as well as an "Acknowledged TCP Delivery" or "Reliable Streaming" mode. The latter uses application-layer acknowledgements for increased reliability.
ストリーミング IPDR は TCP 上で動作します。「Trivial TCP Delivery」モードと、「Acknowledged TCP Delivery」または「Reliable Streaming」モードがあります。後者は、信頼性を高めるためにアプリケーション層の確認応答を使用します。
The protocol is basically unidirectional. The exporter opens a connection towards the collector, then sends a header followed by a set of record descriptors. Then it can send "Usage Event" records corresponding to these descriptors until the connection is terminated. New record descriptors can be sent at any time. Messages carry sequence numbers that are used for de-duplication during failover. They are also referenced by application-level acknowledgements when Reliable Streaming is used.
プロトコルは基本的に一方向です。エクスポータはコレクタへの接続を開き、ヘッダーとその後に一連のレコード記述子を送信します。その後、接続が終了するまで、これらの記述子に対応する「使用状況イベント」レコードを送信できます。新しいレコード記述子はいつでも送信できます。メッセージには、フェイルオーバー中の重複排除に使用されるシーケンス番号が含まれています。これらは、Reliable Streaming が使用されている場合、アプリケーション レベルの確認応答によっても参照されます。
IPDR uses an information modeling technique based on the XML-Schema language [24]. Data can be represented in XML or in a streamlined encoding based on the External Data Representation [25]. XDR forms the basis of Sun's Remote Procedure Call and Network File System protocols, and has proven to be both space- and processing-efficient.
IPDR は、XML スキーマ言語 [24] に基づいた情報モデリング技術を使用します。データは、XML または外部データ表現 [25] に基づいた合理化されたエンコーディングで表現できます。XDR は、Sun のリモート プロシージャ コールおよびネットワーク ファイル システム プロトコルの基礎を形成しており、スペース効率と処理効率の両方が高いことが証明されています。
In order to evaluate the candidate protocols against the higher-level requirements laid out in the IPFIX Working Group charter, it is useful to group them into broader categories.
IPFIX ワーキング グループ憲章に規定されている上位レベルの要件に照らして候補プロトコルを評価するには、プロトコルをより広いカテゴリにグループ化すると便利です。
One way to look at the candidate protocols is to study the goals that have directed their respective design. Note that the intention is not to exclude protocols that have been designed with a different class of applications in mind, but simply to better understand the different tradeoffs that distinguish the protocols.
候補プロトコルを検討する 1 つの方法は、それぞれの設計を方向づけた目標を研究することです。目的は、異なるクラスのアプリケーションを念頭に置いて設計されたプロトコルを除外することではなく、単にプロトコルを区別するさまざまなトレードオフをよりよく理解することであることに注意してください。
Of the candidate protocols, Cisco's NetFlow is the purest example of a highly specialized protocol that has been designed with the sole objective of conveying accounting data from flow-aware routers at high rates. Starting from a fixed set of accounting fields, it has been extended a few times over the years to support additional fields and various types of aggregation in the metering/exporting process.
候補プロトコルの中で、Cisco の NetFlow は、フロー対応ルータからアカウンティング データを高速で伝送するという唯一の目的を持って設計された高度に特殊化されたプロトコルの最も純粋な例です。会計フィールドの固定セットから始まり、計測/エクスポート プロセスでの追加フィールドやさまざまな種類の集計をサポートするために、長年にわたって数回拡張されてきました。
Riverstone's LFAP is similarly focused, except that it originated in a protocol to outsource the decision whether to create shortcuts in flow-based routers. This is still manifest in an increased emphasis on reliable operation, and in the split reporting of flow information using Flow Accounting Request (FAR) and Flow Update Notification (FUN) messages.
Riverstone の LFAP も同様に焦点を当てていますが、フローベースのルーターにショートカットを作成するかどうかの決定を外部委託するプロトコルに由来している点が異なります。このことは、信頼性の高い動作が重視されるようになり、フロー アカウンティング要求 (FAR) およびフロー更新通知 (FUN) メッセージを使用したフロー情報の分割レポートに依然として現れています。
It has been pointed out that split reporting as done by LFAP can reduce memory requirements at the exporter. This concerns a subset of attributes that are neither "key" attributes which define flows, nor attributes such as packet or byte counters that must be updated for each packet anyway. On the other hand, when there are many short-lived flows, the number of flow export messages will be significantly higher than with "unitary" flow export models, and the collector will have to keep state about active flows until they are terminated.
LFAP によって行われる分割レポートにより、エクスポータでのメモリ要件が軽減される可能性があることが指摘されています。これは、フローを定義する「キー」属性でも、パケットごとに更新する必要があるパケットやバイト カウンタなどの属性でもない、属性のサブセットに関係します。一方、存続期間の短いフローが多数ある場合、フロー エクスポート メッセージの数は「単一」フロー エクスポート モデルよりも大幅に多くなり、コレクターはアクティブなフローが終了するまでアクティブなフローに関する状態を保持する必要があります。
Streaming IPDR and CRANE describe themselves as protocols to facilitate the reliable transfer of accounting information between Network Elements (or more generally "Service Elements" in the case of IPDR) and Mediation Systems or Business Support Systems (BSS). They reflect a view of the accounting problem and of network system architectures that originates in traditional "vertically integrated" telecommunications.
ストリーミング IPDR および CRANE は、ネットワーク要素 (IPDR の場合はより一般的には「サービス要素」) と仲介システムまたはビジネス サポート システム (BSS) の間のアカウンティング情報の信頼できる転送を促進するプロトコルであると説明されています。これらは、会計問題と、従来の「垂直統合型」電気通信に由来するネットワーク システム アーキテクチャの見解を反映しています。
Both protocols also emphasize extensibility with the goal of applicability to a wide range of accounting tasks.
どちらのプロトコルも、幅広い会計タスクに適用できるようにすることを目的とした拡張性にも重点を置いています。
IPDR is based on NDM-U, which uses the XML-Schema language for machine-readable specification of accounting data structures, while using the efficient XDR encoding for the actual data transfer.
IPDR は NDM-U に基づいており、実際のデータ転送には効率的な XDR エンコーディングを使用しながら、会計データ構造の機械可読仕様に XML スキーマ言語を使用します。
CRANE uses templates to describe exported data. These templates are negotiated between collector and exporter and can change during a session.
CRANE は、テンプレートを使用してエクスポートされたデータを記述します。これらのテンプレートはコレクターとエクスポーターの間でネゴシエートされ、セッション中に変更される可能性があります。
Diameter is another example of a broader-purpose protocol, in that it covers aspects of authentication and authorization as well as accounting. This explains its strong emphasis on security and reliability. The design also takes into account various types of intermediate agents.
Diameter は、アカウンティングだけでなく認証と認可の側面をカバーするという点で、より広範な目的のプロトコルのもう 1 つの例です。これは、セキュリティと信頼性を強く重視していることを説明しています。設計では、さまざまなタイプの中間エージェントも考慮されています。
IPFIX is intended to be deployed, among others, in high-speed routers and to be used for exporting detailed flow data at high flow rates. Therefore it is useful to look at the tradeoffs between the efficiency of data representation and the extensibility of data models. The two main efficiency goals should be (1) to minimize the export data rate and (2) to minimize data encoding overhead in the exporter. The overhead of decoding flow data at the collector is deemed less critical, and is partly covered by efficiency target (2), since an encoding that is easy on the encoder is often also easy on the decoder.
IPFIX は、特に高速ルーターに導入され、高フロー レートで詳細なフロー データをエクスポートするために使用されることを目的としています。したがって、データ表現の効率とデータ モデルの拡張性の間のトレードオフを検討することが役立ちます。2 つの主な効率目標は、(1) エクスポート データ レートを最小限に抑えること、および (2) エクスポーターでのデータ エンコーディングのオーバーヘッドを最小限に抑えることです。エンコーダにとって容易なエンコードはデコーダにとっても容易であることが多いため、コレクタにおけるフロー データのデコードのオーバーヘッドはそれほど重要ではないと考えられており、効率目標 (2) によって部分的にカバーされています。
The protocols in this group use an external mechanism to fully describe the format in which flow data is encoded. The mechanisms are "templates" in the case of CRANE and NetFlow, and a subset of the XML-Schema language, or alternatively XDR IDL, for IPDR.
このグループのプロトコルは、外部メカニズムを使用して、フロー データがエンコードされる形式を完全に記述します。このメカニズムは、CRANE および NetFlow の場合は「テンプレート」であり、IPDR の場合は XML スキーマ言語のサブセット、または XDR IDL です。
A fully external data format description allows for very compact encoding, with data components such as 32-bit integers taking up only four octets. The XDR representation used in IPDR additionally ensures that larger fields are always aligned on 32-bit boundaries, which can reduce processing requirements at both the exporter and the collector, at a slight cost of space (thus bandwidth) due to padding.
完全に外部のデータ形式の記述により、32 ビット整数などのデータ コンポーネントがわずか 4 オクテットを占める非常にコンパクトなエンコードが可能になります。さらに、IPDR で使用される XDR 表現により、より大きなフィールドが常に 32 ビット境界でアラインされることが保証され、パディングによるスペース (したがって帯域幅) がわずかに犠牲になりますが、エクスポーターとコレクターの両方での処理要件を軽減できます。
Most protocols specify "network byte order" or "big-endian" format in the export data format. CRANE is the only protocol where the exporter may choose the byte ordering. The principal benefit is that this lowers the processing demand on exporters based on little-endian architectures.
ほとんどのプロトコルは、エクスポート データ形式で「ネットワーク バイト オーダー」または「ビッグ エンディアン」形式を指定します。CRANE は、エクスポーターがバイト順序を選択できる唯一のプロトコルです。主な利点は、リトル エンディアン アーキテクチャに基づくエクスポータの処理要求が軽減されることです。
Diameter and LFAP represent flow data using Type/Length/Value encodings. While this makes it possible to partly decode flow data without full context information - possibly useful for debugging - it does increase the encoding size and thus the bandwidth requirements both on the wire and in the exporter and collector.
直径と LFAP は、タイプ/長さ/値エンコーディングを使用してフロー データを表します。これにより、完全なコンテキスト情報なしでフロー データを部分的にデコードできるようになります (デバッグに役立つ可能性があります) が、エンコード サイズが増加するため、回線上とエクスポータおよびコレクタの両方で帯域幅要件が増加します。
LFAP has a "multi-record" encoding which claims to provide similar wire efficiency as the externally described encodings while still supporting diagnostic tools.
LFAP には「マルチレコード」エンコーディングがあり、診断ツールをサポートしながら、外部で記述されたエンコーディングと同様の配線効率を提供すると主張しています。
Another criterion for classification is the flow of protocol messages between exporter and collector.
分類のもう 1 つの基準は、エクスポータとコレクタの間のプロトコル メッセージのフローです。
In IPDR and NetFlow, the data flow is essentially from exporter to collector, with the collector only sending acknowledgements. The protocols send data descriptions (templates) on session establishment, and then start sending flow export data based on these templates. "Meta-information" about the operational status of the metering and exporting processes (for example about the sampling parameters in force at a given moment) is conveyed using a special type of "Option" template in NetFlow v9. IPDR currently doesn't have definitions for such "meta-data" types, but they could easily be defined outside the protocol proper.
IPDR と NetFlow では、データ フローは基本的にエクスポータからコレクタへの流れであり、コレクタは確認応答のみを送信します。プロトコルは、セッションの確立時にデータ記述 (テンプレート) を送信し、これらのテンプレートに基づいてフロー エクスポート データの送信を開始します。メータリングおよびエクスポート プロセスの動作ステータスに関する「メタ情報」（たとえば、特定の瞬間に有効なサンプリング パラメータに関する）は、NetFlow v9 の特別なタイプの「オプション」テンプレートを使用して伝達されます。現在、IPDR にはそのような「メタデータ」タイプの定義はありませんが、プロトコル本来の外部で簡単に定義できる可能性があります。
CRANE allows for negotiation of the templates used for data export at the start of a session, and also allows negotiated template updates later on. CRANE sessions include an exporter and potentially several collectors, so these negotiations can involve more than two parties.
CRANE を使用すると、セッションの開始時にデータのエクスポートに使用されるテンプレートのネゴシエーションが可能になり、後でネゴシエートされたテンプレートの更新も可能になります。CRANE セッションには輸出業者と、場合によっては複数のコレクターが含まれるため、これらの交渉には 2 者以上の関係者が関与する可能性があります。
LFAP has an initial phase of version negotiation, followed by a phase of "data negotiation". After these startup phases, the exporter sends FAR and FUN messages to the collector. However, either party may also send Administrative Request (AR) messages to the other, and will normally receive Administrative Request Answers (ARA) in response. Administrative Requests can be used for status inquiries, including information about a specific active flow, or for negotiation of the "Information Elements" that the collector wants the exporter to export.
LFAP には、バージョン ネゴシエーションの初期フェーズがあり、その後に「データ ネゴシエーション」フェーズが続きます。これらの起動フェーズの後、エクスポータは FAR メッセージと FUN メッセージをコレクタに送信します。ただし、どちらの当事者も他方に管理要求 (AR) メッセージを送信することもでき、通常は応答として管理要求回答 (ARA) を受信します。管理リクエストは、特定のアクティブなフローに関する情報を含むステータスの問い合わせ、またはコレクタがエクスポータにエクスポートすることを希望する「情報要素」のネゴシエーションに使用できます。
Diameter has a general capabilities negotiation mechanism. The use of Diameter for IPFIX hasn't been described in sufficient detail to determine how capabilities negotiation would be used. After negotiation, the protocol would operate in essentially unidirectional mode, with Accounting-Request (ACR) messages flowing from the exporter to the collector, and Accounting-Answer (ACA) messages flowing back.
Diameter には、一般的な機能ネゴシエーション メカニズムがあります。IPFIX での Diameter の使用については、機能ネゴシエーションがどのように使用されるかを決定するのに十分な詳細が説明されていません。ネゴシエーション後、プロトコルは基本的に単方向モードで動作し、Accounting-Request (ACR) メッセージがエクスポータからコレクタに流れ、Accounting-Answer (ACA) メッセージが戻ってきます。
The template for protocol advocates noted that not all requirements in [1] apply directly to the flow export protocol. In particular, sections 4 (Distinguishing Flows) and 5 (Metering Process) mainly specify requirements on the metering mechanism that "feeds" the exporter. However, in some cases they require information about the metering process to be reported to collectors, so the flow export protocol must support conveying this information.
プロトコル支持者向けのテンプレートでは、[1] のすべての要件がフロー エクスポート プロトコルに直接適用されるわけではないことが指摘されています。特に、セクション 4 (フローの識別) とセクション 5 (計量プロセス) では、主にエクスポーターに「供給」する計量メカニズムに関する要件を指定します。ただし、場合によっては、計量プロセスに関する情報をコレクターに報告する必要があるため、フロー エクスポート プロトコルはこの情報の伝達をサポートする必要があります。
CRANE, Diameter, IPDR consider requirement 5.1 (reliability of the metering process or indication of "missing reliability") out of scope for the IPFIX protocol, which presumably means that they assume the metering process to be reliable.
CRANE、Diameter、IPDR は、要件 5.1 (計量プロセスの信頼性、または「信頼性の欠落」の表示) を IPFIX プロトコルの範囲外とみなしています。これは、おそらく、計量プロセスが信頼できるものであると想定していることを意味します。
The NetFlow v9 advocacy document takes a similar stance when it claims "Total Compliance. The metering process is reliable." (although this has been documented not to be true for all current Cisco implementations of NetFlow v5).
NetFlow v9 の擁護文書でも、「完全なコンプライアンス。測定プロセスは信頼できる」と主張する際に、同様の立場をとっています。（ただし、これは現在の Cisco の NetFlow v5 実装すべてに当てはまらないことが文書化されています）。
LFAP is the only protocol that explicitly addresses the possibility that data might be lost in the metering process, and provides useful statistics for the collectors to estimate, not just the amount of flow data that was lost, but also the amount of data that was not unaccounted for.
LFAP は、メータリング プロセスでデータが失われる可能性に明示的に対処する唯一のプロトコルであり、コレクターが推定するために役立つ統計情報を提供します。これには、失われたフロー データの量だけでなく、失われなかったデータの量も含まれます。行方不明で。
Note that in the general case, it can be considered unrealistic to assume total reliability of a flow-based metering process in all situations, unless sampling or coarse flow definitions are used. With the fine-grained flow classification mechanisms mandated by IPFIX, it is easy to imagine traffic where each - possibly very small - packet would create a new flow. This kind of traffic is in fact encountered in practice during aggressive port scans, and will eventually lead to table overflows or exceeding of memory bandwidth at the meter.
一般的なケースでは、サンプリングまたは粗い流量定義が使用されない限り、あらゆる状況で流量ベースの計量プロセスの完全な信頼性を想定することは非現実的であると考えられることに注意してください。IPFIX によって義務付けられたきめ細かいフロー分類メカニズムを使用すると、各 (おそらく非常に小さい) パケットが新しいフローを作成するトラフィックを容易に想像できます。実際、この種のトラフィックは積極的なポート スキャン中に実際に発生し、最終的にはテーブルのオーバーフローやメーターのメモリ帯域幅の超過につながります。
While some of these situations can be handled by dropping data later on in the exporter, data transfer, or collector, or by transitioning the meter to sampling mode (or increasing the sampling interval), it will sometimes be considered the lesser evil to simply report on the data that couldn't be accounted for. Currently LFAP is the only protocol that supports this.
これらの状況の一部は、後でエクスポーター、データ転送、またはコレクターでデータをドロップするか、メーターをサンプリング モードに移行する (またはサンプリング間隔を増やす) ことによって処理できますが、単純にレポートする方が害が少ないと考えられる場合もあります。説明できなかったデータについて。現在、これをサポートするプロトコルは LFAP だけです。
CRANE and IPDR don't mention the possibility of sampling. This is natural because they are targeted towards telco-grade accounting, where sampling would be considered inadmissible. Since support for sampling is a "MAY" requirement, its lack could be tolerated, but severely restricts the applicability of these protocols in places of high aggregation, where absolute precision is not necessary. This includes applications such as traffic profiling, traffic engineering, and large-scale attack/intrusion detection, but also usage-based accounting applications where charging based on sampling is agreed upon.
CRANEとIPDRはサンプリングの可能性については言及していない。これは、サンプリングが認められないと考えられる通信会社レベルの会計を対象としているため、当然のことです。サンプリングのサポートは「MAY」要件であるため、その欠如は許容されますが、絶対的な精度が必要ない高度な集約の場所でのこれらのプロトコルの適用可能性は厳しく制限されます。これには、トラフィック プロファイリング、トラフィック エンジニアリング、大規模な攻撃/侵入検出などのアプリケーションが含まれますが、サンプリングに基づいた課金が合意されている使用量ベースのアカウンティング アプリケーションも含まれます。
The Diameter advocate acknowledges the existence of sampling and suggests to define new (grouped) AVPs to carry information about the sampling parameters in use.
Diameter の提唱者は、サンプリングの存在を認めており、使用中のサンプリング パラメーターに関する情報を伝える新しい (グループ化された) AVP を定義することを提案しています。
LFAP does not currently support sampling, although its advocate contends that adding support for this would be relatively straightforward, without going into too much detail.
LFAP は現在サンプリングをサポートしていませんが、その支持者は、あまり詳しく説明することなく、これのサポートを追加するのは比較的簡単であると主張しています。
NetFlow v9 does support sampling (and many implementations and deployments of sampled NetFlow exist for previous NetFlow versions). Option Data is supposed to convey sampling configuration, although no sampling-related field types have yet been defined in the document.
NetFlow v9 はサンプリングをサポートしています (以前の NetFlow バージョンには、サンプリングされた NetFlow の実装と展開が多数存在します)。オプション データはサンプリング設定を伝えることになっていますが、ドキュメントではサンプリング関連のフィールド タイプがまだ定義されていません。
The requirements document suggests that meters adapt to overload situations, for example by changing to sampling (or reducing the sampling rate if sampling is already in effect), by changing the flow definition to coarser flow categories (thinning), by stopping to meter, or by reducing packet processing.
要件文書では、メーターが過負荷状況に適応することを示唆しています。たとえば、サンプリングに変更する (または、サンプリングがすでに有効である場合はサンプリング レートを下げる)、流量定義をより粗い流量カテゴリに変更する (間引く)、計測を停止する、またはパケット処理を減らすことによって。
In these situations, the requirements document mandates that flow information from before the modification of metering behavior can be cleanly distinguished from flow information from after the modification. For the suggested mitigation methods of sampling or thinning, this essentially means that all existing flows have to be expired, and an entirely new set of flows must be started. This is undesirable because it causes a peak of resource usage in an already overloaded situation.
このような状況では、要件文書では、メータリング動作の変更前のフロー情報と変更後のフロー情報を明確に区別できることが義務付けられています。サンプリングまたは間引きという提案された緩和方法の場合、これは本質的に、既存のフローをすべて期限切れにし、まったく新しいフローのセットを開始する必要があることを意味します。これは、すでに過負荷になっている状況でリソース使用量のピークを引き起こすため、望ましくありません。
LFAP and NetFlow claim to handle this requirement, both by supporting only the simple overload mitigation methods that don't require the entire set of existing flows to be expired. The NetFlow advocate claims that the reporting requirement could be easily met by expiring existing flows with the old template, while sending a new template for new flows. While it is true that NetFlow handles this requirement in a very graceful manner, the general performance issue remains.
LFAP と NetFlow は、既存のフローのセット全体を期限切れにする必要のない単純な過負荷軽減方法のみをサポートすることで、この要件に対応すると主張しています。NetFlow の支持者は、古いテンプレートを使用して既存のフローを期限切れにし、新しいフローには新しいテンプレートを送信することで、レポート要件を簡単に満たせると主張しています。NetFlow がこの要件を非常に適切に処理しているのは事実ですが、一般的なパフォーマンスの問題は依然として残っています。
CRANE, Diameter, and IPDR consider the requirement out of scope for the protocol, although Diameter summarily acknowledges the possible need for new AVP definitions related to mitigation methods.
CRANE、Diameter、および IPDR は、この要件はプロトコルの範囲外であると考えていますが、Diameter は、緩和方法に関連する新しい AVP 定義が必要になる可能性があることを要約的に認めています。
All protocols support reporting of timestamps with the required (one centisecond) or better precision.
すべてのプロトコルは、必要な精度 (1 センチ秒) 以上のタイムスタンプのレポートをサポートしています。
While all other protocols have timestamp types that are relative to a well-known reference time, timestamps in NetFlow are reported relative to the sysUpTime of the exporting device. For applications that require the absolute start/end times of flows, this means that exporter sysUpTime has to be matched with absolute time. Although every NetFlow export packet header contains a "UNIX Secs" field, it cannot be used for UTC synchronization without loss of precision, because this field only has 1-second resolution.
他のすべてのプロトコルには既知の基準時刻に相対的なタイムスタンプ タイプがありますが、NetFlow のタイムスタンプはエクスポートするデバイスの sysUpTime に相対して報告されます。フローの絶対的な開始/終了時刻を必要とするアプリケーションの場合、これは、エクスポータの sysUpTime を絶対時刻と一致させる必要があることを意味します。すべての NetFlow エクスポート パケット ヘッダーには「UNIX Secs」フィールドが含まれていますが、このフィールドの解像度は 1 秒しかないため、精度を損なうことなく UTC 同期に使用することはできません。
As currently specified, this requirement concerns the metering process only and has no bearing on the export protocol.
現在指定されているように、この要件は計量プロセスのみに関係し、エクスポート プロトコルには関係ありません。
If it is desired to export the reason for flow expiration (e.g., inactivity timeout, active flow timeout, expiration to reclaim resources, or observation of a flow termination indication such as a TCP FIN segment), then none of the protocols currently supports this, although each could be extended to do so.
フローの有効期限の理由 (非アクティビティ タイムアウト、アクティブ フローのタイムアウト、リソースを再利用するための有効期限、または TCP FIN セグメントなどのフロー終了指示の観察など) をエクスポートする必要がある場合、現在これをサポートしているプロトコルはありません。ただし、それぞれを拡張してそうすることもできます。
This requirement only concerns the metering process and has no bearing on the export protocol.
この要件は計量プロセスにのみ関係し、エクスポート プロトコルには関係ありません。
All candidate protocols have information models that can represent all required and all optional attributes. The Diameter contribution lacks some detail on how exactly the IPFIX-specific attributes should be mapped.
すべての候補プロトコルには、すべての必須属性とすべてのオプション属性を表すことができる情報モデルがあります。Diameter の貢献には、IPFIX 固有の属性をどのように正確にマッピングするかについての詳細が欠けています。
Each candidate protocol defines a data model that allows for some degree of extensibility.
各候補プロトコルは、ある程度の拡張性を可能にするデータ モデルを定義します。
CRANE uses Keys to specify fields in templates. A key "specification MUST consist of the description and the data type of the accounting item." Apparently extensibility is intended, but it is not clear whether adding a new Key really only involves writing a textual description and deciding upon a base type. Every Key also has a 32- bit Key ID, but from the current specification they don't seem to carry global semantics.
CRANE はキーを使用してテンプレート内のフィールドを指定します。重要な「仕様は、会計項目の説明とデータ型で構成されなければなりません」。明らかに拡張性が意図されていますが、新しいキーの追加が実際にテキストによる説明を記述して基本タイプを決定するだけであるかどうかは不明です。すべてのキーには 32 ビットのキー ID もありますが、現在の仕様からすると、グローバル セマンティクスを保持していないようです。
Diameter's Attribute/Value Pairs (AVP) have a 32-bit identifier (AVP Code) administered by IANA. In addition, there is an optional 32-bit Vendor-ID that can contain an SMI Enterprise Number for vendor-defined attributes. If the Vendor-ID (and a corresponding flag in the attribute) is set, the AVP Code becomes local to that vendor.
Diameter の属性/値ペア (AVP) には、IANA によって管理される 32 ビットの識別子 (AVP コード) があります。さらに、ベンダー定義属性の SMI エンタープライズ番号を含めることができるオプションの 32 ビット ベンダー ID があります。Vendor-ID (および属性内の対応するフラグ) が設定されている場合、AVP コードはそのベンダーに対してローカルになります。
IPDR uses a subset of the XML-Schema language for extensibility, thus allowing for vendor- and application-specific extensions of the data model.
IPDR は拡張性のために XML スキーマ言語のサブセットを使用するため、データ モデルのベンダー固有およびアプリケーション固有の拡張が可能になります。
In LFAP, flow attributes are defined as Information Elements. There is a 16-bit IE type code (which is carried in the export protocol for every IE). One type code is reserved for vendor-specific extensions. Arbitrary sub-types of the vendor-specific IE can be defined using ASN.1 Object IDs (OIDs).
LFAP では、フロー属性は情報要素として定義されます。16 ビットの IE タイプ コードがあります (すべての IE のエクスポート プロトコルで伝送されます)。1 つのタイプ コードはベンダー固有の拡張用に予約されています。ベンダー固有 IE の任意のサブタイプは、ASN.1 オブジェクト ID (OID) を使用して定義できます。
In NetFlow v9 as reviewed, data items are identified by a sixteen-bit field type. 26 field types are defined in the document. The document suggests to look check a Web page at Cisco Systems' site for the current list of field types. It would be preferable if the administration of the field type space would be delegated to IANA.
レビューした NetFlow v9 では、データ項目は 16 ビットのフィールド タイプによって識別されます。ドキュメントでは 26 のフィールド タイプが定義されています。この文書では、Cisco Systems サイトの Web ページでフィールド タイプの現在のリストを確認することを推奨しています。フィールド型空間の管理が IANA に委任されることが望ましいでしょう。
All protocols allow for flexible flow record definitions. CRANE and LFAP make the selection/negotiation of the attributes to be included in flow records a part of the protocol, the other protocols leave this to outside configuration mechanisms.
すべてのプロトコルで柔軟なフロー レコード定義が可能です。CRANE と LFAP は、フロー レコードに含める属性の選択/ネゴシエーションをプロトコルの一部にし、他のプロトコルはこれを外部の設定メカニズムに任せます。
All protocols except for NetFlow v9 operate over a single TCP or SCTP transport connection, and inherit the congestion-friendliness of these protocols.
NetFlow v9 を除くすべてのプロトコルは、単一の TCP または SCTP トランスポート接続上で動作し、これらのプロトコルの輻輳耐性を継承します。
NetFlow v9 was initially defined to operate over UDP, but specified in a transport-independent manner. Recently, a document [16] has been issued that describes how NetFlow v9 can be run over SCTP with the proposed Partial Reliability extension. This transport mapping would fill the congestion awareness requirement.
NetFlow v9 は当初、UDP 上で動作するように定義されていましたが、トランスポートに依存しない方法で指定されました。最近、提案されている Partial Reliability 拡張機能を使用して NetFlow v9 を SCTP 上で実行する方法を説明した文書 [16] が発行されました。このトランスポート マッピングは、輻輳認識要件を満たすことになります。
The requirements in the area of reliability are specified as follows: If flow records can be lost during transfer, this must be indicated to the collector in a way that permits the number of lost records to be gauged; and the protocol must be open to reliability extensions including retransmission of lost flow records, detection of exporter/collector disconnection and fail-over, and acknowledgement of flow records by the collecting process (application-level acknowledgements).
信頼性の分野の要件は次のように指定されます。転送中にフロー レコードが失われる可能性がある場合は、失われたレコードの数を測定できる方法でコレクタにそのことを示す必要があります。また、プロトコルは、失われたフロー レコードの再送信、エクスポータ/コレクタの切断とフェイルオーバーの検出、収集プロセスによるフロー レコードの確認応答 (アプリケーション レベルの確認応答) など、信頼性の拡張にオープンでなければなりません。
Here are a few observations regarding the candidate protocols' approaches to reliability. Note that the requirement for multiple collectors (8.3) also touches on the issue of reliability.
ここでは、候補プロトコルの信頼性へのアプローチに関するいくつかの観察を示します。複数のコレクタ (8.3) の要件は信頼性の問題にも触れていることに注意してください。
CRANE, Diameter, and IPDR, as protocols that strive to be carrier-grade accounting protocols, understandably exhibit a strong emphasis on near-total reliability of the flow export process. All three protocols use application-level acknowledgements (in case of IPDR, optionally) to include the entire collection process in the feedback loop. Indications of "lack of reliability" (lost flow data) are somewhat unnatural to these protocols, because they take every effort to never lose anything. These protocols seem suitable in situations where one would rather drop a packet than forward it unaccounted for.
CRANE、Diameter、および IPDR は、キャリア グレードのアカウンティング プロトコルを目指すプロトコルとして、当然のことながら、フロー エクスポート プロセスのほぼ完全な信頼性を重視しています。3 つのプロトコルはすべて、アプリケーション レベルの確認応答 (IPDR の場合はオプション) を使用して、収集プロセス全体をフィードバック ループに含めます。これらのプロトコルでは何も失われないようにあらゆる努力が必要であるため、「信頼性の欠如」（フロー データの損失）の兆候はやや不自然です。これらのプロトコルは、パケットを不明瞭に転送するよりもドロップしたい状況に適していると思われます。
LFAP has application-level acknowledgements, and it also reports detailed statistics about lost flows and the amount of data that couldn't be accounted for. It represents a middle ground in that it acknowledges that accounting reliability will sometimes be sacrificed for the benefit of other tasks, such as switching packets, and provides the tools to gracefully deal with such situations.
LFAP にはアプリケーション レベルの確認応答があり、失われたフローと説明できなかったデータ量に関する詳細な統計も報告します。これは、パケットのスイッチングなどの他のタスクの利益のためにアカウンティングの信頼性が時々犠牲になることを認識し、そのような状況に適切に対処するツールを提供するという点で中間点を表します。
NetFlow v9 is the only protocol for which the use of a "reliable" transport protocol is optional, and the only protocol that doesn't support application-level acknowledgements. In all fairness, it should be noted that it is a very simple and efficient protocol, so in an actual deployment it might exhibit a higher level of reliability than some of the other protocols given the same amount of resources.
NetFlow v9 は、「信頼できる」トランスポート プロトコルの使用がオプションである唯一のプロトコルであり、アプリケーション レベルの確認応答をサポートしない唯一のプロトコルです。公平を期すために、これは非常にシンプルで効率的なプロトコルであるため、実際の展開では、同じ量のリソースが与えられた他のプロトコルよりも高いレベルの信頼性を示す可能性があることに注意してください。
All protocols can use, and their descriptions in fact recommend them to use, lower-layer security mechanisms such as IPsec and, with the exception of NetFlow v9 over UDP, TLS. It can be argued that in all envisioned usage scenarios for IPFIX, both IPsec and TLS provide sufficient protection against the main identified threats of flow data disclosure and forgery.
すべてのプロトコルは、IPsec や、NetFlow v9 over UDP、TLS を除く、下位層のセキュリティ メカニズムを使用でき、実際にその説明でも使用することが推奨されています。IPFIX で想定されるすべての使用シナリオにおいて、IPsec と TLS の両方が、フロー データの開示と偽造という主な特定の脅威に対して十分な保護を提供すると主張できます。
The Diameter document is the only protocol definition that goes into sufficient level of detail with respect to the application of these mechanisms, in particular the negotiation of certificates and ciphers in TLS, and the use of IKE [6] for IPsec. Diameter also mandates that either IPsec or TLS be used.
Diameter 文書は、これらのメカニズムの適用、特に TLS での証明書と暗号のネゴシエーション、および IPsec での IKE [6] の使用に関して、十分な詳細レベルに踏み込んだ唯一のプロトコル定義です。また、Diameter では、IPsec または TLS の使用が義務付けられています。
Diameter suggests an additional end-to-end security framework for dealing with untrusted third-party agents. I am not entirely convinced that this additional level of security justifies the additional complexity in the context of IPFIX.
Diameter は、信頼できないサードパーティ エージェントに対処するための追加のエンドツーエンド セキュリティ フレームワークを提案しています。この追加のセキュリティ レベルが IPFIX のコンテキストにおける追加の複雑さを正当化するかどうか、私は完全に確信しているわけではありません。
LFAP [11] is the only other protocol that includes some higher-level security mechanisms, providing four levels of security including no security, authenticated peers, flow data authentication, and flow data encryption using HMAC-MD5-96 and DES-CBC.
LFAP [11] は、いくつかの高レベルのセキュリティ メカニズムを含む唯一の他のプロトコルであり、セキュリティなし、認証済みピア、フロー データ認証、HMAC-MD5-96 および DES-CBC を使用したフロー データ暗号化を含む 4 つのレベルのセキュリティを提供します。
As far as the author can judge (not being a security expert), LFAP's built-in support for authentication and encryption doesn't provide significant additional security compared with the use of TLS or IPsec. It is potentially useful in situations where TLS or IPsec are unavailable for some reason, although in the context of IPFIX scenarios, it should be possible to assume support for these lower-layer mechanisms if the participating devices are capable of the necessary cryptographic methods at all.
著者が (セキュリティの専門家ではない) 判断できる限り、LFAP に組み込まれた認証と暗号化のサポートは、TLS や IPsec の使用と比較して重要な追加のセキュリティを提供しません。これは、何らかの理由で TLS または IPsec が利用できない状況で潜在的に役立つ可能性がありますが、IPFIX シナリオのコンテキストでは、参加しているデバイスが必要な暗号化方式をまったく使用できる場合には、これらの下位層メカニズムのサポートを想定できるはずです。。
All protocols support the mandatory "push" mode.
すべてのプロトコルは必須の「プッシュ」モードをサポートしています。
The optional "pull" mode could be supported relatively easily in Diameter, and is foreseen in NDM-U, the basis of the Streaming IPDR proposal. CRANE, LFAP and NetFlow don't have a "pull" mode. For CRANE and LFAP, adding one would not violate the spirit of the protocols because they are already two-way, and in fact LFAP already foresees inquiries about specific active flows using Administrative Request (AR) messages with a RETURN_INDICATED_FLOWS Command Code IE.
オプションの「プル」モードは、Diameter で比較的簡単にサポートでき、ストリーミング IPDR 提案の基礎である NDM-U で予見されています。CRANE、LFAP、および NetFlow には「プル」モードがありません。CRANE と LFAP の場合、これらを追加してもプロトコルの精神に違反することはありません。これらはすでに双方向であるためです。実際、LFAP は、RETURN_INDICATED_FLOWS コマンド コード IE を持つ管理要求 (AR) メッセージを使用して、特定のアクティブ フローに関する問い合わせをすでに予測しています。
As stated, this requirement concerns the metering process only and has no bearing on the export protocol.
前述したように、この要件は計量プロセスのみに関係し、輸出プロトコルには関係ありません。
The specific events listed in the requirements documents as examples for "specific events" are "the arrival of the first packet of a new flow and the termination of a flow after flow timeout". For the former, only LFAP explicitly generates messages upon creation of a new flow. NetFlow always exported flow information on expiration of flows, either due to timeout or due to an indication of flow termination. The other protocols are unspecific about when flow information is exported.
要件文書に「特定のイベント」の例として挙げられている特定のイベントは、「新しいフローの最初のパケットの到着とフローのタイムアウト後のフローの終了」です。前者の場合、LFAP のみが新しいフローの作成時に明示的にメッセージを生成します。NetFlow は、タイムアウトまたはフロー終了の兆候により、フローの有効期限が切れたときに常にフロー情報をエクスポートしました。他のプロトコルでは、フロー情報がいつエクスポートされるかが明確ではありません。
On "specific events" in general, all protocols have some mechanism that could be used for notification of asynchronous events. An example for such an event would be that the sampling rate of the meter was changed in response to a change in the load on the exporting process.
一般に、「特定のイベント」に関しては、すべてのプロトコルに、非同期イベントの通知に使用できる何らかのメカニズムが備わっています。このようなイベントの例としては、エクスポート プロセスの負荷の変化に応じてメーターのサンプリング レートが変更されたことが挙げられます。
CRANE has Status Request/Status Response messages, but as defined, Status Requests can only be issued by the server (collector), so they cannot be used by the server to signal asynchronous events. As in IPDR, this could be circumvented by defining templates for meta-information.
CRANE にはステータス要求/ステータス応答メッセージがありますが、定義されているように、ステータス要求はサーバー (コレクター) によってのみ発行できるため、サーバーが非同期イベントを通知するためにステータス要求を使用することはできません。IPDR と同様に、これはメタ情報のテンプレートを定義することで回避できます。
Diameter could use special Accounting-Request messages for event notification.
Diameter は、イベント通知に特別な Accounting-Request メッセージを使用できます。
IPDR would presumably define pseudo-"Usage Events" using an XML Schema so that events can be reported along with usage data.
IPDR は、イベントを使用状況データとともにレポートできるように、XML スキーマを使用して疑似「使用状況イベント」を定義すると考えられます。
LFAP has Administrative Requests (AR) that can be initiated from either side. The currently defined ARs are all information inquiries or reconfiguration requests, but new ARs could be defined to provide unsolicited information about specific asynchronous events. The LFAP MIB also defines some traps/notifications. SNMP notifications are useful to signal events to a network management system, but they are less attractive as a mechanism to signal events that should be somehow handled by a collector.
LFAP には、どちらの側からでも開始できる管理要求 (AR) があります。現在定義されている AR はすべて情報の問い合わせまたは再構成の要求ですが、特定の非同期イベントに関する一方的な情報を提供するために新しい AR を定義することもできます。LFAP MIB は、いくつかのトラップ/通知も定義します。SNMP 通知は、ネットワーク管理システムにイベントを通知するのに役立ちますが、コレクタによって何らかの方法で処理される必要があるイベントを通知するメカニズムとしてはあまり魅力的ではありません。
In NetFlow v9, Option Data FlowSets are defined to convey information about the metering and export processes. The current document specifies that Option Data should be exported periodically, although this requirement will be relaxed for asynchronous events. It should be noted that periodical export of option flowsets (and also of templates) may have been considered necessary because NetFlow can run over an unreliable transport; it seems less natural when a reliable transport such as TCP is used.
NetFlow v9 では、メータリングおよびエクスポート プロセスに関する情報を伝達するためにオプション データ フローセットが定義されています。現在の文書では、オプション データを定期的にエクスポートする必要があると指定されていますが、この要件は非同期イベントでは緩和されます。NetFlow は信頼性の低いトランスポート上で実行される可能性があるため、オプション フローセット (およびテンプレート) の定期的なエクスポートが必要であると考えられる場合があることに注意してください。TCP などの信頼できるトランスポートが使用される場合、これはそれほど自然ではありません。
None of the protocols include explicit support for anonymization. All protocols could be extended to convey when and how anonymization is being performed by an exporter, using mechanisms similar to those that would be used to report on sampling.
どのプロトコルにも匿名化の明示的なサポートは含まれていません。すべてのプロトコルは、サンプリングに関するレポートに使用されるものと同様のメカニズムを使用して、輸出者によって匿名化がいつ、どのように実行されるかを伝えるように拡張できます。
CRANE, Diameter, and IPDR all support multiple collectors in a backup configuration. The failover case is analyzed in some detail, with support for data buffering and de-duplication in failover situations.
CRANE、Diameter、および IPDR はすべて、バックアップ構成で複数のコレクタをサポートします。フェイルオーバーの状況は、フェイルオーバー状況でのデータ バッファリングと重複排除のサポートにより、ある程度詳細に分析されます。
NetFlow takes a more simple-minded approach in that it allows multiple (currently: two) collectors to be configured in an exporter. Both collectors will generally receive all data and could use sequence numbers and inter-collector communication to de-duplicate them. This is a simple way to improve availability but may also be considered to be wasteful, both in terms of bandwidth and in terms of other exporter resources. With the current UDP mapping it is easy enough to send multiple copies of datagrams to different collectors, but when SCTP or TCP is used, sending all data over multiple connections will exacerbate performance issues.
NetFlow は、エクスポータで複数 (現在: 2 つ) のコレクタを設定できるという点で、より単純なアプローチを採用しています。通常、どちらのコレクターもすべてのデータを受信し、シーケンス番号とコレクター間通信を使用してデータの重複を排除できます。これは可用性を向上させる簡単な方法ですが、帯域幅と他のエクスポーター リソースの両方の点で無駄であると考えられる場合もあります。現在の UDP マッピングを使用すると、データグラムの複数のコピーを異なるコレクタに送信するのは簡単ですが、SCTP または TCP を使用する場合、複数の接続を介してすべてのデータを送信すると、パフォーマンスの問題が悪化します。
Failover in LFAP must take into account that flow information is split into FARs and FUNs. When a (primary) FAS A fails, a secondary FAS B will receive FUNs for flows whose FARs had only been sent to A. If such FUNs are to be handled correctly in the failover case, then either the set of active flows must be kept in sync between the primary and backup FASs, or the exporting CCE must have a way to generate new FARs on failover.
LFAP のフェールオーバーでは、フロー情報が FAR と FUN に分割されることを考慮する必要があります。(プライマリ) FAS A に障害が発生すると、セカンダリ FAS B は、FAR が A にのみ送信されていたフローの FUN を受信します。フェイルオーバーの場合にそのような FUN が正しく処理される場合は、アクティブなフローのセットを保持する必要があります。プライマリ FAS とバックアップ FAS の間で同期しているか、エクスポートする CCE にフェールオーバー時に新しい FAR を生成する方法が必要です。
Every candidate protocol has its strengths and weaknesses. If the primary goal of the IPFIX standardization effort were to define a carrier-grade accounting protocol that can also be used to carry IP flow information, then one of CRANE, Diameter and Streaming IPDR would probably be the candidate of choice.
どの候補プロトコルにも長所と短所があります。IPFIX 標準化の取り組みの主な目標が、IP フロー情報の伝送にも使用できるキャリア グレードのアカウンティング プロトコルを定義することである場合、おそらく CRANE、Diameter、ストリーミング IPDR のいずれかが候補となるでしょう。
But since the goal is to standardize existing practice in the area of IP Flow Information Export, it makes sense to analyze why previous versions of NetFlow have been so widely implemented and used. The strong position of Cisco in the router market certainly played a major role, but we should not underestimate the value of having a simple and streamlined protocol that "does one thing and does it well". It has been extremely easy to write NetFlow collecting processes, as all the protocol demands from a collector is to sit there and receive data. This model is no longer adequate when one wants to support increased levels of reliability or dynamically changing semantics for data export. But NetFlow remains a simple protocol, mainly by leaving out issues of configuration/negotiation.
しかし、目標は IP フロー情報エクスポートの分野における既存の実践を標準化することであるため、なぜ以前のバージョンの NetFlow がこれほど広く実装され、使用されてきたのかを分析することは理にかなっています。ルータ市場における Cisco の強力な地位は確かに大きな役割を果たしましたが、「1 つのことを実行し、それをうまく実行する」シンプルで合理化されたプロトコルの価値を過小評価すべきではありません。コレクターから要求されるプロトコルはすべてそこに座ってデータを受信することだけであるため、NetFlow 収集プロセスを作成するのは非常に簡単でした。このモデルは、信頼性の向上レベルをサポートしたり、データ エクスポートのセマンティクスを動的に変更したりする場合には、もはや適切ではありません。しかし、NetFlow は、主に構成/ネゴシエーションの問題を省略しているため、単純なプロトコルのままです。
So far, the biggest issue with NetFlow is that it could not resolve itself to mandate a reliable (and congestion-friendly) transport. This could easily be fixed, and bring with it some additional possibilities for simplifications. For example it would no longer be necessary to periodically retransmit Template FlowSets, and Option Data FlowSets could become a more versatile way of reporting meta-information about the metering and exporting processes either synchronously or asynchronously. Application-level acknowledgements - possibly as an option - would be a low-impact addition to improve overall reliability.
これまでのところ、NetFlow の最大の問題は、信頼性の高い (そして輻輳に優しい) トランスポートを義務付けるために NetFlow 自体を解決できなかったことです。これは簡単に修正でき、簡素化の可能性がさらに高まります。たとえば、テンプレート フローセットを定期的に再送信する必要がなくなり、オプション データ フローセットは、同期または非同期で計測およびエクスポート プロセスに関するメタ情報をレポートする、より汎用性の高い方法になる可能性があります。アプリケーション レベルの確認応答 (おそらくオプション) は、全体的な信頼性を向上させるための追加としては影響が少ないでしょう。
LFAP is also relatively focused on flow information export, but carries around too much baggage from its youth as the Lightweight Flow Admission Protocol. The bidirectional nature and large number of message types in the protocol are one symptom of this, the separation of flow information into FARs and FUNs - which must be matched at the collector - are another. Data encoding is less space-efficient than that of CRANE, NetFlow or IPDR, and will present a performance issue at high flow rates.
LFAP もフロー情報のエクスポートに比較的重点を置いていますが、Lightweight Flow Admission Protocol として初期の頃からの荷物が多すぎます。プロトコル内の双方向性と多数のメッセージ タイプはこの症状の 1 つであり、フロー情報が FAR と FUN に分離されること (コレクタで一致する必要がある) は別の症状です。データ エンコーディングは、CRANE、NetFlow、または IPDR よりもスペース効率が低く、高フロー レートではパフォーマンスの問題が発生します。
LFAP's indications of unaccounted data and its MIB are excellent features that would be very useful in many operational situations.
LFAP の不明なデータの表示とその MIB は、多くの運用状況で非常に役立つ優れた機能です。
It is the opinion of the evaluation team that the goals of the IPFIX WG charter would best be served by starting with NetFlow v9, working on lacking mechanisms in the areas of transport, security, reliability, and redundant configurations, and doing so very carefully in order to retain as much simplicity as possible and to avoid overloading the protocol. By starting from the simplest protocol that meets a large percentage of the specific requirements, we can hope to arrive at a protocol that meets all requirements and still allows widespread and cost-effective implementation.
IPFIX WG 憲章の目標は、NetFlow v9 から始めて、トランスポート、セキュリティ、信頼性、冗長構成の分野で不足しているメカニズムに取り組み、非常に注意深く行うことで最もよく達成されるだろう、というのが評価チームの意見です。可能な限り単純さを保ち、プロトコルの過負荷を避けるためです。特定の要件の大部分を満たす最も単純なプロトコルから始めることで、すべての要件を満たしながら、広範かつコスト効率の高い実装を可能にするプロトコルに到達することが期待できます。
As evaluated, NetFlow v9 doesn't specify any security mechanisms. The IPFIX protocol specification must specify how the security requirements in section 6.3.3 of [1] can be assured. The IPFIX specification must be specific about the choice of security-supporting protocol(s) and about all relevant issues such as security negotiation, protocol modes permitted, and key management.
評価したところ、NetFlow v9 にはセキュリティ メカニズムが何も指定されていません。IPFIX プロトコル仕様では、[1] のセクション 6.3.3 のセキュリティ要件をどのように保証できるかを指定する必要があります。IPFIX 仕様は、セキュリティをサポートするプロトコルの選択と、セキュリティ ネゴシエーション、許可されるプロトコル モード、キー管理などのすべての関連問題について具体的である必要があります。
The other important requirement that isn't fulfilled by NetFlow v9 today is support for a congestion-aware protocol (see section 6.3.1 of [1]). So a mapping to a known congestion-friendly protocol such as TCP, or, as suggested in [16], (PR-)SCTP, is considered as another necessary step in the preparation of the IPFIX specification.
現在の NetFlow v9 で満たされていないもう 1 つの重要な要件は、輻輳対応プロトコルのサポートです ([1] のセクション 6.3.1 を参照)。したがって、TCP や [16] で提案されているように (PR-)SCTP などの既知の輻輳に優しいプロトコルへのマッピングは、IPFIX 仕様の準備におけるもう 1 つの必要なステップと考えられます。
The security mechanisms of the candidate protocols were discussed in Section 4.10.3.
候補プロトコルのセキュリティ メカニズムについては、セクション 4.10.3 で説明しました。
Many of the issues have been discussed with the other members of the IPFIX evaluation team: Juergen Quittek, Mark Fullmer, Ram Gopal, and Reinaldo Penno. Many participants on the ipfix mailing list provided valuable feedback, including Vamsidhar Valluri, Paul Calato, Tal Givoly, Jeff Meyer, Robert Lowe, Benoit Claise, and Carter Bullard. Bert Wijnen, Steve Bellovin, Russ Housley, and Allison Mankin provided valuable feedback during AD and IESG review.
問題の多くは、IPFIX 評価チームの他のメンバーである Juergen Quittek、Mark Fullmer、Ram Gopal、Reinaldo Penno と議論されました。Vamsidhar Valluri、Paul Calato、Tal Givoly、Jeff Meyer、Robert Lowe、Benoit Claise、Carter Bullard など、ipfix メーリング リストの多くの参加者が貴重なフィードバックを提供してくれました。Bert Wijnen、Steve Bellovin、Russ Housley、Allison Mankin は、AD および IESG のレビュー中に貴重なフィードバックを提供してくれました。
[1] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export", RFC 3917, October 2004.
[1] Quittek, J.、Zseby, T.、Claise, B.、および S. Zander、「IP フロー情報エクスポートの要件」、RFC 3917、2004 年 10 月。
[2] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[2] Claise, B. 編、「Cisco Systems NetFlow Services Export Version 9」、RFC 3954、2004 年 10 月。
[3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[3] Postel, J.、「伝送制御プロトコル」、STD 7、RFC 793、1981 年 9 月。
[4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[4] Postel, J.、「ユーザー データグラム プロトコル」、STD 6、RFC 768、1980 年 8 月。
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Stewart, R.、Xie, Q.、Morneault, K.、Sharp, C.、Schwarzbauer, H.、Taylor, T.、Rytina, I.、Kalla, M.、Zhang, L.、V. Paxson、「ストリーム制御伝送プロトコル」、RFC 2960、2000 年 10 月。
[6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[6] Harkins, D. および D. Carrel、「インターネット鍵交換 (IKE)」、RFC 2409、1998 年 11 月。
[7] Zhang, K. and E. Elkin, "XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0", RFC 3423, November 2002.
[7] Zhang, K. および E. Elkin、「XACCT の Common Reliable Accounting for Network Element (CRANE) プロトコル仕様バージョン 1.0」、RFC 3423、2002 年 11 月。
[8] Zhang, K., "Evaluation of the CRANE Protocol Against IPFIX Requirements", Work in Progress, September 2002.
[8] Zhang, K.、「IPFIX 要件に対する CRANE プロトコルの評価」、進行中の作業、2002 年 9 月。
[9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[9] Calhoun, P.、Loughney, J.、Guttman, E.、Zorn, G.、および J. Arkko、「Diameter Base Protocol」、RFC 3588、2003 年 9 月。
[10] Zander, S., "Evaluation of Diameter Protocol against IPFIX Requirements", Work in Progress, September 2002.
[10] Zander, S.、「IPFIX 要件に対する Diameter プロトコルの評価」、進行中の作業、2002 年 9 月。
[11] Calato, P. and M. MacFaden, "Light-weight Flow Accounting Protocol Specification Version 5.0", July 2002.
[11] Calato, P. および M. MacFaden、「軽量フロー アカウンティング プロトコル仕様バージョン 5.0」、2002 年 7 月。
[12] Calato, P. and M. MacFaden, "Light-weight Flow Accounting Protocol Data Definition Specification Version 5.0", July 2002.
[12] Calato, P. および M. MacFaden、「軽量フロー アカウンティング プロトコル データ定義仕様バージョン 5.0」、2002 年 7 月。
[13] Calato, P., "Evaluation Of Protocol LFAP Against IPFIX Requirements", Work in Progress, September 2002.
[13] Calato, P.、「IPFIX 要件に対するプロトコル LFAP の評価」、進行中の作業、2002 年 9 月。
[14] Calato, P. and M. MacFaden, "Light-weight Flow Accounting Protocol MIB", Work in Progress, September 2002.
[14] Calato, P. および M. MacFaden、「軽量フロー アカウンティング プロトコル MIB」、進行中の作業、2002 年 9 月。
[15] Claise, B., "Evaluation Of NetFlow Version 9 Against IPFIX Requirements", Work in Progress, September 2002.
[15] Claise, B.、「IPFIX 要件に対する NetFlow バージョン 9 の評価」、進行中の作業、2002 年 9 月。
[16] Djernaes, M., "Cisco Systems NetFlow Services Export Version 9 Transport", Work in Progress, February 2003.
[16] Djernaes, M.、「Cisco Systems NetFlow Services Export Version 9 Transport」、進行中の作業、2003 年 2 月。
[17] Meyer, J., "Reliable Streaming Internet Protocol Detail Records", Work in Progress, August 2002.
[17] Meyer, J.、「Reliable Streaming Internet Protocol Detail Records」、進行中の作業、2002 年 8 月。
[18] Meyer, J., "Evaluation Of Streaming IPDR Against IPFIX Requirements", Work in Progress, September 2002.
[18] Meyer, J.、「IPFIX 要件に対するストリーミング IPDR の評価」、進行中の作業、2002 年 9 月。
[19] Internet Protocol Detail Record Organization, "Network Data Management - Usage (NDM-U) For IP-Based Services Version 3.1", April 2002. URL: http://www.ipdr.org/documents/NDM-U_3.1.pdf
[19] Internet Protocol Detail Record Organization、「ネットワーク データ管理 - IP ベース サービスの使用法 (NDM-U) バージョン 3.1」、2002 年 4 月 URL: http://www.ipdr.org/documents/NDM-U_3.1.pdf
[20] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[20] Kent, S. および R. Atkinson、「インターネット プロトコルのセキュリティ アーキテクチャ」、RFC 2401、1998 年 11 月。
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[21] Dierks, T. および C. Allen、「TLS プロトコル バージョン 1.0」、RFC 2246、1999 年 1 月。
[22] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[22] Rigney, C.、Willens, S.、Rubens, A. および W. Simpson、「リモート認証ダイヤルイン ユーザー サービス (RADIUS)」、RFC 2865、2000 年 6 月。
[23] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[23] Stewart, R.、Ramalho, M.、Xie, Q.、Tuexen, M.、および P. Conrad、「ストリーム制御伝送プロトコル (SCTP) 部分信頼性拡張」、RFC 3758、2004 年 5 月。
[24] DeRose, S., Maler, E. and D. Orchard, "XML 1.0 Recommendation", W3C FirstEdition REC-xml-19980210, February 1998.
[24] DeRose, S.、Maler, E.、および D. Orchard、「XML 1.0 Recommendation」、W3C FirstEdition REC-xml-19980210、1998 年 2 月。
[25] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[25] Srinivasan, R.、「XDR: 外部データ表現標準」、RFC 1832、1995 年 8 月。
[26] <http://www.nmops.org/>
[27] <http://www.ipdr.org/>
At the time of the evaluation, the candidate protocol definitions, as well as their respective accompanying advocacy documents, were available as Internet-Drafts. As of the time of publication of this document, some of the protocols have been published as RFCs, others are still being revised as Internet-Drafts, and some will have expired. This document attempts to extract the relevant information from the individual protocol definitions and, in the context of the IPFIX requirements, provide a meaningful comparison between them.
評価の時点では、候補プロトコル定義とそれに付随する擁護文書はインターネット ドラフトとして入手可能でした。この文書の発行時点で、プロトコルの一部は RFC として発行されており、その他はまだインターネット ドラフトとして改訂中であり、有効期限が切れているものもあります。この文書は、個々のプロトコル定義から関連情報を抽出し、IPFIX 要件のコンテキストで、それらの間の意味のある比較を提供することを試みます。
Since this evaluation proposes to use NetFlow v9 as the basis for the IPFIX protocol, only the reference to this protocol is considered "normative", although strictly spoken, the present document doesn't define any protocol, and the selected protocol will have to be further refined to become the IPFIX protocol.
この評価では、IPFIX プロトコルの基礎として NetFlow v9 を使用することが提案されているため、このプロトコルへの参照のみが「標準」とみなされますが、厳密に言えば、この文書ではプロトコルは定義されておらず、選択されたプロトコルは次のとおりである必要があります。さらに洗練されて IPFIX プロトコルになりました。
In the interest of stable references, the bibliography points to RFCs where those have become available (for DIAMETER and CRANE). Other protocols are still available only as Internet-Drafts and may eventually expire. The LFAP drafts - which already have expired - are still available from the www.nmops.org Web site [26] (as well as other places). The IPDR documents are available on the IPDR Web site [27].
安定した参照を目的として、参考文献は、(DIAMETER および CRANE について) 利用可能になった RFC を示しています。他のプロトコルは依然としてインターネット ドラフトとしてのみ利用可能であり、最終的に期限切れになる可能性があります。すでに有効期限が切れている LFAP ドラフトは、www.nmops.org Web サイト [26] (および他の場所) からまだ入手できます。IPDR 文書は IPDR Web サイト [27] から入手できます。
Author's Address
著者の連絡先
Simon Leinen SWITCH Limmatquai 138 P.O. Box CH-8021 Zurich Switzerland
Simon Leinen SWITCH Limmatquai 138 P.O.ボックス CH-8021 チューリッヒ スイス
Phone: +41 1 268 1536
EMail: simon@switch.ch
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 および www.rfc-editor.org に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを示すものでもありません。ISOC 文書の権利に関する ISOC の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。