RFC5153 日本語訳
5153 IPFIX Implementation Guidelines. E. Boschi, L. Mark, J. Quittek,M. Stiemerling, P. Aitken. April 2008. (Format: TXT=82845 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Boschi
Request for Comments: 5153 Hitachi Europe
Category: Informational L. Mark
Fraunhofer FOKUS
J. Quittek
M. Stiemerling
NEC
P. Aitken
Cisco Systems, Inc.
April 2008
Boschiがコメントのために要求するワーキンググループE.をネットワークでつないでください: 5153年の日立ヨーロッパカテゴリ: 情報のL.のNEC P.エイトケンシスコシステムズInc.マークフラウンホーファーFOKUS J.Quittek M.Stiemerling2008年4月
IP Flow Information Export (IPFIX) Implementation Guidelines
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.).
IP Flow情報Export(IPFIX)プロトコルはルータ、測定徹底的調査、または対向機器からIP Flow情報をどう輸出できるかを定義します。 このドキュメントはIPFIXプロトコルの実現と使用のためのガイドラインを提供します。 数セットのガイドラインはTemplate管理、輸送特有の問題、ExportingとCollecting Processesの実現、およびmiddleboxesにおけるIPFIX実現(ファイアウォール、ネットワークアドレス変換機構、トンネル終点、パケットクラシファイアなどの)に演説します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3
1.2. Overview of the IPFIX Protocol . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Template Management Guidelines . . . . . . . . . . . . . . . . 4
3.1. Template Management . . . . . . . . . . . . . . . . . . . 4
3.2. Template Records versus Options Template Records . . . . . 5
3.3. Using Scopes . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Multiple Information Elements of the Same Type . . . . . . 6
3.5. Selecting Message Size . . . . . . . . . . . . . . . . . . 6
4. Exporting Process Guidelines . . . . . . . . . . . . . . . . . 7
4.1. Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Information Element Coding . . . . . . . . . . . . . . . . 7
4.3. Using Counters . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 IPFIXは概観. . . . . . . . . . . . . . . . . 3 1.2を記録します。 IPFIXプロトコル. . . . . . . . . . . . . . 3 2の概観。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 テンプレート管理ガイドライン. . . . . . . . . . . . . . . . 4 3.1。 テンプレート管理. . . . . . . . . . . . . . . . . . . 4 3.2。 テンプレートはオプションテンプレートに対して記録. . . . . 5 3.3を記録します。 範囲. . . . . . . . . . . . . . . . . . . . . . . 6 3.4を使用します。 同じくらいの複数の情報要素が.63.5をタイプします。 メッセージサイズ. . . . . . . . . . . . . . . . . . 6 4を選択します。 過程ガイドライン. . . . . . . . . . . . . . . . . 7 4.1を輸出します。 セット. . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2。 情報要素コード化. . . . . . . . . . . . . . . . 7 4.3。 カウンタ. . . . . . . . . . . . . . . . . . . . . . 8 4.4を使用します。 詰め物. . . . . . . . . . . . . . . . . . . . . . . . . 8
Boschi, et al. Informational [Page 1] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [1ページ]情報のRFC5153IPFIX実施要綱2008年4月
4.4.1. Alignment of Information Elements within a Data
Record . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4.2. Alignment of Information Element Specifiers within
a Template Record . . . . . . . . . . . . . . . . . . 9
4.4.3. Alignment of Records within a Set . . . . . . . . . . 9
4.4.4. Alignment of Sets within an IPFIX Message . . . . . . 9
4.5. Time Issues . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. IPFIX Message Header Export Time and Data Record Time . . 10
4.7. Devices without an Absolute Clock . . . . . . . . . . . . 11
5. Collecting Process Guidelines . . . . . . . . . . . . . . . . 11
5.1. Information Element (De)Coding . . . . . . . . . . . . . . 11
5.2. Reduced-Size Encoding of Information Elements . . . . . . 12
5.3. Template Management . . . . . . . . . . . . . . . . . . . 12
6. Transport-Specific Guidelines . . . . . . . . . . . . . . . . 12
6.1. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Guidelines for Implementation on Middleboxes . . . . . . . . . 18
7.1. Traffic Flow Scenarios at Middleboxes . . . . . . . . . . 20
7.2. Location of the Observation Point . . . . . . . . . . . . 21
7.3. Reporting Flow-Related Middlebox Internals . . . . . . . . 22
7.3.1. Packet Dropping Middleboxes . . . . . . . . . . . . . 23
7.3.2. Middleboxes Changing the DSCP . . . . . . . . . . . . 23
7.3.3. Middleboxes Changing IP Addresses and Port Numbers . . 24
8. Security Guidelines . . . . . . . . . . . . . . . . . . . . . 25
8.1. Introduction to TLS and DTLS for IPFIX Implementers . . . 25
8.2. X.509-Based Identity Verification for IPFIX over TLS
or DTLS . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. Implementing IPFIX over TLS over TCP . . . . . . . . . . . 26
8.4. Implementing IPFIX over DTLS over UDP . . . . . . . . . . 26
8.5. Implementing IPFIX over DTLS over SCTP . . . . . . . . . . 27
9. Extending the Information Model . . . . . . . . . . . . . . . 27
9.1. Adding New IETF-Specified Information Elements . . . . . . 27
9.2. Adding Enterprise-Specific Information Elements . . . . . 28
10. Common Implementation Mistakes . . . . . . . . . . . . . . . . 28
10.1. IPFIX and NetFlow Version 9 . . . . . . . . . . . . . . . 28
10.2. Padding of the Data Set . . . . . . . . . . . . . . . . . 29
10.3. Field ID Numbers . . . . . . . . . . . . . . . . . . . . . 30
10.4. Template ID Numbers . . . . . . . . . . . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . . 31
4.4.1. データレコード. . . . . . . . . . . . . . . . . . . . . . . . 9 4.4.2の中のInformation Elementsの整列。 テンプレート記録. . . . . . . . . . . . . . . . . . 9 4.4.3の中の情報要素特許説明書の作成書の整列。 セット. . . . . . . . . . 9 4.4.4の中の記録の整列。 IPFIXメッセージ. . . . . . 9 4.5の中のセットの整列。 時間は.104.6を発行します。 IPFIXメッセージヘッダー輸出時間とデータレコード時間. . 10 4.7。 絶対時計. . . . . . . . . . . . 11 5のない装置。 過程ガイドライン. . . . . . . . . . . . . . . . 11 5.1を集めます。 情報要素(De)コード化. . . . . . . . . . . . . . 11 5.2。 情報要素. . . . . . 12 5.3の減少しているサイズコード化。 テンプレート管理. . . . . . . . . . . . . . . . . . . 12 6。 輸送特有のガイドライン.126.1。 SCTP. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2。 UDP. . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3。 TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7。 Middleboxes. . . . . . . . . 18 7.1における実現のためのガイドライン。 Middleboxes. . . . . . . . . . 20 7.2の交通の流れシナリオ。 観測ポイント. . . . . . . . . . . . 21 7.3の位置。 流れ関連のMiddleboxインターナル. . . . . . . . 22 7.3.1を報告します。 Middleboxes. . . . . . . . . . . . . 23 7.3.2を落とすパケット。 DSCP. . . . . . . . . . . . 23 7.3.3を変えるMiddleboxes。 IPアドレスとポートナンバー. . 24 8を変えるMiddleboxes。 安全ガイドライン. . . . . . . . . . . . . . . . . . . . . 25 8.1。 IPFIX Implementers. . . 25 8.2のためのTLSとDTLSへの紹介。 TLSかDTLS. . . . . . . . . . . . . . . . . . . . . . . . . 25 8.3の上のIPFIXのためのX.509ベースのアイデンティティ検証。 TCP. . . . . . . . . . . 26 8.4の上のTLSの上でIPFIXを実行します。 UDP. . . . . . . . . . 26 8.5の上のDTLSの上でIPFIXを実行します。 SCTP. . . . . . . . . . 27 9の上のDTLSの上でIPFIXを実行します。 情報モデル. . . . . . . . . . . . . . . 27 9.1を広げています。 新しいIETFによって指定された情報要素. . . . . . 27 9.2を加えます。 エンタープライズ-特殊情報要素. . . . . 28 10を加えます。 一般的な実現誤り. . . . . . . . . . . . . . . . 28 10.1。 IPFIXとNetFlowバージョン9.28 10.2。 データセット. . . . . . . . . . . . . . . . . 29 10.3の詰め物。 ID No.. . . . . . . . . . . . . . . . . . . . . 30 10.4をさばいてください。 テンプレートID No.. . . . . . . . . . . . . . . . . . . 30 11。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 30 12。 承認. . . . . . . . . . . . . . . . . . . . . . . 31 13。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 31 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 31 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 31
Boschi, et al. Informational [Page 2] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [2ページ]情報のRFC5153IPFIX実施要綱2008年4月
1. Introduction
1. 序論
The IPFIX protocol [RFC5101] defines how IP Flow information can be exported from routers, measurement probes, or other devices. In this document, we provide guidelines for its implementation.
IPFIXプロトコル[RFC5101]はルータ、測定徹底的調査、または対向機器からIP Flow情報をどう輸出できるかを定義します。 本書では、私たちは実現のためのガイドラインを提供します。
The guidelines are split into seven main sets. These sets address implementation aspects for Template management, Exporting Process, Collecting Process, transport, implementation on middleboxes, security, and extending the information model.
ガイドラインは主な7セットに分けられます。 これらのセットは管理と、Exporting Processと、Collecting Processと、輸送と、middleboxesにおける実現と、保証と、情報を広げているとモデル化されるTemplateのために実現局面を記述します。
Finally, this document contains a list of common mistakes related to issues that had been misinterpreted in the first IPFIX implementations and that created (and still might create) interoperability problems.
最終的に、このドキュメントは最初のIPFIX実現で誤解されて、相互運用性問題を生じさせた(そして、まだ、作成しているかもしれません)問題に関連する一般的な誤りのリストを含んでいます。
1.1. IPFIX Documents Overview
1.1. IPFIXドキュメント概観
The IPFIX protocol [RFC5101] provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in the IPFIX architecture [IPFIX-ARCH], per the requirements defined in [RFC3917].
IPFIXプロトコル[RFC5101]はIP Flow情報へのアクセスをネットワーク管理者に提供します。 Collecting ProcessへのIPFIX Exporting Processからの測定IP Flow情報の輸出のための構造はIPFIX構造[IPFIX-ARCH]で定義されます、[RFC3917]で定義された要件単位で。
The IPFIX architecture [IPFIX-ARCH] specifies how IPFIX Data Records and Templates are carried via a congestion-aware transport protocol from IPFIX Exporting Processes to IPFIX Collecting Processes.
IPFIX構造[IPFIX-ARCH]はIPFIX Data RecordsとTemplatesが混雑意識しているIPFIX Exporting ProcessesからIPFIX Collecting Processesまでのトランスポート・プロトコルでどう運ばれるかを指定します。
IPFIX has a formal description of IPFIX Information Elements, their name, type, and additional semantic information, as specified in the IPFIX information model [RFC5102].
IPFIXには、IPFIX情報モデル[RFC5102]の指定されるとしてのIPFIX Information Elementsの形式的記述、それらの名前、タイプ、および追加意味情報があります。
Finally, the IPFIX applicability statement [IPFIX-AS] describes what type of applications can use the IPFIX protocol and how they can use the information provided. It furthermore shows how the IPFIX framework relates to other architectures and frameworks.
最終的に、IPFIX適用性証明[IPFIX-AS]は、どんなタイプのアプリケーションがIPFIXプロトコルを使用できるかを説明します、そして、それらがどう情報を使用できるかは前提とされました。 その上、それはIPFIX枠組みがどう他の構造と枠組みに関連するかを示しています。
1.2. Overview of the IPFIX Protocol
1.2. IPFIXプロトコルの概観
In the IPFIX protocol, { type, length, value } tuples are expressed
in Templates containing { type, length } pairs, specifying which
{ value } fields are present in Data Records conforming to the
Template, giving great flexibility as to what data is transmitted.
IPFIXプロトコルでは、タイプ、長さ、値は、タイプ、対にして、分野がどの値であるかを指定するのがData Recordsに提示する長さを含んでいて、Templateに従いながらTemplatesで言い表されて、どんなデータが送られるかに関してかなりの柔軟性を与えながら、tuplesされます。
Since Templates are sent very infrequently compared with Data Records, this results in significant bandwidth savings.
Data Recordsと比べてTemplatesを非常にまれに送るので、これは重要な帯域幅貯蓄をもたらします。
Boschi, et al. Informational [Page 3] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [3ページ]情報のRFC5153IPFIX実施要綱2008年4月
Different Data Records may be transmitted simply by sending new
Templates specifying the { type, length } pairs for the new data
format. See [RFC5101] for more information.
単に新しいTemplatesに指定させることによって異なったData Recordsが伝えられるかもしれない、タイプ、長さは新しいデータの形式のために対にされます。 詳しい情報に関して[RFC5101]を見てください。
The IPFIX information model [RFC5102] defines a large number of
standard Information Elements that provide the necessary
{ type } information for Templates.
IPFIX情報モデル[RFC5102]はTemplatesのための情報を必要なタイプに提供する標準のInformation Elementsの多くを定義します。
The use of standard elements enables interoperability among different vendors' implementations. The list of standard elements may be extended in the future through the process defined in Section 9, below. Additionally, non-standard enterprise-specific elements may be defined for private use.
標準の要素の使用は異なった業者の実現の中で相互運用性を可能にします。 標準の要素のリストは将来、以下のセクション9で定義された過程で広げられるかもしれません。 さらに、標準的でない企業特有の要素は私的使用目的で定義されるかもしれません。
2. Terminology
2. 用語
The terminology used in this document is fully aligned with the terminology defined in [RFC5101]. Therefore, the terms defined in the IPFIX terminology are capitalized in this document, as in other IPFIX documents ([RFC5101], [RFC5102], [IPFIX-ARCH]).
本書では使用される用語は[RFC5101]で定義される用語に完全に並べられます。 したがって、IPFIX用語で定義された用語は本書では大文字で書かれます、他のIPFIXドキュメント[RFC5101]のように、[RFC5102]、[IPFIX-ARCH。)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
This document is Informational. It does not specify a protocol and does not use RFC 2119 key words [RFC2119] such as "MUST" and "SHOULD", except in quotations and restatements from the IPFIX standards documents. The normative specification of the protocol is given in the IPFIX protocol [RFC5101] and information model [RFC5102] documents.
このドキュメントはInformationalです。 それは、プロトコルを指定しないで、また“MUST"や“SHOULD"などのRFC2119キーワード[RFC2119]を使用しません、IPFIX規格文書からの引用と再声明を除いて。 IPFIXプロトコル[RFC5101]と情報モデル[RFC5102]ドキュメントでプロトコルの標準の仕様を与えます。
3. Template Management Guidelines
3. テンプレート管理ガイドライン
3.1. Template Management
3.1. テンプレート管理
The Exporting Process should always endeavor to send Template Records before the related Data Records. However, since the Template Record may not arrive before the corresponding Data Records, the Collecting Process MAY store Data Records with an unknown Template ID pending the arrival of the corresponding Template (see Section 9 of [RFC5101]). If no Template becomes available, we recommend logging the event and discarding the corresponding Data Records, and for SCTP and TCP we recommend resetting the Transport Session. The amount of time the Collecting Process waits for a Template before resetting should be configurable. We recommend a default of 30 minutes. Note
Exporting Processは、いつも関連するData Recordsの前にTemplate Recordsを送るよう努力するはずです。 しかしながら、Template Recordが対応するData Recordsの前で到着しないかもしれないので、Collecting Processは対応するTemplateの到着まで未知のTemplate IDと共にData Recordsを格納するかもしれません([RFC5101]のセクション9を見てください)。 どんなTemplateも利用可能にならないなら、私たちは、出来事を登録して、対応するData Recordsを捨てることを勧めます、そして、SCTPとTCPに関して、Transport Sessionをリセットすることを勧めます。 Collecting Processがリセットの前にTemplateを待つ時間は構成可能であるべきです。 私たちは30分のデフォルトを推薦します。 注意
Boschi, et al. Informational [Page 4] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [4ページ]情報のRFC5153IPFIX実施要綱2008年4月
that when using UDP as the transport protocol, this delay should be bound, when possible, by the Template Retransmit and the Template Expiry times (see Section 6.2).
輸送としてUDPを使用するとき、それは議定書を作って、この遅れは制限されているべきです、可能であるときに、Template RetransmitとTemplate Expiry回で(セクション6.2を見てください)。
The Exporting Process must be able to resend active Templates. Templates must be resent in the case of a Stream Control Transport Protocol (SCTP) association restart, a User Datagram Protocol (UDP) template refresh, or a Transmission Control Protocol (TCP) connection restart.
Exporting ProcessはアクティブなTemplatesを再送できなければなりません。 Stream Control Transportプロトコル(SCTP)協会再開に関するケース、(UDP)テンプレートがリフレッシュするユーザー・データグラム・プロトコル、または通信制御プロトコル(TCP)接続再開でテンプレートを再送しなければなりません。
The Exporting Process is responsible for the management of Template IDs. Should an insufficient number of Template IDs be available, the Exporting Process must send a Template Withdrawal Message in order to free up the allocation of unused Template IDs. Note that UDP doesn't use the Template Withdrawal Message, and the Template lifetime on the Collecting Process relies on timeout.
Exporting ProcessはTemplate IDの管理に責任があります。 不十分な数のTemplate IDが利用可能であるなら、Exporting Processは、未使用のTemplate IDの配分を開けるためにTemplate Withdrawal Messageを送らなければなりません。 UDPがTemplate Withdrawal Messageを使用しないことに注意してください。そうすれば、Collecting Processの上のTemplate寿命はタイムアウトを当てにします。
3.2. Template Records versus Options Template Records
3.2. テンプレート記録対オプションテンプレート記録
The IPFIX protocol [RFC5101] defines and specifies the use of Templates and Options Templates. Templates define the layout of Data Records, which represent Flow data. Options Templates additionally specify scope Information Elements, which can be used to define scoped Data Records. Scoped Data Records generally export control plane data (such as metadata about processes in the IPFIX collection architecture) or data otherwise applicable to multiple Flow Data Records (such as common properties as in [IPFIX-REDUCING]).
IPFIXプロトコル[RFC5101]は、TemplatesとOptions Templatesの使用を定義して、指定します。 テンプレートはData Recordsのレイアウトを定義します。(Data RecordsはFlowデータを表します)。 オプションTemplatesはさらに、範囲Information Elementsを指定します。(見られたData Recordsを定義するのにElementsを使用できます)。 一般に、見られたData Recordsはコントロール飛行機データ(IPFIX収集構造の過程に関するメタデータなどの)かそうでなければ、複数のFlow Data Recordsに適切なデータ(同じくらい中の通有性[IPFIX-REDUCING]などの)を輸出します。
Aside from Section 4 of [RFC5101], which defines specific Options Templates to use for reporting Metering Process and Exporting Process statistics and configuration information, the choice to use Options Templates is left up to the implementer. Indeed, there is a trade- off between bandwidth efficiency and complexity in the use of Options Templates and scoped Data Records.
[RFC5101]のセクション4は別として、Options Templatesを使用する選択はimplementerに任せられます。セクションは、Metering ProcessとExporting Processを報告するのに統計と設定情報を使用するために特定のOptions Templatesを定義します。 本当に、取り引きがOptions Templatesと見られたData Recordsの使用における帯域幅効率と複雑さの間で離れてあります。
For example, control plane information about an Observation Point could be exported with every Flow Record measured at that Observation Point, or in a single Data Record described by an Options Template, scoped to the Observation Point identifier. In the former case, simplicity of decoding the data is gained in exchange for redundant export of the same data with every applicable Flow Record. The latter case is more bandwidth-efficient, but at the expense of requiring the Collecting Process to maintain the relationship between each applicable Flow Record and the Observation Point.
例えば、そのObservation Pointで測定されるあらゆるFlow Record、またはObservation Point識別子に見られたOptions Templateによって説明された独身のData RecordでObservation Pointのコントロール飛行機情報を輸出できました。 前の場合では、あらゆる適切なFlow Recordとの同じデータの余分な輸出と引き換えにデータを解読する簡単さを獲得します。 より帯域幅効率的ですがCollecting Processがそれぞれの適切なFlow RecordとObservation Pointとの関係を維持するのが必要であることを犠牲にして後者のケース。
A generalized method of using Options Templates to increase bandwidth efficiency is fully described in [IPFIX-REDUCING].
帯域幅効率を増加させるOptions Templatesを使用する一般的な方法は[IPFIX-REDUCING]で完全に説明されます。
Boschi, et al. Informational [Page 5] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [5ページ]情報のRFC5153IPFIX実施要綱2008年4月
3.3. Using Scopes
3.3. 範囲を使用します。
The root scope for all IPFIX Messages is the Observation Domain, which appears in the Message Header. In other words, all Data Records within a message implicitly belong to the Observation Domain. All Data Records described by Options Templates (and only those) must be restricted to an additional scope within the Observation Domain, as defined by the scope Information Elements in the Options Template Record.
すべてのIPFIX Messagesのための根の範囲はObservation Domainです。(そのObservation DomainはMessage Headerに現れます)。 言い換えれば、メッセージの中のすべてのData RecordsがそれとなくObservation Domainに属します。 Options Templates(そして、それらだけ)によって説明されたすべてのData RecordsをObservation Domainの中の追加範囲に制限しなければなりません、Options Template Recordで範囲Information Elementsによって定義されるように。
In IPFIX, any Information Element can be used for scope. However, Information Elements such as counters, timestamps, padding elements, Flow properties like timeout, Flow end reason, duration, or Min/Max Flow properties [RFC5102] may not be appropriate.
IPFIXでは、範囲にどんな情報Elementも使用できます。 しかしながら、タイムアウトのようなカウンタ、タイムスタンプなどのInformation Elementsが要素を水増しすることでのFlowの特性、Flow終わりの理由、持続時間、またはMin/マックスFlowの特性[RFC5102]が適切でないかもしれません。
Note that it is sometimes necessary to export information about entities that exist outside any Observation Domain, or within multiple Observation Domains (e.g., information about Metering Processes scoped to meteringProcessID). Such information SHOULD be exported in an IPFIX Message with Observation Domain ID 0 (see [RFC5101], Section 3.1).
どんなObservation Domainの外、または、複数のObservation Domainsの中に存在する実体の情報を輸出するのが時々必要であることに注意してください(例えばMetering Processesの情報はmeteringProcessIDにおいて見られました)。 そのような情報SHOULD、Observation Domain ID0があるIPFIX Messageで輸出してください([RFC5101]、セクション3.1を見てください)。
3.4. Multiple Information Elements of the Same Type
3.4. 同じタイプの複数のInformation Elements
The Exporting Process and Collecting Process MUST support the use of multiple Information Elements of the same type in a single Template [RFC5101]. This was first required by Packet Sampling (PSAMP) [PSAMP-PROTO] for the export of multiple Selector IDs. Note that the IPFIX protocol recommends that Metering Processes SHOULD use packet treatment order when exporting multiple Information Elements of the same type in the same record ([RFC5101] Section 8). This implies that ordering is important, and changes to the order of multiple identical Information Elements could cause information loss. Therefore, we strongly recommend preservation of the order of multiple Information Elements of the same type by Exporting and Collecting Processes for correct processing and storage.
Exporting ProcessとCollecting Processは独身のTemplate[RFC5101]における同じタイプの複数のInformation Elementsの使用を支持しなければなりません。 これは最初に、複数のSelector IDの輸出のためにPacket Sampling(PSAMP)[PSAMP-プロト]によって必要とされました。 IPFIXプロトコルが、同じ記録([RFC5101]セクション8)で同じタイプの複数のInformation Elementsを輸出するとき、Metering Processes SHOULDがパケット処理命令を使用することを勧めることに注意してください。 これは、注文が重要であることを含意します、そして、複数の同じInformation Elementsの注文への変化が、情報の損失をもたらすことができました。 したがって、私たちは強くExportingとCollecting Processesによる同じタイプの複数のInformation Elementsの注文の保存を正しい処理と格納に推薦します。
3.5. Selecting Message Size
3.5. メッセージサイズを選択します。
Section 10.3.3 of the IPFIX protocol defines the maximum message size for IPFIX Messages transported over UDP to be constrained by the path MTU, or if the path MTU is not available, 512 bytes, which is the minimum datagram size all IP implementations must support (see also Section 8.4). However, no maximum message size is imposed on other transport protocols, beyond the 65535-byte limit imposed by the 16- bit Message Length field in the IPFIX Message Header specified in Section 3.1 of [RFC5101].
.3のセクション10.3IPFIXプロトコルが経路MTUかそれとも経路MTUが512バイト利用可能でないかどうかによって抑制されるためにUDPの上で輸送されたIPFIX Messagesのために最大のメッセージサイズを定義します(また、セクション8.4を見てください)。(IPFIX MessagesはすべてのIP実現が支持しなければならない最小のデータグラムサイズです)。 しかしながら、どんな最大のメッセージサイズも他のトランスポート・プロトコルに課されません、Message Lengthが[RFC5101]のセクション3.1で指定されたIPFIX Message Headerでさばく16ビットによって課された65535バイトの限界を超えて。
Boschi, et al. Informational [Page 6] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [6ページ]情報のRFC5153IPFIX実施要綱2008年4月
An IPFIX Exporting Process operating over SCTP or TCP may export IPFIX Messages up to this 64-kB limit, and an IPFIX Collecting Process must accept any IPFIX Message up to that size.
SCTPかTCPの上で作動するIPFIX Exporting ProcessはIPFIX Messagesをこの64-kB限界まで輸出するかもしれません、そして、IPFIX Collecting ProcessはどんなIPFIX Messageもそのサイズまで受け入れなければなりません。
4. Exporting Process Guidelines
4. 輸出過程ガイドライン
4.1. Sets
4.1. セット
A Set is identified by a Set ID [RFC5101]. A Set ID has an integral data type and its value is in the range of 0-65535. The Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. A value of 2 identifies a Template Set. A value of 3 identifies an Options Template Set. Values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets. In this case, the Set ID corresponds to the Template ID of the used Template.
SetはSet ID[RFC5101]によって特定されます。 Set IDには、不可欠のデータ型があります、そして、値が0-65535の範囲にあります。 0と1のSet ID値は歴史的な理由[RFC3954]に使用されません。 2の値はTemplate Setを特定します。 3の値はOptions Template Setを特定します。 4〜255までの値は今後の使用のために予約されます。 255を超えた値はData Setsに使用されます。 この場合、Set IDは中古のTemplateのTemplate IDに対応します。
A Data Set received with an unknown Set ID may be stored pending the arrival of the corresponding Template (see Section 9 of [RFC5101]). If no Template becomes available, we recommend logging the event and discarding the corresponding Data Records, and for SCTP and TCP we recommend resetting the Transport Session. The amount of time the Collecting Process waits for a Template before resetting should be configurable. We recommend a default of 30 minutes. Note that when using UDP as the transport protocol, this delay should be bound, when possible, by the Template Retransmit and the Template Expiry times (see Section 6.2).
未知のSet IDと共に受け取られたData Setは対応するTemplateの到着まで格納されるかもしれません([RFC5101]のセクション9を見てください)。 どんなTemplateも利用可能にならないなら、私たちは、出来事を登録して、対応するData Recordsを捨てることを勧めます、そして、SCTPとTCPに関して、Transport Sessionをリセットすることを勧めます。 Collecting Processがリセットの前にTemplateを待つ時間は構成可能であるべきです。 私たちは30分のデフォルトを推薦します。 トランスポート・プロトコルとしてUDPを使用するとき、この遅れが制限されているべきであることに注意してください、Template RetransmitとTemplate Expiry回で可能であるときに(セクション6.2を見てください)。
The arrival of a Set with a reserved Set ID should be logged, and the Collector must ignore the Set.
予約されたSet IDとのSetの到着は登録されるべきです、そして、CollectorはSetを無視しなければなりません。
4.2. Information Element Coding
4.2. 情報要素コード化
[IPFIX-ARCH] does not specify which entities are responsible for the encoding and decoding of Information Elements transferred via IPFIX. An IPFIX device can do the encoding either within the Metering Process or within the Exporting Process. The decoding of the Information Elements can be done by the Collecting Process or by the data processing application.
[IPFIX-ARCH]は、どの実体がIPFIXを通して移されたInformation Elementsのコード化と解読に原因となるかを指定しません。 IPFIX装置はMetering Process以内かExporting Processの中でコード化できること。 Collecting Processかデータ処理アプリケーションでInformation Elementsの解読ができます。
If an IPFIX node simply relays IPFIX Records (like a proxy), then no decoding or encoding of Information Elements is needed. In this case, the Exporting Process may export unknown Information Elements, i.e., Information Elements with an unknown Information Element identifier.
IPFIXノードが単に、IPFIX Records(プロキシのような)をリレーするなら、Information Elementsの解読かコード化は必要ではありません。 この場合、Exporting Processは未知の情報Element識別子と共に未知のInformation Elements、すなわち、Information Elementsを輸出するかもしれません。
Boschi, et al. Informational [Page 7] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [7ページ]情報のRFC5153IPFIX実施要綱2008年4月
4.3. Using Counters
4.3. カウンタを使用します。
IPFIX offers both Delta and Total counters (e.g., octetDeltaCount, octetTotalCount). If information about a Flow is only ever exported once, then it's not important whether Delta or Total counters are used. However, if further information about additional packets in a Flow is exported after the first export, then either:
IPFIXはカウンタ(例えば、octetDeltaCount、octetTotalCount)をデルタとTotalの両方に提供します。 今までに一度Flowの情報を輸出するだけであるなら、デルタかTotalカウンタが使用されているか否かに関係なく、重要ではありません。 しかしながら、1番目はFlowの追加パケットに関する詳細のときに輸出した後なら輸出して、その時はどちらかです:
o the metering system must reset its counters to zero after the
first export and report the new counter values using Delta
counters, or
o または計量システムが最初の輸出とレポートの後にデルタカウンタを使用することで新しい対価のゼロを合わせるためにカウンタをリセットしなければならない。
o the metering system must carefully maintain its counters and
report the running total using Total counters.
o 計量システムは、Totalカウンタを使用することで慎重にカウンタを維持して、現在高を報告しなければなりません。
At first, reporting the running total may seem to be the obvious choice. However, this requires that the system accurately maintains information about the Flow over a long time without any loss or error, because when reported to a Collecting Process, the previous total values will be replaced with the new information.
初めに、現在高を報告するのは当然の選択であるように思えるかもしれません。 しかしながら、これは、システムが長い間上で少しも損失や誤りなしでFlowの情報を正確に保守するのを必要とします、Collecting Processに報告すると、前の総価格を新情報に取り替えるので。
Delta counters offer some advantages: information about Flows doesn't have to be permanently maintained, and any loss of information has only a small impact on the total stored at the Collecting Process. Finally, Deltas may be exported in fewer bytes than Total counters using the IPFIX "Reduced Size Encoding" scheme [RFC5101].
デルタカウンタはいくつかの利点を示します: Flowsの情報は永久に保守される必要はありません、そして、情報のどんな損失もCollecting Processに格納された合計に小さい影響力しか持っていません。 最終的に、Totalカウンタより少ないバイトでIPFIX「減少しているサイズコード化」計画[RFC5101]を使用することでDeltasを輸出するかもしれません。
Note that Delta counters have an origin of zero and that a Collecting Process receiving Delta counters for a Flow that is new to the Collecting Process must assume the Deltas are from zero.
デルタカウンタにはゼロの起源があって、Collecting Processに新しいFlowのためにデルタカウンタを受けるCollecting Processが、Deltasがゼロから来ていると仮定しなければならないことに注意してください。
4.4. Padding
4.4. 詰め物
The IPFIX information model defines an Information Element for padding called paddingOctets [RFC5102]. It is of type octetArray, and the IPFIX protocol allows encoding it as a fixed-length array as well as a variable-length array.
IPFIX情報モデルはpaddingOctets[RFC5102]と呼ばれる詰め物のために情報Elementを定義します。 タイプoctetArrayにはそれがあります、そして、IPFIXプロトコルは可変長のアレイと同様に固定長アレイとしてそれをコード化するのを許容します。
The padding Information Element can be used to align Information Elements within Data Records, Records within Sets, and Sets within IPFIX Messages, as described below.
Data Records、Setsの中のRecords、およびIPFIX Messagesの中のSetsの中でInformation Elementsを並べるのに詰め物情報Elementを使用できます、以下で説明されるように。
Boschi, et al. Informational [Page 8] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [8ページ]情報のRFC5153IPFIX実施要綱2008年4月
4.4.1. Alignment of Information Elements within a Data Record
4.4.1. データレコードの中のInformation Elementsの整列
The padding Information Element gives flexible means for aligning Information Elements within a Data Record. Aligning within a Data Record can be useful, because internal data structures can be easily converted into Flow Records at the Exporter and vice versa at the Collecting Process.
詰め物情報ElementはData Recordの中でInformation Elementsを並べるための柔軟な手段を与えます。 Data Recordの中に並ぶのは役に立つ場合があります、Collecting Processで容易に逆もまた同様に内部のデータ構造をExporterのFlow Recordsに変換できるので。
Alignment of Information Elements within a Data Record is achieved by inserting an instance of the paddingOctets Information Element with appropriate length before each unaligned Information Element. This insertion is explicitly specified within the Template Record or Options Template Record, respectively, that corresponds to the Data Record.
Data Recordの中のInformation Elementsの整列は、適切な長さがそれぞれの非同盟の情報Elementの前にある状態でpaddingOctets情報Elementの例を挿入することによって、達成されます。 この挿入はTemplate RecordかOptions Template Recordの中で明らかに指定されて、それぞれ、それはData Recordに対応しています。
4.4.2. Alignment of Information Element Specifiers within a Template
Record
4.4.2. テンプレート記録の中の情報要素特許説明書の作成書の整列
There is no means for aligning Information Element specifiers within Template Records. However, there is limited need for such a method, as Information Element specifiers are always 32-bit aligned, and 32- bit alignment is generally sufficient.
Template Recordsの中で情報Element特許説明書の作成書を並べるための手段が全くありません。 しかしながら、そのような方法の限られた必要があって、一般に、整列は、情報Element特許説明書の作成書が並べられるのと32いつも32ビットのビットであるので、十分です。
4.4.3. Alignment of Records within a Set
4.4.3. セットの中の記録の整列
There is no means for aligning Template Records within a Set. However, there is limited need for such a method, as Information Element specifiers are always 32-bit aligned, and 32-bit alignment is generally sufficient.
Setの中でTemplate Recordsを並べるための手段が全くありません。 しかしながら、いつも並べられた状態で情報Element特許説明書の作成書が32ビットであるので、そのような方法の限られた必要があります、そして、一般に、32ビットの整列は十分です。
Data Records can be aligned within a Set by appending instances of the paddingOctets Information Element at the end of the Record. Since all Data Records within a Set have the same structure and size, aligning one Data Record implies aligning all the Data Records within a single Set.
Setの中でRecordの端でpaddingOctets情報Elementの例を追加することによって、データRecordsを並べることができます。 以来、Setの中のすべてのData Recordsには、1Data Recordが含意する同じ構造とサイズ、並べることが、独身のSetの中ですべてのData Recordsを並べながら、あります。
4.4.4. Alignment of Sets within an IPFIX Message
4.4.4. IPFIXメッセージの中のセットの整列
If Records are already aligned within a Set by using paddingOctets Information Elements, then this alignment will already be achieved. But for aligning Sets within an IPFIX Message, padding Information Elements can be used at the end of the Set so that the subsequent Set starts at an aligned boundary. This padding mechanism is described in Section 3.3.1 of [RFC5101] and can be applied even if the Records within the Set are not aligned. However, it should be noted that this method is limited by the constraint that "the padding length MUST be shorter than any allowable Record in the Set", to prevent the padding from being misinterpreted as an additional Data Record.
RecordsがSetの中でpaddingOctets Information Elementsを使用することによって既に並べられると、この整列は既に達成されるでしょう。 しかし、IPFIX Messageの中でSetsを並べるのに、Setの端でInformation Elementsを水増しするのを使用できるので、その後のSetは並べられた境界で始まります。 この詰め物メカニズムを.1セクション3.3[RFC5101]で説明して、Setの中のRecordsが並べられないでも、適用できます。 しかしながら、「詰め物の長さはSetのどんな許容できるRecordよりも短いに違いない」という規制でこの方法が詰め物が追加Data Recordとして誤解されるのを防ぐために制限されることに注意されるべきです。
Boschi, et al. Informational [Page 9] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [9ページ]情報のRFC5153IPFIX実施要綱2008年4月
4.5. Time Issues
4.5. 時間問題
IPFIX Messages contain the export time in the Message Header. In addition, there is a series of Information Elements defined to transfer time values. [RFC5102] defines four abstract data types to transfer time values in second, millisecond, microsecond, and nanosecond resolution.
IPFIX MessagesはMessage Headerに輸出時間を含んでいます。 さらに、転送時間値と定義されたInformation Elementsのシリーズがあります。 [RFC5102]は2番目、ミリセカンド、マイクロセカンド、およびナノ秒の解決で4つの抽象データ型を転送時間値と定義します。
The accuracy and precision of these values depend on the accuracy and the precision of the Metering Process clock. The accuracy and precision of the Exporting Process clock, and the synchronization of the Metering Process and Exporting Process clocks, are also important when using the delta timestamp Information Elements. To ensure accuracy, the clocks should be synchronized to a UTC time source. Normally, it would be sufficient to derive the time from a remote time server using the Network Time Protocol (NTP) [RFC1305]. IPFIX Devices operating with time values of microsecond or nanosecond resolution need direct access to a time source, for example, to a GPS (Global Positioning System) unit.
これらの値の精度と精度はMetering Process時計の精度と精度に依存します。 また、デルタタイムスタンプInformation Elementsを使用するとき、Exporting Process時計の精度と精度、およびMetering ProcessとExporting Process時計の同期も重要です。 精度を確実にするために、時計はUTC時間ソースに連動するべきです。 通常、それは、リモート時間サーバからNetwork Timeプロトコル(NTP)[RFC1305]を使用することで時間を得るために十分でしょう。 例えば、マイクロセカンドの時間的価値で作動するIPFIX Devicesかナノ秒の解決の必要性がGPS(全地球測位システム)ユニットに時間ソースへのアクセスを向けます。
The most important consideration in selecting timestamp Information Elements is to use a precision appropriate for the timestamps as generated from the Metering Process. Specifically, an IPFIX Device should not export timestamp Information Elements of higher precision than the timestamps used by the Metering Process (e.g., millisecond- precision Flows should not be exported with flowStartMicroseconds and flowEndMicroseconds).
タイムスタンプInformation Elementsを選ぶのにおいて最も重要な考慮すべき事柄はMetering Processから発生するようにタイムスタンプに、適切な精度を使用することです。 明確に、IPFIX Deviceはタイムスタンプより高い精度のElementsがMetering Processで使用したタイムスタンプ情報を輸出するはずがありません(flowStartMicrosecondsとflowEndMicrosecondsと共に例えば、ミリセカンド精度Flowsを輸出するべきではありません)。
4.6. IPFIX Message Header Export Time and Data Record Time
4.6. IPFIXメッセージヘッダー輸出時間とデータレコード時間
Section 5 of [RFC5101] defines a method for optimized export of time- related Information Elements based upon the Export Time field of the IPFIX Message Header. The architectural separation of the Metering Process and Exporting Process in [IPFIX-ARCH] raises some difficulties with this method, of which implementers should be aware.
[RFC5101]のセクション5は関連するInformation ElementsがIPFIX Message HeaderのExport Time分野に基礎づけた時間の最適化された輸出のための方法を定義します。 [IPFIX-ARCH]のMetering ProcessとExporting Processの建築分離はこの方法における困難を上げます。(そこをimplementersは意識しているべきです)。
Since the Metering Process has no information about the export time of the IPFIX Message (that is, when the message leaves the Exporting Process), it cannot properly use the delta time Information Elements; it must store absolute timestamps and transmit these to the Exporting Process. The Exporting Process must then convert these to delta timestamps once the export time is known. This increases the processing burden on the Exporting Process. Note also that the absolute timestamps require more storage than their delta timestamp counterparts. However, this method can result in reduced export bandwidth.
IPFIX Messageの輸出時間(すなわち、メッセージはいつExporting Processを出ますか)頃に、Metering Processには情報が全くないので、適切にデルタ時間Information Elementsを使用できません。 それは、絶対タイムスタンプを格納して、これらをExporting Processに伝えなければなりません。 そして、輸出時間がいったん知られていると、Exporting Processはデルタタイムスタンプにこれらを変換しなければなりません。 これはExporting Processで処理負担を増加させます。 また、絶対タイムスタンプが彼らのデルタタイムスタンプ対応者より多くの格納を必要とすることに注意してください。 しかしながら、この方法は減少している輸出帯域幅をもたらすことができます。
Boschi, et al. Informational [Page 10] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [10ページ]情報のRFC5153IPFIX実施要綱2008年4月
Alternatively, the Exporting Process may simply export absolute timestamp Information Elements. This simplifies the Exporting Process' job and reduces processing burden, but increases export bandwidth requirements.
あるいはまた、Exporting Processは単に絶対タイムスタンプInformation Elementsを輸出するかもしれません。 これは、Exporting Processの仕事を簡素化して、処理負担を減少させますが、輸出帯域幅要件を増加させます。
4.7. Devices without an Absolute Clock
4.7. 絶対時計のない装置
Exporting just relative times in a device without an absolute clock is often not sufficient. For instance, observed traffic could be retained in the device's cache for some time before being exported (e.g., if the Exporter runs once per minute), or stuck in an Inter Process Communication (IPC) queue, or stuck in the export stack, or delayed in the network between the Exporter and Collector.
装置で絶対時計なしでちょうど相対的な時勢を輸出するのはしばしば十分であるというわけではありません。 例えば、ExporterとCollectorの間のネットワークで輸出するか(例えば、Exporterが1分に一度走るなら)、Inter Process Communication(IPC)待ち行列で張り付けるか、輸出スタックで張り付ける、または遅らせる前にしばらく装置のキャッシュで観測された交通を保有できました。
For these reasons, it can be difficult for the Collecting Process to convert the relative times exported using the flowStartSysUpTime and flowEndSysUpTime Information Elements to absolute times with any sort of accuracy without knowing the systemInitTimeMilliseconds. Therefore, the sending of the flowStartSysUpTime and flowEndSysUpTime Information Elements without also sending the systemInitTimeMilliseconds Information Element is not recommended.
これらの理由で、Collecting Processがどんな種類の精度でもsystemInitTimeMillisecondsを知らないでflowStartSysUpTimeとflowEndSysUpTime Information Elementsを使用することで輸出された相対的な時勢から絶対回を変換するのは、難しい場合があります。 したがって、また、systemInitTimeMilliseconds情報Elementを送ることのないflowStartSysUpTimeとflowEndSysUpTime Information Elementsの発信は推薦されません。
5. Collecting Process Guidelines
5. 過程ガイドラインを集めます。
5.1. Information Element (De)Coding
5.1. 情報要素(De)コード化
Section 9 of [RFC5101] specifies: "The Collecting Process MUST note the Information Element identifier of any Information Element that it does not understand and MAY discard that Information Element from the Flow Record". The Collecting Process may accept Templates with Information Elements of unknown types. In this case, the value received for these Information Elements should be decoded as an octet array.
[RFC5101]のセクション9は指定します: 「Collecting Processは、それがするどんな情報Elementに関する情報Element識別子も分かって、Flow Recordからその情報Elementを捨てないかもしれないことに注意しなければなりません。」 Collecting Processは未知のタイプのInformation Elementsと共にTemplatesを受け入れるかもしれません。 この場合、これらのInformation Elementsのための対価領収は八重奏アレイとして解読されるべきです。
Alternatively, the Collecting Process may ignore Templates and subsequent Data Sets that contain Information Elements of unknown types.
あるいはまた、Collecting Processは未知のタイプのInformation Elementsを含むTemplatesとその後のData Setsを無視するかもしれません。
It is recommended that Collecting Processes provide means to flexibly add types of new Information Elements to their knowledge base. An example is a configuration file that is read by the Collecting Process and that contains a list of Information Element identifiers and their corresponding types. Particularly for adding enterprise- specific Information Elements, such a feature can be very useful.
Collecting Processesが柔軟に新しいInformation Elementsのタイプを彼らの知識ベースに加える手段を提供するのは、お勧めです。 例は、Collecting Processによって読まれて、情報Element識別子のリストを含む構成ファイルと彼らの対応するタイプです。 特に企業の特定のInformation Elementsを加えるのに、そのような特徴は非常に役に立つ場合があります。
Boschi, et al. Informational [Page 11] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [11ページ]情報のRFC5153IPFIX実施要綱2008年4月
5.2. Reduced-Size Encoding of Information Elements
5.2. Information Elementsの減少しているサイズコード化
Since a Collector may receive data from the same device and Observation Domain in two Templates using different reduced-size encodings, it is recommended that the data be stored using full-size encoding, to ensure that the values can be stored or even aggregated together.
Collectorが2Templatesに同じ装置とObservation Domainから異なった減少しているサイズencodingsを使用することでデータを受け取るかもしれないので、データが値を格納できるのを保証するのにフルサイズコード化を使用することで格納されるか、または一緒に集められさえする、お勧めです。
5.3. Template Management
5.3. テンプレート管理
Template IDs are generated dynamically by the Exporting Process. They are unique per Transport Session and Observation Domain.
テンプレートIDはExporting Processによってダイナミックに発生します。 彼らはTransport SessionとObservation Domain単位でユニークです。
Therefore, for each Transport Session, the Collecting Process has to maintain a list of Observation Domains. For each Observation Domain, the Collecting Process has to maintain a list of current Template IDs in order to decode subsequent Data Records.
したがって、各Transport Sessionに関して、Collecting ProcessはObservation Domainsのリストを維持しなければなりません。 各Observation Domainに関しては、Collecting Processは、その後のData Recordsを解読するために現在のTemplate IDのリストを維持しなければなりません。
Note that a restart of the Transport Session may lead to a Template ID renumbering.
Transport Sessionの再開がTemplate IDの番号を付け替えるのに通じるかもしれないことに注意してください。
6. Transport-Specific Guidelines
6. 輸送特有のガイドライン
IPFIX can use SCTP, TCP, or UDP as a transport protocol. IPFIX implementations MUST support SCTP with partial reliability extensions (PR-SCTP), and MAY support TCP and/or UDP (see [RFC5101], Section 10.1). In the IPFIX documents, the terms SCTP and PR-SCTP are often used interchangeably to mean SCTP with partial reliability extensions.
IPFIXはトランスポート・プロトコルとしてSCTP、TCP、またはUDPを使用できます。 IPFIX実現は、部分的な信頼性の拡大(PR-SCTP)を伴うSCTPを支持しなければならなくて、TCP、そして/または、UDPを支持するかもしれません([RFC5101]、セクション10.1を見てください)。 IPFIXドキュメントでは、用語のSCTPとPR-SCTPは、部分的な信頼性の拡大を伴うSCTPを意味するのにしばしば互換性を持って使用されます。
6.1. SCTP
6.1. SCTP
PR-SCTP is the preferred transport protocol for IPFIX because it is congestion-aware, reducing total bandwidth usage in the case of congestion, but with a simpler state machine than TCP. This saves resources on lightweight probes and router line cards.
PR-SCTPはそれが混雑意識しているのでIPFIXに、都合のよいトランスポート・プロトコルですが、混雑の場合で総帯域幅用法を減少させて、TCPより簡単な州のマシンでそのようなトランスポート・プロトコルです。 これは軽量の徹底的調査とルータ線カードにリソースを保存します。
SCTP, as specified in [RFC4960] with the PR-SCTP extension defined in [RFC3758], provides several features not available in TCP or UDP. The two of these most universally applicable to IPFIX implementations, and which IPFIX implementers need to know about, are multiple streams and per-message partial reliability.
PR-SCTP拡張子が[RFC3758]で定義されている状態で[RFC4960]で指定されるSCTPはTCPかUDPで利用可能でないいくつかの特徴を提供します。 これら2つ、IPFIX実現とIPFIX implementersが、どれに関して知る必要があるかの周りに一般に最も適切であるのは、複数の流れと1メッセージあたり部分的な信頼性です。
An SCTP association may contain multiple streams. Streams are useful for avoiding head-of-line blocking, thereby minimizing end-to-end delay from the Exporting Process to the Collecting Process. Example
SCTP協会は複数の流れを含むかもしれません。流れは線のヘッドブロッキングを避けることの役に立ちます、その結果、Exporting ProcessからCollecting Processまで終わりから終わりへの遅れを最小にします。 例
Boschi, et al. Informational [Page 12] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [12ページ]情報のRFC5153IPFIX実施要綱2008年4月
applications for this feature would be using one SCTP stream per Observation Domain, one stream per type of data (or Template ID), or one stream for Flow data and one for metadata.
この特徴のアプリケーションはメタデータに1Observation Domainあたり1つのSCTPの流れ、データ(または、Template ID)のタイプあたり1つの流れ、またはFlowデータと1のための1つの流れを使用しているでしょう。
An Exporting Process may request any number of streams, and may send IPFIX Messages containing any type of Set (Data Set, Template Set, etc.) on any stream. A Collecting Process MUST be able to process any Message received on any stream.
Exporting Processはいろいろな流れを要求して、どんな流れにもSet(データSet、Template Setなど)のどんなタイプも含むIPFIX Messagesを送るかもしれません。 Collecting Processはどんな流れのときにも受け取られたどんなMessageも処理できなければなりません。
Stream negotiation is a feature of the SCTP protocol. Note, however, that the IPFIX protocol doesn't provide any mechanism for the Exporter to convey any information about which streams are in use to the Collector. Therefore, stream configuration must be done out of band.
流れの交渉はSCTPプロトコルの特徴です。 しかしながら、Exporterが流れがCollectorに使用中であるどんな情報も伝えるようにIPFIXプロトコルがどんなメカニズムも提供しないことに注意してください。 したがって、バンドから流れの構成をしなければなりません。
One extra advantage of the PR-SCTP association is its ability to send messages with different levels of reliability, selected according to the application. For example, billing or security applications might require reliable delivery of all their IPFIX Messages, while capacity planning applications might be more tolerant of message loss. SCTP allows IPFIX Messages for all these applications to be transported over the same association with the appropriate level of reliability.
PR-SCTP協会の1つの余分な利点がアプリケーションに従って選択された異なったレベルの信頼性があるメッセージを送るその性能です。 例えば、支払いかセキュリティアプリケーションがそれらのすべてのIPFIX Messagesの信頼できる配信を必要とするかもしれません、メッセージの損失ではキャパシティプランニングアプリケーションは、より許容性があるかもしれませんが。 SCTPは、これらのすべてのアプリケーションが信頼性の適正水準との同じ協会の上で輸送されるためにIPFIX Messagesを許容します。
IPFIX Messages may be sent with full or partial reliability, on a per-message basis. Fully reliable delivery guarantees that the IPFIX Message will be received at the Collecting Process or that that SCTP association will be reset, as with TCP. Partially reliable delivery does not guarantee the receipt of the IPFIX Message at the Collecting Process. This feature may be used to allow Messages to be dropped during network congestion, i.e., while observing a Denial of Service attack.
1メッセージあたり1個のベースに関する完全であるか部分的な信頼性でIPFIX Messagesを送るかもしれません。 完全に、信頼できる配信は、Collecting ProcessにIPFIX Messageを受け取るか、またはそのSCTP協会をリセットするのを保証します、TCPのように。 部分的に、信頼できる配信はCollecting ProcessでIPFIX Messageの領収書を保証しません。 この特徴は、Messagesがネットワークの混雑の間、落とされるのを許容するのにすなわち、サービス妨害攻撃を観測している間、使用されるかもしれません。
[RFC3758] defines the concept of a Partial Reliability policy, which specifies the interface used to control partially reliable delivery. It also defines a single example Partial Reliability policy called "timed reliability", which uses a single parameter: lifetime. The lifetime is specified per message in milliseconds, and after it expires, no further attempt will be made to transmit the message. Longer lifetimes specify more retransmission attempts per message and therefore higher reliability; however, it should be noted that the absolute reliability provided by a given lifetime is highly dependent on network conditions, so an Exporting Process using the timed reliability service should provide a mechanism for configuring the lifetime of exported IPFIX Messages. Another possible Partial Reliability policy could be limited retransmission, which guarantees a specified number of retransmissions for each message. It is up to the implementer to decide which Partial Reliability policy is most appropriate for its application.
[RFC3758]はPartial Reliability方針の概念を定義します。(方針は信頼できる配信を部分的に制御するのに使用されるインタフェースを指定します)。 また、それはただ一つのパラメタを使用する「調節された信頼性」と呼ばれるただ一つの例のPartial Reliability方針を定義します: 生涯。 ミリセカンドでメッセージ単位で生涯を指定します、そして、期限が切れた後にメッセージを送るのをさらなる試みを全くしないでしょう。 より長い寿命は、より多くの1メッセージあたりの「再-トランスミッション」試みを指定して、その結果より高い信頼性を指定します。 しかしながら、調節された信頼性のサービスを利用するExporting Processが輸出されたIPFIX Messagesの生涯を構成するのにメカニズムを提供するはずであって、与えられた生涯によって提供された絶対信頼性がネットワーク条件に非常に依存していることに注意されるべきです。 別の可能なPartial Reliability方針は限られた「再-トランスミッション」であるかもしれません。(その「再-トランスミッション」は各メッセージのために「再-トランスミッション」の指定された数を保証します)。 アプリケーションに、どのPartial Reliability方針が最も適切であるかを決めるのは、implementer次第です。
Boschi, et al. Informational [Page 13] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [13ページ]情報のRFC5153IPFIX実施要綱2008年4月
There is an additional service provided by SCTP and useful in conjunction with PR-SCTP: unordered delivery. This also works on a per-message basis by declaring that a given message should be delivered to the receiver as soon as it is queued rather than kept in sequence; however, it should be noted that unless explicitly requested by the sender, even messages sent partially reliably will still be delivered in order. Unordered delivery should not be used when the order of IPFIX Messages may matter: e.g., a Template or Options Template. Unordered delivery should not be used when Total counters are used, as reordering could result in the counter value decreasing at the Collecting Process and even being left with a stale value if the last message processed is stale.
SCTPでPR-SCTPに関連して役に立つことによって提供された追加サービスがあります: 順不同の配送。 また、それが系列に閉じ込めるよりむしろ列に並ばせられるとすぐに、与えられたメッセージが受信機に渡されるべきであると宣言することによって、これは1メッセージあたり1個のベースに取り組みます。 しかしながら、それでも、送付者によって明らかに要求されないと、部分的に確かに送られたメッセージさえ整然とした状態で送られることに注意されるべきです。 IPFIX Messagesの注文が重要であるときに、順不同の配送を使用するべきではありません: 例えば、TemplateかOptions Template。 Totalカウンタが使用されているとき、順不同の配送を使用するべきではありません、再命令がCollecting Processで対価減少をもたらすかもしれなくて、最後のメッセージが処理されたなら聞き古した値と共に残されさえする聞き古したである。
By convention, when the IPFIX documents state a requirement for reliable delivery (as, for example, the IPFIX protocol document does for Template Sets, Options Template Sets, and Template Withdrawal Messages), an IPFIX Exporting Process must not use partially reliable delivery for those Messages. By default, and explicitly if the IPFIX documents call for "partially reliable" or "unreliable" delivery, an IPFIX Exporting Process may use partially reliable delivery if the other requirements of the application allow.
IPFIXドキュメントが信頼できる配信のための要件を述べるときの(例えば、IPFIXプロトコルドキュメントがTemplate Sets、Options Template Sets、およびTemplate Withdrawal Messagesのためにそうするように)コンベンションで、IPFIX Exporting ProcessはそれらのMessagesに信頼できる配信を部分的に使用してはいけません。 IPFIXドキュメントが「部分的に信頼できる」か「頼り無い」配送を求めるなら、デフォルトで、明らかに、IPFIX Exporting Processはアプリケーションの他の要件であるなら信頼できる配信を部分的に使用するかもしれません。許容します。
The Collecting Process may check whether IPFIX Messages are lost by checking the Sequence Number in the IPFIX header. The Collecting Process should use the Sequence Number in the IPFIX Message Header to determine whether any messages are lost when sent with partial reliability. Sequence Numbers should be tracked independently for each stream.
Collecting Processは、IPFIX MessagesがIPFIXヘッダーでSequence Numberをチェックすることによってなくされているかどうかチェックするかもしれません。 Collecting Processは、部分的な信頼性で送ると何かメッセージが無くなるかどうか決定するのにIPFIX Message HeaderでSequence Numberを使用するはずです。 系列民数記は各流れのために独自に追跡されるべきです。
The following may be done to mitigate message loss:
メッセージの損失を緩和するために以下をするかもしれません:
o Increase the SCTP buffer size on the Exporter.
o ExporterでSCTPバッファサイズを増加させてください。
o Increase the bandwidth available for communicating the exported
Data Records.
o 輸出されたData Recordsを伝えるのに利用可能な帯域幅を増加させてください。
o Use sampling, filtering, or aggregation in the Metering Process to
reduce the amount of exported data (see [RFC5101], Section
10.4.2.3).
o [RFC5101]、セクション10.4を見てください。Metering Processで標本抽出、フィルタリング、または集合を使用して、輸出されたデータの量を減少させてください、(.2 .3)。
o If partial reliability is used, switch to fully reliable delivery
on the Exporting Process or increase the level of partial
reliability (e.g., when using timed reliability, by specifying a
longer lifetime for exported IPFIX Messages).
o 部分的な信頼性が使用されているなら、完全に信頼できる配送にExporting Processを切り換えるか、または部分的な信頼性のレベルを増加させてください(例えば、使用はいつ輸出されたIPFIX Messagesにより長い生涯を指定することによって、信頼性を調節しましたか)。
Boschi, et al. Informational [Page 14] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [14ページ]情報のRFC5153IPFIX実施要綱2008年4月
If the SCTP association is brought down because the IFPIX Messages can't be exported reliably, the options are:
SCTP協会がIFPIX Messagesを確かに輸出できないので破滅しているなら、オプションは以下の通りです。
o Increase the SCTP buffer size on the Exporter.
o ExporterでSCTPバッファサイズを増加させてください。
o Increase the bandwidth available for communicating the exported
Data Records.
o 輸出されたData Recordsを伝えるのに利用可能な帯域幅を増加させてください。
o Use sampling, filtering, or aggregation in the Metering Process to
reduce the amount of exported data.
o Metering Processで標本抽出、フィルタリング、または集合を使用して、輸出されたデータの量を減少させてください。
Note that Templates must not be resent when using SCTP, without an intervening Template Withdrawal or SCTP association reset. Note also that since Template Sets and Template Withdrawal Messages may be sent on any SCTP stream, a Template Withdrawal Message may withdraw a Template sent on a different stream, and a Template Set may reuse a Template ID withdrawn by a Template Withdrawal Message sent on a different stream. Therefore, an Exporting Process sending Template Withdrawal Messages should ensure to the extent possible that the Template Withdrawal Messages and subsequent Template Sets reusing the withdrawn Template IDs are received and processed at the Collecting Process in proper order. The Exporting Process can achieve this by one of two possible methods: 1. by sending a Template Withdrawal Message reliably, in order, and on the same stream as the subsequent Template Set reusing its ID; or 2. by waiting an appropriate amount of time (on the scale of one minute) after sending a Template Withdrawal Message before attempting to reuse the withdrawn Template ID.
介入しているTemplate WithdrawalもSCTP協会リセットなしでSCTPを使用するときにはTemplatesを再送してはいけないことに注意してください。 また、Template Withdrawal MessageがどんなSCTPの流れにもTemplate SetsとTemplate Withdrawal Messagesを送るかもしれないので異なった流れに送られたTemplateを引っ込めるかもしれなくて、Template Setが異なった流れに送られたTemplate Withdrawal Messageが引き下がらせたTemplate IDを再利用するかもしれないことに注意してください。 したがって、Exporting Process送付Template Withdrawal Messagesは、よそよそしいTemplate IDを再利用するTemplate Withdrawal Messagesとその後のTemplate Setsが適切なオーダーでCollecting Processに受け取られて、処理されるのを可能な範囲内で確実にするはずです。 Exporting Processは2つの可能な方法の1つでこれを達成できます: 1. 確か、注文、IDを再利用するその後のTemplate Setと同じ流れの発信するのによるTemplate Withdrawal Message。 2 または、試みる前にTemplate Withdrawal Messageを送った後に適切な時間(1分のスケールの)を待つことによって、よそよそしいTemplate IDを再利用してください。
6.2. UDP
6.2. UDP
UDP is useful in simple systems where an SCTP stack is not available, and where there is insufficient memory for TCP buffering.
UDPはSCTPスタックが利用可能でなく、TCPバッファリングのための不十分な記憶がある簡単なシステムで役に立ちます。
However, UDP is not a reliable transport protocol, and IPFIX Messages sent over UDP might be lost as with partially reliable SCTP streams. UDP is not the recommended protocol for IPFIX and is intended for use in cases in which IPFIX is replacing an existing NetFlow infrastructure, with the following properties:
しかしながら、UDPは信頼できるトランスポート・プロトコルではありません、そして、UDPの上に送られたIPFIX Messagesは部分的に信頼できるSCTPの流れならなくされるかもしれません。UDPはIPFIXにおけるお勧めのプロトコルでなく、IPFIXが既存のNetFlowインフラストラクチャを置き換えている場合における使用のために意図します、以下の特性で:
o A dedicated network,
o 専用ネットワーク
o within a single administrative domain,
o ただ一つの管理ドメインの中で
o where SCTP is not available due to implementation constraints, and
o そしてSCTPが実現規制のために入手できないところ。
o the Collector is as topologically close as possible to the
Exporter.
o CollectorはExporterに可能な状態で同じくらい位相的に閉じることです。
Boschi, et al. Informational [Page 15] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [15ページ]情報のRFC5153IPFIX実施要綱2008年4月
Note that because UDP itself provides no congestion control mechanisms, it is recommended that UDP transport be used only on managed networks, where the network path has been explicitly provisioned for IPFIX traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations.
ネットワーク経路がIPFIX交通通過交通工学メカニズムのために明らかに食糧を供給されたところでレート制限や容量の予約のようにUDP自身が混雑制御機構を全く提供しないのでUDP輸送が管理されたネットワークだけで使用されるのが、お勧めであることに注意してください。
An important example of an explicitly provisioned, managed network for IPFIX is the use of IPFIX to replace a functioning NetFlow implementation on a dedicated network. In this situation, the dedicated network should be provisioned in accordance with the NetFlow deployment experience that Flow export traffic generated by monitoring an interface will amount to 2-5% of the monitored interface's bandwidth.
IPFIXのための明らかに食糧を供給されて、管理されたネットワークの重要な例は専用ネットワークで機能しているNetFlow実現を取り替えるIPFIXの使用です。 この状況で、専用ネットワークはNetFlow展開経験に従って食糧を供給されて、インタフェースをモニターすることによって発生するそのFlow輸出交通が2-5 モニターされたインタフェースの%の帯域幅に達するということであるべきです。
As recommended in [TSVWG-UDP], an application should not send UDP messages that result in IP packets that exceed the MTU of the path to the destination and should enable UDP checksums (see Sections 3.2 and 3.4 of [TSVWG-UDP], respectively).
[TSVWG-UDP]で推薦されるように、アプリケーションは、経路のMTUを目的地に超えているIPパケットでその結果をUDPメッセージに送るべきでなくて、UDPチェックサムを可能にするべきです(それぞれ[TSVWG-UDP]のセクション3.2と3.4を見てください)。
Since IPFIX assumes reliable transport of Templates over SCTP, this necessitates some changes for IPFIX Template management over UDP. Templates sent from the Exporting Process to the Collecting Process over UDP MUST be resent at regular time intervals; these intervals MUST be configurable (see Section 10.3 of [RFC5101]).
IPFIXがSCTPの上でTemplatesの信頼できる輸送を仮定するので、これはUDPの上のIPFIX Template管理のためのいくつかの変化を必要とします。 テンプレートはExporting ProcessからCollecting Processまで発信しました。UDP MUSTの上に、規定時間間隔を置いて、再送してください。 これらの間隔は構成可能であるに違いありません([RFC5101]のセクション10.3を見てください)。
We recommend a default Template-resend time of 10 minutes, configurable between 1 minute and 1 day.
私たちは、デフォルトが微小な1日と1日の間で構成可能な10分の時間をTemplate再送することを勧めます。
Note that this could become an interoperability problem; e.g., if an Exporter resends Templates once per day, while a Collector expires Templates hourly, then they may both be IPFIX-compatible, but not be interoperable.
これが相互運用性問題になることができたことに注意してください。 例えば、Exporterが1日に一度Templatesを再送しますが、Collectorが一時間Templatesを吐き出すなら、彼らは、IPFIXともに互換性がありますが、共同利用できないかもしれません。
Retransmission time intervals that are too short waste bandwidth on unnecessary Template retransmissions. On the other hand, time intervals that are too long introduce additional costs or risk of data loss by potentially requiring the Collector to cache more data without having the Templates available to decode it.
短過ぎるRetransmission時間間隔は不要なTemplate retransmissionsに帯域幅を浪費します。 他方では、Collectorがそれを解読するために利用可能なTemplatesを持っていなくて、より多くのデータをキャッシュするのを潜在的に必要とすることによって、長過ぎる時間間隔は別途費用かデータの損失の危険を導入します。
To increase reliability and limit the amount of potentially lost data, the Exporting Process may resend additional Templates using a packet-based schedule. In this case, Templates are resent depending on the number of data packets sent. Similarly to the time interval, resending a Template every few packets introduces additional overhead, while resending after a large amount of packets have already been sent means high costs due to the data caching and potential data loss.
信頼性を増加させて、潜在的に無くなっているデータの量を制限するために、Exporting Processはパケットベースのスケジュールを使用することで追加Templatesを再送するかもしれません。 この場合、パケットが送ったデータの数に依存するのをTemplatesを再送します。 同様に、あらゆるわずかなパケット単位でTemplateを再送すると、時間間隔まで、追加オーバーヘッドは導入されます、既に多量のパケットを送った後に、データのキャッシュしていて潜在的のデータの損失のため、再送は高いコストを意味しますが。
Boschi, et al. Informational [Page 16] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [16ページ]情報のRFC5153IPFIX実施要綱2008年4月
We recommend a default Template-resend interval of 20 packets, configurable between 1 and 1000 data packets.
私たちは、デフォルトが20のパケット、構成可能な1〜1000のデータ・パケットの間隔をTemplate再送することを勧めます。
Note that a sufficiently small resend time or packet interval may cause a system to become stuck, continually resending Templates or Options Data. For example, if the resend packet interval is 2 (i.e., Templates or Options Data are to be sent in every other packet) but more than two packets are required to send all the information, then the resend interval will have expired by the time the information has been sent, and Templates or Options Data will be sent continuously -- possibly preventing any data from being sent at all. Therefore, the resend intervals should be considered from the last data packet, and should not be tied to specific Sequence Numbers.
張り付けられるようになるように間隔が引き起こすかもしれない時間かパケットにシステムを再送して、絶えずTemplatesかOptions Dataを再送して、十分小さくそのaに注意してください。 例えば、再送、パケット間隔は2(すなわち、TemplatesかOptions Dataが他のあらゆるパケットで送られることになっている)ですが、2つ以上のパケットがすべての情報を送るのに必要です、そして情報を送って、ことによるとどんなデータも全く送られるのを防いで、絶え間なくTemplatesかOptions Dataを送る時までに意志が吐き出した間隔を再送してください。 間隔を再送してください。したがって、最後のデータ・パケットから考えるべきであり、特定のSequence民数記に結ぶべきではありません。
The Collecting Process should use the Sequence Number in the IPFIX Message Header to determine whether any messages are lost.
Collecting Processは、何かメッセージが無くなるかどうか決定するのにIPFIX Message HeaderでSequence Numberを使用するはずです。
The following may be done to mitigate message loss:
メッセージの損失を緩和するために以下をするかもしれません:
o Move the Collector topologically closer to the Exporter.
o CollectorをExporterの、より近くに位相的に動かしてください。
o Increase the bandwidth of the links through which the Data Records
are exported.
o Data Recordsが輸出されるリンクの帯域幅を増加させてください。
o Use sampling, filtering, or aggregation in the Metering Process to
reduce the amount of exported data.
o Metering Processで標本抽出、フィルタリング、または集合を使用して、輸出されたデータの量を減少させてください。
o Increase the buffer size at the Collector and/or the Exporter.
o Collector、そして/または、Exporterでバッファサイズを増加させてください。
Before using a Template for the first time, the Exporter may send it in several different IPFIX Messages spaced out over a period of packets in order to increase the likelihood that the Collector has received the Template.
初めてTemplateを使用する前に、ExporterはCollectorがTemplateを受けた可能性を広げるためにパケットの期間、間をおかれた数個の異なったIPFIX Messagesでそれを送るかもしれません。
Template Withdrawal Messages MUST NOT be sent over UDP (per Section 10.3.6 of [RFC5101]). The Exporter must rely on expiration at the Collector to expire old Templates or to reuse Template IDs.
UDP(.6セクション10.3[RFC5101]あたりの)の上にテンプレートWithdrawal Messagesを送ってはいけません。 Exporterは、古いTemplatesを吐き出すか、またはTemplate IDを再利用するためにCollectorで満了に依存しなければなりません。
We recommend that the Collector implements a Template Expiry of three times the Exporter refresh rate.
私たちは、CollectorがExporterリフレッシュレートの3倍のTemplate Expiryを実行することを勧めます。
However, since the IPFIX protocol doesn't provide any mechanism for the Exporter to convey any information about the Template Expiry time to the Collector, configuration must be done out of band.
しかしながら、ExporterがTemplate Expiry時頃にどんな情報もCollectorに伝えるようにIPFIXプロトコルがどんなメカニズムも提供しないので、バンドから構成しなければなりません。
Boschi, et al. Informational [Page 17] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [17ページ]情報のRFC5153IPFIX実施要綱2008年4月
If no out-of-band configuration is made, we recommend to initially set a Template Expiry time at the Collector of 60 minutes. The Collecting Process may estimate each Exporting Process's resend time and adapt the Expiry time for the corresponding Templates accordingly.
いいえなら、バンドの外では、構成は作られて、私たちは、60分のCollectorでTemplate Expiry時間を決めるように初めは勧めます。 Collecting Processは、Exporting Processの各ものが対応するTemplatesのためにそれに従って、時間を再送して、Expiry時間を適合させると見積もるかもしれません。
6.3. TCP
6.3. TCP
TCP can be used as a transport protocol for IPFIX if one of the endpoints has no support for SCTP, but a reliable transport is needed and/or the network between the Exporter and the Collector has not explicitly been provisioned for the IPFIX traffic. TCP is one of the core protocols of the Internet and is widely supported.
信頼できる輸送が必要です、そして、終点の1つにSCTPのサポートが全くないなら、IPFIXにトランスポート・プロトコルとしてTCPを使用できますが、ExporterとCollectorの間のネットワークは明らかにIPFIX交通に食糧を供給されていません。 TCPはインターネットのコアプロトコルの1つであり、広く支持されます。
The Exporting Process may resend Templates (per UDP, above), but it's not required to do so, per Section 10.4.2.2 of [RFC5101]:
Exporting ProcessはTemplates(上でUDP単位で)を再送するかもしれませんが、それはセクション10.4.2あたりのそうに.2[RFC5101]をするのに必要ではありません:
"A Collecting Process MUST record all Template and Options Template Records for the duration of the connection, as an Exporting Process is not required to re-export Template Records."
「Collecting Processは接続の持続時間のためにすべてのTemplateとOptions Template Recordsを記録しなければなりません、Exporting ProcessはTemplate Recordsを再輸出するのに必要でないときに。」
If the available bandwidth between Exporter and Collector is not sufficient or the Metering Process generates more Data Records than the Collector is capable of processing, then TCP congestion control may cause the Exporter to block. Options in this case are:
ExporterとCollectorの間の利用可能な帯域幅が十分でないか、またはMetering ProcessがCollectorが処理できるより多くのData Recordsを発生させるなら、TCP輻輳制御はブロックにExporterを引き起こすかもしれません。 この場合、オプションは以下の通りです。
o Increase the TCP buffer size on the Exporter.
o ExporterでTCPバッファサイズを増加させてください。
o Increase the bandwidth of the links through which the Data Records
are exported.
o Data Recordsが輸出されるリンクの帯域幅を増加させてください。
o Use sampling, filtering, or aggregation in the Metering Process to
reduce the amount of exported data.
o Metering Processで標本抽出、フィルタリング、または集合を使用して、輸出されたデータの量を減少させてください。
7. Guidelines for Implementation on Middleboxes
7. Middleboxesにおける実現のためのガイドライン
The term middlebox is defined in [RFC3234] as:
middleboxという用語は[RFC3234]で以下と定義されます。
"any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host."
「IPルータの正常で、標準の機能を除いて、どんな媒介装置実行も送信元ホストとあて先ホストの間のデータグラム経路で機能します。」
The list of middleboxes discussed in [RFC3234] contains:
[RFC3234]で議論したmiddleboxesのリストは以下を含んでいます。
1. Network Address Translation (NAT),
1. アドレス変換(NAT)をネットワークでつないでください。
2. NAT-Protocol Translation (NAT-PT),
2. NATプロトコル変換(太平洋標準時のNAT)
Boschi, et al. Informational [Page 18] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [18ページ]情報のRFC5153IPFIX実施要綱2008年4月
3. SOCKS gateway,
3. SOCKSゲートウェイ
4. IP tunnel endpoints,
4. IPトンネル終点
5. packet classifiers, markers, schedulers,
5. パケットクラシファイア、マーカー、スケジューラ
6. transport relay,
6. リレーを輸送してください。
7. TCP performance enhancing proxies,
7. プロキシを高めるTCP性能
8. load balancers that divert/munge packets,
8. /mungeパケットを紛らす負荷分散装置
9. IP firewalls,
9. IPファイアウォール
10. application firewalls,
10. アプリケーションファイアウォール
11. application-level gateways,
11. アプリケーションレベルゲートウェイ
12. gatekeepers / session control boxes,
12. 門番/セッションは箱を制御します。
13. transcoders,
13. トランスコーダ
14. proxies,
14. プロキシ
15. caches,
15. キャッシュ
16. modified DNS servers,
16. 変更されたDNSサーバ
17. content and applications distribution boxes,
17. 内容とアプリケーション給水分散皿
18. load balancers that divert/munge URLs,
18. /munge URLを紛らす負荷分散装置
19. application-level interceptors,
19. アプリケーションレベル迎撃戦闘機
20. application-level multicast,
20. アプリケーションレベルマルチキャスト
21. involuntary packet redirection,
21. 不本意なパケットリダイレクション
22. anonymizers.
22. anonymizers。
It is likely that since the publication of RFC 3234 new kinds of middleboxes have been added.
RFCの公表以来、新しい3234種類のmiddleboxesは加えられそうです。
While the IPFIX specifications [RFC5101] based the requirements on the export protocol only (as the IPFIX name implies), these sections cover the guidelines for the implementation of the Metering Process by recommending which Information Elements to export for the different middlebox considerations.
IPFIX仕様[RFC5101]が要件を輸出プロトコルだけに基礎づけていた間(IPFIX名が含意するように)、これらのセクションはどのInformation Elementsを推薦するかによるMetering Processの実現が異なったmiddlebox問題のために輸出するガイドラインをカバーします。
Boschi, et al. Informational [Page 19] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [19ページ]情報のRFC5153IPFIX実施要綱2008年4月
7.1. Traffic Flow Scenarios at Middleboxes
7.1. Middleboxesの交通の流れシナリオ
Middleboxes may delay, reorder, drop, or multiply packets; they may change packet header fields and change the payload. All these actions have an impact on traffic Flow properties. In general, a middlebox transforms a unidirectional original traffic Flow T that arrives at the middlebox into a transformed traffic Flow T' that leaves the middlebox.
Middleboxesはそうするかもしれません。遅れ(追加注文)は、パケットを低下するか、または掛けます。 彼らは、パケットヘッダーフィールドを変えて、ペイロードを変えるかもしれません。 これらのすべての動作が交通Flowの特性に影響を与えます。 '一般に、middleboxはmiddleboxに到着する単方向のオリジナルの交通Flow Tを'それがmiddleboxを残す変成している交通Flow Tに変えます。
+-----------+
T ---->| middlebox |----> T'
+-----------+
+-----------+ T---->| middlebox|----'>T'+-----------+
Figure 1: Unidirectional traffic Flow traversing a middlebox
図1: middleboxを横断する単方向の交通Flow
Note that in an extreme case, T' may be an empty traffic Flow (a Flow with no packets), for example, if the middlebox is a firewall and blocks the Flow.
'はなはだしきに至っては、T'が人影のない交通Flowであるかもしれないこと(パケットのないFlow)に注意してください、middleboxが例えばファイアウォールであり、Flowを妨げるなら。
In case of a middlebox performing a multicast function, a single original traffic Flow may be transformed into more than one transformed traffic Flow.
マルチキャスト機能を実行するmiddlebox、Flowが変成しているかもしれないただ一つの元の交通の場合には、1以上は交通Flowを変えました。
+------> T'
|
+---------+-+
T ---->| middlebox |----> T''
+---------+-+
|
+------> T'''
+------'>T'| +---------++T---->| middlebox|----「>T」+---------+-+ | +------'「>T」'
Figure 2: Unidirectional traffic Flow traversing a middlebox with
multicast function
図2: マルチキャスト機能があるmiddleboxを横断する単方向の交通Flow
For bidirectional traffic Flows, we identify Flows on different sides of the middlebox; say, T_l on the left side and T_r on the right side.
双方向の交通Flowsに、私たちはmiddleboxの異なった側面の上のFlowsを特定します。 たとえば、左側のT_lと右側のT_r。
+-----------+
T_l <--->| middlebox |<---> T_r
+-----------+
+-----------+ T_l<。--->| middlebox| <、-、-->T_r+-----------+
Figure 3: Bidirectional unicast traffic Flow traversing a middlebox
図3: middleboxを横断する双方向のユニキャスト交通Flow
In case of a NAT, T_l might be a traffic Flow in a private address realm and T_r the translated traffic Flow in the public address realm. If the middlebox is a NAT-PT, then T_l may be an IPv4 traffic Flow and T_r the translated IPv6 traffic Flow.
NATの場合には、T_lは、プライベート・アドレス分野の交通Flowと場内放送分野のT_r翻訳された交通Flowであるかもしれません。 middleboxが太平洋標準時のNATであるなら、T_lはIPv4交通FlowとT_r翻訳されたIPv6交通Flowであるかもしれません。
Boschi, et al. Informational [Page 20] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [20ページ]情報のRFC5153IPFIX実施要綱2008年4月
At tunnel endpoints, Flows are multiplexed or demultiplexed. In general, tunnel endpoints can deal with bidirectional traffic Flows.
トンネル終点では、Flowsを多重送信するか、または反多重送信します。 一般に、トンネル終点は双方向の交通Flowsに対処できます。
+------> T_r1
v
+---------+-+
T_l <--->| middlebox |<---> T_r2
+---------+-+
^
+------> T_r3
+------>T_r1対+---------++T_l<。--->| middlebox| <、-、-->T_r2+---------+-+ ^ +------>T_r3
Figure 4: Multiple data reduction
図4: 複数のデータ整理
An example is a traffic Flow T_l of a tunnel and Flows T_rx that are multiplexed into or demultiplexed out of a tunnel. According to the IPFIX definition of traffic Flows in [RFC5101], T and T' or T_l and T_rx, respectively, are different Flows in general.
例はトンネルから多重送信されたか反多重送信されたトンネルとFlows T_rxのトラフィックFlow T_lです。 '[RFC5101]とのトラフィックFlowsのIPFIX定義に従って、TとT'かT_lとT_rxがそれぞれ一般に異なったFlowsです。
However, from an application point of view, they might be considered as closely related or even as the same Flow, for example, if the payloads they carry are identical.
しかしながら、アプリケーション観点から、例えば、それらが運ぶペイロードが同じであるなら、それらは同じくらい同じ密接に関係づけられたか、同等のFlowであるとみなされるかもしれません。
7.2. Location of the Observation Point
7.2. 観測所の位置
Middleboxes might be integrated with other devices. An example is a router with a NAT or a firewall at a line card. If an IPFIX Observation Point is located at the line card, then the properties of measured traffic Flows may depend on the side of the integrated middlebox at which packets were captured for traffic Flow measurement.
Middleboxesは対向機器について統合しているかもしれません。 例は、NATがあるルータか系列カードのファイアウォールです。 IPFIX Observation Pointが系列カードに位置しているなら、測定トラフィックFlowsの特性はパケットがトラフィックFlow測定のためにキャプチャされた統合middleboxの側面に依存するかもしれません。
Consequently, an Exporting Process reporting traffic Flows measured at a device that hosts one or more middleboxes should clearly indicate to Collecting Processes the location of the used Observation Point(s) with respect to the middlebox(es). This can be done by using Options with Observation Point as scope and elements like, for instance, lineCardID or samplerID. Otherwise, processing the measured Flow data could lead to wrong results.
その結果、トラフィックFlowsが1middleboxesを接待するデバイスで測定したと報告するExporting Processはmiddlebox(es)に関して明確に中古のObservation Point(s)の位置をCollecting Processesに示すはずです。 範囲と要素が例えばlineCardIDかsamplerIDが好きであるようにObservation Pointと共にOptionsを使用することによって、これができます。 さもなければ、測定Flowデータを処理するのは間違った結果に通じるかもしれません。
At first glance, choosing an Observation Point that covers the entire middlebox looks like an attractive choice. But this leads to ambiguities for all kinds of middleboxes. Within the middlebox, properties of packets are modified, and it should be clear at a Collecting Process whether packets were observed and metered before or after modification. For example, it must be clear whether a reported source IP address was observed before or after a NAT changed it or whether a reported packet count was measured before or after a
一見したところでは、全体のmiddleboxをカバーするObservation Pointを選ぶと、魅力的な選択は似られています。 しかし、これはすべての種類のmiddleboxesのためのあいまいさに通じます。 middleboxの中では、パケットの特性は変更されていて、パケットが変更の前または後に観測されて、計量されたかどうかが、Collecting Processで明確であるはずです。 例えば、aが、以前かNATがそれを変えた後にソースIPアドレスが観測されたと報告したかどうか、または報告されたパケットカウントがaの前または後に測定されたかどうかが、明確であるに違いありません。
Boschi, et al. Informational [Page 21] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [21ページ]情報のRFC5153IPFIX実施要綱2008年4月
firewall dropped packets. For this reason, [RFC5102] provides Information Elements with prefix "post" for Flow properties that are changed within a middlebox.
ファイアウォールはパケットを下げました。 この理由で、[RFC5102]はmiddleboxの中で変えられるFlow資産のために接頭語「ポスト」をInformation Elementsに提供します。
If an Observation Point is located inside a middlebox, the middlebox must have well-defined and well-separated internal functions, for example, a combined NAT and firewall, and the Observation Point should be located on a boundary between middlebox functions rather than within one of the functions.
Observation Pointがmiddleboxの中に位置しているなら、middleboxには、例えば結合した明確でよく切り離された内部の機能、NAT、およびファイアウォールがなければなりません、そして、Observation Pointは機能の1つの中でというよりむしろmiddlebox機能の間の境界に位置するべきです。
7.3. Reporting Flow-Related Middlebox Internals
7.3. 流れ関連のMiddleboxインターナルを報告します。
While this document recommends IPFIX implementations using Observation Points outside of middlebox functions, there are a few special cases where reporting Flow-related internals of a middlebox is of interest.
このドキュメントはmiddlebox機能の外でObservation Pointsを使用することで実装をIPFIXに推薦しますが、いくつかの特別なケースがmiddleboxのFlow関連のインターナルを報告するのは興味があるところにあります。
For many applications that use traffic measurement results, it is desirable to get more information than can be derived from just observing packets on one side of a middlebox. If, for example, packets are dropped by the middlebox acting as a firewall, NAT, or traffic shaper, then information about how many observed packets are dropped may be of high interest.
トラフィック測定結果を使用する多くのアプリケーションに、middleboxの半面の上でただパケットを観察するのから派生できるより多くの情報を得るのは望ましいです。 例えば、パケットがファイアウォール、NAT、またはトラフィック整形器として作動するmiddleboxが下げられるなら、いくつが、パケットが下げられるのを観測したかの情報は高利のものであるかもしれません。
This section gives recommendations on middlebox internal information that may be reported if the IPFIX Observation Point is co-located with one or more middleboxes. Since the internal information to be reported depends on the kind of middlebox, it is discussed per kind.
このセクションはIPFIX Observation Pointが1middleboxesで共同見つけられているなら報告されるかもしれないmiddleboxの内部の情報で推薦を与えます。 報告されるべき内部の情報がmiddleboxの種類によるので、1種類単位でそれについて議論します。
The recommendations cover middleboxes that act per packet and that do not modify the application-level payload of the packet (except by dropping the entire packet) and that do not insert additional packets into an application-level or transport-level traffic stream.
推薦はパケット単位で行動して、パケット(低下を除いた全体のパケット)のアプリケーションレベルペイロードを変更しないで、またアプリケーションレベルか輸送レベルトラフィックストリームに追加パケットを挿入しないmiddleboxesをカバーしています。
Covered are the packet-level middleboxes of kinds 1, 2, 3, 5, 9, 10, 21, and 22 (according to the enumeration given at the beginning of Section 7 of this document). Not covered are 4, 6-8 and 11-20. TCP performance-enhancing proxies (7) are not covered because they may add ACK packets to a TCP connection.
カバーされているのは、種類1、2、3、5、9、10、21、および22(このドキュメントのセクション7の始めに与えられた列挙に従って)のパケット・レベルmiddleboxesです。 カバーされていないのは、4と、6-8と11-20です。 彼らがTCP接続にACKパケットを加えるかもしれないので、性能を高めるTCPプロキシ(7)はカバーされていません。
Still, if possible, IPFIX implementations co-located with uncovered middleboxes (i.e., of type 7 or 11-20) should follow the recommendations given in this section if they can be applied in a way that reflects the intention of these recommendations.
それでも、できれば、むき出しのmiddleboxes(すなわち、タイプ7か11-20の)で共同見つけられたIPFIX実装はこれらの推薦の意志を反映する方法でそれらを適用できるならこのセクションで与えられた推薦に続くべきです。
Boschi, et al. Informational [Page 22] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [22ページ]情報のRFC5153IPFIX実施要綱2008年4月
7.3.1. Packet Dropping Middleboxes
7.3.1. Middleboxesを下げるパケット
If an IPFIX Observation Point is co-located with one or more middleboxes that potentially drop packets, then the corresponding IPFIX Exporting Process should be able to report the number of packets that were dropped per reported Flow.
IPFIX Observation Pointが潜在的にパケットを下げる1middleboxesで共同見つけられているなら、対応するIPFIX Exporting Processは報告されたFlow単位で下げられたパケットの数を報告するはずであることができます。
Concerned kinds of middleboxes are NAT (1), NAT-PT (2), SOCKS gateway (3), packet schedulers (5), IP firewalls (9) and application-level firewalls (10).
middleboxesの関係がある種類はNAT(1)です(太平洋標準時のNAT(2)、SOCKSゲートウェイ(3)、パケットスケジューラ(5)、IPファイアウォール(9)、およびアプリケーションレベルファイアウォール(10))。
7.3.2. Middleboxes Changing the DSCP
7.3.2. DSCPを変えるMiddleboxes
If an IPFIX Observation Point is co-located with one or more middleboxes that potentially modify the Diffserv Code Point (DSCP, see [RFC2474]) in the IP header, then the corresponding IPFIX Exporting Process should be able to report both the observed incoming DSCP value and also the DSCP value on the 'other' side of the middlebox (if this is a constant value for the particular traffic flow). The related Information Elements specified in [RFC5102] are: IpClassOfService and postIpClassOfService.
IPFIX Observation PointがIPヘッダーで潜在的に、Diffserv Code Point(DSCP、[RFC2474]を見る)を変更する1middleboxesで共同見つけられているなら、対応するIPFIX Exporting Processはmiddleboxの'他'の側面の観測された入って来るDSCP値とDSCP値についても両方を報告するはずであることができます(これが特定の交通の流れのための恒常価値であるなら)。 Elementsが[RFC5102]で指定した関連する情報は以下の通りです。 IpClassOfServiceとpostIpClassOfService。
Note that the current IPFIX information model only contains Information Elements supporting packets observed before the DSCP change, i.e. ipClassOfService and postIpClassOfService, where the latter reports the value of the IP TOS field after the DSCP change. We recommend, whenever possible, to move the Observation Point to the point before the DSCP change and report the Observed and post- values. If reporting the value of the IP TOS field before DSCP change is required, "pre" values can be exported using enterprise- specific Information Elements.
DSCPが変化した後に現在のIPFIX情報モデルがDSCPが変化する前に観察されたパケットをサポートするInformation Elements、すなわち、ipClassOfService、およびpostIpClassOfServiceを含むだけであることに注意してください。(そこでは、後者がIP TOS分野の値を報告します)。 可能であるときはいつも、私たちは、DSCPが以前肝心のObservation Pointを動かすために、Observedとポスト値を変えて、報告することを勧めます。 報告するならDSCPが変化する前にIP TOS分野の値が必要である、「前、」 企業の特定のInformation Elementsを使用することで値をエクスポートすることができます。
Note also that a classifier may change the same DSCP value of packets from the same Flow to different values depending on the packet or other conditions. Also, it is possible that packets of a single unidirectional arriving Flow contain packets with different DSCP values that are all set to the same value by the middlebox. In both cases, there is a constant value for the DSCP field in the IP packet header to be observed on one side of the middlebox, but on the other side the value may vary. In such a case, reliable reporting of the DSCP value on the 'other' side of the middlebox is not possible by just reporting a single value. According to the IPFIX information model [RFC5102], the first value observed for the DSCP is reported by the IPFIX protocol in that case.
また、クラシファイアがパケットの同じDSCP値を同じFlowからパケットに依存する異価か他の状態に変えるかもしれないことに注意してください。 また、到着Flowがすべてである異なったDSCP値があるパケットを含む単一の単方向のパケットがmiddleboxで同じ値にセットしたのも、可能です。 どちらの場合も、IPパケットのヘッダーのDSCP分野がmiddleboxの半面の上で観測されるために、恒常価値がありますが、反対側では、値は異なるかもしれません。 このような場合には、middleboxの'他'の側面でのDSCP価値の信頼できる報告はただただ一つの値を報告することによって、可能ではありません。 IPFIX情報モデル[RFC5102]に従って、DSCPに関して観測された最初の値はその場合IPFIXプロトコルによって報告されます。
This recommendation applies to packet markers (5).
この推薦はパケットマーカー(5)に適用されます。
Boschi, et al. Informational [Page 23] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [23ページ]情報のRFC5153IPFIX実施要綱2008年4月
7.3.3. Middleboxes Changing IP Addresses and Port Numbers
7.3.3. IPアドレスとポートナンバーを変えるMiddleboxes
If an IPFIX Observation Point is co-located with one or more middleboxes that potentially modify the:
IPFIX Observation Pointがそれが潜在的に変更する1middleboxesで共同位置している、:
o IP version field,
o IPバージョン分野
o IP source address header field,
o IPソースアドレスヘッダーフィールド
o IP destination address header field,
o 受信者IPアドレスヘッダーフィールド
o Source transport port number, or
o またはソース輸送ポートナンバー。
o Destination transport port number
o 目的地輸送ポートナンバー
in one of the headers, then the corresponding IPFIX Exporting Process should be able to report the 'translated' value of these fields, as far as they have constant values for the particular traffic Flow, in addition to the observed values of these fields.
次に、ヘッダーのひとりでは、対応するIPFIX Exporting Processはこれらの分野の'翻訳された'値を報告するはずであることができます、それらに特定のトラフィックFlowのための恒常価値がある限り、これらの分野の観測値に加えて。
If the changed values are not constant for the particular traffic Flow but still reporting is desired, then it is recommended that the general rule from [RFC5102] for Information Elements with changing values is applied: the reported value is the one that applies to the first packet observed for the reported Flow.
特定のトラフィックFlowには、変えられた値が一定ではありませんが、それでも、報告が望まれているなら、値を変えるInformation Elementsのための[RFC5102]からの一般的な規則が適用されているのは、お勧めです: 報告された値は報告されたFlowに関して観察された最初のパケットに適用されるものです。
Note that the 'translated' value of the fields can be the values before or after the translation depending on the Flow direction and the location of the Observation Point with respect to the middlebox. We always call the value that is not the one observed at the Observation Point the translated value.
分野の'翻訳された'値がmiddleboxに関してFlow方向とObservation Pointの位置に依存する翻訳の前または後に値であるかもしれないことに注意してください。 私たちは、Observation Pointで観測されたものでない値をいつも翻訳された値と呼びます。
Note also that a middlebox may change the same port number value of packets from the same Flow to different values depending on the packet or other conditions. Also, it is possible that packets of different unidirectional arriving Flows with different source/ destination port number pairs may be mapped to a single Flow with a single source/destination port number pair by the middlebox. In both cases, there is a constant value for the port number pair to be observed on one side of the middlebox, but on the other side the values may vary. In such a case, reliable reporting of the port number pairs on the 'other' side of the middlebox is not possible. According to the IPFIX information model [RFC5102], the first value observed for each port number is reported by the IPFIX protocol in that case.
また、middleboxがパケットの同じポートナンバー値を同じFlowからパケットに依存する異価か他の状態に変えるかもしれないことに注意してください。 また、異なったソース/仕向港数の組がある異なった単方向到着Flowsのパケットが単一のソース/仕向港数の組と共にmiddleboxによって独身のFlowに写像されるのも、可能です。 どちらの場合も、ポートナンバー組がmiddleboxの半面の上で観察されるために、恒常価値がありますが、反対側では、値は異なるかもしれません。 このような場合には、middleboxの'他'の側面でのポートナンバー組の信頼できる報告は可能ではありません。 IPFIX情報モデル[RFC5102]に従って、各ポートナンバーに関して観測された最初の値はその場合IPFIXプロトコルによって報告されます。
Boschi, et al. Informational [Page 24] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [24ページ]情報のRFC5153IPFIX実施要綱2008年4月
This recommendation applies to NAT (1), NAT-PT (2), SOCKS gateway (3) and involuntary packet redirection (21) middleboxes. It may also be applied to anonymizers (22), though it should be noted that this carries the risk of losing the effect of anonymization.
この推薦は太平洋標準時のNATのナット(1)、(2)、SOCKSゲートウェイ(3)、および不本意なパケットリダイレクション(21)middleboxesに適用されます。 また、それはanonymizers(22)に適用されるかもしれません、これがanonymizationの効果を失う危険を伴うことに注意されるべきですが。
8. Security Guidelines
8. 安全ガイドライン
8.1. Introduction to TLS and DTLS for IPFIX Implementers
8.1. IPFIX ImplementersのためのTLSとDTLSへの紹介
Transport Layer Security (TLS) [RFC4346] and Datagram Transport Layer Security (DTLS) [RFC4347] are the REQUIRED protocols for securing network traffic exported with IPFIX (see Section 11 of [RFC5101]). TLS requires a reliable transport channel and is selected as the security mechanism for TCP. DTLS is a version of TLS capable of securing datagram traffic and is selected for UDP, SCTP, and PR-SCTP.
輸送Layer Security(TLS)[RFC4346]とデータグラムTransport Layer Security(DTLS)[RFC4347]は、IPFIXと共にエクスポートされたネットワークトラフィックを確保するためのREQUIREDプロトコル([RFC5101]のセクション11を見る)です。 TLSは高信頼の輸送チャンネルを必要として、TCPのためのセキュリティー対策として選定されます。 DTLSはデータグラムトラフィックを保証できるTLSのバージョンであり、UDP、SCTP、およびPR-SCTPのために選択されます。
When mapping TLS terminology used in [RFC4346] to IPFIX terminology, keep in mind that the IPFIX Exporting Process, as it is the connection initiator, corresponds to the TLS client, and the IPFIX Collecting Process corresponds to the TLS server. These terms apply only to the bidirectional TLS handshakes done at Transport Session establishment and completion time; aside from TLS connection set up between the Exporting Process and the Collecting Process, and teardown at the end of the session, the unidirectional Flow of messages from Exporting Process to Collecting Process operates over TLS just as over any other transport layer for IPFIX.
いつ[RFC4346]でIPFIX用語に使用されるTLS用語を写像して、IPFIX Exporting Processがそれが接続創始者であるのでTLSクライアントに文通するのを覚えておいてください。そうすれば、IPFIX Collecting Processはサーバこれらの用語がTransport Session設立で行われた双方向のTLS握手だけに適用するTLSに対応しますか、そして、完成時間。 Exporting ProcessとCollecting Processの間でセットアップされたTLS接続、およびセッションの終わりの分解は別として、Exporting ProcessからCollecting Processまでのメッセージの単方向FlowはIPFIXのためのまさしくいかなる他のトランスポート層のようにもTLSの上で作動します。
8.2. X.509-Based Identity Verification for IPFIX over TLS or DTLS
8.2. TLSかDTLSの上のIPFIXのためのX.509ベースのアイデンティティ検証
When using TLS or DTLS to secure an IPFIX Transport Session, the Collecting Process and Exporting Process must use strong mutual authentication. In other words, each IPFIX endpoint must have its own X.509 certificate [RFC3280] and private key, and the Collecting Process, which acts as the TLS or DTLS server, must send a Certificate Request to the Exporting Process during the TLS handshake, and fail to establish a session if the Exporting Process does not present a valid certificate.
IPFIX Transport Sessionを固定するのにTLSかDTLSを使用するとき、Collecting ProcessとExporting Processは強い互いの認証を使用しなければなりません。 言い換えれば、それぞれのIPFIX終点にはそれ自身のX.509証明書[RFC3280]と秘密鍵がなければならなくて、Exporting Processが有効な証明書を提示しないなら、Collecting Process(TLSかDTLSサーバとして機能する)はTLS握手の間、Certificate RequestをExporting Processに送って、セッションを確立してはいけません。
Each Exporting Process and Collecting Process must verify the identity of its peer against a set of authorized peers. This may be done by configuring a set of authorized distinguished names and comparing the peer certificate's subject distinguished name against each name in the set. However, if a private certification authority (CA) is used to sign the certificates identifying the Collecting Processes and Exporting Processes, and the set of certificates signed by that private CA may be restricted to those identifying peers authorized to communicate with each other, it is sufficient to merely verify that the peer's certificate is issued by this private CA.
各Exporting ProcessとCollecting Processは1セットの認可された同輩に対して同輩のアイデンティティについて確かめなければなりません。 1セットの認可された分類名を構成して、セットにおける各名前に対して同輩証明書の対象の分類名をたとえることによって、これをするかもしれません。 しかしながら、個人的な証明権威(カリフォルニア)が証明書がCollecting Processesを特定して、Exporting Processesであると署名するのに使用されて、その個人的なカリフォルニアによって署名された証明書のセットが互いにコミュニケートするのに権限を与えられた同輩を特定するものに制限されるかもしれないなら、同輩の証明書がこの個人的なカリフォルニアによって発行されることを単に確かめるのは十分です。
Boschi, et al. Informational [Page 25] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [25ページ]情報のRFC5153IPFIX実施要綱2008年4月
When verifying the identity of its peer, an IPFIX Exporting Process or Collecting Process must verify that the peer certificate's subject common name or subjectAltName extension dNSName matches the fully- qualified domain name (FQDN) of the peer. This involves retrieving the expected domain name from the peer certificate and the address of the peer, then verifying that the two match via a DNS lookup. Such verification should require both that forward lookups (FQDN to peer address) and reverse lookups (peer address to FQDN) match. In deployments without DNS infrastructure, it is acceptable to represent the FQDN as an IPv4 dotted-quad or a textual IPv6 address as in [RFC1924].
同輩のアイデンティティについて確かめるとき、IPFIX Exporting ProcessかCollecting Processが、同輩証明書の対象の一般名かsubjectAltName拡張子dNSNameが同輩の完全に適切なドメイン名(FQDN)に合っていることを確かめなければなりません。 これは、同輩証明書と同輩のアドレスから予想されたドメイン名を検索することを伴います、次に、DNSルックアップで2が合っていることを確かめて。 そのような検証は前進のルックアップ(同輩アドレスへのFQDN)と逆のルックアップ(FQDNへの同輩アドレス)が合っている両方を必要とするべきです。 DNSインフラストラクチャのない展開では、IPv4の点を打たされた回路か原文のIPv6アドレスとしてFQDNを表すのは[RFC1924]のように許容できます。
8.3. Implementing IPFIX over TLS over TCP
8.3. TCPの上のTLSの上でIPFIXを実装します。
Of the security solutions specified for IPFIX, TLS over TCP is as of this writing the most mature and widely implemented. Until stable implementations of DTLS over SCTP are widely available (see Section 8.5, below), it is recommended that applications requiring secure transport for IPFIX Messages use TLS over TCP.
IPFIXに指定されたセキュリティソリューションでは、TCPの上のTLSは大部分が熟させるこの書くこと現在、あって、広く実装されます。 SCTPの上のDTLSの安定した実装が広く利用可能になるまで(以下でセクション8.5を見てください)、IPFIX Messagesのために安全な輸送を必要とするアプリケーションがTCPの上でTLSを使用するのは、お勧めです。
When using TLS over TCP, IPFIX Exporting Processes and Collecting Processes should behave in all other aspects as if using TCP as the transport protocol, especially as regards the handling of Templates and Template withdrawals.
TCPの上でTLSを使用するとき、まるで輸送としての使用TCPが特にあいさつとしてTemplatesとTemplate退出の取り扱いについて議定書の中で述べるかのようにIPFIX Exporting ProcessesとCollecting Processesは他のすべての局面で振る舞うはずです。
8.4. Implementing IPFIX over DTLS over UDP
8.4. UDPの上のDTLSの上でIPFIXを実装します。
An implementation of the DTLS protocol version 1, described in [RFC4347] and required to secure IPFIX over UDP, is available in OpenSSL [OPENSSL] as of version 0.9.8. However, DTLS support is as of this writing under active development and certain implementations might be unstable. We recommend extensive testing of DTLS-based IPFIX implementations to build confidence in the DTLS stack over which your implementation runs.
[RFC4347]で説明されて、UDPの上にIPFIXを固定するのに必要であるDTLSプロトコルバージョン1の実装はバージョン0.9.8現在、OpenSSL[OPENSSL]で利用可能です。 しかしながら、DTLSサポートは、この書くこと現在、活発な開発中であり、実装が不安定であるかもしれないと確信されています。 私たちは、DTLSベースのIPFIX実装の大規模なテストがあなたの実装が稼働するDTLSスタックで自信を育むことを勧めます。
When using DTLS over UDP, IPFIX Exporting Processes and Collecting Processes should behave in all other aspects as if using UDP as the transport protocol, especially as regards the handling of Templates and Template timeouts.
UDPの上でDTLSを使用するとき、まるで輸送としての使用UDPが特にあいさつとしてTemplatesとTemplateタイムアウトの取り扱いについて議定書の中で述べるかのようにIPFIX Exporting ProcessesとCollecting Processesは他のすべての局面で振る舞うはずです。
Note that the selection of IPFIX Message sizes for DTLS over UDP must account for overhead per packet introduced by the DTLS layer.
UDPの上のDTLSのためのIPFIX Messageサイズの品揃えが1DTLS層で導入されたパケットあたりのオーバーヘッドを説明しなければならないことに注意してください。
Boschi, et al. Informational [Page 26] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [26ページ]情報のRFC5153IPFIX実施要綱2008年4月
8.5. Implementing IPFIX over DTLS over SCTP
8.5. SCTPの上のDTLSの上でIPFIXを実装します。
As of this writing, there is no publicly available implementation of DTLS over SCTP as described in [RFC4347] and [TUEXEN].
この書くこと現在、SCTPの上にDTLSのどんな公的に利用可能な実装も[RFC4347]と[TUEXEN]で説明されるようにありません。
When using DTLS over SCTP, IPFIX Exporting Processes and Collecting Processes should behave in all other aspects as if using SCTP as the transport protocol, especially as regards the handling of Templates and the use of reliable transport for Template and scope information.
SCTPの上でDTLSを使用するとき、IPFIX Exporting ProcessesとCollecting Processesはまるでトランスポート・プロトコルとしてSCTPを使用するかのように他のすべての局面で振る舞うはずです、特にTemplatesの取り扱いと信頼できることの使用がTemplateと範囲情報のために輸送するあいさつとして。
An implementation of the DTLS protocol version 1, described in [RFC4347] and required to secure IPFIX over SCTP, is available in OpenSSL [OPENSSL] as of version 0.9.8. However, DTLS support is as of this writing under active development and certain implementations might be unstable. We recommend extensive testing of DTLS-based IPFIX implementations to build confidence in the DTLS stack over which your implementation runs.
[RFC4347]で説明されて、SCTPの上にIPFIXを固定するのに必要であるDTLSプロトコルバージョン1の実装はバージョン0.9.8現在、OpenSSL[OPENSSL]で利用可能です。 しかしながら、DTLSサポートは、この書くこと現在、活発な開発中であり、実装が不安定であるかもしれないと確信されています。 私たちは、DTLSベースのIPFIX実装の大規模なテストがあなたの実装が稼働するDTLSスタックで自信を育むことを勧めます。
9. Extending the Information Model
9. 情報モデルを広げています。
IPFIX supports two sets of Information Elements: IANA-registered Information Elements and enterprise-specific Information Elements. New Information Elements can be added to both sets as described in this section. If an Information Element is considered of general interest, it should be added to the set of IETF-specified Information Elements that is maintained by IANA.
IPFIXはInformation Elementsの2セットを支えます: IANAによって登録されたInformation Elementsと企業特有のInformation Elements。 このセクションで説明されるように新しいInformation Elementsを両方のセットに追加できます。 情報Elementが一般的興味について考えられるなら、それはIANAによって維持されるIETFによって指定されたInformation Elementsのセットに追加されるべきです。
Alternatively, private enterprises can define proprietary Information Elements for internal purposes. There are several potential reasons for doing so. For example, the Information Element might only relate to proprietary features of a device or protocol of the enterprise. Also, pre-standard product delivery or commercially sensitive product features might cause the need for enterprise-specific Information Elements.
あるいはまた、私企業は内部の目的のために独占Information Elementsを定義できます。 そうするいくつかの潜在的理由があります。 例えば、情報Elementは企業についてデバイスの独占特徴に関係づけるか、または議定書の中で述べるだけであるかもしれません。 また、プレ規格品配送か商業的に機密の製品特性が企業特有のInformation Elementsの必要性を引き起こすかもしれません。
The IPFIX information model [RFC5102] document contains an XML-based specification of Template, abstract data types, and IPFIX Information Elements, which may be used to create consistent machine-readable extensions to the IPFIX information model. This description can be used for automatically checking syntactic correctness of the specification of IPFIX Information Elements and for generating code that deals with processing IPFIX Information Elements.
IPFIX情報モデル[RFC5102]ドキュメントはTemplate、抽象データ型、およびIPFIX Information ElementsのXMLベースの仕様を含んでいます。(Elementsは、一貫した機械可読な拡大をIPFIX情報モデルに作成するのに使用されるかもしれません)。 自動的にIPFIX Information Elementsの仕様の構文の正当性をチェックして、処理IPFIX Information Elementsに対応するコードを生成するのにこの記述を使用できます。
9.1. Adding New IETF-Specified Information Elements
9.1. 新しいIETFによって指定されたInformation Elementsを加えます。
New IPFIX Information Elements that are considered to be of general interest should be added to the set of IETF-specified Information Elements that is maintained by IANA.
一般的興味があると考えられる新しいIPFIX Information ElementsはIANAによって維持されるIETFによって指定されたInformation Elementsのセットに追加されるべきです。
Boschi, et al. Informational [Page 27] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [27ページ]情報のRFC5153IPFIX実施要綱2008年4月
The introduction of new Information Elements in the IANA registry is subject to expert review. As described in Section 7.1 of [RFC5102], an expert review is performed by one of a group of experts designated by an IETF Operations and Management Area Director. The experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups. The group of experts must double check the Information Elements definitions with already defined Information Elements for completeness, accuracy, redundancy, and correct naming following the naming conventions in [RFC5102], Section 2.3.
IANA登録での新しいInformation Elementsの導入は専門のレビューを受けることがあります。 [RFC5102]のセクション7.1で説明されるように、専門のレビューはIETF Operationsによって任命された専門家とManagement Areaディレクターのグループの1つによって実行されます。 初めは、IPFIXとPSAMP Working Groupsの作業部会Chairsとドキュメントエディタから専門家を得るでしょう。 専門家のグループは既にがある情報Elementsの定義が命名規則に続く完全性、精度、冗長、および正しい命名のためのInformation Elementsを定義したチェック[RFC5102]を倍にしなければなりません、セクション2.3。
The specification of new IPFIX Information Elements must use the Template specified in [RFC5102], Section 2.1, and must be published using a well-established and persistent publication medium.
新しいIPFIX Information Elementsの仕様を[RFC5102]、セクション2.1で指定されたTemplateを使用しなければならなくて、安定していて永続的な公表媒体を使用することで発表しなければなりません。
9.2. Adding Enterprise-Specific Information Elements
9.2. エンタープライズ-特殊情報Elementsを加えます。
Enterprises or other organizations holding a registered Structure of Management Information (SMI) network management private enterprise code number can specify enterprise-specific Information Elements. Their identifiers can be chosen arbitrarily within the range of 1-32767 and have to be coupled with a Private Enterprise Identifier [PEN]. Enterprise identifiers MUST be registered as SMI network management private enterprise code numbers with IANA. The registry can be found at http://www.iana.org/assignments/enterprise-numbers.
Management情報(SMI)ネットワークマネージメント私企業コード番号の登録されたStructureを支えるエンタープライズか他の組織が企業特有のInformation Elementsを指定できます。 それらの識別子は、1-32767の範囲の中で任意に選ぶことができて、兵士のエンタープライズIdentifier[PEN]に結びつけられなければなりません。 SMIネットワークマネージメント私企業コード番号としてエンタープライズ識別子をIANAに登録しなければなりません。 http://www.iana.org/assignments/enterprise-numbers で登録を見つけることができます。
10. Common Implementation Mistakes
10. 一般的な実装誤り
The issues listed in this section were identified during implementation and interoperability testing. They do not stem from insufficient clarity in the protocol, but each of these was an actual mistake made in a tested IPFIX implementation. They are listed here for the convenience of future implementers.
このセクションで記載された問題は実装と相互運用性テストの間、特定されました。 それらはプロトコルにおける不十分な明快に由来しませんが、それぞれのこれらはテストされたIPFIX実装に関する実際の誤りでした。 それらは将来のimplementersの都合のためにここに記載されています。
10.1. IPFIX and NetFlow Version 9
10.1. IPFIXとNetFlowバージョン9
A large group of mistakes stems from the fact that many implementers started implementing IPFIX from an existing version of NetFlow version 9 [RFC3954]. Despite their similarity, the two protocols differ in many aspects. We list here some of the most important differences.
誤りの大きいグループは多くのimplementersがNetFlowバージョン9[RFC3954]の既存のバージョンからIPFIXを実装し始めたという事実によります。 それらの類似性にもかかわらず、2つのプロトコルが多くの局面で異なります。 私たちはここに最も重要な違いのいくつかを記載します。
o Transport protocol: NetFlow version 9 initially ran over UDP,
while IPFIX must have a congestion-aware transport protocol.
IPFIX specifies PR-SCTP as its mandatory protocol, while TCP and
UDP are optional.
o トランスポート・プロトコル: NetFlowバージョン9は初めは、UDPをひきましたが、IPFIXには、混雑意識しているトランスポート・プロトコルがなければなりません。 IPFIXは義務的なプロトコルとしてPR-SCTPを指定しますが、TCPとUDPは任意です。
Boschi, et al. Informational [Page 28] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [28ページ]情報のRFC5153IPFIX実施要綱2008年4月
o IPFIX differentiates between IANA-registered and enterprise-
specific Information Elements. Enterprise-specific Information
Elements can be specified by coupling a non-IANA-registered
Information Element identifier with an Enterprise ID
(corresponding to the vendor that defined the Information
Element).
o IPFIXはIANAによって登録されるのと企業の特定のInformation Elementsを区別します。 エンタープライズID(情報Elementを定義したベンダーに対応する)と非IANAが登録している情報Element識別子を結合することによって、エンタープライズ特有のInformation Elementsを指定できます。
o Options Templates: in IPFIX, an Options Template must have a
scope, and the scope is not allowed to be of length zero. The
NetFlow version 9 specifications [RFC3954] don't specify that the
scope must not be of length zero.
o オプションテンプレート: IPFIXでは、Options Templateは範囲を持たなければなりません、そして、範囲は長さゼロのものであることであることができません。 NetFlowバージョン9仕様[RFC3954]は、範囲が長さゼロのものであるはずがないと指定しません。
Message Header:
メッセージヘッダー:
o Set ID: Even if the packet headers are different between IPFIX and
NetFlow version 9, similar fields are used in both of them. The
difference between the two protocols is in the values that these
fields can assume. A typical example is the Set ID values: the
Set ID values of 0 and 1 are used in NetFlow version 9, while they
are not used in IPFIX.
o IDを設定してください: パケットのヘッダーがIPFIXとNetFlowバージョン9の間で異なっても、同様の分野はそれらの両方で使用されます。 これらの分野が仮定できる値には2つのプロトコルの違いがあります。 典型的な例はSet ID値です: 0と1のSet ID値はNetFlowバージョン9で使用されます、それらがIPFIXで使用されませんが。
o Length field: in NetFlow version 9, this field (called count)
contains the number of Records. In IPFIX, it indicates the total
length of the IPFIX Message, measured in octets (including Message
Header and Set(s)).
o 長さの分野: NetFlowバージョン9では、この分野(カウントと呼ばれる)はRecordsの数を含んでいます。 八重奏で測定されて、IPFIXでは、それはIPFIX Messageの全長を示します。(Message HeaderとSet(s))を含んでいます。
o Timestamp: the NetFlow version 9 header has an additional
timestamp: sysUpTime. It indicates the time in milliseconds since
the last reboot of the Exporting Process.
o タイムスタンプ: NetFlowバージョン9ヘッダーには、追加タイムスタンプがあります: sysUpTime。 それはExporting Processの最後のリブート以来のミリセカンドで時間を示します。
o The version number is different. NetFlow version 9 uses the
version number 9, while IPFIX uses the version number 10.
o バージョン番号は異なっています。 NetFlowバージョン9はバージョンNo.9を使用しますが、IPFIXはバージョンNo.10を使用します。
10.2. Padding of the Data Set
10.2. データセットの詰め物
[RFC5101] specifies that the Exporting Process MAY insert some octets for set padding to align Data Sets within a Message. The padding length must be shorter than any allowable Record in that set.
[RFC5101]は、セット詰め物がMessageの中でData Setsを並べるようにExporting Processがいくつかの八重奏を挿入するかもしれないと指定します。 詰め物の長さはそれのどんな許容できるRecordによるセットだったよりも短いに違いありません。
It is important to respect this limitation: if the padding length is equal to or longer than the length of the shortest Record, it will be interpreted as another Record.
この制限を尊敬するのは重要です: 最も短いRecordで、詰め物の長さが等しいか、または長さより長いなら、それは別のRecordとして解釈されるでしょう。
An alternative is to use the paddingOctets Information Element in the Template definition.
代替手段はTemplate定義にpaddingOctets情報Elementを使用することです。
Boschi, et al. Informational [Page 29] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [29ページ]情報のRFC5153IPFIX実施要綱2008年4月
10.3. Field ID Numbers
10.3. 分野ID番号
Information Element numbers in IPFIX have the range 0-32767 (0-0x7FFF). Information Element numbers outside this range (i.e., with the high bit set) are taken to be enterprise-specific Information Elements, which have an additional four-byte Private Enterprise Number following the Information Element number and length. Inadvertently setting the high bit of the Information Element number by selecting a number out of this range will therefore cause Template scanning errors.
IPFIXの情報Element番号には、範囲0-32767(0-0 x7FFF)があります。 企業特有のInformation Elementsと、情報Element番号に従って、どれに追加4バイトの兵士のエンタープライズNumberがあるか、そして、長さになるようにこの範囲(すなわち、高いビットがセットしたことでの)の外の情報Element番号を取ります。 したがって、この範囲から数を選択することによってうっかり情報Element番号の高いビットを設定すると、走査誤差はTemplateに引き起こされるでしょう。
10.4. Template ID Numbers
10.4. テンプレートID番号
Template IDs are generated as required by the Exporting Process. When the same set of Information Elements is exported at different times, the corresponding Template is usually identified by different Template IDs. Similarly, if multiple co-existing Templates are composed of the same set of Information Elements, they are also identified by different Template IDs. The Collecting Process does not know in advance which Template ID a particular Template will use.
テンプレートIDは必要に応じてExporting Processによって生成されます。 Information Elementsの同じセットがいろいろな時間にエクスポートされるとき、通常、対応するTemplateは異なったTemplate IDによって特定されます。 また、同様に、複数の共存しているTemplatesがInformation Elementsの同じセットで構成されるなら、彼らは異なったTemplate IDによって特定されます。 Collecting Processは、あらかじめ、特定のTemplateがどのTemplate IDを使用するかを知りません。
11. Security Considerations
11. セキュリティ問題
This document describes the implementation guidelines of IPFIX. The security requirements for the IPFIX target applications are addressed in the IPFIX requirements document [RFC3917]. These requirements are considered for the specification of the IPFIX protocol [RFC5101], for which a Security Considerations Section exists.
このドキュメントはIPFIXに関する実施要綱について説明します。 IPFIX目標アプリケーションのためのセキュリティ要件はIPFIX要件ドキュメント[RFC3917]で扱われます。 これらの要件はIPFIXプロトコル[RFC5101]の仕様のために考えられます。(Security Considerationsセクションはプロトコルのために存在します)。
Section 7 of this document recommends that IPFIX Exporting Processes report internals about middleboxes. These internals may be security- relevant, and the reported information needs to be protected appropriately for reasons given below.
このドキュメントのセクション7は、IPFIX Exporting Processesがmiddleboxesに関してインターナルを報告することを勧めます。 これらのインターナルはセキュリティ関連しているかもしれません、そして、報告された情報は以下にあげられた理由で適切に保護される必要があります。
Reporting of packets dropped by firewalls and other packet-dropping middleboxes carries the risk that this information can be used by attackers for analyzing the configuration of the middlebox and for developing attacks against it. Address translation may be used for hiding the network structure behind an address translator. If an IPFIX Exporting Process reports the translations performed by an address translator, then parts of the network structure may be revealed. If an IPFIX Exporting Process reports the translations performed by an anonymizer, the main function of the anonymizer may be compromised.
パケットの報告はそれに対してファイアウォールとこの情報がリスクであるかもしれませんが、middleboxの構成を分析して、展開している攻撃に攻撃者によって使用されて、middleboxesが運ぶ他のパケット低下に立ち寄りました。 アドレス変換は、アドレス変換機構の後ろにネットワーク構造を隠すのに使用されるかもしれません。 IPFIX Exporting Processが、翻訳がアドレス変換機構で働いたと報告するなら、ネットワーク構造の部品は顕にせられるかもしれません。 IPFIX Exporting Processが、翻訳がanonymizerで働いたと報告するなら、anonymizerの主な機能は感染されるかもしれません。
Note that there exist vulnerabilities in DTLS over SCTP as specified in the IPFIX protocol, such that a third party could cause messages to be undetectably lost, or an SCTP association to shut down. These
IPFIXプロトコルで指定されるSCTPの上のDTLSの脆弱性が存在することに注意してください、第三者がundetectablyに失われるべきメッセージ、または停止するSCTP協会を引き起こす場合があったように。 これら
Boschi, et al. Informational [Page 30] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [30ページ]情報のRFC5153IPFIX実施要綱2008年4月
vulnerabilities are addressed by [TUEXEN]; however, it is unclear whether initial OpenSSL-based implementations of DTLS over SCTP will contain the required fixes. DTLS over SCTP should be used with caution in production environments until these issues are completely addressed.
脆弱性は[TUEXEN]によって記述されます。 しかしながら、SCTPの上のDTLSの初期のOpenSSLベースの実現が必要なフィックスを含むかどうかが、不明瞭です。 これらの問題が完全に記述されるまで、SCTPの上のDTLSは実稼動環境に慎重に使用されるべきです。
12. Acknowledgments
12. 承認
We would like to thank the MoMe project for organizing two IPFIX Interoperability Events in July 2005 and in March 2006, and Fraunhofer Fokus for organizing the third one in November 2006. The Interoperability Events provided us precious input for this document. Thanks to Brian Trammell for his contributions to the SCTP section and the security guidelines and for the multiple thorough reviews. We would also like to thank Benoit Claise, Carsten Schmoll, and Gerhard Muenz for the technical review and feedback, and Michael Tuexen, Randall Stewart, and Peter Lei for reviewing the SCTP section.
2005年7月、2006年3月に2IPFIX Interoperability Eventsを組織化して頂いて、MoMeプロジェクトに感謝します、そして、私たちは、2006年11月の3番目のものを組織化するためにフラウンホーファーFokusに感謝したいです。 Interoperability Eventsはこのドキュメントのための貴重な入力を私たちに提供しました。 SCTP部への彼の貢献と安全ガイドラインと複数の徹底的なレビューをブライアン・トラメルをありがとうございます。 また、SCTP部を見直すために技術審査、フィードバック、マイケルTuexen、ランドル・スチュワート、およびピーターLeiについてブノワClaise、カルステンSchmoll、およびゲルハルトMuenzに感謝申し上げます。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[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.(エド)、「IP流れ情報の仕様はIP交通の流れ情報の交換のために(IPFIX)プロトコルを輸出します」、RFC5101、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.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、「IP流れ情報輸出のための情報モデル」、RFC5102(2008年1月)。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
13.2. Informative References
13.2. 有益な参照
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
"IPFIX Applicability", Work in Progress, July 2007.
[IPFIX、-、]、Zseby、T.、Boschi、E.、ブラウンリー、N.、およびB.Claise、「IPFIXの適用性」が進歩、2007年7月に働いています。
[IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and J.
Quittek, "Architecture for IP Flow Information
Export", Work in Progress, September 2006.
G.とブラウンリーとN.とClaise、B.とJ.Quittek、「IP流れ情報輸出のための構造」という[IPFIX-アーチ]Sadasivanは進行中(2006年9月)で働いています。
[IPFIX-REDUCING] Boschi, E., Mark, L., and B. Claise, "Reducing
Redundancy in IP Flow Information Export (IPFIX)
and Packet Sampling (PSAMP) Reports", Work
in Progress, May 2007.
[IPFIX-減少] 「IP流れ情報輸出(IPFIX)とパケット標本抽出(PSAMP)レポートの冗長を減らし」て、Boschi、E.、マーク、L.、およびB.Claiseは進行中(2007年5月)で働いています。
Boschi, et al. Informational [Page 31] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [31ページ]情報のRFC5153IPFIX実施要綱2008年4月
[PSAMP-PROTO] Claise, B., Quittek, J., and A. Johnson, "Packet
Sampling (PSAMP) Protocol Specifications", Work
in Progress, December 2007.
B.、Quittek、J.、およびA.ジョンソン、「パケット標本抽出(PSAMP)プロトコル仕様」という[PSAMP-プロト]Claiseは進歩、2007年12月に働いています。
[TUEXEN] Tuexen, M. and E. Rescorla, "Datagram Transport
Layer Security for Stream Control Transmission
Protocol", Work in Progress, November 2007.
[TUEXEN] 「流れの制御伝動プロトコルのためのデータグラムトランスポート層セキュリティ」というTuexen、M.、およびE.レスコラは進歩、2007年11月に働いています。
[TSVWG-UDP] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines
for Application Designers", Work in Progress,
February 2008.
[TSVWG-UDP] 「アプリケーション設計者へのUDP用法ガイドライン」というエッゲルト、L.、およびG.Fairhurstは進歩、2008年2月に働いています。
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis",
RFC 1305, March 1992.
[RFC1305] 工場、D.、「ネットワーク時間は仕様、実現、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[RFC1924] Elz, R., "A Compact Representation of IPv6
Addresses", RFC 1924, April 1996.
[RFC1924]Elz、1996年4月のR.、「IPv6アドレスのコンパクトな表現」RFC1924。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2474] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」、RFC2474(1998年12月)。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy
and Issues", RFC 3234, February 2002.
[RFC3234]大工、B.、およびS.があふれそうになる、「Middleboxes:」 「分類学と問題」、RFC3234、2月2002日
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[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]スチュワート、R.、Ramalho(M.、シェ、Q.、Tuexen、M.、およびP.コンラッド)は「制御伝動のプロトコルの(SCTP)部分的な信頼性の拡大を流します」、RFC3758、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.ザンダー、「IP流れ情報のための要件は(IPFIX)を輸出します」、RFC3917、2004年10月。
[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services
Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B.、エド、「シスコシステムズのNetFlowサービスは2004年10月にバージョン9インチ、RFC3954を輸出します」。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346,
April 2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
Boschi, et al. Informational [Page 32] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [32ページ]情報のRFC5153IPFIX実施要綱2008年4月
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport
Layer Security", RFC 4347, April 2006.
[RFC4347] レスコラとE.とN.Modadugu、「データグラムトランスポート層セキュリティ」、RFC4347、2006年4月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission
Protocol", RFC 4960, September 2007.
[RFC4960] スチュワート、R.、エド、「流れの制御伝動プロトコル」、RFC4960、9月2007日
[OPENSSL] OpenSSL, "OpenSSL: The Open Source toolkit for SSL/
TLS", <http://www.openssl.org/>.
[OPENSSL]OpenSSL、「OpenSSL:」 「SSL/ TLSのためのオープンSourceツールキット」、<http://www.openssl.org/>。
[PEN] IANA, "PRIVATE ENTERPRISE NUMBERS", <http://
www.iana.org/assignments/enterprise-numbers>.
[PEN]IANA、「私企業番号」、<企業http://www.iana.org/課題/番号>。
Authors' Addresses
作者のアドレス
Elisa Boschi Hitachi Europe c/o ETH Zurich Gloriastr. 35 8092 Zurich Switzerland
エリーサBoschi日立ヨーロッパ気付ETHチューリッヒGloriastr。 35 8092チューリッヒスイス
Phone: +41 44 6327057 EMail: elisa.boschi@hitachi-eu.com
以下に電話をしてください。 +41 44 6327057はメールされます: elisa.boschi@hitachi-eu.com
Lutz Mark Fraunhofer FOKUS Kaiserin Augusta Allee 31 10589 Berlin Germany
ルッツマークフラウンホーファーFOKUS皇后オーガスタ並木道31 10589ベルリンドイツ
Phone: +49 421 2246-206 EMail: lutz.mark@ifam.fraunhofer.de
以下に電話をしてください。 +49 421 2246-206 メールしてください: lutz.mark@ifam.fraunhofer.de
Juergen Quittek NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
ユルゲンQuittek NECヨーロッパLtd.Kurfuersten-原基36 69115ハイデルベルグドイツ
Phone: +49 6221 4342-115 EMail: quittek@nw.neclab.eu
以下に電話をしてください。 +49 6221 4342-115 メールしてください: quittek@nw.neclab.eu
Boschi, et al. Informational [Page 33] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [33ページ]情報のRFC5153IPFIX実施要綱2008年4月
Martin Stiemerling NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
マーチンStiemerling NECヨーロッパLtd.Kurfuersten-原基36 69115ハイデルベルグドイツ
Phone: +49 6221 4342-113 EMail: stiemerling@nw.neclab.eu
以下に電話をしてください。 +49 6221 4342-113 メールしてください: stiemerling@nw.neclab.eu
Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Edinburgh EH6 6LX Scotland
ポールエイトケンシスコシステムズInc.96の商業波止場エディンバラEH6 6LXスコットランド
Phone: +44 131 561 3616 EMail: paitken@cisco.com
以下に電話をしてください。 +44 3616年の131 561メール: paitken@cisco.com
Boschi, et al. Informational [Page 34] RFC 5153 IPFIX Implementation Guidelines April 2008
Boschi、他 [34ページ]情報のRFC5153IPFIX実施要綱2008年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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-ipr@ietf.org のIETFに情報を記述してください。
Boschi, et al. Informational [Page 35]
Boschi、他 情報[35ページ]
一覧
スポンサーリンク
