[要約] RFC 5345は、SNMPトラフィックの測定とトレースの交換形式に関する標準仕様です。このRFCの目的は、SNMPベースのネットワーク管理システムでトラフィックの測定とトレースを効果的に行うための方法を提供することです。
Network Working Group J. Schoenwaelder
Request for Comments: 5345 Jacobs University Bremen
Category: Informational October 2008
Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats
シンプルなネットワーク管理プロトコル（SNMP）トラフィック測定とトレース交換形式
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
IESG Note
IESGノート
The IESG thinks that this work is related to IETF work done in the Operations and Management Area related to SNMP, but this does not prevent publishing. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and notes that the decision to publish is not based on IETF review apart from the IETF Last Call on the allocation of a URI by IANA and the IESG review for conflict with IETF work. The RFC Editor has chosen to publish this document at its discretion. See RFC 3932 for more information.
IESGは、この作業はSNMPに関連する運用および管理分野で行われたIETF作業に関連していると考えていますが、これは公開を妨げません。このRFCは、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄し、公開する決定はIETFレビューに基づいていないことを指摘。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。詳細については、RFC 3932を参照してください。
Abstract
概要
The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.
Simple Network Management Protocol（SNMP）は、ネットワーク要素を監視、制御、および（場合によっては）構成するために広く展開されています。SNMPテクノロジーは十分に文書化されていますが、SNMPが実際にどのように使用されているか、および典型的なSNMP使用パターンがどのようなものであるかは比較的不明のままです。
This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.
このドキュメントでは、SNMPが実際の生産ネットワークでどのように使用されるかをよりよく理解するために、大規模なSNMPトラフィック測定を実行するアプローチについて説明します。これは、そのような研究を実行するために必要な動機、測定アプローチ、およびツールとデータ形式を説明しています。
This document was produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group.
このドキュメントは、IRTFのネットワーク管理研究グループ（NMRG）内で作成され、このグループへのすべてのアクティブな貢献者のコンセンサスを表しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Measurement Approach ............................................4
2.1. Capturing Traffic Traces ...................................5
2.2. Converting Traffic Traces ..................................6
2.3. Filtering Traffic Traces ...................................7
2.4. Storing Traffic Traces .....................................7
2.5. Analyzing Traffic Traces ...................................8
3. Analysis of Traffic Traces ......................................9
3.1. Basic Statistics ...........................................9
3.2. Periodic versus Aperiodic Traffic ..........................9
3.3. Message Size and Latency Distributions .....................9
3.4. Concurrency Levels ........................................10
3.5. Table Retrieval Approaches ................................10
3.6. Trap-Directed Polling - Myths or Reality? .................10
3.7. Popular MIB Definitions ...................................11
3.8. Usage of Obsolete Objects .................................11
3.9. Encoding Length Distributions .............................11
3.10. Counters and Discontinuities .............................11
3.11. Spin Locks ...............................................12
3.12. Row Creation .............................................12
4. Trace Exchange Formats .........................................12
4.1. XML Representation ........................................12
4.2. CSV Representation ........................................17
5. Security Considerations ........................................18
6. IANA Considerations ............................................19
7. Acknowledgements ...............................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................20
The Simple Network Management Protocol (SNMP) was introduced in the late 1980s [RFC1052] and has since then evolved to what is known today as the SNMP version 3 Framework (SNMPv3) [RFC3410]. While SNMP is widely deployed, it is not clear what protocol versions are being used, which protocol features are being used, how SNMP usage differs in different types of networks or organizations, which information is frequently queried, and what typical SNMP interaction patterns occur in real-world production networks.
シンプルなネットワーク管理プロトコル（SNMP）は、1980年代後半に[RFC1052]に導入され、それ以来、SNMPバージョン3フレームワーク（SNMPV3）[RFC3410]として今日知られているものに進化しました。SNMPは広く展開されていますが、どのプロトコルバージョンが使用されているか、どのプロトコル機能が使用されているか、SNMPの使用がさまざまな種類のネットワークまたは組織でどのように異なるか、どの情報が頻繁に照会されるか、どの典型的なSNMP相互作用パターンが発生するかは明らかではありません。実世界の生産ネットワーク。
There have been several publications in the recent past dealing with the performance of SNMP in general [SM99][Mal02][Pat01], the impact of SNMPv3 security [DSR01][CT04], or the relative performance of SNMP compared to Web Services [PDMQ04][PFGL04]. While these papers are generally useful to better understand the impact of various design decisions and technologies, some of these papers lack a strong foundation because authors typically assume certain SNMP interaction patterns without having experimental evidence that the assumptions are correct. In fact, there are many speculations on how SNMP is being used in real-world production networks, and performance comparisons are based on limited test cases, but no systematic measurements have been performed and published so far.
最近の過去には、一般的な[SM99] [MAL02] [PAT01]、SNMPV3セキュリティの影響[DSR01] [CT04]、またはWebサービスと比較したSNMPの相対的なパフォーマンスを扱ういくつかの出版物がありました[PAT01]、PDMQ04] [PFGL04]。これらの論文は一般に、さまざまな設計上の決定や技術の影響をよりよく理解するのに役立ちますが、これらの論文のいくつかは、仮定が正しいという実験的証拠を持たずに特定のSNMP相互作用パターンを想定しているため、強力な基盤を欠いています。実際、SNMPが実際の生産ネットワークでどのように使用されているかについて多くの推測があり、パフォーマンスの比較は限られたテストケースに基づいていますが、これまでに系統的測定は実行され、公開されていません。
Many authors use the ifTable of the IF-MIB [RFC2863] or the tcpConnTable of the TCP-MIB [RFC4022] as a starting point for their analysis and comparison. Despite the fact that there is no evidence that operations on these tables dominate SNMP traffic, it is even more unclear how these tables are read and which optimizations are done (or not done) by real-world applications. It is also unclear what the actual traffic trade-off between periodic polling and more aperiodic bulk data retrieval is. Furthermore, we do not generally understand how much traffic is devoted to standardized MIB objects and how much traffic deals with proprietary MIB objects and whether the operation mix between these object classes differs between different operational environments (e.g., backbone networks, access networks, enterprise networks).
多くの著者は、分析と比較の出発点として、IF-MIB [RFC2863]またはTCP-MIB [RFC4022]のTCPCONNTABLEを使用しています。これらのテーブルの操作がSNMPトラフィックを支配しているという証拠はないという事実にもかかわらず、これらのテーブルがどのように読み取られ、どの最適化が実世界のアプリケーションによって行われている（または行われない）のかはさらに不明です。また、定期的なポーリングとより非周期的なバルクデータ検索の間の実際の交通トレードオフが何であるかは不明です。さらに、一般に、標準化されたMIBオブジェクトに充てられているトラフィックの量と、独自のMIBオブジェクトをどの程度取引するか、およびこれらのオブジェクトクラス間の操作が異なる動作環境間で異なるかどうか（例えば、バックボーンネットワーク、アクセスネットワーク、エンタープライズネットワークが異なるかどうかを理解していません。）。
This document recommends an approach to collecting, codifying, and handling SNMP traffic traces in order to find answers to some of these questions. It describes the tools that have been developed to allow network operators to collect traffic traces and to share them with research groups interested in analyzing and modeling network management interactions.
このドキュメントでは、これらの質問のいくつかに対する回答を見つけるために、SNMPトラフィックトレースを収集、成文化、および処理するアプローチを推奨しています。ネットワークオペレーターがトラフィックトレースを収集し、ネットワーク管理の対話の分析とモデリングに関心のある研究グループと共有できるように開発されたツールについて説明します。
While the SNMP trace collection and analysis effort was initiated by the research community, network operators can benefit from the SNMP measurements too. Several new tools are being developed as part of this effort that can be used to capture and analyze the traffic generated by management stations. This resulting information can then be used to improve the efficiency and scalability of management systems.
SNMPトレースの収集と分析の取り組みは研究コミュニティによって開始されましたが、ネットワークオペレーターはSNMP測定からも恩恵を受けることができます。この取り組みの一環として、管理ステーションが生成するトラフィックをキャプチャおよび分析するために使用できるいくつかの新しいツールが開発されています。その後、この結果の情報を使用して、管理システムの効率とスケーラビリティを改善できます。
The measurement approach described in this document is by design limited to the study of SNMP traffic. Studies of other management protocols or the impact of management protocols such as SNMP on other traffic sharing the same network resources is left to future efforts.
このドキュメントで説明されている測定アプローチは、SNMPトラフィックの研究に限定されています。他の管理プロトコルの研究または他のトラフィックに対するSNMPなどの管理プロトコルの影響と同じネットワークリソースを共有することは、将来の取り組みに任されています。
This is an Informational document, produced within the IRTF's Network Management Research Group (NMRG), and it represents the consensus of all of the active contributors to this group.
これは、IRTFのネットワーク管理研究グループ（NMRG）内で作成される情報文書であり、このグループへのすべてのアクティブな貢献者のコンセンサスを表しています。
This section outlines the process of doing SNMP traffic measurements and analysis. The process consists of the following five basic steps:
このセクションでは、SNMPトラフィックの測定と分析を実行するプロセスの概要を説明します。このプロセスは、次の5つの基本的な手順で構成されています。
1. Capture raw SNMP traffic traces in pcap packet capture files [1].
1. PCAPパケットキャプチャファイルのRAW SNMPトラフィックトレースをキャプチャします[1]。
2. Convert the raw traffic traces into a structured machine and human-readable format. A suitable XML schema has been developed for this purpose that captures all SNMP message details. Another more compact comma-separated values (CSV) format has been developed that only keeps key information about SNMP messages.
2. 生のトラフィックトレースを構造化されたマシンと人間の読み取り可能な形式に変換します。すべてのSNMPメッセージの詳細をキャプチャするこの目的のために、適切なXMLスキーマが開発されました。SNMPメッセージに関する重要な情報のみを保持する別のよりコンパクトなキャパートされた値（CSV）形式が開発されました。
3. Filter the converted traffic traces to hide or anonymize sensitive information. While the filtering is conceptually a separate step, filtering may actually be implemented as part of the previous data conversion step for efficiency reasons.
3. 変換されたトラフィックトレースをフィルタリングして、機密情報を非難または匿名化します。フィルタリングは概念的には別のステップですが、フィルタリングは、効率的な理由で以前のデータ変換ステップの一部として実際に実装される場合があります。
4. Submit the filtered traffic traces to a repository from which they can be retrieved and analyzed. Such a repository may be public, under the control of a research group, or under the control of a network operator who commits to run analysis scripts on the repository on behalf of researchers.
4. ろ過されたトラフィックトレースをリポジトリに送信し、そこから取得して分析することができます。このようなリポジトリは、研究グループの管理下で、または研究者に代わってリポジトリで分析スクリプトを実行することをコミットするネットワークオペレーターの管理下にある場合があります。
5. Analyze the traces by creating and executing analysis scripts that extract and aggregate information.
5. 情報を抽出および集約する分析スクリプトを作成および実行することにより、トレースを分析します。
Several of the steps listed above require the involvement of network operators supporting the SNMP measurement projects. In many cases, the filtered XML and CSV representation of the SNMP traces will be the interface between the researchers writing analysis scripts and the operators involved in the measurement activity. It is therefore important to have a well-defined specification of these interfaces.
上記のいくつかの手順では、SNMP測定プロジェクトをサポートするネットワークオペレーターの関与が必要です。多くの場合、SNMPトレースのフィルター処理されたXMLおよびCSV表現は、分析スクリプトを作成する研究者と測定活動に関与する演算子との間のインターフェースとなります。したがって、これらのインターフェイスの明確に定義された仕様を持つことが重要です。
This section provides some advice and concrete hints on how the steps listed above can be carried out efficiently. Some special tools have been developed to assist network operators and researchers so that the time spent on supporting SNMP traffic measurement projects is limited. The following sections describe the five steps and some tools in more detail.
このセクションでは、上記の手順を効率的に実行する方法に関するアドバイスと具体的なヒントを提供します。SNMPトラフィック測定プロジェクトのサポートに費やされる時間が限られているように、ネットワークオペレーターと研究者を支援するためにいくつかの特別なツールが開発されました。次のセクションでは、5つのステップといくつかのツールについて詳しく説明します。
Capturing SNMP traffic traces can be done using packet sniffers such as tcpdump [2], wireshark [3], or similar applications. Some care must be taken to specify pcap filter expressions that match the SNMP transport endpoints used to carry SNMP traffic (typically 'udp and (port 161 or port 162)'). Furthermore, it is necessary to ensure that full packets are captured, that is packets are not truncated (tcpdump option -s 0). Finally, it is necessary to carefully select the placement of the capturing probe within the network. Especially on bridged LANs, it is important to ensure that all management traffic is captured and that the probe has access to all virtual LANs carrying management traffic. This usually requires placing the probe(s) close to the management system(s) and configuring dedicated monitoring ports on bridged networks. Some bridges have restrictions concerning their monitoring capabilities, and this should be investigated and documented where necessary.
SNMPトラフィックトレースのキャプチャは、TCPDump [2]、Wireshark [3]、または同様のアプリケーションなどのパケットスニッファーを使用して実行できます。SNMPトラフィックを運ぶために使用されるSNMPトランスポートエンドポイントに一致するPCAPフィルター式を指定するように注意する必要があります（通常は「UDPおよび（ポート161またはポート162）」）。さらに、完全なパケットがキャプチャされていることを確認する必要があります。つまり、パケットが切り捨てられていません（TCPDUMPオプション-S 0）。最後に、ネットワーク内のキャプチャプローブの配置を慎重に選択する必要があります。特にブリッジ付きLANでは、すべての管理トラフィックがキャプチャされ、プローブがすべての仮想LANを運ぶ管理トラフィックにアクセスできるようにすることが重要です。これには、通常、プローブを管理システムの近くに配置し、ブリッジ型ネットワークに専用の監視ポートを構成する必要があります。一部のブリッジには、監視機能に関する制限があり、これは必要に応じて調査および文書化する必要があります。
It is recommended to capture at least a full week of data to capture diurnal patterns and one cycle of weekly behavior. Operators are strongly encouraged to capture traces over even longer periods of time. Tools such as tcpdump and tcpslice [2] or mergecap and editcap [3] can be used to split or merge pcap trace files as needed.
日中のパターンと毎週の動作の1つのサイクルをキャプチャするために、少なくとも1週間のデータをキャプチャすることをお勧めします。オペレーターは、さらに長期にわたってトレースをキャプチャすることを強くお勧めします。TCPDUMPやTCPSLICE [2]やMergECAPやEditCap [3]などのツールを使用して、必要に応じてPCAPトレースファイルを分割またはマージできます。
Several operating systems can offload some of the TCP/IP processing such as the calculation of transport layer checksum to network interface cards. Traces that include traffic to/from a capturing interface that supports TCP/IP offloading can include incorrect transport layer checksums. The simplest solution is of course to turn checksum offloading off while capturing traces (if that is feasible without losing too many packets). The other solution is to correct or ignore checksums during the subsequent conversion of the raw pcap files.
いくつかのオペレーティングシステムは、輸送層チェックサムのネットワークインターフェイスカードへの計算など、TCP/IP処理の一部をオフロードできます。TCP/IPオフロードをサポートするキャプチャインターフェイスへの出入りのトラフィックを含むトレースには、誤った輸送層チェックサムが含まれる場合があります。最も単純なソリューションは、もちろん、痕跡をキャプチャしながらチェックサムをオフロードすることです（あまりにも多くのパケットを失うことなく実行可能な場合）。もう1つのソリューションは、RAW PCAPファイルのその後の変換中にチェックサムを修正または無視することです。
It is important to note that the raw pcap files should ideally be kept in permanent storage (e.g., compressed and encrypted on a CD ROM or DVD). To verify measurements, it might be necessary to go back to the original pcap files if, for example, bugs in the tools described below have been detected and fixed.
生のPCAPファイルは、理想的には永久ストレージ（たとえば、CD ROMまたはDVDで圧縮および暗号化された）に保持する必要があることに注意することが重要です。測定を検証するには、以下に説明するツールのバグが検出されて固定されている場合、元のPCAPファイルに戻る必要がある場合があります。
For each captured trace, some meta data should be recorded and made available. The meta data should include information such as where the trace was collected (name of the network and name of the organization owning the network, description of the measurement point in the network topology where the trace was collected), when it was collected, contact information, the size of the trace, any known special events, equipment failures, or major infrastructure changes during the data collection period and so on. It is also extremely useful to provide a unique identification. There are special online services such as DatCat [4] where meta data can be stored and which provide unique identifiers.
キャプチャされた各トレースについて、一部のメタデータを記録して利用できるようにする必要があります。メタデータには、トレースが収集された場所（ネットワークの名前とネットワークを所有する組織の名前、トレースが収集されたネットワークトポロジの測定ポイントの説明）などの情報を含める必要があります。、痕跡のサイズ、既知の特別なイベント、機器の故障、またはデータ収集期間中の主要なインフラストラクチャの変化など。また、ユニークな識別を提供することも非常に便利です。METAデータを保存できるDatcat [4]などの特別なオンラインサービスがあり、ユニークな識別子を提供します。
Raw traces in pcap format must be converted into a format that is human readable while also remaining machine readable for efficient post-processing. Human readability makes it easy for an operator to verify that no sensitive data is left in a trace while machine readability is needed to efficiently extract relevant information.
PCAP形式の生のトレースは、効率的な後処理のために読みやすいマシンのままであると、人間の読み取り可能な形式に変換する必要があります。人間の読みやすさにより、オペレーターは、関連情報を効率的に抽出するために機械の読みやすさが必要な間、機密データがトレースに残されていないことを簡単に確認できます。
The natural choice here is to use an XML format since XML is human as well as machine readable and there are many tools and high-level scripting language application programming interfaces (APIs) that can be used to process XML documents and to extract meaningful information. However, XML is also pretty verbose, which increases processing overhead. In particular, the usage of XML streaming APIs is strongly suggested since APIs that require an in-memory representation of XML documents do not handle large traces well.
ここでの自然な選択は、XMLが読みやすいマシンであり、XMLドキュメントの処理と意味のある情報を抽出するために使用できる多くのツールと高レベルのスクリプト言語アプリケーションプログラミングインターフェイス（API）があるため、XML形式を使用することです。ただし、XMLもかなり冗長であり、オーバーヘッドの処理が増加します。特に、XMLストリーミングAPIの使用は、XMLドキュメントのメモリ内表現を必要とするAPIが大きなトレースをうまく処理しないため、強く提案されています。
Section 4.1 of this document defines a RELAX NG schema [OASISRNG] for representing SNMP traffic traces in XML. The schema captures all relevant details of an SNMP message in the XML format. Note that the XML format retains some information about the original ASN.1/BER encoding to support message size analysis.
このドキュメントのセクション4.1では、XMLのSNMPトラフィックトレースを表すためのリラックスNgスキーマ[Oasisrng]を定義しています。スキーマは、XML形式でSNMPメッセージのすべての関連する詳細をキャプチャします。XML形式は、メッセージサイズ分析をサポートするために元のASN.1/BERエンコードに関するいくつかの情報を保持していることに注意してください。
A lightweight alternative to the full-blown XML representation based on comma-separated values (CSV) is defined in Section 4.2. The CSV format only captures selected parts of SNMP messages and is thus more compact and faster to process.
Comma分離値（CSV）に基づく本格的なXML表現の軽量な代替品は、セクション4.2で定義されています。CSV形式は、SNMPメッセージの選択された部分のみをキャプチャするため、よりコンパクトで処理が速くなります。
As explained in the previous sections, analysis programs that process raw pcap files should have an option to ignore incorrect checksums caused by TCP/IP offloading. In addition, analysis programs that process raw pcap files should be able to perform IP reassembly for SNMP messages that were fragmented at the IP layer.
前のセクションで説明したように、RAW PCAPファイルを処理する分析プログラムには、TCP/IPオフロードによって引き起こされる誤ったチェックサムを無視するオプションが必要です。さらに、RAW PCAPファイルを処理する分析プログラムは、IPレイヤーで断片化されたSNMPメッセージのIP再組み立てを実行できる必要があります。
The snmpdump [5] package has been developed to convert raw pcap files into XML and CSV format. The snmpdump program reads pcap, XML, or CSV files as input and produces XML files or CSV files as output.
SNMPDUMP [5]パッケージは、生のPCAPファイルをXMLおよびCSV形式に変換するために開発されました。SNMPDUMPプログラムは、PCAP、XML、またはCSVファイルを入力として読み取り、XMLファイルまたはCSVファイルを出力として生成します。
Specific elements can be filtered as required to protect sensitive data.
機密データを保護するために、特定の要素を必要に応じてフィルタリングできます。
Filtering sensitive data (e.g., access control lists or community strings) can be achieved by manipulating the XML representation of an SNMP trace. Standard XSLT processors (e.g., xsltproc [6]) can be used for this purpose. People familiar with the scripting language Perl might be interested in choosing a suitable Perl module to manipulate XML documents [7].
SNMPトレースのXML表現を操作することにより、機密データのフィルタリング（アクセス制御リストやコミュニティ文字列など）を実現できます。この目的には、標準XSLTプロセッサ（XSLTProc [6]など）を使用できます。Scripting Language Perlに精通している人は、XMLドキュメントを操作するための適切なPERLモジュールを選択することに興味があるかもしれません[7]。
The snmpdump program, for example, can filter out sensitive information, e.g., by deleting or clearing all XML elements whose name matches a regular expression. Data type specific anonymization transformations that maintain lexicographic ordering for values that appear in instance identifiers [HS06] can be applied. Note that anonymization transformations are often bound to an initialization key and depend on the data being anonymized in an anonymization run. As a consequence, users must be careful when they merge data from independently anonymized traces. More information about network traffic trace anonymization techniques can be found in [XFA02], [FXAM04], [PAPL06], and [RW07].
たとえば、SNMPDUMPプログラムは、たとえば、名前が正規表現と一致するすべてのXML要素を削除またはクリアすることにより、機密情報をフィルタリングできます。インスタンス識別子[HS06]に表示される値の辞書的順序を維持するデータ型固有の匿名化変換を適用できます。匿名化の変換は、多くの場合、初期化キーに結合され、匿名化の実行で匿名化されているデータに依存することに注意してください。結果として、ユーザーは独立して匿名化されたトレースからのデータをマージする場合、注意する必要があります。ネットワークトラフィックトレースの匿名化手法の詳細については、[XFA02]、[FXAM04]、[PAPL06]、および[RW07]に記載されています。
The raw pcap traces as well as the XML / CSV formatted traces should be stored in a stable archive or repository. Such an archive or repository might be maintained by research groups (e.g., the NMRG), network operators, or both. It is of key importance that captured traces are not lost or modified as they may form the basis of future research projects and may also be needed to verify published research results. Access to the archive might be restricted to those who have signed some sort of a non-disclosure agreement.
生のPCAPトレースとXML / CSV形式のトレースは、安定したアーカイブまたはリポジトリに保存する必要があります。このようなアーカイブまたはリポジトリは、研究グループ（NMRGなど）、ネットワーク演算子、またはその両方によって維持される場合があります。キャプチャされた痕跡は、将来の研究プロジェクトの基礎を形成する可能性があるため、失われたり変更されたりしないことが重要です。また、公開された研究結果を検証するためにも必要になる可能性があります。アーカイブへのアクセスは、何らかの非公開契約に署名した人に制限される場合があります。
While this document recommends that raw traces should be kept, it must be noted that there are situations where this may not be feasible. The recommendation to keep raw traces may be ignored, for example, to comply with data-protection laws or to protect a network operator from being forced to provide the data to other organizations.
この文書は、生の痕跡を保持する必要があることを推奨していますが、これが実行不可能な状況があることに注意する必要があります。生の痕跡を維持するための推奨事項は、たとえば、データ保護法に準拠したり、ネットワークオペレーターが他の組織にデータを提供することを余儀なくされないように保護するために無視される場合があります。
Lossless compression algorithms embodied in programs such as gzip or bzip2 can be used to compress even large trace files down to a size where they can be burned on DVDs for cheap long-term storage.
GZIPやBZIP2などのプログラムに具体化されたロスレス圧縮アルゴリズムを使用して、大規模なトレースファイルをサイズに圧縮して、安価な長期ストレージのためにDVDで燃やすことができます。
It must be stressed again that it is important to keep the original pcap traces in addition to the XML/CSV formatted traces since the pcap traces are the most authentic source of information. Improvements in the tool chain may require going back to the original pcap traces and rebuilding all intermediate formats from them.
PCAPトレースが最も本物の情報源であるため、XML/CSVフォーマットされたトレースに加えて、元のPCAPトレースを維持することが重要であることを再度強調する必要があります。ツールチェーンの改善には、元のPCAPトレースに戻り、それらからのすべての中間形式を再構築する必要がある場合があります。
Scripts that analyze traffic traces must be verified for correctness. Ideally, all scripts used to analyze traffic traces will be publically accessible so that third parties can verify them. Furthermore, sharing scripts will enable other parties to repeat an analysis on other traffic traces and to extend such analysis scripts. It might be useful to establish a common, versioning repository for analysis scripts.
トラフィックトレースを分析するスクリプトは、正確性を検証する必要があります。理想的には、トラフィックトレースを分析するために使用されるすべてのスクリプトは、第三者がそれらを検証できるように、公開されています。さらに、スクリプトを共有すると、他の関係者が他のトラフィックトレースで分析を繰り返し、そのような分析スクリプトを拡張できます。分析スクリプトのための一般的なバージョンリポジトリを確立すると便利かもしれません。
Due to the availability of XML parsers and the simplicity of the CSV format, trace files can be processed with tools written in almost any programming language. However, in order to facilitate a common vocabulary and to allow operators to easily read scripts they execute on trace files, it is suggested that analysis scripts be written in scripting languages such as Perl using suitable Perl modules to manipulate XML documents <http://perl-xml.sourceforge.net/faq/>. Using a scripting language such as Perl instead of system programming languages such as C or C++ has the advantage of reducing development time and making scripts more accessible to operators who may want to verify scripts before running them on trace files that may contain sensitive data.
XMLパーサーの可用性とCSV形式のシンプルさにより、トレースファイルは、ほぼすべてのプログラミング言語で記述されたツールで処理できます。ただし、一般的な語彙を促進し、オペレーターがトレースファイルで実行するスクリプトを簡単に読み取ることができるようにするために、分析スクリプトは、XMLドキュメントを操作するための適切なPerlモジュールを使用してPerlなどのスクリプト言語で記述されることをお勧めします。perl-xml.sourceforge.net/faq/>。CやCなどのシステムプログラミング言語ではなくPERLなどのスクリプト言語を使用すると、開発時間を短縮し、スクリプトをよりアクセスしやすくするという利点があります。
The snmpdump tool provides an API to process SNMP messages in C/C++. While the coding of trace analysis programs in C/C++ should in general be avoided for code readability, verifiability, and portability reasons, using C/C++ might be the only option in dealing with very large traces efficiently.
SNMPDUMPツールは、C/CでSNMPメッセージを処理するAPIを提供します。C/Cでのトレース分析プログラムのコーディングは、一般にコードの読みやすさ、検証可能性、および移植性の理由で避けるべきですが、C/Cを使用することが非常に大きな痕跡を効率的に処理する唯一のオプションかもしれません。
Any results produced by analyzing a trace must be interpreted in the context of the trace. The nature of the network, the attachment point used to collect the trace, the nature of the applications generating SNMP traffic, or the events that happened while the trace was collected clearly influence the result. It is therefore important to be careful when drawing general conclusions based on a potentially (too) limited data set.
トレースを分析することによって生成された結果は、トレースのコンテキストで解釈する必要があります。ネットワークの性質、トレースを収集するために使用されるアタッチメントポイント、SNMPトラフィックを生成するアプリケーションの性質、または収集されたときに発生したイベントは、結果に明らかに影響します。したがって、潜在的に（あまりにも）限られたデータセットに基づいて一般的な結論を描くときは、注意することが重要です。
This section discusses several questions that can be answered by analyzing SNMP traffic traces. The questions raised in the following subsections are meant to be illustrative and no attempt has been made to provide a complete list.
このセクションでは、SNMPトラフィックトレースを分析することで回答できるいくつかの質問について説明します。以下のサブセクションで提起された質問は、説明的であることを意図しており、完全なリストを提供する試みは行われていません。
Basic statistics cover things such as:
基本的な統計は次のようなものをカバーしています：
o protocol version used,
o 使用されるプロトコルバージョン、
o protocol operations used,
o 使用されるプロトコル操作、
o message size distribution,
o メッセージサイズの分布、
o error message type frequency, or
o エラーメッセージタイプ頻度、または
o usage of authentication and encryption mechanisms.
o 認証と暗号化メカニズムの使用。
The Object Identifier (OID) names of the objects manipulated can be categorized into OID subtrees, for example, to identify 'standardized', 'proprietary', and 'experimental' objects.
操作されたオブジェクトのオブジェクト識別子（OID）名は、たとえば「標準化」、「独自」、および「実験的」オブジェクトを識別するために、OIDサブツリーに分類できます。
SNMP is used to periodically poll devices as well as to retrieve information at the request of an operator or application. The periodic polling leads to periodic traffic patterns while on-demand information retrieval causes more aperiodic traffic patterns. It is worthwhile to understand what the relationship is between the amount of periodic and aperiodic traffic. It will be interesting to understand whether there are multiple levels of periodicity at different time scales.
SNMPは、定期的にデバイスを投票するだけでなく、オペレーターまたはアプリケーションの要求に応じて情報を取得するために使用されます。定期的なポーリングは定期的な交通パターンにつながりますが、オンデマンドの情報検索はより多くの非周期的な交通パターンを引き起こします。周期的なトラフィックと非周期的なトラフィックの量との関係が何であるかを理解することは価値があります。異なる時期に複数のレベルの周期性があるかどうかを理解することは興味深いでしょう。
Periodic polling behavior may be dependent on the application and polling engine it uses. For example, some management platforms allow applications to specify how long polled values may be kept in a cache before they are polled again. Such optimizations need to be considered when analyzing traces for periodic and aperiodic traffic.
定期的な投票行動は、使用するアプリケーションとポーリングエンジンに依存する場合があります。たとえば、一部の管理プラットフォームでは、アプリケーションが再びポーリングされる前に、ポーリング値をキャッシュに保持できる期間を指定することができます。このような最適化は、周期的および非周期的なトラフィックのトレースを分析するときに考慮する必要があります。
SNMP messages are size constrained by the transport mappings used and the buffers provided by the SNMP engines. For the further evolution of the SNMP framework, it would be useful to know what the actual message size distributions are. It would be useful to understand the latency distributions, especially the distribution of the processing times by SNMP command responders. Some SNMP implementations approximate networking delays by measuring request-response times, and it would be useful to understand to what extent this is a viable approach.
SNMPメッセージは、使用されるトランスポートマッピングとSNMPエンジンが提供するバッファーによって制約されています。SNMPフレームワークのさらなる進化のために、実際のメッセージサイズ分布が何であるかを知ることは有用です。レイテンシ分布、特にSNMPコマンドレスポンダーによる処理時間の分布を理解すると便利です。一部のSNMP実装は、リクエスト応答時間を測定することによりネットワークの遅延を近似しており、これがどの程度実行可能なアプローチであるかを理解することは有用です。
Some SNMP implementations update their counters from the underlying instrumentation following adaptive algorithms, not necessarily periodically, and not necessarily on-demand. The granularity of internal counter updates may impact latency measurements and should be taken into account.
一部のSNMP実装は、必ずしも定期的にではなく、必ずしもオンデマンドではなく、適応アルゴリズムに従って基礎となる計装からカウンターを更新します。内部カウンターアップデートの粒度は、遅延測定に影響を与える可能性があり、考慮する必要があります。
SNMP allows management stations to retrieve information from multiple agents concurrently. It will be interesting to identify what the typical concurrency level is that can be observed on production networks or whether management applications prefer more sequential ways of retrieving data.
SNMPにより、管理局は複数のエージェントから同時に情報を取得できます。生産ネットワークで典型的な並行性レベルが何であるか、または管理アプリケーションがデータを取得するためのより連続的な方法を好むかどうかを特定することは興味深いでしょう。
Furthermore, it will be interesting to analyze how many redundant requests coming from applications are processed almost simultaneously by a device. The concurrency level and the amount of redundant requests has implications on caching strategies employed by SNMP agents.
さらに、アプリケーションからの冗長リクエストの数がデバイスによってほぼ同時に処理されるものを分析することは興味深いでしょう。並行性レベルと冗長リクエストの量は、SNMPエージェントが採用したキャッシュ戦略に影響を与えます。
Tables can be read in several different ways. The simplest and most inefficient approach is to retrieve tables object-by-object in column-by-column order. More advanced approaches try to read tables row-by-row or even multiple-rows-by-multiple-rows. The retrieval of index elements can be suppressed in most cases or only a subset of columns of a table are retrieved. It will be useful to know which of these approaches are used on production networks since this has a direct implication on agent implementation techniques and caching strategies.
テーブルはいくつかの異なる方法で読むことができます。最も単純で最も非効率的なアプローチは、列ごとの順序でオブジェクトごとのテーブルを取得することです。より高度なアプローチは、列ごとにテーブルを読み取ろうとします。インデックス要素の検索は、ほとんどの場合に抑制されるか、テーブルの列のサブセットのみが取得されます。エージェントの実装技術とキャッシュ戦略に直接的な意味を持つため、これらのアプローチのどれが生産ネットワークで使用されているかを知ることは有用です。
SNMP is built around a concept called trap-directed polling. Management applications are responsible to periodically poll SNMP agents to determine their status. In addition, SNMP agents can send traps to notify SNMP managers about events so that SNMP managers can adapt their polling strategy and basically react faster than normal polling would allow.
SNMPは、TRAP指向のポーリングと呼ばれる概念を中心に構築されています。管理アプリケーションは、SNMPエージェントを定期的に投票してステータスを決定する責任があります。さらに、SNMPエージェントは、SNMPマネージャーがイベントについてSNMPマネージャーに通知するためにトラップを送信して、SNMPマネージャーがポーリング戦略を適応させ、基本的に通常のポーリングが許すよりも速く対応できるようにすることができます。
Analysis of SNMP traffic traces can identify whether trap-directed polling is actually deployed. In particular, the question that should be addressed is whether SNMP notifications lead to changes in the short-term polling behavior of management stations. In particular, it should be investigated to what extent SNMP managers use automated procedures to track down the meaning of the event conveyed by an SNMP notification.
SNMPトラフィックトレースの分析では、トラップ指向のポーリングが実際に展開されているかどうかを識別できます。特に、対処すべき問題は、SNMP通知が管理ステーションの短期投票行動の変化につながるかどうかです。特に、SNMPマネージャーが自動化された手順を使用して、SNMP通知によって伝えられるイベントの意味を追跡する程度まで調査する必要があります。
An analysis of object identifier prefixes can identify the most popular MIB modules and the most important object types or notification types defined by these modules. Such information would be very valuable for the further maintenance and development of these and related MIB modules.
オブジェクト識別子プレフィックスの分析では、これらのモジュールで定義された最も人気のあるMIBモジュールと最も重要なオブジェクトタイプまたは通知タイプを識別できます。このような情報は、これらおよび関連するMIBモジュールのさらなるメンテナンスと開発にとって非常に価値があります。
Several objects from the early days have been obsoleted because they cannot properly represent today's networks. A typical example is the ipRouteTable that was obsoleted because it was not able to represent classless routing, introduced and deployed on the Internet in 1993. Some of these obsolete objects are still mentioned in popular publications as well as research papers. It will be interesting to find out whether they are also still used by management applications or whether management applications have been updated to use the replacement objects.
初期のいくつかのオブジェクトは、今日のネットワークを適切に表現できないため、廃止されています。典型的な例は、1993年にインターネットに導入および展開されたクラスレスルーティングを表すことができなかったために廃止されたiProuteTableです。これらの時代遅れのオブジェクトのいくつかは、人気のある出版物や研究論文でまだ言及されています。それらがまだ管理アプリケーションで使用されているかどうか、または交換オブジェクトを使用するために管理アプリケーションが更新されたかどうかを調べることは興味深いでしょう。
Depending on the data recorded in a trace, it might be possible to determine the age of devices by looking at the values of objects such as sysObjectID and sysDecr [RFC3418]. The age of a device can then be taken into consideration when analyzing the use of obsolete and deprecated objects.
トレースで記録されたデータに応じて、SysobjectidやSysdecrなどのオブジェクトの値を調べることにより、デバイスの年齢を決定することが可能です[RFC3418]。その後、デバイスの年齢は、時代遅れで非推奨されたオブジェクトの使用を分析する際に考慮に入れることができます。
It will be useful to understand the encoding length distributions for various data types. Assumptions about encoding length distributions are sometimes used to estimate SNMP message sizes in order to meet transport and buffer size constraints.
さまざまなデータ型のエンコーディングの長さ分布を理解することは便利です。エンコードの長さ分布に関する仮定は、輸送およびバッファーサイズの制約を満たすためにSNMPメッセージサイズを推定するために使用されることがあります。
Counters can experience discontinuities [RFC2578]. A widely used discontinuity indicator is the sysUpTime scalar of the SNMPv2-MIB [RFC3418], which can be reset through a warm start to indicate counter discontinuities. Some MIB modules introduce more specific discontinuity indicators, e.g., the ifCounterDiscontinuityTime of the IF-MIB [RFC2863]. It will be interesting to study to what extent these objects are actually used by management applications to handle discontinuity events.
カウンターは不連続性を発生させる可能性があります[RFC2578]。広く使用されている不連続指標は、SNMPV2-MIB [RFC3418]のsysuptimeスカラーであり、温かいスタートからリセットしてカウンターの不連続性を示すことができます。一部のMIBモジュールは、IF-MIB [RFC2863]のIFCounterDiscontinuityTimeなど、より具体的な不連続性インジケーターを導入します。これらのオブジェクトが、不連続イベントを処理するために実際にどの程度使用されているかを研究することは興味深いでしょう。
Cooperating command generators can use advisory locks to coordinate their usage of SNMP write operations. The snmpSetSerialNo scalar of the SNMPv2-MIB [RFC3418] is the default coarse-grain coordination object. It will be interesting to find out whether there are command generators that coordinate themselves using these spin locks.
協力コマンドジェネレーターは、アドバイザリーロックを使用して、SNMP書き込み操作の使用を調整できます。SNMPV2-MIB [RFC3418]のSnmpsetserialnoスカラーは、デフォルトの粗粒調整オブジェクトです。これらのスピンロックを使用して自分自身を調整するコマンドジェネレーターがあるかどうかを調べることは興味深いでしょう。
Row creation is an operation not natively supported by the protocol operations. Instead, conceptual tables supporting row creation typically provide a control column that uses the RowStatus textual convention defined in the SNMPv2-TC [RFC2579] module. The RowStatus itself supports different row creation modes, namely createAndWait (dribble-mode) and createAndGo (one-shot mode). Different approaches can be used to derive the instance identifier if it does not have special semantics associated with it. It will be useful to study which of the various row creation approaches are actually used by management applications on production networks.
行の作成は、プロトコル操作によってネイティブにサポートされていない操作です。代わりに、行の作成をサポートする概念テーブルは、通常、SNMPV2-TC [RFC2579]モジュールで定義されているRowStatusテキスト条約を使用するコントロール列を提供します。RowStatus自体は、さまざまな行作成モード、つまりCreateandWait（Dribble-Mode）とCreateAndgo（ワンショットモード）をサポートしています。さまざまなアプローチを使用して、インスタンス識別子を導き出すことができます。さまざまな行の作成アプローチのうち、実際に生産ネットワーク上の管理アプリケーションで使用されているのはどれですか。
The XML format has been designed to keep all information associated with SNMP messages. The format is specified in RELAX NG compact notation [OASISRNC]. Freely available tools such as trang [8] can be used to convert RELAX NG compact syntax to other XML schema notations.
XML形式は、すべての情報をSNMPメッセージに関連付けるように設計されています。このフォーマットは、緩和ngコンパクト表記[oasisrnc]で指定されています。Trang [8]などの自由に利用可能なツールを使用して、リラックスNGコンパクト構文を他のXMLスキーマ表記に変換できます。
The XML format can represent SNMPv1, SNMPv2c, and SNMPv3 messages. In case a new version of SNMP is introduced in the future or existing SNMP versions are extended in ways that require changes to the XML format, a new XML format with a different namespace needs to be defined (e.g., by incrementing the version number included in the namespace URI).
XML形式は、SNMPV1、SNMPV2C、およびSNMPV3メッセージを表すことができます。SNMPの新しいバージョンが将来導入された場合、または既存のSNMPバージョンがXML形式の変更を必要とする方法で拡張された場合、別の名前空間を持つ新しいXML形式を定義する必要があります（例：名前空間uri）。
# Relax NG grammar for the XML SNMP trace format. # # Published as part of RFC 5345.
＃XML SNMPトレース形式のグラマーをリラックスします。＃＃RFC 5345の一部として公開されています。
default namespace = "urn:ietf:params:xml:ns:snmp-trace-1.0"
start =
element snmptrace {
packet.elem*
}
packet.elem =
element packet {
element time-sec { xsd:unsignedInt },
element time-usec { xsd:unsignedInt },
element src-ip { ipaddress.type },
element src-port { xsd:unsignedInt },
element dst-ip { ipaddress.type },
element dst-port { xsd:unsignedInt },
snmp.elem
}
snmp.elem =
element snmp {
length.attrs?,
message.elem
}
message.elem =
element version { length.attrs, xsd:int },
element community { length.attrs, xsd:hexBinary },
pdu.elem
message.elem |=
element version { length.attrs, xsd:int },
element message {
length.attrs,
element msg-id { length.attrs, xsd:unsignedInt },
element max-size { length.attrs, xsd:unsignedInt },
element flags { length.attrs, xsd:hexBinary },
element security-model { length.attrs, xsd:unsignedInt }
},
usm.elem?,
element scoped-pdu {
length.attrs,
element context-engine-id { length.attrs, xsd:hexBinary },
element context-name { length.attrs, xsd:string },
pdu.elem
}
usm.elem = element usm {
usm.elem = element usm {
length.attrs,
element auth-engine-id { length.attrs, xsd:hexBinary },
element auth-engine-boots { length.attrs, xsd:unsignedInt },
element auth-engine-time { length.attrs, xsd:unsignedInt },
element user { length.attrs, xsd:hexBinary },
element auth-params { length.attrs, xsd:hexBinary },
element priv-params { length.attrs, xsd:hexBinary }
}
pdu.elem =
element trap {
length.attrs,
element enterprise { length.attrs, oid.type },
element agent-addr { length.attrs, ipv4address.type },
element generic-trap { length.attrs, xsd:int },
element specific-trap { length.attrs, xsd:int },
element time-stamp { length.attrs, xsd:int },
element variable-bindings { length.attrs, varbind.elem* }
}
pdu.elem |=
element (get-request | get-next-request | get-bulk-request |
set-request | inform-request | snmpV2-trap |
response | report) {
length.attrs,
element request-id { length.attrs, xsd:int },
element error-status { length.attrs, xsd:int },
element error-index { length.attrs, xsd:int },
element variable-bindings { length.attrs, varbind.elem* }
}
varbind.elem = element varbind { length.attrs, name.elem, value.elem }
varbind.elem = element varbind {length.attrs、name.elem、value.elem}}
name.elem = element name { length.attrs, oid.type }
name.elem = element name {length.attrs、oid.type}
value.elem =
element null { length.attrs, empty } |
element integer32 { length.attrs, xsd:int } |
element unsigned32 { length.attrs, xsd:unsignedInt } |
element counter32 { length.attrs, xsd:unsignedInt } |
element counter64 { length.attrs, xsd:unsignedLong } |
element timeticks { length.attrs, xsd:unsignedInt } |
element ipaddress { length.attrs, ipv4address.type } |
element octet-string { length.attrs, xsd:hexBinary } |
element object-identifier { length.attrs, oid.type } |
element opaque { length.attrs, xsd:hexBinary } |
element no-such-object { length.attrs, empty } |
element no-such-instance { length.attrs, empty } |
element end-of-mib-view { length.attrs, empty }
# The blen attribute indicates the number of octets used by the BER # encoded tag / length / value triple. The vlen attribute indicates # the number of octets used by the BER encoded value alone.
＃BLEN属性は、BER＃エンコードされたタグ /長さ /値トリプルで使用されるオクテットの数を示します。vlen属性は、berエンコードされた値のみで使用されるオクテットの数を示します。
length.attrs =
( attribute blen { xsd:unsignedShort },
attribute vlen { xsd:unsignedShort } )?
oid.type =
xsd:string {
pattern =
"(([0-1](\.[1-3]?[0-9]))|(2.(0|([1-9]\d*))))" ~
"(\.(0|([1-9]\d*))){0,126}"
}
# The types below are for IP addresses. Note that SNMP's buildin # IpAddress type only supports IPv4 addresses; IPv6 addresses are only # introduced to cover SNMP over IPv6 endpoints.
＃以下のタイプはIPアドレス用です。SNMPのbuildin＃iPaddressタイプは、IPv4アドレスのみをサポートすることに注意してください。IPv6アドレスは、IPv6エンドポイントを介してSNMPをカバーするために導入された＃のみです。
ipv4address.type =
xsd:string {
pattern =
"((0|(1[0-9]{0,2})" ~
"|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))\.){3}" ~
"(0|(1[0-9]{0,2})" ~
"|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))"
}
ipv6address.type =
xsd:string {
pattern =
"(([0-9a-fA-F]+:){7}[0-9a-fA-F]+)|" ~
"(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?"
}
ipaddress.type = ipv4address.type | ipv6address.type
iPaddress.type = ipv4address.type |IPv6Address.Type
The following example shows an SNMP trace file in XML format containing an SNMPv1 get-next-request message for the OID 1.3.6.1.2.1.1.3 (sysUpTime) and the response message returned by the agent.
次の例は、OID 1.3.6.1.2.1.1.3（sysuptime）のSNMPV1 Get-Next-Requestメッセージを含むXML形式のSNMPトレースファイルと、エージェントが返した応答メッセージを示しています。
<snmptrace xmlns="urn:ietf:params:xml:ns:snmp-trace-1.0">
<packet>
<time-sec>1147212206</time-sec>
<time-usec>739609</time-usec>
<src-ip>192.0.2.1</src-ip>
<src-port>60371</src-port>
<dst-ip>192.0.2.2</dst-ip>
<dst-port>12345</dst-port>
<snmp blen="42" vlen="40">
<version blen="3" vlen="1">1</version>
<community blen="8" vlen="6">7075626c6963</community>
<get-next-request blen="29" vlen="27">
<request-id blen="6" vlen="4">1804289383</request-id>
<error-status blen="3" vlen="1">0</error-status>
<error-index blen="3" vlen="1">0</error-index>
<variable-bindings blen="15" vlen="13">
<varbind blen="13" vlen="11">
<name blen="9" vlen="7">1.3.6.1.2.1.1.3</name>
<null blen="2" vlen="0"/>
</varbind>
</variable-bindings>
</get-next-request>
</snmp>
</packet>
<packet>
<time-sec>1147212206</time-sec>
<time-usec>762891</time-usec>
<src-ip>192.0.2.2</src-ip>
<src-port>12345</src-port>
<dst-ip>192.0.2.1</dst-ip>
<dst-port>60371</dst-port>
<snmp blen="47" vlen="45">
<version blen="3" vlen="1">1</version>
<community blen="8" vlen="6">7075626c6963</community>
<response blen="34" vlen="32">
<request-id blen="6" vlen="4">1804289383</request-id>
<error-status blen="3" vlen="1">0</error-status>
<error-index blen="3" vlen="1">0</error-index>
<variable-bindings blen="20" vlen="18">
<varbind blen="18" vlen="16">
<name blen="10" vlen="8">1.3.6.1.2.1.1.3.0</name>
<unsigned32 blen="6" vlen="4">26842224</unsigned32>
</varbind>
</variable-bindings>
</response>
</snmp>
</packet>
</snmptrace>
The comma-separated values (CSV) format has been designed to capture only the most relevant information about an SNMP message. In situations where all information about an SNMP message must be captured, the XML format defined above must be used. The CSV format uses the following fields:
CommaSeparated値（CSV）形式は、SNMPメッセージに関する最も関連性の高い情報のみをキャプチャするように設計されています。SNMPメッセージに関するすべての情報をキャプチャする必要がある状況では、上記のXML形式を使用する必要があります。CSV形式では、次のフィールドを使用します。
1. Timestamp in the format seconds.microseconds since 1970, for example, "1137764769.425484".
1. たとえば、1970年以降、scond.microsecondsの形式のタイムスタンプ、たとえば「1137764769.425484」。
2. Source IP address in dotted quad notation (IPv4), for example, "192.0.2.1", or compact hexadecimal notation (IPv6), for example, "2001:DB8::1".
2. たとえば、「192.0.2.1」、またはコンパクトな16進表（IPv6）など、点線のクアッド表記（IPv4）のソースIPアドレス（2001年：DB8 :: 1」など。
3. Source port number represented as a decimal number, for example, "4242".
3. ソースポート番号は、たとえば「4242」など、小数点以下として表されます。
4. Destination IP address in dotted quad notation (IPv4), for example, "192.0.2.1", or compact hexadecimal notation (IPv6), for example, "2001:DB8::1".
4. 宛先IPアドレスは、「192.0.2.1」、または「2001：DB8 :: 1」など、「192.0.2.1」、またはコンパクトな16進表（IPv6）などの点線のIPアドレスです。
5. Destination port number represented as a decimal number, for example, "161".
5. 宛先ポート番号は、たとえば「161」などの10進数として表されます。
6. Size of the SNMP message (a decimal number) counted in octets, for example, "123". The size excludes all transport, network, and link-layer headers.
6. たとえば、「123」など、オクテットでカウントされたSNMPメッセージ（小数点以下）のサイズ。サイズは、すべてのトランスポート、ネットワーク、およびリンク層ヘッダーを除外します。
7. SNMP message version represented as a decimal number. The version 0 stands for SNMPv1, 1 for SNMPv2c, and 3 for SNMPv3, for example, "3".
7. 小数点以下の数字として表されるSNMPメッセージバージョン。バージョン0は、snmpv1、snmpv2cの1、snmpv3の場合は「3」を表します。
8. SNMP protocol operation indicated by one of the keywords get-request, get-next-request, get-bulk-request, set-request, trap, snmpV2-trap, inform-request, response, report.
8. SNMPプロトコル操作は、キーワードGet-Request、Get-Next-Request、Get-Bulk-Request、Set-Request、TRAP、SNMPV2-Trap、Inform-Request、Response、Reportによって示されます。
9. SNMP request-id in decimal notation, for example, "1511411010".
9. たとえば、「1511411010」など、小数表のsnmp request-id。
10. SNMP error-status in decimal notation, for example, "0".
10. たとえば、「0」など、小数表のSNMPエラーステータス。
11. SNMP error-index in decimal notation, for example, "0".
11. たとえば、「0」など、小数表のSNMPエラーインデックス。
12. Number of variable-bindings contained in the varbind-list in decimal notation, for example, "5".
12. たとえば、「5」など、小数表のvarbind-listに含まれる可変バインディングの数。
13. For each varbind in the varbind list, three output elements are generated: 1. Object name given as object identifier in dotted decimal notation, for example, "1.3.6.1.2.1.1.3.0".
13. Varbindリストの各varbindについて、3つの出力要素が生成されます。1。オブジェクト名は、たとえば「1.3.6.1.2.1.1.3.0」など、点線の小数表でオブジェクト識別子として与えられます。
2. Object base type name or exception name, that is one of the following: null, integer32, unsigned32, counter32, counter64, timeticks, ipaddress, octet-string, object-identifier, opaque, no-such-object, no-such-instance, and end-of-mib-view.
2. オブジェクトベースのタイプ名または例外名、それは次のいずれかです：null、integer32、unsigned32、counter32、counter64、時系列、iPaddress、オクテットストリング、オブジェクト識別子、不透明、ノーオブジェクト、ノー - インスタンス、MIB-view。
3. Object value is printed as a number if the underlying base type is numeric. An IPv4 addresses is rendered in the dotted quad notation and an IPv6 address is rendered in the usual hexadecimal notation. An octet string value is printed in hexadecimal format while an object identifier value is printed in dotted decimal notation. In case of an exception, the object value is empty.
3. 基礎となるベースタイプが数値の場合、オブジェクト値は数として印刷されます。IPv4アドレスは、点線のクワッド表記でレンダリングされ、IPv6アドレスは通常の16進表でレンダリングされます。Object String値は16進形式で印刷され、オブジェクト識別子値は点線の小数表で印刷されます。例外の場合、オブジェクト値は空です。
Note that the format does not preserve the information needed to understand SNMPv1 traps. It is therefore recommended that implementations be able to convert the SNMPv1 trap format into the trap format used by SNMPv2c and SNMPv3, according to the rules defined in [RFC3584]. The activation of trap format conversion should be the user's choice.
このフォーマットは、SNMPV1トラップを理解するために必要な情報を保存しないことに注意してください。したがって、[RFC3584]で定義されているルールに従って、実装はSNMPV2CおよびSNMPV3が使用するTRAP形式にSNMPV1トラップ形式を変換できるようにすることをお勧めします。トラップ形式の変換のアクティブ化は、ユーザーの選択である必要があります。
The following example shows an SNMP trace file in CSV format containing an SNMPv1 get-next-request message for the OID 1.3.6.1.2.1.1.3 (sysUpTime) and the response message returned by the agent. (Note that the example uses backslash line continuation marks in order to fit the example into the RFC format. Backslash line continuations are not part of the CSV format.)
次の例は、OID 1.3.6.1.2.1.1.1.3（sysuptime）のSNMPV1 Get-Next-Requestメッセージを含むCSV形式のSNMPトレースファイルと、エージェントが返した応答メッセージを示しています。（この例では、例をRFC形式に適合させるためにバックスラッシュラインの継続マークを使用していることに注意してください。バックスラッシュラインの継続はCSV形式の一部ではありません。）
1147212206.739609,192.0.2.1,60371,192.0.2.2,12345,42,1,\ get-next-request,1804289383,0,0,1,1.3.6.1.2.1.1.3,null, 1147212206.762891,192.0.2.2,12345,192.0.2.1,60371,47,1,\ response,1804289383,0,0,1,1.3.6.1.2.1.1.3.0,timeticks,26842224
1147212206.739609,192.0.2.1,60371,192.0.2.2,12345,42,1、\ get-next-request、1804289383,0,0,1,1.1.3.6.1.2.1.1.、192.0.2.1,60371,47,1、\ Response、1804289383,0,0,1,1.3.6.1.2.1.1.1.3.0、Timeticks、268422224
SNMP traffic traces usually contain sensitive information. It is therefore necessary to (a) remove unwanted information and (b) to anonymize the remaining necessary information before traces are made available for analysis. It is recommended to encrypt traces when they are archived.
SNMPトラフィックトレースには通常、機密情報が含まれています。したがって、（a）不要な情報を削除し、（b）分析のためにトレースを利用できるようにする前に、残りの必要な情報を匿名化する必要があります。トレースがアーカイブされたときにトレースを暗号化することをお勧めします。
Implementations that generate CSV or XML traces from raw pcap files should have an option to suppress or anonymize values. Note that instance identifiers of tables also include values, and it might therefore be necessary to suppress or anonymize (parts of) the instance identifiers. Similarly, the packet and message headers typically contain sensitive information about the source and destination of SNMP messages as well as authentication information (community strings or user names).
RAW PCAPファイルからCSVまたはXMLトレースを生成する実装には、値を抑制または匿名化するオプションが必要です。テーブルのインスタンス識別子には値も含まれているため、インスタンス識別子を抑制または匿名化する必要がある場合があることに注意してください。同様に、パケットヘッダーとメッセージヘッダーには、通常、SNMPメッセージのソースと宛先に関する機密情報、および認証情報（コミュニティ文字列またはユーザー名）が含まれています。
Anonymization techniques can be applied to keep information in traces that could otherwise reveal sensitive information. When using anonymization, values should only be kept when the underlying data type is known and an appropriate anonymization transformation is available (filter-in principle). For values appearing in instance identifiers, it is usually desirable to maintain the lexicographic order. Special anonymization transformations that preserve this property have been developed, although their anonymization strength is usually reduced compared to transformations that do not preserve lexicographic ordering [HS06].
匿名化手法を適用して、それ以外の場合は機密情報を明らかにする可能性のあるトレースに情報を保持できます。匿名化を使用する場合、値は基礎となるデータ型が既知であり、適切な匿名化変換が利用可能である場合にのみ保持する必要があります（フィルターイン原則）。インスタンス識別子に表示される値については、通常、辞書編集順序を維持することが望ましいです。この特性を維持する特別な匿名化変換が開発されましたが、匿名化強度は通常、辞書的秩序を保持しない変換と比較して減少します[HS06]。
The meta data associated with traces and in particular information about the organization owning a network and the description of the measurement point in the network topology where a trace was collected may be misused to decide/pinpoint where and how to attack a network. Meta data therefore needs to be properly protected.
トレースに関連付けられたメタデータと、ネットワークを所有する組織に関する特別な情報と、トレースが収集されたネットワークトポロジの測定ポイントの説明は、ネットワークを攻撃する場所と方法を決定/特定するために誤用される場合があります。したがって、メタデータを適切に保護する必要があります。
Per this document, IANA has registered a URI for the SNMP XML trace format namespace in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration has been made:
このドキュメントに従って、IANAはIETF XMLレジストリ[RFC3688]のSNMP XMLトレース形式の名前空間のURIを登録しています。RFC 3688の形式に続いて、次の登録が行われました。
URI: "urn:ietf:params:xml:ns:snmp-trace-1.0"
Registrant Contact: The NMRG of the IRTF.
登録者の連絡先：IRTFのNMRG。
XML: N/A, the URI is an XML namespace.
XML：N/A、URIはXMLネームスペースです。
This document was influenced by discussions within the Network Management Research Group (NMRG). Special thanks to Remco van de Meent for writing the initial Perl script that lead to the development of the snmpdump software package and Matus Harvan for his work on lexicographic order preserving anonymization transformations. Aiko Pras contributed ideas to Section 3 while David Harrington helped to improve the readability of this document.
このドキュメントは、ネットワーク管理研究グループ（NMRG）内の議論の影響を受けました。SnmpdumpソフトウェアパッケージとMatus Harvanの開発につながる最初のPerlスクリプトを作成してくれたRemco Van De Meentに感謝します。Aiko Prasはセクション3にアイデアを提供し、David Harringtonはこのドキュメントの読みやすさを改善するのに役立ちました。
Last call reviews have been received from Bert Wijnen, Aiko Pras, Frank Strauss, Remco van de Meent, Giorgio Nunzi, Wes Hardacker, Liam Fallon, Sharon Chisholm, David Perkins, Deep Medhi, Randy Bush, David Harrington, Dan Romascanu, Luca Deri, and Marc Burgess. Karen R.
Bert Wijnen、Aiko Pras、Frank Strauss、Remco Van De Meent、Giorgio Nunzi、Wes Hardacker、Liam Fallon、Sharon Chisholm、David Perkins、Deep Medhi、Randy Bush、David Harrington、Dan Romascanu、Luca Deri、およびマークバージェス。カレンR.
Sollins reviewed the document for the Internet Research Steering Group (IRSG). Jari Arkko, Pasi Eronen, Chris Newman, and Tim Polk provided helpful comments during the Internet Engineering Steering Group (IESG) review.
Sollinsは、インターネット研究運営グループ（IRSG）の文書をレビューしました。Jari Arkko、Pasi Eronen、Chris Newman、およびTim Polkは、インターネットエンジニアリングステアリンググループ（IESG）レビュー中に有益なコメントを提供しました。
Part of this work was funded by the European Commission under grant FP6-2004-IST-4-EMANICS-026854-NOE.
この作業の一部は、Grant FP6-2004-AST-4-MANICS-026854-NOEの下で欧州委員会によって資金提供されました。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[OASISRNG] Clark, J. and M. Makoto, "RELAX NG Specification", OASIS Committee Specification, December 2001.
[Oasisrng] Clark、J。およびM. Makoto、「Ng Specification」、Oasis Committee Specification、2001年12月。
[OASISRNC] Clark, J., "RELAX NG Compact Syntax", OASIS Committee Specification, November 2002.
[Oasisrnc] Clark、J。、「Compact Syntaxのリラックス」、Oasis Committee Specification、2002年11月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584] Frye、R.、Levi、D.、Routhier、S。、およびB. Wijnen、「インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、およびバージョン3の共存」、BCP 74、RFC 3584、2003年8月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC1052] Cerf, V., "IAB Recommendations for the development of Internet network management standards", RFC 1052, April 1998.
[RFC1052] Cerf、V。、「インターネットネットワーク管理標準の開発に関するIABの推奨」、RFC 1052、1998年4月。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIV2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418] Presuhn、R.、ed。、「Simple Network Management Protocol（SNMP）の管理情報ベース（MIB）」、STD 62、RFC 3418、2002年12月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[RFC4022] Raghunarayan、R。、「送信制御プロトコルの管理情報ベース（TCP）」、RFC 4022、2005年3月。
[PDMQ04] Pras, A., Drevers, T., van de Meent, R., and D. Quartel, "Comparing the Performance of SNMP and Web Services based Management", IEEE Transactions on Network and Service Management 1(2), November 2004.
[PDMQ04] Pras、A.、Drevers、T.、Van de Meent、R。、およびD. Quartel、「SNMPとWebサービスベースの管理のパフォーマンスの比較」、IEEEトランザクション1（2）、2004年11月。
[Pat01] Pattinson, C., "A Study of the Behaviour of the Simple Network Management Protocol", Proc. 12th IFIP/IEEE Workshop on Distributed Systems: Operations and Management , October 2001.
[PAT01] Pattinson、C。、「単純なネットワーク管理プロトコルの動作の研究」、Proc。分散システムに関する第12 IFIP/IEEEワークショップ：運用と管理、2001年10月。
[DSR01] Du, X., Shayman, M., and M. Rozenblit, "Implementation and Performance Analysis of SNMP on a TLS/TCP Base", Proc. 7th IFIP/IEEE International Symposium on Integrated Network Management , May 2001.
[DSR01] Du、X.、Shayman、M。、およびM. Rozenblit、「TLS/TCPベース上のSNMPの実装とパフォーマンス分析」、Proc。2001年5月、統合ネットワーク管理に関する第7回IFIP/IEEE国際シンポジウム。
[CT04] Corrente, A. and L. Tura, "Security Performance Analysis of SNMPv3 with Respect to SNMPv2c", Proc. 2004 IEEE/IFIP Network Operations and Management Symposium , April 2004.
[CT04] Corrente、A。およびL. Tura、「Snmpv2cに関するSNMPV3のセキュリティパフォーマンス分析」、Proc。2004 IEEE/IFIPネットワーク運用および管理シンポジウム、2004年4月。
[PFGL04] Pavlou, G., Flegkas, P., Gouveris, S., and A. Liotta, "On Management Technologies and the Potential of Web Services", IEEE Communications Magazine 42(7), July 2004.
[PFGL04] Pavlou、G.、Flegkas、P.、Gouveris、S。、およびA. Liotta、「管理技術とWebサービスの可能性について」、IEEE Communications Magazine 42（7）、2004年7月。
[SM99] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of MIB Data", Simple Times 7(1), March 1999.
[SM99] Sprenkels、R。およびJ. Martin-Flatin、「MIBデータのバルク転送」、Simple Times 7（1）、1999年3月。
[Mal02] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), December 2002.
[Mal02] Malowidzki、M。、「Getbulk価値が修正される」、Simple Times 10（1）、2002年12月。
[HS06] Harvan, M. and J. Schoenwaelder, "Prefix- and Lexicographical-order-preserving IP Address Anonymization", IEEE/IFIP Network Operations and Management Symposium NOMS 2006, April 2006.
[HS06] Harvan、M。およびJ. Schoenwaelder、「プレフィックスおよびレキシグラフィーの順序を提示するIPアドレス匿名化」、IEEE/IFIPネットワーク運用および管理シンポジウムNOMS 2006、2006年4月。
[XFA02] Xu, J., Fan, J., and M. Ammar, "Prefix-Preserving IP Address Anonymization: Measurement-based Security Evaluation and a New Cryptography-based Scheme", 10th IEEE International Conference on Network Protocols ICNP'02, November 2002.
[XFA02] Xu、J.、Fan、J。、およびM. Ammar、「プレフィックス予約IPアドレス匿名化：測定ベースのセキュリティ評価と新しい暗号ベースのスキーム」、第10回IEEEネットワークプロトコルに関するIEEE国際会議ICNP'02、2002年11月。
[FXAM04] Fan, J., Xu, J., Ammar, M., and S. Moon, "Prefix-Preserving IP Address Anonymization", Computer Networks 46(2), October 2004.
[FXAM04] Fan、J.、Xu、J.、Ammar、M。、およびS. Moon、「プレフィックス予約IPアドレス匿名化」、コンピューターネットワーク46（2）、2004年10月。
[PAPL06] Pang, R., Allman, M., Paxson, V., and J. Lee, "The Devil and Packet Trace Anonymization", Computer Communication Review 36(1), January 2006.
[Papl06] Pang、R.、Allman、M.、Paxson、V。、およびJ. Lee、「The Devil and Packet Trace Anonymization」、Computer Communication Review 36（1）、2006年1月。
[RW07] Ramaswamy, R. and T. Wolf, "High-Speed Prefix-Preserving IP Address Anonymization for Passive Measurement Systems", IEEE Transactions on Networking 15(1), February 2007.
[RW07] Ramaswamy、R。およびT. Wolf、「パッシブ測定システムのための高速プレフィックス予定IPアドレス匿名化」、IEEEトランザクション15（1）、2007年2月。
URIs
ウリス
[1] <http://en.wikipedia.org/wiki/Pcap>
[2] <http://www.tcpdump.org/>
[3] <http://www.wireshark.org/>
[4] <http://www.datcat.org/>
[5] <https://svn.eecs.jacobs-university.de/svn/schoenw/src/snmpdump>
[6] <http://xmlsoft.org/XSLT/>
[7] <http://perl-xml.sourceforge.net/faq/>
[8] <http://www.relaxng.org/>
Author's Address
著者の連絡先
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725ブレーメンドイツ
Phone: +49 421 200-3587
EMail: j.schoenwaelder@jacobs-university.de
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびhttp://www.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。