[要約] RFC 5472は、IPFIXの適用範囲とその目的について説明している。IPFIXは、ネットワークフロー情報のエクスポートに関するプロトコルであり、ネットワーク管理やセキュリティ分析などの目的で使用される。
Network Working Group T. Zseby
Request for Comments: 5472 Fraunhofer FOKUS
Category: Informational E. Boschi
Hitachi Europe
N. Brownlee
CAIDA
B. Claise
Cisco Systems, Inc.
March 2009
IP Flow Information Export (IPFIX) Applicability
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
In this document, we describe the applicability of the IP Flow Information eXport (IPFIX) protocol for a variety of applications. We show how applications can use IPFIX, describe the relevant Information Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks.
このドキュメントでは、さまざまなアプリケーション用のIPフロー情報エクスポート（IPFIX）プロトコルの適用性について説明します。アプリケーションがIPFIXを使用する方法を示し、それらのアプリケーションに関連する情報要素（IE）を説明し、プロトコルの機会と制限を提示します。さらに、IPFIXフレームワークと他のアーキテクチャやフレームワークとの関係について説明します。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Applications of IPFIX ...........................................4
2.1. Accounting .................................................4
2.1.1. Example .............................................5
2.2. Traffic Profiling ..........................................7
2.3. Traffic Engineering ........................................8
2.4. Network Security ...........................................9
2.5. QoS Monitoring ............................................11
2.5.1. Correlating Events from Multiple
Observation Points .................................12
2.5.2. Examples ...........................................12
2.6. Inter-Domain Exchange of IPFIX Data .......................14
2.7. Export of Derived Metrics .................................14
2.8. Summary ...................................................15
3. Relation of IPFIX to Other Frameworks and Protocols ............16
3.1. IPFIX and IPv6 ............................................16
3.2. IPFIX and PSAMP ...........................................16
3.3. IPFIX and RMON ............................................16
3.4. IPFIX and IPPM ............................................18
3.5. IPFIX and AAA .............................................18
3.5.1. Connecting via a AAA Client ........................20
3.5.2. Connecting via an Application Specific
Module (ASM) .......................................21
3.6. IPFIX and RTFM ............................................21
3.6.1. Architecture .......................................21
3.6.2. Flow Definition ....................................22
3.6.3. Configuration and Management .......................22
3.6.4. Data Collection ....................................22
3.6.5. Data Model Details .................................23
3.6.6. Transport Protocol .................................23
3.6.7. Summary ............................................23
4. Limitations ....................................................24
4.1. Using IPFIX for Other Applications than Listed in
RFC 3917 ..................................................24
4.2. Using IPFIX for Billing (Reliability Limitations) .........24
4.3. Using a Different Transport Protocol than SCTP ............25
4.4. Push vs. Pull Mode ........................................25
4.5. Template ID Number ........................................26
4.6. Exporting Bidirectional Flow Information ..................26
4.7. Remote Configuration ......................................27
5. Security Considerations ........................................27
6. Acknowledgements ...............................................28
7. Normative References ...........................................28
8. Informative References .........................................28
The IPFIX protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. IP Flow information provides important input data for a variety of applications. The IPFIX protocol is a general data transport protocol that is easily extensible to suit the needs of such applications. In this document, we describe how typical applications can use the IPFIX protocol and show opportunities and limitations of the protocol. Furthermore, we describe the relationship of IPFIX to other frameworks and architectures. Although examples in this document are shown for IPv4 only, the applicability statements apply to IPv4 and IPv6. IPFIX provides appropriate Information Elements for both IP versions.
IPFIXプロトコルは、ルーター、測定プローブ、またはその他のデバイスからIPフロー情報をエクスポートする方法を定義します。IPフロー情報は、さまざまなアプリケーションの重要な入力データを提供します。IPFIXプロトコルは、このようなアプリケーションのニーズに合わせて簡単に拡張できる一般的なデータ輸送プロトコルです。このドキュメントでは、典型的なアプリケーションがIPFIXプロトコルを使用し、プロトコルの機会と制限を示す方法について説明します。さらに、IPFIXと他のフレームワークやアーキテクチャとの関係について説明します。このドキュメントの例はIPv4のみで示されていますが、アプリケーションステートメントはIPv4およびIPv6に適用されます。IPFIXは、両方のIPバージョンに適切な情報要素を提供します。
IPFIX-specific terminology used in this document is defined in Section 2 of [RFC5101]. In this document, as in [RFC5101], the first letter of each IPFIX-specific term is capitalized.
このドキュメントで使用されるIPFIX固有の用語は、[RFC5101]のセクション2で定義されています。このドキュメントでは、[RFC5101]のように、各IPFIX固有の用語の最初の文字が大文字になります。
IPFIX data enables several critical applications. The IPFIX target applications and the requirements that originate from those applications are described in [RFC3917]. Those requirements were used as basis for the design of the IPFIX protocol. This section describes how these target applications can use the IPFIX protocol. Considerations for using IPFIX for other applications than those described in [RFC3917] can be found in Section 4.1.
IPFIXデータは、いくつかの重要なアプリケーションを有効にします。IPFIXターゲットアプリケーションとそれらのアプリケーションから発生する要件は、[RFC3917]で説明されています。これらの要件は、IPFIXプロトコルの設計の基礎として使用されました。このセクションでは、これらのターゲットアプリケーションがIPFIXプロトコルを使用する方法について説明します。[RFC3917]に記載されているものよりも、他のアプリケーションにIPFIXを使用するための考慮事項は、セクション4.1に記載されています。
Usage-based accounting is one of the target applications for IPFIX as defined in [RFC3917]. IPFIX records provide fine-grained measurement results for highly flexible and detailed usage reporting. Such data is used to realize usage-based accounting. Nevertheless, IPFIX does not provide the reliability required by usage-based billing systems as defined in [RFC2975] (see Section 4.2). The accounting scenarios described in this document only provide limited reliability as explained in Section 4.2 and should not be used in environments where reliability as demanded by [RFC2975] is mandatory.
使用法ベースの会計は、[RFC3917]で定義されているIPFIXのターゲットアプリケーションの1つです。IPFIXレコードは、非常に柔軟で詳細な使用状況レポートのために、きめ細かい測定結果を提供します。このようなデータは、使用法ベースの会計を実現するために使用されます。それにもかかわらず、IPFIXは[RFC2975]で定義されているように、使用法ベースの請求システムに必要な信頼性を提供しません（セクション4.2を参照）。このドキュメントで説明されている会計シナリオは、セクション4.2で説明されているように制限された信頼性のみを提供し、[RFC2975]が要求する信頼性が必須である環境では使用すべきではありません。
In order to realize usage-based accounting with IPFIX, the Flow definition has to be chosen in accordance to the accounting purpose, such as trend analysis, capacity planning, auditing, or billing and cost allocation where some loss of data can be tolerated (see Section 4.2).
IPFIXを使用した使用量ベースの会計を実現するには、トレンド分析、容量計画、監査、請求、およびデータの損失を許容できるコスト配分など、会計目的に従ってフロー定義を選択する必要があります（参照セクション4.2）。
Flows can be distinguished by various IEs (e.g., packet header fields) from [RFC5102]. Due to the flexible IPFIX Flow definition, arbitrary Flow-based accounting models can be realized without extensions to the IPFIX protocol.
フローは、[RFC5102]のさまざまなIE（パケットヘッダーフィールドなど）によって区別できます。柔軟なIPFIXフロー定義により、IPFIXプロトコルを拡張せずに任意のフローベースの会計モデルを実現できます。
Accounting can, for instance, be based on individual end-to-end Flows. In this case, it can be realized with a Flow definition determined by the quintuple consisting of source address (sourceIPv4Address), destination address (destinationIPv4Address), protocol (protocolIdentifier), and port numbers (udpSourcePort, udpDestinationPort). Another example is class-dependent accounting (e.g., in a Diffserv network). In this case, Flows could be distinguished just by the Diffserv codepoint (DSCP) (ipDiffServCodePoint) and IP addresses (sourceIPv4Address, destinationIPv4Address). The essential elements needed for accounting are the number of transferred packets and bytes per Flow, which can be represented by the per-flow counter IEs (e.g., packetTotalCount, octetTotalCount).
たとえば、会計は、個々のエンドツーエンドフローに基づいています。この場合、ソースアドレス（sourtyIPv4Address）、宛先アドレス（destinationIPv4Address）、プロトコル（プロトコルイデイフィア）、ポート番号（udpsourceport、udpdestinationport）で構成されるquintupleによって決定されるフロー定義で実現できます。別の例は、クラス依存の会計（例：DiffServネットワーク）です。この場合、フローは、DiffServ CodePoint（DSCP）（IPDIFFSERVCODEPOINT）およびIPアドレス（sourdaipv4Address、destinationIPv4Address）のみによって区別できます。会計に必要な重要な要素は、転送されたパケットの数とフローあたりのバイトであり、これはフローごとのカウンター（たとえば、packettotalcount、octettotalcount）で表すことができます。
For accounting purposes, it would be advantageous to have the ability to use IPFIX Flow Records as accounting input in an Authentication, Authorization, and Accounting (AAA) infrastructure. AAA servers then could provide the mapping between user and Flow information. Again for such scenarios the limited reliability currently provided by IPFIX has to be taken into account.
会計の目的では、認証、承認、会計（AAA）インフラストラクチャの会計入力としてIPFIXフローレコードを使用することができることが有利です。AAAサーバーは、ユーザーとフロー情報間のマッピングを提供できます。このようなシナリオでは、IPFIXによって現在提供されている限られた信頼性を考慮する必要があります。
Please note: As noted in [RFC3330], the address block 192.0.2.0/24 may be used for example addresses. In the example below, we use two example networks. In order to be conformant to [RFC3330], we divide the given address block into two networks by subnetting with a 25-bit netmask (192.0.2.0/25) as follows:
注：[RFC3330]に記載されているように、アドレスブロック192.0.2.0/24は、アドレスの場合に使用できます。以下の例では、2つのサンプルネットワークを使用しています。[RFC3330]に準拠するために、25ビットネットマスク（192.0.2.0/25）でサブネットでサブネットで2つのネットワークに与えられたアドレスブロックを2つのネットワークに分割します。
Network A: 192.0.2.0 ... 192.0.2.127 Network B: 192.0.2.128 ... 192.0.2.255
ネットワークA：192.0.2.0 ... 192.0.2.127ネットワークB：192.0.2.128 ... 192.0.2.255
Let's suppose someone needs to monitor the individual Flows in a Diffserv network in order to compare traffic amount trend with the terms outlined in a Service Level Agreement (SLA). Flows are distinguished by source and destination address. The information to export in this case is:
トラフィック量の傾向をサービスレベル契約（SLA）で概説した用語と比較するために、誰かがDiffServネットワーク内の個々のフローを監視する必要があるとしましょう。フローは、ソースおよび宛先アドレスによって区別されます。この場合にエクスポートする情報は次のとおりです。
- IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- IPv4ソースIPアドレス：[RFC5102]のsoultyIpv4Address、4オクテットの長さ
- IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- IPv4宛先IPアドレス：[RFC5102]のDestinationIPv4Address、4オクテットの長さ
- DSCP: ipDiffServCodePoint in [RFC5102], with a length of 1 octet
- DSCP：[RFC5102]のIPDIFFSERVCODEPOINT、1オクテットの長さ
- Number of octets of the Flow: octetDeltaCount in [RFC5102], with a length of 4 octets
- フローのオクテットの数：[RFC5102]のOctetDeltacount、4オクテットの長さ
The Template set will look as follows:
テンプレートセットは次のように見えます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 24 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipDiffServCodePoint = 195 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The information to be exported might be as listed in the following example table:
エクスポートされる情報は、次の例の表にリストされている可能性があります。
Src. IP addr. | Dst. IP addr. | DSCP | Octets Number
--------------+---------------+--------+--------------
192.0.2.12 | 192.0.2.144 | 46 | 120868
192.0.2.24 | 192.0.2.156 | 46 | 310364
192.0.2.36 | 192.0.2.168 | 46 | 241239
In the example we use Diffserv codepoint 46, recommended for the Expedited Forwarding Per Hop Behavior (EF PHB) in [RFC3246].
この例では、[RFC3246]のホップあたりの迅速な転送（EF PHB）に推奨されるDiffServ CodePoint 46を使用します。
The Flow Records will then look as follows:
フローレコードは次のように見えます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 43 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.144 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 46 | 120868 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.156 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 46 | 310364 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 192.0.2.168 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 46 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 241239 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measurement results reported in IPFIX records can provide useful input for traffic profiling. IPFIX records captured over a long period of time can be used to track and anticipate network growth and usage. Such information is valuable for trend analysis and network planning.
IPFIXレコードで報告されている測定結果は、トラフィックプロファイリングに有用な入力を提供できます。長期間にわたってキャプチャされたIPFIXレコードを使用して、ネットワークの成長と使用を追跡および予測できます。このような情報は、トレンド分析とネットワーク計画に役立ちます。
The parameters of interest are determined by the profiling objectives. Example parameters for traffic profiling are Flow duration, Flow volume, burstiness, the distribution of used services and protocols, the amount of packets of a specific type, etc. [RFC3917].
関心のあるパラメーターは、プロファイリング目標によって決定されます。トラフィックプロファイリングのパラメーターの例は、フロー持続時間、フローボリューム、バーティネス、使用済みサービスとプロトコルの分布、特定のタイプのパケットの量などです[RFC3917]。
The distribution of services and protocols in use can be analyzed by configuring appropriate Flows Keys for Flow discrimination. Protocols can be distinguished by the protocolIdentifier IE. Portnumbers (e.g., udpDestinationPort) often provide information about services in use. Those Flow Keys are defined in [RFC5102]. If portnumbers are not sufficient for service discrimination, further parts of the packet may be needed. Header fields can be expressed by IEs from [RFC5102].
使用中のサービスとプロトコルの分布は、フロー識別のために適切なフローキーを構成することにより分析できます。プロトコルは、Protocolidentifier IEによって区別できます。Portnumbers（udpdestinationportなど）は、多くの場合、使用中のサービスに関する情報を提供します。これらのフローキーは[RFC5102]で定義されています。Portnumbersがサービス差別に十分でない場合、パケットのさらなる部分が必要になる場合があります。ヘッダーフィールドは、[RFC5102]のIESで表現できます。
Packet payload can be reported by using the IE ipPayloadPacketSection in [RFC5477].
[RFC5477]のIE IPPayLoadPacketectionを使用して、パケットペイロードを報告できます。
The Flow duration can be calculated from the Flow Timestamp IEs defined in [RFC5102] (e.g., flowEndMicroseconds - flowStartMicroseconds). The number of packets and number of bytes of a Flow are represented in the per-flow counter IEs (e.g., packetTotalCount, octetTotalCount). The burstiness of a Flow can be calculated from the Flow volume measured at different time intervals.
フロー期間は、[RFC5102]で定義されたフロータイムスタンプIEから計算できます（たとえば、FlowEndMicroSeconds -Flow -StartMicroseconds）。パケットの数とフローのバイト数は、フローごとのカウンター（例：packettotalcount、octettotalcount）で表されます。フローの爆発は、異なる時間間隔で測定されたフローボリュームから計算できます。
Traffic engineering aims at the optimization of network resource utilization and traffic performance [RFC2702]. Typical parameters are link utilization, load between specific network, nodes, number, size and entry/exit points of active Flows, and routing information [RFC3917].
トラフィックエンジニアリングは、ネットワークリソースの利用とトラフィックパフォーマンスの最適化を目的としています[RFC2702]。典型的なパラメーターは、リンクの使用率、特定のネットワーク間の負荷、アクティブフローのノード、数、サイズ、エントリポイント、およびルーティング情報[RFC3917]です。
The size of Flows in packets and bytes can be reported by the IEs packetTotalCount and octetTotalCount. Utilization of a physical link can be reported by using a coarse-grained Flow definition (e.g., based on identifier IEs such as egressInterface or ingressInterface) and per-flow counter IEs (e.g., packetTotalCount, octetTotalCount) defined in [RFC5102].
パケットとバイトのフローのサイズは、IES packettotalcountとoctettotalcountによって報告できます。物理リンクの利用は、[RFC5102]で定義されている粗粒のフロー定義（例えば、EgressInterfaceやIngressInterfaceなどの識別子IE）およびフローごとのカウンターIE（例：PackettotalCount、octettotalcount）を使用して報告できます。
The load between specific network nodes can be reported in the same way if one interface of a network node receives only traffic from exactly one neighbor node (as is usually the case). If the ingress interface is not sufficient for an unambiguous identification of the neighbor node, sub-IP header fields IEs (like sourceMacAddress) can be added as Flow Keys.
特定のネットワークノード間の負荷は、ネットワークノードの1つのインターフェイスが正確に1つのネイバーノードからトラフィックのみを受信する場合、同じ方法で報告できます（通常の場合のように）。イングレスインターフェイスが近隣ノードの明確な識別に十分でない場合、サブIPヘッダーフィールド（sourcemacaddressなど）をフローキーとして追加できます。
The IE observedFlowTotalCount provides the number of all Flows exported for the Observation Domain since the last initialization of the Metering Process [RFC5102]. If this IE is exported at subsequent points in time, one can derive the number of active Flows in a specific time interval from the difference of the reported counters. The configured Flow termination criteria have to be taken into account to interpret those numbers correctly.
IEの観測FlowTotalCountは、計測プロセスの最後の初期化以降、観測ドメインにエクスポートされるすべてのフローの数を提供します[RFC5102]。これが後続の時点でエクスポートされる場合、報告されたカウンターの差から特定の時間間隔でアクティブフローの数を導き出すことができます。構成されたフロー終了基準を考慮に入れて、それらの数値を正しく解釈する必要があります。
Entry and exit points can be derived from Flow Records if Metering Processes are installed at all edges of the network and results are mapped in accordance to Flow Keys. For this and other analysis methods that require the mapping of records from different Observation Points, the same Flow Keys should be used at all Observation Points. The path that packets take through a network can be investigated by using hash-based sampling techniques as described in [DuGr00] and [RFC5475]. For this, IEs from [RFC5477] are needed.
ネットワークのすべてのエッジに計量プロセスがインストールされ、結果がフローキーに従ってマッピングされている場合、エントリと出口ポイントはフローレコードから導出できます。さまざまな観測ポイントからのレコードのマッピングを必要とするこの分析方法およびその他の分析方法では、すべての観測ポイントで同じフローキーを使用する必要があります。[DUGR00]および[RFC5475]に記載されているように、ハッシュベースのサンプリング手法を使用して、パケットをネットワークに通すパスを調査できます。このためには、[RFC5477]のIESが必要です。
Neither [RFC5102] nor [RFC5477] defines IEs suitable for exporting routing information.
[RFC5102]も[RFC5477]も、ルーティング情報のエクスポートに適したIEを定義していません。
Attack and intrusion detection are among the IPFIX target applications described in [RFC3917]. Due to the enormous amount of different network attack types, only general requirements could be addressed in [RFC3917].
攻撃と侵入検出は、[RFC3917]で説明されているIPFIXターゲットアプリケーションの1つです。膨大な量の異なるネットワーク攻撃タイプのため、[RFC3917]では一般的な要件のみに対処できます。
The number of metrics useful for attack detection is as diverse as attack patterns themselves. Attackers adapt rapidly to circumvent detection methods and try to hide attack patterns using slow or stealth attacks. Furthermore, unusual traffic patterns are not always caused by malicious activities. A sudden traffic increase may be caused by legitimate users who seek access to a recently published web content. Strange traffic patterns may also be caused by misconfiguration.
攻撃検出に役立つメトリックの数は、攻撃パターン自体と同じくらい多様です。攻撃者は迅速に適応して検出方法を回避し、スローまたはステルス攻撃を使用して攻撃パターンを隠そうとします。さらに、異常な交通パターンは、常に悪意のある活動によって引き起こされるわけではありません。突然のトラフィックの増加は、最近公開されたWebコンテンツへのアクセスを求める合法的なユーザーによって引き起こされる可能性があります。奇妙なトラフィックパターンは、誤った構成によって引き起こされる場合があります。
IPFIX can export Flow information for arbitrary Flow definitions as defined in [RFC5101]. Packet information can be exported with IPFIX by using the additional Information Elements described in [RFC5477]. With this, theoretically all information about traffic in the network at the IP layer and above is accessible. This data either can be used directly to detect anomalies or can provide the basis for further post-processing to generate more complex attack detection metrics.
IPFIXは、[RFC5101]で定義されている任意のフロー定義のフロー情報をエクスポートできます。[RFC5477]で説明されている追加情報要素を使用して、パケット情報をIPFIXでエクスポートできます。これにより、理論的には、IPレイヤー以降のネットワーク内のトラフィックに関するすべての情報にアクセスできます。このデータは、異常を検出するために直接使用するか、さらに複雑な攻撃検出メトリックを生成するためのさらに後処理の基礎を提供することができます。
Depending on the attack type, different metrics are useful. A sudden increase of traffic load can be a hint that an attack has been launched. The overall traffic at an Observation Point can be monitored using per-flow counter IEs like packetTotalCount or octetTotalCount as described in Section 2.3. The number of active Flows can be monitored by regular reporting of the observedFlowTotalCount defined in [RFC5102].
攻撃の種類によっては、異なるメトリックが便利です。突然のトラフィック負荷の増加は、攻撃が開始されたというヒントになる可能性があります。セクション2.3で説明されているように、パケットカウントやオクテットタルクアントなど、フローごとのカウンターを使用して、観測点での全体的なトラフィックを監視できます。アクティブフローの数は、[RFC5102]で定義されている観察されたフラウトータルクアウントの定期的な報告によって監視できます。
A sudden increase of Flows from different sources to one destination may be caused by an attack on a specific host or network node using spoofed addresses. The number of Flows from or to specific networks or hosts can be observed by using source and destination addresses as Flow Keys and observing the number of active Flows as explained above. Many Flows to the same machine, but on different ports, or many Flows to the same port and different machines may be an indicator for vertical or horizontal port scanning activities. The number of Flows to different ports can be reported by using the portnumber Information Elements (udpSourcePort, udpDestinationPort, tcpSourcePort, tcpDestinationPort) defined in [RFC5102] as Flow Keys.
さまざまなソースから1つの宛先へのフローの突然の増加は、スプーフィングされたアドレスを使用して特定のホストまたはネットワークノードへの攻撃によって引き起こされる場合があります。特定のネットワークまたはホストへのフローの数は、ソースアドレスと宛先アドレスをフローキーとして使用し、上記のようにアクティブなフローの数を観察することで観察できます。多くは同じマシンに流れますが、異なるポートで、または同じポートや異なるマシンへの多くの流れは、垂直または水平のポートスキャンアクティビティの指標になる場合があります。さまざまなポートへのフローの数は、[RFC5102]でフローキーとして定義されているPortNumber情報要素（udpsourceport、udpdestinationport、tcpsourceport、tcpdestinationport）を使用して報告できます。
An unusual ratio of TCP-SYN to TCP-FIN packets can refer to SYN-flooding. The number of SYN and FIN packets in a Flow can be reported with the IPFIX Information Elements tcpSynTotalCount and tcpFinTotalCount defined in [RFC5102].
TCP-SynとTCP-FINパケットの異常な比率は、Syn-Floodingを参照できます。フロー内のsynとfinパケットの数は、[rfc5102]で定義されているipfix情報要素tcpsyntotalcountおよびtcpfintotalcountで報告できます。
Worms may leave signatures in traffic patterns. Detecting such events requires more detailed measurements and post-processing than detecting simple changes in traffic volumes.
ワームは、交通パターンに署名を残す場合があります。このようなイベントを検出するには、交通量の単純な変更を検出するよりも、より詳細な測定と後処理が必要です。
A difficult task is the separation of good from bad packets to prepare and launch counteraction. This may require a deeper look into packet content by using further header field IEs from [RFC5102] and/or packet payloads from IE ipPayloadPacketSection in [RFC5477].
困難な作業は、カウンターアクションを準備および起動するための悪いパケットから善を分離することです。これには、[RFC5477]のIE IPayLoadPacketectececeからのさらなるヘッダーフィールドIEおよび/またはパケットペイロードを使用することにより、パケットコンテンツをより深く検索する必要があります。
Furthermore, the amount of resources needed for measurement and reporting increases with the level of granularity required to detect an attack. Multi-step analysis techniques may be useful, e.g., to launch an in-depth analysis (e.g., based on packet information) in case the Flow information shows suspicious patterns. In order to supervise traffic to a specific host or network node, it is useful to apply filtering methods such as those described in [RFC5475].
さらに、攻撃を検出するために必要な粒度のレベルとともに、測定と報告に必要なリソースの量が増加します。マルチステップ分析手法は、フロー情報が疑わしいパターンを示した場合に備えて、詳細な分析（たとえば、パケット情報に基づいて）を起動するのに役立つ場合があります。特定のホストまたはネットワークノードへのトラフィックを監督するために、[RFC5475]に記載されているようなフィルタリング方法を適用することが有用です。
Mapping the two directions of communication is often useful for checking correct protocol behavior (see Section 4.6). A correlation of IPFIX data from multiple Observation Points (see Section 2.5.1) allows assessing the propagation of an attack and can help to locate its source.
通信の2つの方向をマッピングすることは、正しいプロトコルの動作をチェックするのに役立つことがよくあります（セクション4.6を参照）。複数の観測ポイントからのIPFIXデータの相関（セクション2.5.1を参照）により、攻撃の伝播を評価し、そのソースを見つけるのに役立ちます。
The integration of previous measurement results helps to review traffic changes over time for detection of traffic anomalies and provides the basis for forensic analysis. A standardized storage format for IPFIX data would support the offline analysis of data from different operators.
以前の測定結果の統合は、トラフィックの異常を検出するために時間の経過とともにトラフィックの変化を確認するのに役立ち、法医学分析の基礎を提供します。IPFIXデータの標準化されたストレージ形式は、異なる演算子からのデータのオフライン分析をサポートします。
Nevertheless, capturing full packet traces at all Observation Points in the network is not viable due to resource limitations and privacy concerns. Therefore, metrics should be chosen wisely to allow a solid detection with minimal resource consumption. Resources can be saved, for instance, by using coarser-grained Flow definitions, reporting pre-processed metrics (e.g., with additional Information Elements), or deploying sampling methods.
それにもかかわらず、ネットワーク内のすべての観測ポイントで完全なパケットトレースをキャプチャすることは、リソースの制限とプライバシーの懸念のために実行可能ではありません。したがって、リソース消費を最小限に抑えて強固な検出を可能にするために、メトリックを賢明に選択する必要があります。たとえば、粗い粒度のフロー定義を使用して、前処理されたメトリック（追加情報要素を使用するなど）の報告、またはサンプリング方法の展開により、リソースを保存できます。
In many cases, only derived metrics provide sufficient evidence about security incidents. For example, comparing the number of SYN and FIN packets for a specific time interval can reveal an ongoing SYN attack, which is not obvious from unprocessed packet and Flow data. Further metrics like the cumulated sum of various counters, distributions of packet attributes, or spectrum coefficients have been used to identify a variety of attacks.
多くの場合、派生したメトリックのみがセキュリティインシデントに関する十分な証拠を提供します。たとえば、特定の時間間隔のSynとFinパケットの数を比較すると、未処理のパケットとフローデータからは明らかではない継続的なSyn攻撃が明らかになります。さまざまなカウンターの累積合計、パケット属性の分布、またはスペクトル係数などのさらなるメトリックを使用して、さまざまな攻撃を特定しています。
In order to detect attacks early, it is useful to process the data as soon as possible in order to generate significant metrics for the detection. Pre-processing of raw packet and Flow data already at the measurement device can speed up the detection process and reduces the amount of data that need to be exported. Furthermore, it is possible to directly report derived metrics by defining appropriate Information Elements. Immediate data export in case of a potential incident is desired. IPFIX supports such source-triggered exporting of information due to the push model approach. Nevertheless, further exporting criteria have to be implemented to export IPFIX records upon incident detection events and not only upon flow-end or fixed-time intervals.
攻撃を早期に検出するためには、検出の重要なメトリックを生成するために、できるだけ早くデータを処理することが有用です。すでに測定デバイスですでに生のパケットとフローデータの前処理は、検出プロセスをスピードアップし、エクスポートする必要があるデータの量を減らすことができます。さらに、適切な情報要素を定義することにより、派生したメトリックを直接報告することができます。潜在的なインシデントの場合の即時データエクスポートが必要です。IPFIXは、プッシュモデルアプローチにより、このようなソーストリガー情報のエクスポートをサポートしています。それにもかかわらず、フローエンドまたは固定時間間隔だけでなく、インシデント検出イベント時にIPFIXレコードをエクスポートするために、さらなるエクスポート基準を実装する必要があります。
Intrusion detection would profit from the combination of IPFIX functions with AAA functions (see Section 3.5). Such an interoperation enables further means for attacker detection, advanced defense strategies, and secure inter-domain cooperation.
侵入検出は、IPFIX関数とAAA関数の組み合わせから利益を得ます（セクション3.5を参照）。このような相互操作により、攻撃者の検出、高度な防衛戦略、およびドメイン間協力を確保するためのさらなる手段が可能になります。
Quality of service (QoS) monitoring is one target application of the IPFIX protocol [RFC3917]. QoS monitoring is the passive observation of the transmission quality for single Flows or traffic aggregates in the network. One example of its use is the validation of QoS guarantees in service level agreements (SLAs). Typical QoS parameters are loss [RFC2680], one-way [RFC2679] and round-trip delay [RFC2681], and delay variation [RFC3393]. Whenever applicable, the IP Performance Metrics (IPPM) definitions [RFC4148] should be used when reporting QoS metrics.
サービス品質（QOS）監視は、IPFIXプロトコル[RFC3917]のターゲットアプリケーションの1つです。QoSモニタリングは、ネットワーク内の単一のフローまたはトラフィック集合体の伝送品質の受動的な観察です。その使用の1つの例は、サービスレベル契約（SLA）におけるQoS保証の検証です。典型的なQoSパラメーターは、損失[RFC2680]、一方向[RFC2679]、および往復遅延[RFC2681]、および遅延変動[RFC3393]です。該当する場合はいつでも、QoSメトリックを報告するときにIPパフォーマンスメトリック（IPPM）定義[RFC4148]を使用する必要があります。
The calculation of those QoS metrics requires per-packet processing. Reporting packet information with IPFIX is possible by simply considering a single packet as Flow. [RFC5101] also allows the reporting of multiple identical Information Elements in one Flow Record. Using this feature for reporting information about multiple packets in one record would require additional agreement on semantics regarding the order of Information Elements (e.g., which timestamp belongs to which packet payload in a sequence of Information Elements). [RFC5477] defines useful additional Information Elements for exporting per-packet information with IPFIX.
これらのQoSメトリックの計算には、パケットごとの処理が必要です。IPFIXでパケット情報を報告することは、単一のパケットをフローとして考慮するだけで可能です。[RFC5101]は、1つのフローレコードに複数の同一の情報要素を報告することもできます。この機能を使用して、1つのレコードで複数のパケットに関する情報を報告するには、情報要素の順序に関するセマンティクスに関する追加の合意が必要です（たとえば、どのタイムスタンプが情報要素のシーケンスでどのパケットペイロードに属しますか）。[RFC5477]は、IPFIXでパケットごとの情報をエクスポートするための有用な追加情報要素を定義します。
Some QoS metrics require the correlation of data from multiple Observation Points. For this, the clocks of the involved Metering Processes must be synchronized. Furthermore, it is necessary to recognize that the same packet was observed at different Observation Points.
一部のQoSメトリックでは、複数の観測ポイントからのデータの相関が必要です。このためには、関係する計量プロセスのクロックを同期する必要があります。さらに、同じパケットが異なる観測点で観察されたことを認識する必要があります。
This can be done by capturing parts of the packet content (packet header and/or parts of the payload) that do not change on the way to the destination. Based on the packet content, it can be recognized when the same packet arrived at another Observation Point. To reduce the amount of measurement data, a unique packet ID can be calculated from the packet content, e.g., by using a Cyclic Redundancy Check (CRC) or hash function instead of transferring and comparing the unprocessed content. Considerations on collision probability and efficiency of using such packet IDs are described in [GrDM98], [DuGr00], and [ZsZC01].
これは、目的地に向かう途中で変更されないパケットコンテンツの一部（パケットヘッダーおよび/またはペイロードの一部）をキャプチャすることで実行できます。パケットコンテンツに基づいて、同じパケットが別の観測点に到着したときに認識できます。測定データの量を減らすために、未処理のコンテンツを転送および比較する代わりに、環状冗長チェック（CRC）またはハッシュ関数を使用して、パケットコンテンツから一意のパケットIDを計算できます。このようなパケットIDを使用する衝突確率と効率に関する考慮事項は、[GRDM98]、[DUGR00]、および[ZSZC01]で説明されています。
IPFIX allows the reporting of several IP and transport header fields (see Sections 5.3 and 5.4 in [RFC5102]). Using only those fields for packet recognition or ID generation can be sufficient in scenarios where those header fields vary a lot among subsequent packets, where a certain amount of packet ID collisions are tolerable, or where packet IDs need to be unique only for a small time interval.
IPFIXを使用すると、いくつかのIPおよびトランスポートヘッダーフィールドのレポートが可能になります（[RFC5102]のセクション5.3および5.4を参照）。パケット認識またはID生成にこれらのフィールドのみを使用すると、それらのヘッダーフィールドが後続のパケット、ある程度のパケットID衝突が許容される、またはパケットIDが小さい時間のためにのみ一意である必要があるシナリオでは十分です。間隔。
For including packet payload information, the Information Element ipPayloadPacketSection defined in [RFC5477] can be used. The Information Element ipHeaderPacketSection can also be used. However, header fields that can change on the way from source to destination have to be excluded from the packet ID generation because they may differ at different Observation Points.
パケットペイロード情報を含めるために、[RFC5477]で定義されている情報要素iPpayLoadPacketectionを使用できます。情報要素ipheaderpacketectectionも使用できます。ただし、ソースから目的地へと途中で変更できるヘッダーフィールドは、異なる観測点で異なる場合があるため、パケットIDの生成から除外する必要があります。
For reporting packet IDs generated by a CRC or hash function, the Information Element digestHashValue defined in [RFC5477] can be used.
CRCまたはハッシュ関数によって生成されたパケットIDを報告するには、[RFC5477]で定義されている情報要素の消化器系を使用できます。
The following examples show which Information Elements need to be reported by IPFIX to generate specific QoS metrics. As an alternative, the metrics can be generated directly at the exporter and IPFIX can be used to export the metrics (see Section 2.7).
次の例は、特定のQoSメトリックを生成するためにIPFIXによって報告する必要がある情報要素を示しています。別の方法として、メトリックは輸出業者で直接生成でき、IPFIXを使用してメトリックをエクスポートできます（セクション2.7を参照）。
The passive measurement of round-trip time (RTT) can be performed by using packet pair matching techniques as described in [Brow00]. For the measurements, request/response packet pairs from protocols such as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK, DATA/ACK) are utilized to passively observe the RTT [Brow00]. This technique requires the correlation of data from both directions.
往復時間（RTT）の受動的測定は、[BROW00]に記載されているように、パケットペアマッチング手法を使用して実行できます。測定では、DNS、ICMP、SNMP、TCP（Syn/Syn_ack、Data/ACK）などのプロトコルからの要求/応答パケットのペアを利用して、RTT [BROW00]を受動的に観察します。この手法には、両方向からのデータの相関が必要です。
Required Information Elements per packet (DNS example): - Packet arrival time: observationTimeMicroseconds [RFC5477] - DNS header: ipPayloadPacketSection [RFC5477]
パケットごとの必要な情報要素（DNS例）： - パケット到着時間：観測時間マイクロ秒[RFC 5477] -DNSヘッダー：IPPAYLOADPACKETECTION [RFC5477]
Required functions: - Recognition of request/response packet pairs
必要な関数： - リクエスト/応答パケットの認識ペア
Remarks: - Requires Information Elements from [RFC5477]. - observationTimeMicroseconds can be substituted by flowStartMicroseconds [RFC5102] because a single packet can be represented as a Flow. - If time values with a finer granularity are needed, observationTimeNanoseconds can be used.
備考： - [RFC5477]の情報要素が必要です。-1つのパケットをフローとして表すことができるため、観測チメミックロシンコンドはFlowStartMicroSeconds [RFC5102]に置き換えることができます。 - より細かい粒度が必要な時間値が必要な場合は、観察チメナノ秒を使用できます。
Passive one-way delay measurements require the collection of data at two Observation Points. As mentioned above, synchronized clocks are needed to avoid time-differences at the involved Observation Points.
受動的な一元配置遅延測定では、2つの観測点でデータの収集が必要です。上記のように、関連する観測点での時間差を避けるために、同期されたクロックが必要です。
The recognition of packets at the second Observation Point can be based on parts of the packet content directly. A more efficient way is to use a packet ID (generated from packet content).
2番目の観測点でのパケットの認識は、パケットコンテンツの一部に直接基づいています。より効率的な方法は、パケットID（パケットコンテンツから生成された）を使用することです。
Required Information Elements per packet (with packet ID): - Packet arrival time: observationTimeMicroseconds [RFC5477] - Packet ID: digestHashValue [RFC5477]
パケットごとの必要な情報要素（パケットIDを使用）： - パケット到着時間：ObservationTimemicRoseconds [RFC5477] - パケットID：Digesthashvalue [RFC5477]
Required functions: - Packet ID generation - Delay calculation (from arrival times at the two Observation Points)
必要な関数： - パケットID生成 - 遅延計算（2つの観測ポイントの到着時間から）
Remarks: - Requires Information Elements from [RFC5477]. - observationTimeMicroseconds can be substituted by flowStartMicroseconds [RFC5102], because a single packet can be represented as a Flow. - If time values with a finer granularity are needed, observationTimeNanoseconds can be used.
備考： - [RFC5477]の情報要素が必要です。-1つのパケットをフローとして表すことができるため、観測チメミックルセカンドはFlowStartMicroSeconds [RFC5102]を置き換えることができます。 - より細かい粒度が必要な時間値が必要な場合は、観察チメナノ秒を使用できます。
- The amount of content used for ID generation influences the number of collisions (different packets that map to the same ID) that can occur. Investigations on this and other considerations on packet ID generation can be found in [GrDM98], [DuGr00], and [ZsZC01].
- ID生成に使用されるコンテンツの量は、発生する可能性のある衝突の数（同じIDにマッピングされる異なるパケット）に影響します。これおよびパケットID生成に関するその他の考慮事項に関する調査は、[Grdm98]、[dugr00]、および[zszc01]に記載されています。
IPFIX data can be used to share information with neighbor providers. A few recommendations should be considered if IPFIX records travel over the public Internet, compared to its usage within a single domain. First of all, security threat levels are higher if data travels over the public Internet. Protection against disclosure or manipulation of data is even more important than for intra-domain usage. Therefore, Transport Layer Security (TLS) or Datagram Transport Layer Security should be used as described in [RFC5101].
IPFIXデータを使用して、近隣プロバイダーと情報を共有できます。IPFixレコードが単一のドメイン内での使用と比較して、IPFIXレコードがパブリックインターネット上を移動する場合、いくつかの推奨事項を考慮する必要があります。まず第一に、データがパブリックインターネットを介して移動する場合、セキュリティの脅威レベルは高くなります。データの開示または操作に対する保護は、ドメイン内の使用よりもさらに重要です。したがって、[RFC5101]に記載されているように、輸送層のセキュリティ（TLS）またはデータグラムの輸送層のセキュリティを使用する必要があります。
Furthermore, data transfer should be congestion-aware in order to allow untroubled coexistence with other data Flows in public or foreign networks. That means transport over Stream Control Transmission Protocol (SCTP) or TCP is required.
さらに、公共または外国のネットワークでの他のデータフローとの交通のない共存を可能にするために、データ転送は渋滞に触れる必要があります。つまり、ストリーム制御伝送プロトコル（SCTP）またはTCPを介した輸送が必要です。
Some ISPs are still reluctant to share information due to concerns that competing ISPs might exploit network information from neighbor providers to strengthen their own position in the market. Nevertheless, technical needs have already triggered the exchange of data in the past (e.g., exchange of routing information by BGP). The need to provide inter-domain guarantees is one big incentive to increase inter-domain cooperation. The necessity to defend networks against current and future threats (denial-of-service attacks, worm distributions, etc.) will hopefully increase the willingness to exchange measurement data between providers.
一部のISPは、競合するISPが近隣プロバイダーからのネットワーク情報を活用して市場での自分の立場を強化する可能性があるという懸念のために、まだ情報を共有することをためられています。それにもかかわらず、技術的なニーズはすでに過去のデータ交換を引き起こしています（たとえば、BGPによるルーティング情報の交換）。ドメイン間保証を提供する必要性は、ドメイン間協力を増やすための大きなインセンティブです。現在および将来の脅威（サービス拒否攻撃、ワーム分布など）からネットワークを守る必要性は、プロバイダー間の測定データを交換する意欲を高めることを願っています。
The IPFIX protocol is used to transport Flow and packet information to provide the input for the calculation of a variety of metrics (e.g., for QoS validation or attack detection). IPFIX can also be used to transfer these metrics directly, e.g., if the metric calculation is co-located with the Metering and Exporting Processes.
IPFIXプロトコルは、流れとパケット情報を輸送するために使用され、さまざまなメトリックの計算の入力を提供します（たとえば、QoS検証または攻撃検出など）。IPFixは、メートルの計算が計量プロセスとエクスポートプロセスと共同で配置されている場合、これらのメトリックを直接転送するためにも使用できます。
It doesn't matter which measurement and post-processing functions are applied to generate a specific metric. IPFIX can be used to transport the results from passive and active measurements and from post-processing operations. For the reporting of derived metrics, additional Information Elements need to be defined.
特定のメトリックを生成するために、どの測定および後処理機能が適用されるかは関係ありません。IPFIXを使用して、パッシブおよびアクティブな測定および後処理操作から結果を輸送できます。派生メトリックのレポートのために、追加情報要素を定義する必要があります。
For most QoS metrics like loss, delay, delay variation, etc., standard IPPM definitions exist. In case such metrics are reported with IPFIX, the IPPM standard definition should be used.
損失、遅延、遅延変動などなどのほとんどのQoSメトリックには、標準のIPPM定義が存在します。IPFIXでこのようなメトリックが報告されている場合、IPPM標準定義を使用する必要があります。
The following table shows an overview of the Information Elements required for the target applications described in [RFC3917] (M-mandatory, R-recommended, O-optional).
次の表は、[RFC3917]（Mマンダトリー、R推奨、O-オプション）で説明されているターゲットアプリケーションに必要な情報要素の概要を示しています。
| Application | [RFC5102] | [RFC5477] | additional IEs |
+-------------+------------+--------------+-----------------+
| Accounting | M | - | - |
+-------------+------------+--------------+-----------------+
| Traffic | M | O | - |
| Profiling | | | |
+-------------+------------+--------------+-----------------+
| Traffic | M | - | O |
| Engineering | | | (routing info) |
+-------------+------------+--------------+-----------------+
| Attack | M | R | R |
| Detection | | |(derived metrics)|
+-------------+------------+--------------+-----------------+
| QoS | M | M | O |
| Monitoring | |(most metrics)|(derived metrics)|
+-------------+------------+--------------+-----------------+
For accounting, the IEs in [RFC5102] are sufficient. As mentioned above, IPFIX does not conform to the reliability requirements demanded by [RFC2975] for usage-based billing systems (see Section 4.2). For traffic profiling, additional IEs from [RFC5477] can be useful to gain more insight into the traffic. For traffic engineering, Flow information from [RFC5102] is sufficient, but it would profit from routing information, which could be exported by IPFIX. Attack detection usually profits from further insight into the traffic. This can be achieved with IEs from [RFC5477]. Furthermore, the reporting of derived metrics in additional IEs would be useful. Most QoS metrics require the use of IEs from [RFC5477]. IEs from [RFC5477] are also useful for the mapping of results from different Observation Points as described in Section 2.5.1.
会計の場合、[RFC5102]のIEで十分です。上記のように、IPFIXは、使用法ベースの請求システムについて[RFC2975]で要求される信頼性要件に準拠していません（セクション4.2を参照）。トラフィックプロファイリングの場合、[RFC5477]からの追加のIEは、トラフィックについてより洞察を得るのに役立ちます。トラフィックエンジニアリングの場合、[RFC5102]からのフロー情報は十分ですが、IPFIXによってエクスポートされる可能性のあるルーティング情報から利益を得ます。攻撃検出は通常、トラフィックに関するさらなる洞察から利益を得ます。これは、[RFC5477]のIESで実現できます。さらに、追加のIEでの派生メトリックの報告は有用です。ほとんどのQoSメトリックでは、[RFC5477]からIESを使用する必要があります。[RFC5477]のIEは、セクション2.5.1で説明されているように、異なる観測点からの結果のマッピングにも役立ちます。
From the beginning, IPFIX has been designed for IPv4 and IPv6. Therefore, IPFIX can be used in IPv4 and IPv6 networks without limitations. The usage of IPFIX in IPv6 networks has two aspects:
最初から、IPFIXはIPv4およびIPv6用に設計されています。したがって、IPFIXは、IPv4およびIPv6ネットワークで制限なく使用できます。IPv6ネットワークでのIPFIXの使用には、次の2つの側面があります。
- Generation and reporting of IPFIX records about IPv6 traffic - Exporting IPFIX records over IPv6
- IPV6トラフィックに関するIPFIXレコードの生成とレポート-IPV6を介したIPFIXレコードのエクスポート
The generation and reporting of IPFIX records about IPv6 traffic is possible. Appropriate Information Elements for the reporting of IPv6 traffic are defined in [RFC5102]. Exporting IPFIX records over IPv6 is not explicitly addressed in [RFC5101]. Since IPFIX runs over a transport protocol (SCTP, PR-SCTP, UDP, or TCP) and all potential IPFIX transport protocols can run in IPv6 networks, one just needs to provide the chosen transport protocol in the IPv6 network to run IPFIX over IPv6.
IPV6トラフィックに関するIPFIXレコードの生成とレポートは可能です。IPv6トラフィックの報告のための適切な情報要素は、[RFC5102]で定義されています。IPV6を介したIPFIXレコードのエクスポートは、[RFC5101]で明示的に対処されていません。IPFIXはトランスポートプロトコル（SCTP、PR-SCTP、UDP、またはTCP）を介して実行され、すべての潜在的なIPFIXトランスポートプロトコルがIPv6ネットワークで実行できるため、IPV6オーバーIPFIXを実行するためにIPv6ネットワークで選択したトランスポートプロトコルを提供する必要があります。
PSAMP defines packet selection methods, their configuration at routers and probes, and the reporting of packet information.
PSAMPは、パケット選択方法、ルーターとプローブでの構成、およびパケット情報のレポートを定義します。
PSAMP uses IPFIX as a basis for exporting packet information [RFC5476]. [RFC5477] describes further Information Elements for exporting packet information and reporting configuration information.
PSAMPは、パケット情報をエクスポートするための基礎としてIPFIXを使用します[RFC5476]。[RFC5477]は、パケット情報をエクスポートし、構成情報を報告するためのさらなる情報要素について説明します。
The main difference between IPFIX and PSAMP is that IPFIX addresses the export of Flow Records, whereas PSAMP addresses the export of packet records. Furthermore, PSAMP explicitly addresses remote configuration. It defines a MIB for the configuration of packet selection processes. Remote configuration is not (yet) addressed in IPFIX, but one could consider extending the PSAMP MIB to also allow configuration of IPFIX processes.
IPFIXとPSAMPの主な違いは、IPFIXがフローレコードのエクスポートに対処し、PSAMPはパケットレコードのエクスポートに対処することです。さらに、PSAMPはリモート構成を明示的にアドレス指定します。パケット選択プロセスの構成のMIBを定義します。リモート構成はIPFIXでは（まだ）アドレス指定されていませんが、PSAMP MIBを拡張してIPFIXプロセスの構成も許可することを検討できます。
Remote Monitoring (RMON) [RFC3577] is a widely used monitoring system that gathers traffic data from RMON Agents in network devices. One major difference between RMON and IPFIX is that RMON uses SNMP for data export, whereas IPFIX defines its own push-oriented protocol. RMON defines MIBs that contain the information to be exported. In IPFIX, the data to be exported is defined as Information Elements.
リモート監視（RMON）[RFC3577]は、ネットワークデバイスのRMONエージェントからトラフィックデータを収集する広く使用されている監視システムです。RMONとIPFIXの大きな違いの1つは、RMONがデータエクスポートにSNMPを使用しているのに対し、IPFIXは独自のプッシュ指向プロトコルを定義していることです。RMONは、エクスポートする情報を含むMIBを定義します。IPFIXでは、エクスポートされるデータは情報要素として定義されます。
The most relevant MIBs for comparison with IPFIX are the Application Performance Measurement MIB (APM-MIB) [RFC3729] and the Transport Performance Metrics MIB (TPM-MIB) [RFC4150]. The APM-MIB has a complex system for tracking user application performance, with reporting about transactions and SLA threshold notification-trigger configuration, and persistence across DHCP lease expirations. It requires a full RMON2-MIB protocolDirTable implementation.
IPFIXと比較するための最も関連性の高いMIBSは、アプリケーションパフォーマンス測定MIB（APM-MIB）[RFC3729]と輸送パフォーマンスメトリックMIB（TPM-MIB）[RFC4150]です。APM-MIBには、ユーザーアプリケーションのパフォーマンスを追跡するための複雑なシステムがあり、トランザクションとSLAしきい値通知 - トリガー構成に関する報告、およびDHCPリースの満了間の永続性があります。完全なRMON2-MIBプロトコルディエル可能な実装が必要です。
The APM-MIB reports the performance of transactions. A transaction is a service-oriented term and describes the data exchange from the transaction start (when a user requests a service) until its completion. The performance parameters include response times, throughput, streaming responsiveness, and availability of services.
APM-MIBは、トランザクションのパフォーマンスを報告します。トランザクションはサービス指向の用語であり、トランザクションの開始から（ユーザーがサービスを要求したとき）の完了までデータ交換を説明します。パフォーマンスパラメーターには、応答時間、スループット、ストリーミング応答性、およびサービスの可用性が含まれます。
The RMON transaction concept differs from the IPFIX Flow concept. A Flow is a very generic term that allows one to group IP packets in accordance with common properties. In contrast to this, the term transaction is service-oriented and contains all data exchange required for service completion.
RMONトランザクションの概念は、IPFIXフローの概念とは異なります。フローは、一般的なプロパティに従ってIPパケットをグループ化できる非常に一般的な用語です。これとは対照的に、トランザクションという用語はサービス指向であり、サービスの完了に必要なすべてのデータ交換が含まれています。
In order to report such data with IPFIX, one would probably need a specific combination of multiple Flows and the ability to map those to the transaction. Due to the service-oriented focus of APM, the required metrics also differ. For instance, the RMON APM requires a metric for the responsiveness of services. Such metrics are not addressed in IPFIX.
そのようなデータをIPFIXで報告するには、おそらく複数のフローとそれらをトランザクションにマッピングする機能の特定の組み合わせが必要です。APMのサービス指向の焦点により、必要なメトリックも異なります。たとえば、RMON APMには、サービスの応答性のメトリックが必要です。このようなメトリックは、IPFIXでは扱われていません。
Furthermore, the APM-MIB allows the configuration of the transaction type to be monitored, which is currently not addressed in IPFIX.
さらに、APM-MIBを使用すると、トランザクションタイプの構成を監視することができますが、現在はIPFIXでは扱われていません。
The APM MIB could be considered as an extension of the IPFIX Metering Process where the application performance of a combination of multiple Flows is measured. If appropriate, IEs would be defined in the IPFIX information model and the IPFIX Device would support the APM MIB data collection, the solutions could be complementary. That means one could use IPFIX to export APM MIB transaction information.
APM MIBは、複数のフローの組み合わせのアプリケーションパフォーマンスが測定されるIPFIXメータープロセスの拡張と見なすことができます。必要に応じて、IEはIPFIX情報モデルで定義され、IPFIXデバイスはAPM MIBデータ収集をサポートします。ソリューションは補完的なものになる可能性があります。つまり、IPFIXを使用してAPM MIBトランザクション情報をエクスポートできます。
The TPM-MIB breaks out the APM-MIB transactions into sub-application level transactions. For instance, a web request is broken down into DNS, TCP, and HTTP sub-transactions. Such sub-transactions can be considered as bidirectional Flows. With an appropriate Flow definition and the ability to map both directions of a Flow (see Section 4.6), one could measure and report Flow characteristics of such sub-application level transaction with IPFIX.
TPM-MIBは、APM-MIBトランザクションをサブアプリケーションレベルトランザクションに分割します。たとえば、Web要求はDNS、TCP、およびHTTPサブトランザクションに分類されます。このようなサブトランザクションは、双方向フローと見なすことができます。適切なフロー定義とフローの両方向をマッピングする機能（セクション4.6を参照）を使用すると、IPFIXを使用したこのようなサブアプリケーションレベルのトランザクションのフロー特性を測定および報告できます。
The TPM-MIB requires APM-MIB and RMON2-MIB.
TPM-MIBには、APM-MIBとRMON2-MIBが必要です。
The IPFIX protocol can be used to carry IPPM network performance metrics or information that can be used to calculate those metrics (see Sections 2.5 and 2.7 for details and references).
IPFIXプロトコルを使用して、IPPMネットワークパフォーマンスメトリックまたはそれらのメトリックを計算するために使用できる情報を運ぶことができます（詳細と参照については、セクション2.5および2.7を参照）。
AAA defines a protocol and architecture for authentication, authorization, and accounting for service usage [RFC2903]. The DIAMETER protocol [RFC3588] is used for AAA communication, which is needed for network access services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture [RFC2903] provides a framework for extending AAA support to other services. DIAMETER defines the exchange of messages between AAA entities, e.g., between AAA clients at access devices and AAA servers, and among AAA servers. DIAMETER is used for the transfer of accounting records. In order to form accounting records for usage-based accounting measurement, data from the network is required. IPFIX defines a protocol to export such data from routers, measurement probes, and other devices. Therefore, it looks promising to connect those two architectures.
AAAは、サービス使用のための認証、承認、および会計のためのプロトコルとアーキテクチャを定義します[RFC2903]。直径プロトコル[RFC3588]は、ネットワークアクセスサービス（モバイルIP、NASREQ、およびROAMOPS）に必要なAAA通信に使用されます。AAAアーキテクチャ[RFC2903]は、AAAサポートを他のサービスに拡張するためのフレームワークを提供します。直径は、AAAエンティティと、たとえば、アクセスデバイスとAAAサーバーのAAAクライアント間、およびAAAサーバー間でメッセージの交換を定義します。直径は、会計記録の転送に使用されます。使用法ベースの会計測定のための会計記録を形成するには、ネットワークからのデータが必要です。IPFIXは、ルーター、測定プローブ、およびその他のデバイスからこのようなデータをエクスポートするプロトコルを定義しています。したがって、これらの2つのアーキテクチャを接続することは有望に見えます。
For all scenarios described here, one has to keep in mind that IPFIX does not conform to the reliability requirements for usage-based billing described in [RFC2975] (see Section 4.2). Using IPFIX without reliability extensions together with AAA would result in accounting scenarios that do not conform to usage-based billing requirements described in [RFC2975].
ここで説明するすべてのシナリオについては、[RFC2975]で説明されている使用可能請求の信頼性要件に適合しないことに留意する必要があります（セクション4.2を参照）。信頼性拡張機能なしでAAAとともにIPFIXを使用すると、[RFC2975]で説明されている使用法ベースの請求要件に準拠していない会計シナリオが生じます。
As shown in Section 2.1, accounting applications can directly incorporate an IPFIX Collecting Process to receive IPFIX records with information about the transmitted volume. Nevertheless, if a AAA infrastructure is in place, the cooperation between IPFIX and AAA provides many valuable synergistic benefits. IPFIX records can provide the input for AAA accounting functions and provide the basis for the generation of DIAMETER accounting records. However, as stated in Section 4.2, the use of IPFIX as described in [RFC5101] is currently limited to situations where the purpose of the accounting does not require reliability.
セクション2.1に示すように、アカウンティングアプリケーションには、IPFIXの収集プロセスを直接組み込んで、送信されたボリュームに関する情報を含むIPFIXレコードを受信できます。それにもかかわらず、AAAインフラストラクチャが導入されている場合、IPFIXとAAAの協力は多くの貴重な相乗効果をもたらします。IPFIXレコードは、AAA会計機能の入力を提供し、直径会計レコードの生成の基礎を提供できます。ただし、セクション4.2で述べたように、[RFC5101]で説明されているIPFIXの使用は、現在、会計の目的が信頼性を必要としない状況に限定されています。
Further potential features include the mapping of a user ID to Flow information (by using authentication information) or using the secure authorized exchange of DIAMETER accounting records with neighbor domains. The last feature is especially useful in roaming scenarios where the user connects to a foreign network and the home provider generates the invoice.
さらなる潜在的な機能には、（認証情報を使用することで）情報をフローするためのユーザーIDのマッピング、または近隣ドメインとの直径の会計記録の安全な許可された交換を使用することが含まれます。最後の機能は、ユーザーが外国ネットワークに接続し、ホームプロバイダーが請求書を生成するローミングシナリオで特に役立ちます。
Coupling an IPFIX Collecting Process with AAA functions also has high potential for intrusion and attack detection. AAA controls network access and maintains data about users and nodes. AAA functions can help to identify the source of malicious traffic. Authorization functions are able to deny access to suspicious users or nodes. Therefore, coupling those functions with an IPFIX Collecting Process can provide an efficient defense against network attacks.
IPFIXの収集プロセスをAAA関数と結合することは、侵入と攻撃の検出の可能性も高いです。AAAはネットワークアクセスを制御し、ユーザーとノードに関するデータを維持します。AAA関数は、悪意のあるトラフィックの原因を特定するのに役立ちます。承認機能は、疑わしいユーザーまたはノードへのアクセスを拒否することができます。したがって、これらの関数をIPFIX収集プロセスと結合すると、ネットワーク攻撃に対する効率的な防御を提供できます。
Sharing IPFIX records (either directly or encapsulated in DIAMETER) with neighbor providers allows an efficient inter-domain attack detection. For this, it would be useful to allow remote configuration of measurement and record generation in order to provide information in the required granularity and accuracy. Since remote configuration is currently not addressed in IPFIX, this would require additional work. The AAA infrastructure itself may be used to configure measurement functions in the network as proposed in [RFC3334].
IPFIXレコード（直接または直径がカプセル化されている）をネイバープロバイダーと共有すると、効率的なドメイン間攻撃検出が可能になります。このためには、必要な粒度と精度で情報を提供するために、測定とレコードの生成のリモート構成を許可することが有用です。現在、リモート構成はIPFIXでは対処されていないため、追加の作業が必要になります。AAAインフラストラクチャ自体を使用して、[RFC3334]で提案されているように、ネットワーク内の測定関数を構成することができます。
Furthermore, the transport of IPFIX records with DIAMETER would require the translation of IPFIX Information Elements into DIAMETER attribute value pairs (AVPs) defined in [RFC3588]. Since the DIAMETER AVPs do not comprise all IPFIX Information Elements, it is necessary to define new AVPs to transport them over DIAMETER.
さらに、IPFIXレコードの直径の輸送には、[RFC3588]で定義された直径属性値ペア（AVP）にIPFIX情報要素を変換する必要があります。直径AVPはすべてのIPFIX情報要素を構成しないため、直径を超えて新しいAVPを定義する必要があります。
Two possibilities exist to connect IPFIX and AAA:
IPFIXとAAAを接続する2つの可能性があります。
- Connecting via a AAA Client - Connecting via an Application Specific Module (ASM)
- AAAクライアントを介して接続 - アプリケーション固有のモジュール（ASM）を介して接続する
Both are explained in the following sections. The approaches only require a few additional functions. They do not require any changes to IPFIX or DIAMETER.
どちらも次のセクションで説明されています。アプローチでは、いくつかの追加機能が必要です。IPFIXまたは直径の変更は必要ありません。
One possibility of connecting IPFIX and AAA is to run a AAA client on the IPFIX Collector. This client can generate DIAMETER accounting messages and send them to a AAA server. The mapping of the Flow information to a user ID can be done in the AAA server by using data from the authentication process. DIAMETER accounting messages can be sent to the accounting application or to other AAA servers (e.g., in roaming scenarios).
IPFIXとAAAを接続する可能性の1つは、IPFIXコレクターでAAAクライアントを実行することです。このクライアントは、直径会計メッセージを生成し、AAAサーバーに送信できます。ユーザーIDへのフロー情報のマッピングは、認証プロセスのデータを使用してAAAサーバーで実行できます。直径の会計メッセージは、会計アプリケーションまたは他のAAAサーバーに送信できます（たとえば、ローミングシナリオなど）。
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
| DIAMETER
|
|
+--+--------+--+
| | AAA-C | |
+ +--------+ |
| |
| Collector |
+--------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 1: IPFIX Collector connects to AAA server via AAA client
図1：IPFIXコレクターはAAAクライアントを介してAAAサーバーに接続します
Another possibility is to directly connect the IPFIX Collector with the AAA server via an application specific module (ASM). Application specific modules have been proposed by the IRTF AAA architecture research group (AAARCH) in [RFC2903]. They act as an interface between AAA server and service equipment. In this case, the IPFIX Collector is part of the ASM. The ASM acts as an interface between the IPFIX protocol and the input interface of the AAA server. The ASM translates the received IPFIX data into an appropriate format for the AAA server. The AAA server then can add information about the user ID and generate a DIAMETER accounting record. This accounting record can be sent to an accounting application or to other AAA servers.
別の可能性は、アプリケーション固有のモジュール（ASM）を介してIPFIXコレクターをAAAサーバーに直接接続することです。アプリケーション固有のモジュールは、[RFC2903]のIRTF AAA Architecture Research Group（AAARCH）によって提案されています。それらは、AAAサーバーとサービス機器の間のインターフェイスとして機能します。この場合、IPFIXコレクターはASMの一部です。ASMは、IPFIXプロトコルとAAAサーバーの入力インターフェイスとの間のインターフェイスとして機能します。ASMは、受信したIPFIXデータをAAAサーバーの適切な形式に変換します。AAAサーバーは、ユーザーIDに関する情報を追加して、直径会計レコードを生成できます。この会計記録は、会計申請書または他のAAAサーバーに送信できます。
+---------+ DIAMETER +---------+
| AAA-S |------------->| AAA-S |
+---------+ +---------+
^
|
+------------------+
| ASM |
| +------------+ |
| | Collector | |
+------------------+
^
| IPFIX
|
+------------+
| Exporter |
+------------+
Figure 2: IPFIX connects to AAA server via ASM
図2：IPFIXはASMを介してAAAサーバーに接続します
The Realtime Traffic Flow Measurement (RTFM) working group defined an architecture for Flow measurement [RFC2722]. This section compares the RTFM framework with the IPFIX framework.
リアルタイムトラフィックフロー測定（RTFM）ワーキンググループは、フロー測定のアーキテクチャを定義しました[RFC2722]。このセクションでは、RTFMフレームワークをIPFIXフレームワークと比較します。
The RTFM architecture [RFC2722] is very similar to the IPFIX architecture. It defines meter, meter reader, and a manager as building blocks of the measurement architecture. The manager configures the meter, and the meter reader collects data from the meter. In RTFM, the building blocks communicate via SNMP.
RTFMアーキテクチャ[RFC2722]は、IPFIXアーキテクチャに非常に似ています。メーター、メーターリーダー、マネージャーを測定アーキテクチャの構成要素として定義します。マネージャーはメーターを構成し、メーターリーダーはメーターからデータを収集します。RTFMでは、ビルディングブロックはSNMPを介して通信します。
The IPFIX architecture [RFC5470] defines Metering, Exporting, and Collecting Processes. IPFIX speaks about processes instead of devices to clarify that multiple of those processes may be co-located on the same machine.
IPFIXアーキテクチャ[RFC5470]は、メーター、エクスポート、および収集プロセスを定義しています。IPFIXは、これらのプロセスの複数が同じマシンで共同で共同で開催される可能性があることを明確にするためのデバイスの代わりにプロセスについて話します。
These definitions do not contradict each other. One could see the Metering Process as part of the meter, and the Collecting Process as part of the meter reader.
これらの定義は互いに矛盾しません。メータープロセスはメーターの一部として、メーターリーダーの一部として収集プロセスを見ることができます。
One difference is that IPFIX currently does not define a managing process because remote configuration was (at least initially) out of scope for the working group.
1つの違いは、IPFIXが現在、ワーキンググループにとって（少なくとも最初は）範囲外であったため、管理プロセスを定義していないことです。
RTFM and IPFIX both consider Flows as a group of packets that share a common set of properties. A Flow is completely specified by that set of values, together with a termination criterion (like inactivity timeout).
RTFMとIPFIXはどちらも、共通のプロパティセットを共有するパケットのグループとしてフローを考慮します。フローは、その値のセットによって完全に指定され、終了基準（非アクティブタイムアウトなど）があります。
A difference is that RTFM defines Flows as bidirectional. An RTFM meter matches packets from B to A and A to B as separate parts of a single Flow, and it maintains two sets of packet and byte counters, one for each direction.
違いは、RTFMがフローを双方向として定義することです。RTFMメーターは、単一のフローの別々の部分としてBからA、AからBへのパケットを一致させ、各方向に1つのパケットカウンターとバイトカウンターの2つのセットを維持します。
IPFIX does not explicitly state whether Flows are uni- or bidirectional. Nevertheless, Information Elements for describing Flow properties were defined for only one direction in [RFC5102]. There are several solutions for reporting bidirectional Flow information (see Section 4.6).
IPFIXは、フローが単方方向であるか双方向かを明示的に述べていません。それにもかかわらず、[RFC5102]の1つの方向のみで、フロー特性を説明するための情報要素が定義されました。双方向の流れ情報を報告するためのいくつかのソリューションがあります（セクション4.6を参照）。
In RTFM, remote configuration is the only way to configure a meter. This is done by using SNMP and a specific Meter MIB [RFC2720]. The IPFIX group currently does not address IPFIX remote configuration.
RTFMでは、リモート構成がメーターを構成する唯一の方法です。これは、SNMPと特定のメーターMIB [RFC2720]を使用して行われます。IPFIXグループは現在、IPFIXリモート構成に対応していません。
IPFIX Metering Processes export the layout of data within their Templates, from time to time. IPFIX Collecting Processes use that Template information to determine how they should interpret the IPFIX Flow data they receive.
IPFIXメータープロセスは、テンプレート内のデータのレイアウトを随時エクスポートします。IPFIXの収集プロセスは、そのテンプレート情報を使用して、受信したIPFIXフローデータをどのように解釈するかを判断します。
One major difference between IPFIX and RTFM is the data collection model. RTFM retrieves data in pull mode, whereas IPFIX uses a push mode model to send data to Collecting Processes.
IPFIXとRTFMの大きな違いの1つは、データ収集モデルです。RTFMはプルモードでデータを取得しますが、IPFIXはプッシュモードモデルを使用してデータを収集プロセスに送信します。
An RTFM meter reader pulls data from a meter by using SNMP. SNMP security on the meter determines whether a reader is allowed to pull data from it. An IPFIX Exporting Process is configured to export records to a specified list of IPFIX Collecting Processes. The condition of when to send IPFIX records (e.g., Flow termination) has to be configured in the Exporting or Metering Process.
RTFMメーターリーダーは、SNMPを使用してメーターからデータを引き出します。メーターのSNMPセキュリティは、読者がそこからデータを取得できるかどうかを判断します。IPFIXエクスポートプロセスは、レコードを指定されたIPFIX収集プロセスのリストにエクスポートするように構成されています。IPFIXレコードをいつ送信するか（フロー終了など）の条件は、エクスポートまたは計量プロセスで構成する必要があります。
RTFM defines all its attributes in the RTFM Meter MIB [RFC2720]. IPFIX Information Elements are defined in [RFC5102].
RTFMは、RTFMメーターMIB [RFC2720]のすべての属性を定義します。IPFIX情報要素は[RFC5102]で定義されています。
RTFM uses continuously-incrementing 64-bit counters for the storage of the number of packets of a Flow. The counters are never reset and just wrap back to zero if the maximum value is exceeded. Flows can be read at any time. The difference between counter readings gives the counts for activity in the interval between readings.
RTFMは、フローのパケットの数を保存するために、連続的に強化された64ビットカウンターを使用します。カウンターがリセットされることはなく、最大値を超えるとゼロに戻るだけです。フローはいつでも読むことができます。カウンターリーディング間の違いにより、測定値間の間隔でのアクティビティのカウントが得られます。
IPFIX allows absolute (totalCounter) and relative counters (deltaCounter) [RFC5102]. The totalCounter is never reset and just wraps to zero if values are too large, exactly as the counters used in RTFM. The deltaCounter is reset to zero when the associated Flow Record is exported.
IPFIXは、絶対（TotalCounter）および相対カウンター（Deltacounter）[RFC5102]を許可します。TotalCounterがリセットされることはなく、RTFMで使用されているカウンターとまったく同じ大きすぎる場合は、ゼロにラップします。関連するフローレコードがエクスポートされると、Deltacounterはゼロにリセットされます。
RTFM has a Standards-Track Meter MIB [RFC2720], which is used both to configure a meter and to store metering results. The MIB provides a way to read lists of attributes with a single Object Identifier (called a 'package'), which reduces the SNMP overhead for Flow data collection. SNMP, of course, normally uses UDP as its transport protocol. Since RTFM requires a reliable Flow data transport system, an RTFM meter reader must time out and resend unanswered SNMP requests. Apart from being clumsy, this can limit the maximum data transfer rate from meter to meter reader.
RTFMには、標準トラックメーターMIB [RFC2720]があり、メーターの構成と計量結果の保存の両方に使用されます。MIBは、単一のオブジェクト識別子（「パッケージ」と呼ばれる）を使用して属性のリストを読み取る方法を提供し、フローデータ収集のためにSNMPオーバーヘッドを削減します。もちろん、SNMPは通常、輸送プロトコルとしてUDPを使用します。RTFMには信頼できるフローデータ輸送システムが必要なため、RTFMメーターリーダーはタイムアウトして未回答のSNMPリクエストを再送信する必要があります。不器用であることとは別に、これはメーターからメーターリーダーへの最大データ転送速度を制限する可能性があります。
IPFIX is designed to work over a variety of different transport protocols. SCTP [RFC4960] and PR-SCTP [RFC3758] are mandatory. UDP and TCP are optional. In addition, the IPFIX protocol encodes data much more efficiently than SNMP does, hence IPFIX has lower data transport overheads than RTFM.
IPFIXは、さまざまな輸送プロトコルで動作するように設計されています。SCTP [RFC4960]およびPR-SCTP [RFC3758]は必須です。UDPとTCPはオプションです。さらに、IPFIXプロトコルはSNMPよりもはるかに効率的にデータをエンコードするため、IPFIXにはRTFMよりもデータトランスポートオーバーヘッドが低くなっています。
IPFIX exports Flow information in a push model by using SCTP, TCP, or UDP. It currently does not address remote configuration. RTFM data collection is using the pull model and runs over SNMP. RTFM addresses remote configuration, which also runs over SNMP. Both frameworks allow a very flexible Flow definition, although RTFM is based on a bidirectional Flow definition.
IPFIXは、SCTP、TCP、またはUDPを使用して、プッシュモデルでフロー情報をエクスポートします。現在、リモート構成には対応していません。RTFMデータ収集はプルモデルを使用しており、SNMPを介して実行されます。RTFMは、SNMPを介して実行されるリモート構成にアドレス指定します。RTFMは双方向のフロー定義に基づいていますが、どちらのフレームワークも非常に柔軟なフロー定義を可能にします。
The goal of this section is to show the limitations of IPFIX and to give advice where not to use IPFIX or in which cases additional considerations are required.
このセクションの目標は、IPFIXの制限を示し、IPFIXを使用しない場合、または追加の考慮事項が必要な場合にアドバイスを提供することです。
IPFIX provides a generic export mechanism. Due to its Template-based structure, it is a quite flexible protocol. Network operators and users may want to use it for other applications than those described in [RFC3917].
IPFIXは、一般的なエクスポートメカニズムを提供します。テンプレートベースの構造により、非常に柔軟なプロトコルです。ネットワークオペレーターとユーザーは、[RFC3917]に記載されているアプリケーションよりも、他のアプリケーションに使用することをお勧めします。
Apart from sending raw Flow information, it can be used to send per-packet data, aggregated or post-processed data. For this, new Templates and Information Elements can be defined if needed. Due to its push mode operation, IPFIX is also suited to send network initiated events like alarms and other notifications. It can be used for exchanging information among network nodes to autonomously improve network operation.
生の流れ情報を送信することとは別に、パケットごとのデータ、集約または後処理データの送信に使用できます。このため、必要に応じて新しいテンプレートと情報要素を定義できます。プッシュモードの操作により、IPFIXはアラームやその他の通知などのネットワーク開始イベントを送信するのにも適しています。ネットワークノード間で情報を交換して、ネットワーク操作を自律的に改善するために使用できます。
Nevertheless, the IPFIX design is based on the requirements that originate only from the target applications stated in [RFC3917]. Using IPFIX for other purposes requires a careful checking of IPFIX capabilities against application requirements. Only with this, one can decide whether IPFIX is a suitable protocol to meet the needs of a specific application.
それにもかかわらず、IPFIX設計は、[RFC3917]に記載されているターゲットアプリケーションからのみ発生する要件に基づいています。IPFIXを他の目的で使用するには、アプリケーション要件に対してIPFIX機能を慎重にチェックする必要があります。これによってのみ、IPFIXが特定のアプリケーションのニーズを満たすのに適したプロトコルであるかどうかを決定できます。
The reliability requirements defined in [RFC3917] are not sufficient to guarantee the level of reliability that is needed for usage-based billing systems as described in [RFC2975]. In particular, IPFIX does not support the following features required by [RFC2975]:
[RFC3917]で定義されている信頼性要件は、[RFC2975]で説明されているように、使用法ベースの請求システムに必要な信頼性のレベルを保証するのに十分ではありません。特に、IPFIXは[RFC2975]で必要な以下の機能をサポートしていません。
- Record loss: IPFIX allows the usage of different transport protocols for the transfer of data records. Resilience against the loss of IPFIX data records can be only provided if TCP or SCTP is used for the transfer of data records.
- 記録損失：IPFIXを使用すると、データレコードを転送するためのさまざまなトランスポートプロトコルを使用できます。IPFIXデータレコードの損失に対する回復力は、データレコードの転送にTCPまたはSCTPが使用される場合にのみ提供できます。
- Network or device failures: IPFIX does allow the usage of multiple Collectors for one Exporter, but it neither specifies nor demands the use of multiple Collectors for the provisioning of fault tolerance.
- ネットワークまたはデバイスの障害：IPFIXでは、1人の輸出業者に複数のコレクターの使用が許可されていますが、フォールトトレランスのプロビジョニングのために複数のコレクターの使用を指定したり要求したりしません。
- Detection and elimination of duplicate records: This is currently not supported by IPFIX.
- 重複レコードの検出と排除：これは現在、IPFIXによってサポートされていません。
- Application layer acknowledgements: IPFIX does not support the control of measurement and Exporting Processes by higher-level applications. Application layer acknowledgements are necessary, e.g., to inform the Exporter in case the application is not able to process the data exported with IPFIX. Such acknowledgements are not supported in IPFIX.
- アプリケーションレイヤーの確認：IPFIXは、高レベルのアプリケーションによる測定およびエクスポートプロセスの制御をサポートしていません。アプリケーションがIPFIXでエクスポートされたデータを処理できない場合に輸送者に通知するために、アプリケーションレイヤーの確認が必要です。このような謝辞はIPFIXではサポートされていません。
Further features like archival accounting and pre-authorization are out of scope of the IPFIX specification but need to be realized in billing system architectures as described in [RFC2975].
アーカイブ会計や事前承認などのさらなる機能は、IPFIX仕様の範囲外ですが、[RFC2975]で説明されているように、請求システムアーキテクチャで実現する必要があります。
SCTP is the preferred protocol for IPFIX, i.e., a conforming implementation must work over SCTP. Although IPFIX can also work over TCP or UDP, both protocols have drawbacks [RFC5101]. Users should make sure they have good reasons before using protocols other than SCTP in a specific environment.
SCTPはIPFIXの優先プロトコルです。つまり、適合実装はSCTPに対して動作する必要があります。IPFIXはTCPまたはUDPでも動作する可能性がありますが、両方のプロトコルには欠点があります[RFC5101]。ユーザーは、特定の環境でSCTP以外のプロトコルを使用する前に、正当な理由があることを確認する必要があります。
IPFIX works in push mode. That means IPFIX records are automatically exported without the need to wait for a request. The responsibility for initiating a data export lies with the Exporting Process.
IPFIXはプッシュモードで動作します。つまり、IPFIXレコードは、リクエストを待つ必要なく自動的にエクスポートされます。データエクスポートを開始する責任は、エクスポートプロセスにあります。
Criteria for exporting data need to be configured at the Exporting Process. Therefore, push mode has more benefits if the trigger for data export is related to events at the Exporting Process (e.g., Flow termination, memory shortage due to large amount of Flows, etc.). If the protocol used pull mode, the Exporting Process would need to wait for a request to send the data. With push mode, it can send data immediately, e.g., before memory shortage would require a discarding of data.
エクスポートデータの基準は、エクスポートプロセスで構成する必要があります。したがって、データエクスポートのトリガーがエクスポートプロセスでのイベント（フロー終了、大量のフローによるメモリ不足など）に関連している場合、プッシュモードにはより多くの利点があります。プロトコルがプルモードを使用した場合、エクスポートプロセスはデータの送信リクエストを待つ必要があります。プッシュモードを使用すると、メモリ不足がデータを破棄する必要がある前に、すぐにデータを送信できます。
With push mode, one can prevent the overloading of resources at the Exporting Process by simply exporting the information as soon as certain thresholds are about to be exceeded. Therefore, exporting criteria are often related to traffic characteristics (e.g., Flow timeout) or resource limitations (e.g., size of Flow cache). However, traffic characteristics are usually quite dynamic and often impossible to predict. If they are used to trigger Flow export, the exporting rate and the resource consumption for Flow export becomes variable and unpredictable.
プッシュモードを使用すると、特定のしきい値を超えようとするとすぐに情報をエクスポートするだけで、エクスポートプロセスでのリソースの過負荷を防ぐことができます。したがって、エクスポート基準は、多くの場合、トラフィック特性（フロータイムアウトなど）またはリソースの制限（フローキャッシュのサイズなど）に関連しています。ただし、トラフィックの特性は通常非常に動的であり、多くの場合、予測することは不可能です。それらがフローエクスポートをトリガーするために使用されると、フローエクスポートのエクスポートレートとリソース消費が変動し、予測不可能になります。
Pull mode has advantages if the trigger for data export is related to events at the Collecting Process (e.g., a specific application requests immediate input).
データエクスポートのトリガーが収集プロセスでのイベントに関連している場合（たとえば、特定のアプリケーションが即時入力を要求する場合）、プルモードには利点があります。
In a pull mode, a request could simply be forwarded to the Exporting Process. In a push mode, the exporting configuration must be changed to trigger the export of the requested data. Furthermore, with pull mode, one can prevent the overloading of the Collecting Process by the arrival of more records than it can process.
プルモードでは、リクエストをエクスポートプロセスに単純に転送できます。プッシュモードでは、要求されたデータのエクスポートをトリガーするためにエクスポート構成を変更する必要があります。さらに、プルモードでは、処理するよりも多くのレコードが到着することにより、収集プロセスの過負荷を防ぐことができます。
Whether this is a relevant drawback depends on the flexibility of the IPFIX configuration and how IPFIX configuration rules are implemented.
これが関連する欠点であるかどうかは、IPFIX構成の柔軟性とIPFIX構成ルールの実装方法に依存します。
The IPFIX specification limits the different Template ID numbers that can be assigned to the newly generated Template records in an Observation Domain. In particular, Template IDs up to 255 are reserved for Template or option sets (or other sets to be created) and Template IDs from 256 to 65535 are assigned to data sets. In the case of many exports requiring many different Templates, the set of Template IDs could be exhausted.
IPFIX仕様は、観測ドメインの新しく生成されたテンプレートレコードに割り当てることができるさまざまなテンプレートID番号を制限します。特に、最大255までのテンプレートIDは、テンプレートまたはオプションセット（または作成されるその他のセット）用に予約されており、256〜65535のテンプレートIDがデータセットに割り当てられます。多くの異なるテンプレートを必要とする多くのエクスポートの場合、テンプレートIDのセットが使い果たされる可能性があります。
Although IPFIX does not explicitly state that Flows are unidirectional, Information Elements that describe Flow characteristics are defined only for one direction in [RFC5102]. [RFC5101] allows the reporting of multiple identical Information Elements in one Flow Record. With this, Information Elements for forward and reverse directions can be reported in one Flow Record.
IPFIXは、フローが単方向であると明示的に述べていませんが、フロー特性を説明する情報要素は、[RFC5102]の1つの方向に対してのみ定義されます。[RFC5101]により、1つのフローレコードに複数の同一の情報要素を報告できます。これにより、順方向と逆方向の情報要素は、1つのフローレコードで報告できます。
However, this is not sufficient. Using this feature for reporting bidirectional Flow information would require an agreement on the semantics of Information Elements (e.g., first counter is the counter for the forward direction, the second counter for the reverse direction).
ただし、これで十分ではありません。この機能を使用するには、双方向の流れ情報を報告するには、情報要素のセマンティクスに関する一致が必要です（たとえば、最初のカウンターは前方向のカウンターであり、逆方向の2番目のカウンターです）。
Another option is to use two adjacent Flow Records to report both directions of a bidirectional Flow separately. This approach requires additional means for mapping those records and is quite inefficient due to the redundant reporting of Flow Keys.
別のオプションは、2つの隣接するフローレコードを使用して、双方向フローの両方向を個別に報告することです。このアプローチには、これらのレコードをマッピングするための追加の手段が必要であり、フローキーの冗長レポートのために非常に非効率的です。
Remote configuration was initially out of scope of the IPFIX working group in order to concentrate on the protocol specification. Therefore, there is currently no standardized way to configure IPFIX processes remotely. Nevertheless, due to the broad need for this feature, it is quite likely that solutions for this will be standardized soon.
リモート構成は、プロトコル仕様に集中するために、最初はIPFIXワーキンググループの範囲外でした。したがって、現在、IPFIXプロセスをリモートで構成する標準化された方法はありません。それにもかかわらず、この機能の幅広いニーズがあるため、これの解決策がまもなく標準化される可能性が非常に高いです。
This document describes the usage of IPFIX in various scenarios. Security requirements for IPFIX target applications and security considerations for IPFIX are addressed in [RFC3917] and [RFC5101]. Those requirements have to be met for the usage of IPFIX for all scenarios described in this document. To our current knowledge, the usage scenarios proposed in Section 2 do not induce further security hazards.
このドキュメントでは、さまざまなシナリオでのIPFIXの使用について説明しています。IPFIXのセキュリティ要件は、[RFC3917]および[RFC5101]で対処されています。これらの要件は、このドキュメントで説明されているすべてのシナリオでIPFIXを使用するために満たす必要があります。私たちの現在の知識のために、セクション2で提案されている使用シナリオは、さらなるセキュリティの危険を誘発しません。
The threat level to IPIFX itself may depend on the usage scenario of IPFIX. The usage of IPFIX for accounting or attack detection may increase the incentive to attack IPFIX itself. Nevertheless, security considerations have to be taken into account in all described scenarios.
IPIFX自体に対する脅威レベルは、IPFIXの使用シナリオに依存する可能性があります。会計または攻撃の検出にIPFIXを使用すると、IPFIX自体を攻撃するインセンティブが増加する可能性があります。それにもかかわらず、記述されたすべてのシナリオでセキュリティ上の考慮事項を考慮する必要があります。
As described in the security considerations in [RFC5101], security incidents can become a threat to IPFIX processes themselves, even if IPIFX is not the target of the attack. If an attack generates a large amount of Flows (e.g., by sending packets with spoofed addresses or simulating Flow termination), Exporting and Collecting Processes may get overloaded by the immense amount of records that are exported. A flexible deployment of packet or Flow sampling methods can be useful to prevent the exhaustion of resources.
[RFC5101]のセキュリティ上の考慮事項で説明されているように、たとえIPIFXが攻撃のターゲットではない場合でも、セキュリティインシデントはIPFIXプロセス自体に対する脅威になる可能性があります。攻撃が大量のフローを生成する場合（たとえば、スプーフィングされたアドレスを備えたパケットを送信したり、フロー終了をシミュレートすることにより）、エクスポートと収集プロセスは、エクスポートされる膨大な量のレコードによって過負荷になる場合があります。パケットまたはフローサンプリング方法の柔軟な展開は、リソースの消耗を防ぐために役立ちます。
Section 3 of this document describes how IPFIX can be used in combination with other technologies. New security hazards can arise when two individually secure technologies or architectures are combined. For the combination of AAA with IPFIX, an application specific module (ASM) or an IPFIX Collector can function as a transit point for the messages. One has to ensure that at this point the applied security mechanisms (e.g., encryption of messages) are maintained.
このドキュメントのセクション3では、IPFIXを他のテクノロジーと組み合わせて使用する方法について説明します。2つの個別に安全なテクノロジーまたはアーキテクチャを組み合わせると、新しいセキュリティハザードが発生する可能性があります。AAAとIPFIXの組み合わせの場合、アプリケーション固有のモジュール（ASM）またはIPFIXコレクターは、メッセージのトランジットポイントとして機能できます。この時点で、適用されたセキュリティメカニズム（メッセージの暗号化など）が維持されることを確認する必要があります。
We would like to thank the following people for their contributions, discussions on the mailing list, and valuable comments:
貢献、メーリングリストでの議論、貴重なコメントに感謝します。
Sebastian Zander Robert Loewe Reinaldo Penno Lutz Mark Andy Biermann
セバスチャン・ザンダー・ロバート・ローウェウ・レイナルド・ペンノ・ルッツ・マーク・アンディ・ビアマン
Part of the work has been developed in the research project 6QM, co-funded with support from the European Commission.
作業の一部は、欧州委員会からの支援と共同資金を提供し、6QMの研究プロジェクトで開発されました。
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005.
[RFC4148] Stephan、E。、「IPパフォーマンスメトリック（IPPM）メトリックレジストリ」、BCP 108、RFC 4148、2005年8月。
[RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B.、ed。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F.、およびG. Carle、「パケットサンプリングエクスポートの情報モデル」、RFC 5477、2009年3月。
[Brow00] Brownlee, N., "Packet Matching for NeTraMet Distributions", <http://www.caida.org/tools/measurement/ netramet/packetmatching/>.
[Brow00] Brownlee、N。、「Netramet Distributionsのパケットマッチング」、<http://www.caida.org/tools/measurement/ netramet/packetmatching/>。
[DuGr00] Duffield, N. and M. Grossglauser, "Trajectory Sampling for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000.
[DUGR00] Duffield、N。およびM. Grossglauser、「直接交通観察のための軌跡サンプリング」、ACM Sigcomm 2000の議事録、スウェーデン、ストックホルム、8月28日 - 2000年9月1日。
[GrDM98] Graham, I., Donnelly, S., Martin, S., Martens, J., and J. Cleary, "Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on the Internet", INET'98, Geneva, Switzerland, 21-24 July, 1998.
[Grdm98] Graham、I.、Donnelly、S.、Martin、S.、Martens、J。、およびJ. Cleary、「インターネット上の単方向の遅延と遅延の変動の非侵害的かつ正確な測定」、INET'98、Geneva、スイス、1998年7月21〜24日。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの一方向遅延メトリック」、RFC 2679、1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの一元配置パケット損失メトリック」、RFC 2680、1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、1999年9月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[RFC2702] Awduche、D.、Malcolm、J.、Agogbua、J.、O'dell、M。、およびJ. McManus、「MPLS上のトラフィックエンジニアリングの要件」、RFC 2702、1999年9月。
[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
[RFC2720]ブラウンリー、N。、「トラフィックフロー測定：Meter MIB」、RFC 2720、1999年10月。
[RFC2722] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
[RFC2722] Brownlee、N.、Mills、C。、およびG. Ruth、「トラフィックフロー測定：アーキテクチャ」、RFC 2722、1999年10月。
[RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and D. Spence, "Generic AAA Architecture", RFC 2903, August 2000.
[RFC2903] de Laat、C.、Gross、G.、Gommans、L.、Vollbrecht、J。、およびD. Spence、「Generic AAA Architecture」、RFC 2903、2000年8月。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2975] Aboba、B.、Arkko、J。、およびD. Harrington、「会計管理の紹介」、RFC 2975、2000年10月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B。、チャーニー、A。、ベネット、J。、ベンソン、K。、ル・ブーデック、J。、コートニー、W。、ダバリ、S。、フィロウ、V。、およびD.スティリアディス、 "迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、「特別使用IPv4アドレス」、RFC 3330、2002年9月。
[RFC3334] Zseby, T., Zander, S., and C. Carle, "Policy-Based Accounting", RFC 3334, October 2002.
[RFC3334] Zseby、T.、Zander、S。、およびC. Carle、「政策ベースの会計」、RFC 3334、2002年10月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」、RFC 3393、2002年11月。
[RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, August 2003.
[RFC3577] Waldbusser、S.、Cole、R.、Kalbfleisch、C。、およびD. Romascanu、「MIBモジュールのリモート監視（RMON）ファミリーの紹介」、RFC 3577、2003年8月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004.
[RFC3729] Waldbusser、S。、「アプリケーションパフォーマンス測定MIB」、RFC 3729、2004年3月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758] Stewart、R.、Ramalho、M.、Xie、Q.、Tuexen、M。、およびP. Conrad、「ストリーム制御伝送プロトコル（SCTP）部分信頼性拡張」、RFC 3758、2004年5月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B。、およびS. Zander、「IP Flow Information Export（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005.
[RFC4150] Dietz、R。およびR. Cole、「Transport Performance Metrics MIB」、RFC 4150、2005年8月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R.、ed。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、Brownlee、N.、Claise、B。、およびJ. Quittek、「IPフロー情報エクスポートのアーキテクチャ」、RFC 5470、2009年3月。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475] Zseby、T.、Molina、M.、Duffield、N.、Niccolini、S。、およびF. Raspall、「IPパケット選択のためのサンプリングとフィルタリング技術」、RFC 5475、2009年3月。
[RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、ed。、「パケットサンプリング（PSAMP）プロトコル仕様」、RFC 5476、2009年3月。
[ZsZC01] Zseby, T., Zander, S., and G. Carle, "Evaluation of Building Blocks for Passive One-way-delay Measurements", Proceedings of Passive and Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001
[ZSZC01] Zseby、T.、Zander、S。、およびG. Carle、「パッシブ片道測定のためのビルディングブロックの評価」、パッシブおよびアクティブ測定ワークショップの議事録（PAM 2001）、アムステルダム、オランダ、2001年4月23〜24日
Authors' Addresses
著者のアドレス
Tanja Zseby Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 EMail: tanja.zseby@fokus.fraunhofer.de
Tanja Zseby Fraunhofer Open Communication Systems（Fokus）Kaiserin-Augusta-Allee 31 10589ベルリン、ドイツ電話：49 30 3463 7153電子メール：tanja.zseby@fokus.fraunhofer.de
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastrasse 35 8092 Zurich Switzerland Phone: +41 44 6327057 EMail: elisa.boschi@hitachi-eu.com
Elisa Boschi Hitachi Europe c/o Eth Zurich Gloriastrasse 35 8092 Zurich Switzerland電話：41 44 6327057メール：elisa.boschi@hitachi-eu.com
Nevil Brownlee CAIDA (UCSD/SDSC) 9500 Gilman Drive La Jolla, CA 92093-0505 Phone: +1 858 534 8338 EMail: nevil@caida.org
Nevil Brownlee Caida（UCSD/SDSC）9500 Gilman Drive La Jolla、CA 92093-0505電話：1 858 534 8338メール：nevil@caida.org
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com
Benoit Claise Cisco Systems、Inc。De Kleetlaan 6a B1 1831 Diegem Belgium電話：32 2 704 5622メール：bclaise@cisco.com