RFC5345 日本語訳
5345 Simple Network Management Protocol (SNMP) Traffic Measurementsand Trace Exchange Formats. J. Schoenwaelder. October 2008. (Format: TXT=52411 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Schoenwaelder Request for Comments: 5345 Jacobs University Bremen Category: Informational October 2008
Schoenwaelderがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5345年のジェイコブズ大学ブレーメンカテゴリ: 情報の2008年10月
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に関連するOperationsとManagement Areaで行われたIETF仕事に関連すると思いますが、これは、発行するのを防ぎません。 このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFはどんな目的と発行するという決定がIANAによるURIの配分とIETF仕事との闘争のためのIESGレビューでのIETF Last Callは別としてIETFレビューに基づいていないというメモのためにもこのRFCのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 詳しい情報に関してRFC3932を見てください。
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プロトコル(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のNetwork Management Research Group(NMRG)の中で製作されました、そして、それは活発な貢献者のすべてのコンセンサスをこのグループに表します。
Schoenwaelder Informational [Page 1] RFC 5345 SNMP Traffic Measurements October 2008
[1ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
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
1. 序論…3 2. 測定アプローチ…4 2.1. トラフィックが跡であるとキャプチャします…5 2.2. トラフィック跡を変換します…6 2.3. トラフィック跡をフィルターにかけます…7 2.4. トラフィック跡を保存します…7 2.5. トラフィック跡を分析します…8 3. トラフィック跡の分析…9 3.1. 基本的な統計…9 3.2. 非周期的のトラフィックに対して周期的…9 3.3. メッセージサイズと潜在配…9 3.4. 並行性レベル…10 3.5. テーブル検索にアプローチします…10 3.6. 罠で指示された世論調査--神話ですかそれとも現実ですか? .................10 3.7. ポピュラーなMIB定義…11 3.8. 時代遅れのオブジェクトの使用法…11 3.9. 長さの配をコード化します…11 3.10. カウンタと不連続…11 3.11. 錠を回転させてください…12 3.12. 作成をこいでください…12 4. 交換形式をたどってください…12 4.1. XML表現…12 4.2. CSV表現…17 5. セキュリティ問題…18 6. IANA問題…19 7. 承認…19 8. 参照…20 8.1. 標準の参照…20 8.2. 有益な参照…20
Schoenwaelder Informational [Page 2] RFC 5345 SNMP Traffic Measurements October 2008
[2ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
1. Introduction
1. 序論
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.
Simple Network Managementプロトコル(SNMP)は、1980年代後半の[RFC1052]で紹介されて、それ以来、今日SNMPバージョン3Framework(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.
Webサービス[PDMQ04][PFGL04]と比べて、最近において一般に、SNMP[SM99][Mal02]の性能[Pat01]、SNMPv3セキュリティ[DSR01]の影響[CT04]、またはSNMPの相対的パフォーマンスに対処するいくつかの刊行物がありました。 一般に、これらの書類が様々なデザイン決定と技術の影響をより理解するために役に立つ間、作者が仮定が正しいという実験上の証拠を持っていなくてある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).
多くの作者がifTableを使用する、-、MIB、彼らの分析と比較のための出発点としてのTCP-MIB[RFC4022]の[RFC2863]か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
SNMP跡の収集と分析取り組みが研究団体によって開始されていた間、ネットワーク・オペレータはSNMP測定値も利益を得ることができます。 いくつかの新しいツールが部分として開発されています。
Schoenwaelder Informational [Page 3] RFC 5345 SNMP Traffic Measurements October 2008
[3ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
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.
管理局によって生成されたトラフィックを得て、分析するのに使用できるこの取り組み。 そして、マネージメントシステムの効率とスケーラビリティを改良するのにこの結果として起こる情報を使用できます。
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のNetwork Management Research Group(NMRG)の中で製作されたInformationalドキュメントです、そして、それは活発な貢献者のすべてのコンセンサスをこのグループに表します。
2. Measurement Approach
2. 測定アプローチ
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パケットキャプチャーファイル[1]で生のSNMPトラフィックが跡であるとキャプチャしてください。
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. 機密情報を変換されたトラフィック跡をフィルターにかけて、隠すか、またはanonymizeしてください。 フィルタリングが概念的にそうである、別々のステップで、効率のための前のデータ変換ステップの一部が推論するようにフィルタリングは実際に実装されるかもしれません。
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表現は分析スクリプトを書いている研究者と測定活動にかかわるオペレータとのインタフェースになるでしょう。 したがって、これらのインタフェースの明確な仕様を持っているのは重要です。
Schoenwaelder Informational [Page 4] RFC 5345 SNMP Traffic Measurements October 2008
[4ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
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ステップといくつかのツールについて説明します。
2.1. Capturing Traffic Traces
2.1. トラフィックが跡であるとキャプチャします。
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トラフィック(通常'udpと(ポート161かポート162)')を運ぶのに使用されるSNMP輸送終点に合っているpcapフィルタ式を指定するために何らかの注意を払わなければなりません。 その上、完全なパケットが捕らわれているのを保証するのが必要である、すなわち、パケットは端が欠けていません(tcpdumpオプション-s0)。 最終的に、ネットワークの中で慎重にキャプチャする徹底的調査のプレースメントを選択するのが必要です。 特にブリッジしている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週間をキャプチャするのはお勧めです。 オペレータがさらに長い期間にわたって跡をキャプチャするよう強く奨励されます。 必要に応じてpcap跡のファイルを分かれるか、または合併するのにtcpdumpやtcpslice[2]かmergecapやeditcap[3]などのツールを使用できます。
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陸揚をサポートするキャプチャするインタフェースからの/にトラフィックを含んでいる跡は不正確なトランスポート層チェックサムを含めることができます。最も簡単なソリューションはもちろん跡をキャプチャしている間(それがあまりに多くの損をしているパケットなしで可能であるなら)、回転チェックサム陸揚に向かいます。 もう片方のソリューションは、生の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ファイルに戻るのが必要であるかもしれません。
Schoenwaelder Informational [Page 5] RFC 5345 SNMP Traffic Measurements October 2008
[5ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
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.
それぞれの捕らわれている跡に関しては、いくつかのメタデータを記録して、利用可能にするべきです。 メタデータは跡が集められたところの情報(ネットワークの名前とネットワークを所有している組織名、ネットワーク形態の跡が集められた測定ポイントの記述)を含むべきです、それが集められたとき、問い合わせ先、跡のサイズ、どんな知られている特別なイベント、設備故障、または、主要なインフラストラクチャがデータ収集の期間などの間、変化します。 また、ユニークな識別を提供するのも非常に役に立ちます。 ユニークな識別子を提供するメタデータを保存できるDatCat[4]などの特別なオンラインサービスがあります。
2.2. Converting Traffic Traces
2.2. トラフィック跡を変換します。
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トラフィック跡を表すために、RELAX 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.
コンマ区切り値(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.
前項で説明されるように、生のpcapファイルを処理する分析プログラムはTCP/IPによって引き起こされた不正確なチェックサムを無視するオプションを積み下ろすようにするはずです。 さらに、生のpcapファイルを処理する分析プログラムはIP層で断片化されたSNMPメッセージのためにIP再アセンブリを実行するはずであることができます。
Schoenwaelder Informational [Page 6] RFC 5345 SNMP Traffic Measurements October 2008
[6ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
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.
極秘データを保護するために必要に応じて特定の要素をフィルターにかけることができます。
2.3. Filtering Traffic Traces
2.3. トラフィック跡をフィルターにかけます。
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])を使用できます。 スクリプト言語Perlに詳しい人々は、XMLドキュメント[7]を操作するために適当なPerlモジュールを選びたがっているかもしれません。
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]に現れる値のための辞書編集の注文を維持するデータ型の特定のanonymization変換は適用できます。 anonymization変換がしばしば初期化キーに縛られて、anonymization走行でanonymizedされるデータによることに注意してください。 彼らが独自にanonymizedされた跡からのデータを合併するとき、結果として、ユーザは慎重であるに違いありません。 [XFA02]、[FXAM04]、[PAPL06]、および[RW07]でネットワークトラフィック跡のanonymizationのテクニックに関する詳しい情報を見つけることができます。
2.4. Storing Traffic Traces
2.4. トラフィック跡を保存します。
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.
XML / CSVが跡をフォーマットしたので、また、生のpcap跡は安定したアーカイブか倉庫に保存されるべきです。 そのようなアーカイブか倉庫が研究グループ(例えば、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.
このドキュメントが、生の跡が保たれるべきであることを勧めている間、状況がこれが可能でないかもしれないところにあることに注意しなければなりません。 例えば、生の跡を保つという推薦は、データ保護法に従うか、またはデータを提供させるのから他の組織までネットワーク・オペレータを保護するために無視されるかもしれません。
Schoenwaelder Informational [Page 7] RFC 5345 SNMP Traffic Measurements October 2008
[7ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
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.
サイズまでのそれらが安い長期貯蔵のためのDVDで燃えることができる大きい跡のファイルさえ圧縮するのにgzipかbzip2などのプログラムに表現された可逆圧縮アルゴリズムは使用できます。
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.
XML/CSVに加えた元のpcap跡を保つのがpcap跡が最も正統の情報源であるので跡をフォーマットしたのが、重要であると再び強調しなければなりません。 ツールチェーンにおける改良は、元のpcap跡に戻って、それらからすべての中間的形式を再建するのを必要とするかもしれません。
2.5. Analyzing Traffic Traces
2.5. トラフィック跡を分析します。
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.
正当性のためにトラフィック跡を分析するスクリプトを確かめなければなりません。 理想的に、トラフィック跡を分析するのに使用されるすべてのスクリプトが、第三者が彼らについて確かめることができるように、publicallyに理解できるでしょう。 その上、スクリプトを共有するのは、相手が他のトラフィック跡の分析を繰り返して、そのような分析スクリプトを広げるのを可能にするでしょう。 分析スクリプトのために一般的で、versioningしている倉庫を設立するのは役に立つかもしれません。
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ドキュメント<http://パール-xml.sourceforgeを操作するのに適当なPerlモジュールを使用することでPerlなどのスクリプト言語に書かれていることが提案されます; 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がトラフィックであると生成するアプリケーションの本質、または跡が集められましたが、起こったイベントが明確に結果に影響を及ぼします。 したがって、潜在的に限られた(また)データセットに基づく一般的な結論を引き起こすとき、慎重であるのは重要です。
Schoenwaelder Informational [Page 8] RFC 5345 SNMP Traffic Measurements October 2008
[8ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
3. Analysis of Traffic Traces
3. トラフィック跡の分析
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トラフィック跡を分析することによって答えることができるいくつかの問題について論じます。 説明に役立つことを以下の小区分で引き起こされた疑問を意味します、そして、全リストを提供するのを試みを全くしていません。
3.1. Basic Statistics
3.1. 基本的な統計
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.
例えば、'標準化され'て、'独占で'、'実験的な'オブジェクトを特定するために操作されたオブジェクトのObject Identifier(OID)名をOID下位木に分類できます。
3.2. Periodic versus Aperiodic Traffic
3.2. 非周期的のトラフィックに対して周期的です。
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.
周期的な世論調査の振舞いはそれが使用するアプリケーションと世論調査エンジンに依存しているかもしれません。 例えば、いくつかの管理プラットフォームで、それらが再び投票される前にアプリケーションは、投票された値がキャッシュでどれくらい長い状態で保たれるかもしれないかを指定できます。 そのような最適化は、周期的で非周期的のトラフィックのために跡を分析するとき、考えられる必要があります。
3.3. Message Size and Latency Distributions
3.3. メッセージサイズと潜在配
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
SNMPメッセージはマッピングが使用した輸送とSNMPエンジンによって提供されたバッファによって抑制されたサイズです。 SNMPフレームワークの一層の発展に、実際のメッセージサイズ配が何であるかを知るのは役に立つでしょう。 分かるのは役に立つでしょう。
Schoenwaelder Informational [Page 9] RFC 5345 SNMP Traffic Measurements October 2008
[9ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
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実装がネットワーク遅れに近似します、そして、これが実行可能なアプローチであるというどんな範囲まで分かるかは役に立つでしょう。
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実装が必ず定期的、そして、必ず要求からアップデートするのではなく、適応型のアルゴリズムに従う基本的な計装からそれらのカウンタをアップデートします。 内部のカウンタアップデートの粒状は、潜在測定値に影響を与えるかもしれなくて、考慮に入れられるべきです。
3.4. Concurrency Levels
3.4. 並行性レベル
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エージェントは戦略をキャッシュするときの含意を使います。
3.5. Table Retrieval Approaches
3.5. テーブル検索アプローチ
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.
いくつかの異なった方法でテーブルを読むことができます。 最も簡単で最も効率の悪いアプローチはカラム配列によるコラムのオブジェクトごとのテーブルを検索することです。 より高度なアプローチは行ごとの複数の行ごとにさえテーブルを読もうとします。 多くの場合、インデックス要素の検索を抑圧できますか、またはテーブルに関するコラムの部分集合だけが検索されます。 これらのアプローチのどれがこれがエージェント実装のテクニックにダイレクト意味を持っているので生産ネットワークで使用されて、戦略をキャッシュしているかを知るのは役に立ちます。
3.6. Trap-Directed Polling - Myths or Reality?
3.6. 罠で指示された世論調査--神話ですかそれとも現実ですか?
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 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.
Schoenwaelder Informational [Page 10] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 10] RFC 5345 SNMP Traffic Measurements October 2008
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.
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.
3.7. Popular MIB Definitions
3.7. Popular MIB Definitions
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.
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.
3.8. Usage of Obsolete Objects
3.8. Usage of Obsolete Objects
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.
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.
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.
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.
3.9. Encoding Length Distributions
3.9. Encoding Length Distributions
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.
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.
3.10. Counters and Discontinuities
3.10. Counters and Discontinuities
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
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
Schoenwaelder Informational [Page 11] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 11] RFC 5345 SNMP Traffic Measurements October 2008
IF-MIB [RFC2863]. It will be interesting to study to what extent these objects are actually used by management applications to handle discontinuity events.
IF-MIB [RFC2863]. It will be interesting to study to what extent these objects are actually used by management applications to handle discontinuity events.
3.11. Spin Locks
3.11. Spin Locks
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.
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.
3.12. Row Creation
3.12. Row Creation
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.
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.
4. Trace Exchange Formats
4. Trace Exchange Formats
4.1. XML Representation
4.1. XML Representation
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.
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.
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).
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).
# Relax NG grammar for the XML SNMP trace format. # # Published as part of RFC 5345.
# Relax NG grammar for the XML SNMP trace format. # # Published as part of RFC 5345.
Schoenwaelder Informational [Page 12] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 12] RFC 5345 SNMP Traffic Measurements October 2008
default namespace = "urn:ietf:params:xml:ns:snmp-trace-1.0"
default namespace = "urn:ietf:params:xml:ns:snmp-trace-1.0"
start =
element snmptrace {
packet.elem*
}
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
}
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
}
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 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
}
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 {
Schoenwaelder Informational [Page 13] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 13] RFC 5345 SNMP Traffic Measurements October 2008
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 }
}
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 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* }
}
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 } |
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 } |
Schoenwaelder Informational [Page 14] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 14] RFC 5345 SNMP Traffic Measurements October 2008
element no-such-object { length.attrs, empty } |
element no-such-instance { length.attrs, empty } |
element end-of-mib-view { length.attrs, empty }
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.
# 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.
length.attrs =
( attribute blen { xsd:unsignedShort },
attribute vlen { xsd:unsignedShort } )?
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}"
}
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.
# 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.
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]?))"
}
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]+)?"
}
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.
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.
Schoenwaelder Informational [Page 15] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 15] RFC 5345 SNMP Traffic Measurements October 2008
<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>
<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>
Schoenwaelder Informational [Page 16] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 16] RFC 5345 SNMP Traffic Measurements October 2008
4.2. CSV Representation
4.2. CSV Representation
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:
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:
1. Timestamp in the format seconds.microseconds since 1970, for
example, "1137764769.425484".
1. Timestamp in the format seconds.microseconds since 1970, for example, "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. Source IP address in dotted quad notation (IPv4), for example, "192.0.2.1", or compact hexadecimal notation (IPv6), for example, "2001:DB8::1".
3. Source port number represented as a decimal number, for example,
"4242".
3. Source port number represented as a decimal number, for example, "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. Destination IP address in dotted quad notation (IPv4), for example, "192.0.2.1", or compact hexadecimal notation (IPv6), for example, "2001:DB8::1".
5. Destination port number represented as a decimal number, for
example, "161".
5. Destination port number represented as a decimal number, for example, "161".
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. Size of the SNMP message (a decimal number) counted in octets, for example, "123". The size excludes all transport, network, and link-layer headers.
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 message version represented as a decimal number. The version 0 stands for SNMPv1, 1 for SNMPv2c, and 3 for SNMPv3, for example, "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 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.
9. SNMP request-id in decimal notation, for example, "1511411010".
9. SNMP request-id in decimal notation, for example, "1511411010".
10. SNMP error-status in decimal notation, for example, "0".
10. SNMP error-status in decimal notation, for example, "0".
11. SNMP error-index in decimal notation, for example, "0".
11. SNMP error-index in decimal notation, for example, "0".
12. Number of variable-bindings contained in the varbind-list in
decimal notation, for example, "5".
12. Number of variable-bindings contained in the varbind-list in decimal notation, for example, "5".
13. For each varbind in the varbind list, three output elements are
generated:
13. For each varbind in the varbind list, three output elements are generated:
Schoenwaelder Informational [Page 17] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 17] RFC 5345 SNMP Traffic Measurements October 2008
1. Object name given as object identifier in dotted decimal
notation, for example, "1.3.6.1.2.1.1.3.0".
1. Object name given as object identifier in dotted decimal notation, for example, "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. 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.
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. 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.
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.
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.
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.)
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.)
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.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
5. Security Considerations
5. Security Considerations
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 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.
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
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
Schoenwaelder Informational [Page 18] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 18] RFC 5345 SNMP Traffic Measurements October 2008
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).
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).
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].
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].
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.
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.
6. IANA Considerations
6. IANA Considerations
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:
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:
URI: "urn:ietf:params:xml:ns:snmp-trace-1.0"
URI: "urn:ietf:params:xml:ns:snmp-trace-1.0"
Registrant Contact: The NMRG of the IRTF.
Registrant Contact: The NMRG of the IRTF.
XML: N/A, the URI is an XML namespace.
XML: N/A, the URI is an XML namespace.
7. Acknowledgements
7. Acknowledgements
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.
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.
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.
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.
Schoenwaelder Informational [Page 19] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 19] RFC 5345 SNMP Traffic Measurements October 2008
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 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.
Part of this work was funded by the European Commission under grant FP6-2004-IST-4-EMANICS-026854-NOE.
Part of this work was funded by the European Commission under grant FP6-2004-IST-4-EMANICS-026854-NOE.
8. References
8. References
8.1. Normative References
8.1. Normative References
[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., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[OASISRNG] Clark, J. and M. Makoto, "RELAX NG Specification",
OASIS Committee Specification, December 2001.
[OASISRNG] Clark, J. and M. Makoto, "RELAX NG Specification", OASIS Committee Specification, December 2001.
[OASISRNC] Clark, J., "RELAX NG Compact Syntax", OASIS Committee
Specification, November 2002.
[OASISRNC] Clark, J., "RELAX NG Compact Syntax", OASIS Committee Specification, November 2002.
[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., 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.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
8.2. Informative References
8.2. Informative References
[RFC1052] Cerf, V., "IAB Recommendations for the development of
Internet network management standards", RFC 1052,
April 1998.
[RFC1052] Cerf, V., "IAB Recommendations for the development of Internet network management standards", RFC 1052, April 1998.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579,
April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[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., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
Schoenwaelder Informational [Page 20] RFC 5345 SNMP Traffic Measurements October 2008
Schoenwaelder Informational [Page 20] RFC 5345 SNMP Traffic Measurements October 2008
[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., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002.
[RFC4022] Raghunarayan, R., "Management Information Base for the
Transmission Control Protocol (TCP)", RFC 4022,
March 2005.
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[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., and D. Quartel, "Comparing the Performance of SNMP and Web Services based Management", IEEE Transactions on Network and Service Management 1(2), November 2004.
[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., "A Study of the Behaviour of the Simple Network Management Protocol", Proc. 12th IFIP/IEEE Workshop on Distributed Systems: Operations and Management , October 2001.
[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., 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.
[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. and L. Tura, "Security Performance Analysis of SNMPv3 with Respect to SNMPv2c", Proc. 2004 IEEE/IFIP Network Operations and Management Symposium , April 2004.
[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., and A. Liotta, "On Management Technologies and the Potential of Web Services", IEEE Communications Magazine 42(7), July 2004.
[SM99] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of
MIB Data", Simple Times 7(1), March 1999.
[SM99] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of MIB Data", Simple Times 7(1), March 1999.
[Mal02] Malowidzki, M., "GetBulk Worth Fixing", Simple
Times 10(1), December 2002.
[Mal02] Malowidzki, M., "GetBulk Worth Fixing", Simple Times 10(1), December 2002.
[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アドレスAnonymization」IEEE/IFIPは操作と管理シンポジウムNOMS2006(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] シュー、J.、ファン、J.、およびM.Ammar、「IPを接頭語で保存して、Anonymizationを記述してください」 「測定ベースの機密保護評価と新しい暗号ベースの計画」、2002'年11月のネットワーク・プロトコルICNP'02に関する第10IEEE国際会議。
Schoenwaelder Informational [Page 21] RFC 5345 SNMP Traffic Measurements October 2008
[21ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
[FXAM04] Fan, J., Xu, J., Ammar, M., and S. Moon, "Prefix-
Preserving IP Address Anonymization", Computer
Networks 46(2), October 2004.
[FXAM04]ファン、J.、シュー、J.、Ammar、M.、およびS.は2004年10月に「接頭語はIPアドレスAnonymizationを保存すること」でのコンピュータネットワーク46(2)にお尻を出します。
[PAPL06] Pang, R., Allman, M., Paxson, V., and J. Lee, "The Devil
and Packet Trace Anonymization", Computer Communication
Review 36(1), January 2006.
[PAPL06] 心痛、R.、オールマン、M.、パクソン、V.、およびJ.リー、「悪魔とパケットはAnonymizationをたどる」コンピュータコミュニケーションが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] ネットワーク15(1)(2007年2月)におけるRamaswamyとR.とT.ヴォルフ、「受け身の測定システムのための接頭語を保存する高速IPアドレスAnonymization」IEEE取引。
URIs
URI
[1] <http://en.wikipedia.org/wiki/Pcap>
[1] <http://en.wikipedia.org/wiki/Pcap>。
[2] <http://www.tcpdump.org/>
[2] <http://www.tcpdump.org/>。
[3] <http://www.wireshark.org/>
[3] <http://www.wireshark.org/>。
[4] <http://www.datcat.org/>
[4] <http://www.datcat.org/>。
[5] <https://svn.eecs.jacobs-university.de/svn/schoenw/src/snmpdump>
[5] <https://svn.eecs.jacobs-university.de/svn/schoenw/src/snmpdump>。
[6] <http://xmlsoft.org/XSLT/>
[6] <http://xmlsoft.org/XSLT/>。
[7] <http://perl-xml.sourceforge.net/faq/>
[7] <http://パール-xml.sourceforge.net/faq/、>。
[8] <http://www.relaxng.org/>
[8] <http://www.relaxng.org/>。
Author's Address
作者のアドレス
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
ユルゲン・Schoenwaelderジェイコブズ・大学ブレーメンキャンパスリング1 28725ブレーメンドイツ
Phone: +49 421 200-3587 EMail: j.schoenwaelder@jacobs-university.de
以下に電話をしてください。 +49 421 200-3587 メールしてください: j.schoenwaelder@jacobs-university.de
Schoenwaelder Informational [Page 22] RFC 5345 SNMP Traffic Measurements October 2008
[22ページ]RFC5345SNMPトラフィック測定2008年10月の情報のSchoenwaelder
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 at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78と 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はどんな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に情報を記述してください。
Schoenwaelder Informational [Page 23]
Schoenwaelder情報です。[23ページ]
一覧
スポンサーリンク
