| < draft-schoenw-nrmg-snmp-measure-00.txt | draft-schoenw-nrmg-snmp-measure-01.txt > | |||
|---|---|---|---|---|
| NMRG J. Schoenwaelder | NMRG J. Schoenwaelder | |||
| Internet-Draft International University Bremen | Internet-Draft International University Bremen | |||
| Expires: June 12, 2006 December 9, 2005 | Expires: September 22, 2006 March 21, 2006 | |||
| SNMP Traffic Measurements | SNMP Traffic Measurements | |||
| draft-schoenw-nrmg-snmp-measure-00.txt | draft-schoenw-nrmg-snmp-measure-01.txt | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 33 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on June 12, 2006. | This Internet-Draft will expire on September 22, 2006. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2005). | Copyright (C) The Internet Society (2006). | |||
| Abstract | Abstract | |||
| The Simple Network Management Protocol (SNMP) is widely deployed to | The Simple Network Management Protocol (SNMP) is widely deployed to | |||
| monitor, control and configure network elements. Even though the | monitor, control and configure network elements. Even though the | |||
| SNMP technology is well documented, it remains unclear how SNMP is | SNMP technology is well documented, it remains relatively unclear how | |||
| used in practice and what typical SNMP usage patterns are. This | SNMP is used in practice and what typical SNMP usage patterns are. | |||
| document proposes to carry out large scale SNMP traffic measurements | This document proposes to carry out large scale SNMP traffic | |||
| in order to develop a better understanding how SNMP is used in real | measurements in order to develop a better understanding how SNMP is | |||
| world production networks. It describes the motivation, the | used in real world production networks. It describes the motivation, | |||
| measurement approach, and the tools and data formats needed to carry | the measurement approach, and the tools and data formats needed to | |||
| out such a study. | carry out such a study. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Measurement Approach . . . . . . . . . . . . . . . . . . . . . 4 | 2. Measurement Approach . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.1. Capturing Traffic Traces . . . . . . . . . . . . . . . . . 4 | 2.1. Capturing Traffic Traces . . . . . . . . . . . . . . . . . 4 | |||
| 2.2. Converting Traffic Traces . . . . . . . . . . . . . . . . 5 | 2.2. Converting Traffic Traces . . . . . . . . . . . . . . . . 5 | |||
| 2.3. Filtering Traffic Traces . . . . . . . . . . . . . . . . . 5 | 2.3. Filtering Traffic Traces . . . . . . . . . . . . . . . . . 6 | |||
| 2.4. Storing Traffic Traces . . . . . . . . . . . . . . . . . . 6 | 2.4. Storing Traffic Traces . . . . . . . . . . . . . . . . . . 6 | |||
| 2.5. Processing Traffic Traces . . . . . . . . . . . . . . . . 6 | 2.5. Processing Traffic Traces . . . . . . . . . . . . . . . . 7 | |||
| 3. Analysis of Traffic Traces . . . . . . . . . . . . . . . . . . 8 | 3. Analysis of Traffic Traces . . . . . . . . . . . . . . . . . . 8 | |||
| 3.1. Basic Statistics . . . . . . . . . . . . . . . . . . . . . 8 | 3.1. Basic Statistics . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.2. Periodic vs. Aperiodic Traffic . . . . . . . . . . . . . . 8 | 3.2. Periodic vs. Aperiodic Traffic . . . . . . . . . . . . . . 8 | |||
| 3.3. Message Size and Latency Distributions . . . . . . . . . . 8 | 3.3. Message Size and Latency Distributions . . . . . . . . . . 8 | |||
| 3.4. Concurrency Levels . . . . . . . . . . . . . . . . . . . . 8 | 3.4. Concurrency Levels . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.5. Table Retrieval Approaches . . . . . . . . . . . . . . . . 9 | 3.5. Table Retrieval Approaches . . . . . . . . . . . . . . . . 9 | |||
| 3.6. Trap-Directed Polling - Myths or Reality? . . . . . . . . 9 | 3.6. Trap-Directed Polling - Myths or Reality? . . . . . . . . 9 | |||
| 3.7. Popular MIB Modules . . . . . . . . . . . . . . . . . . . 9 | 3.7. Popular MIB Modules . . . . . . . . . . . . . . . . . . . 9 | |||
| 3.8. Usage of Obsolete Objects . . . . . . . . . . . . . . . . 9 | 3.8. Usage of Obsolete Objects . . . . . . . . . . . . . . . . 9 | |||
| 3.9. Encoding Length Distributions . . . . . . . . . . . . . . 10 | 3.9. Encoding Length Distributions . . . . . . . . . . . . . . 10 | |||
| 3.10. Counters and Discontinuities . . . . . . . . . . . . . . . 10 | 3.10. Counters and Discontinuities . . . . . . . . . . . . . . . 10 | |||
| 3.11. Spin Locks . . . . . . . . . . . . . . . . . . . . . . . . 10 | 3.11. Spin Locks . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 3.12. Row Creation . . . . . . . . . . . . . . . . . . . . . . . 10 | 3.12. Row Creation . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
| 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
| 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 | 6.2. Informative References . . . . . . . . . . . . . . . . . . 13 | |||
| Appendix A. RELAX NG Schema Definition . . . . . . . . . . . . . 16 | Appendix A. RELAX NG Schema Definition . . . . . . . . . . . . . 16 | |||
| Appendix B. Sample Perl Analysis Script . . . . . . . . . . . . . 19 | Appendix B. CSV Format Definition . . . . . . . . . . . . . . . . 19 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 | Appendix C. Sample Perl Analysis Script . . . . . . . . . . . . . 20 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 22 | Appendix D. Trace Description Form . . . . . . . . . . . . . . . 24 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 | ||||
| Intellectual Property and Copyright Statements . . . . . . . . . . 26 | ||||
| 1. Introduction | 1. Introduction | |||
| The Simple Network Management Protocol (SNMP) was introduced in the | The Simple Network Management Protocol (SNMP) was introduced in the | |||
| late 1980s [RFC1052] and has since then evolved to what is known | late 1980s [RFC1052] and has since then evolved to what is known | |||
| today as the SNMP version 3 Framework (SNMPv3) [RFC3410]. While SNMP | today as the SNMP version 3 Framework (SNMPv3) [RFC3410]. While SNMP | |||
| is widely deployed, it is not clear which features are being used, | is widely deployed, it is not clear which features are being used, | |||
| how SNMP usage differs in different types of networks or | how SNMP usage differs in different types of networks or | |||
| organizations, which information is frequently queried, and what | organizations, which information is frequently queried, and what | |||
| typical SNMP interactions patterns are in real world production | typical SNMP interactions patterns are in real world production | |||
| networks. | networks. | |||
| There have been several publications in the recent past dealing with | There have been several publications in the recent past dealing with | |||
| the performance of SNMP in general, the impact of SNMPv3 security or | the performance of SNMP in general [Pat01], the impact of SNMPv3 | |||
| the relative performance of SNMP compared to Web Services | security [DSR01][CT04], or the relative performance of SNMP compared | |||
| [PDMQ04][PFGL04]. While these papers are generally useful to better | to Web Services [PDMQ04][PFGL04]. While these papers are generally | |||
| understand the impact of various design decisions and technologies, | useful to better understand the impact of various design decisions | |||
| some of these papers lack a strong foundation because authors | and technologies, some of these papers lack a strong foundation | |||
| typically assume certain SNMP interaction patterns without having | because authors typically assume certain SNMP interaction patterns | |||
| experimental evidence that the assumptions are correct. In fact, | without having experimental evidence that the assumptions are | |||
| there are many speculations how SNMP is being used in real world | correct. In fact, there are many speculations how SNMP is being used | |||
| production networks and how it performs, but no systematic | in real world production networks and how it performs, but no | |||
| measurements have been performed and published so far. | systematic measurements have been performed and published so far. | |||
| Many authors use the ifTable of the IF-MIB [RFC2863] or the | Many authors use the ifTable of the IF-MIB [RFC2863] or the | |||
| tcpConnTable of the TCP-MIB [RFC4022] as a starting point for their | tcpConnTable of the TCP-MIB [RFC4022] as a starting point for their | |||
| analysis and comparison. Despite the fact that it is not even clear | analysis and comparison. Despite the fact that there is no evidence | |||
| that operations on these tables dominate SNMP traffic, it is even | that operations on these tables dominate SNMP traffic, it is even | |||
| more unclear how these tables are read and which optimizations are | more unclear how these tables are read and which optimizations are | |||
| done (or not done) by real world applications. It is also unclear | done (or not done) by real world applications. It is also unclear | |||
| what the actual traffic trade-off between periodic polling and more | what the actual traffic trade-off between periodic polling and more | |||
| aperiodic bulk data retrieval is. Furthermore, we do not generally | aperiodic bulk data retrieval is. Furthermore, we do not generally | |||
| understand how much traffic is devoted to standardized MIB objects | understand how much traffic is devoted to standardized MIB objects | |||
| and how much traffic deals with proprietary MIB objects and whether | and how much traffic deals with proprietary MIB objects and whether | |||
| the operation mix differs between those object classes or between | the operation mix differs between these object classes or between | |||
| different operational environments. | different operational environments. | |||
| This document describes an effort to collect SNMP traffic traces in | This document describes an effort to collect SNMP traffic traces in | |||
| order to find answers to some of these questions. It describes the | order to find answers to some of these questions. It describes the | |||
| tools that have been developed to allow network operators to collect | tools that have been developed to allow network operators to collect | |||
| traffic traces and to share them with research groups interested in | traffic traces and to share them with research groups interested in | |||
| analyzing and modeling network management interactions. | analyzing and modeling network management interactions. | |||
| 2. Measurement Approach | 2. Measurement Approach | |||
| This section outlines the process of doing SNMP traffic measurements | This section outlines the process of doing SNMP traffic measurements | |||
| and analysis. The process consists of the following basic steps: | and analysis. The process consists of the following five basic | |||
| steps: | ||||
| 1. Capture raw SNMP traffic traces in pcap capture files. | 1. Capture raw SNMP traffic traces in pcap capture files. | |||
| 2. Convert the raw traffic traces into a structured machine and | 2. Convert the raw traffic traces into a structured machine and | |||
| human readable format. A suitable XML schema has been developed | human readable format. A suitable XML schema has been developed | |||
| for this purpose. | for this purpose which captures all SNMP message details. In | |||
| addition, another more compact comma separated values (CSV) | ||||
| format has been developed which only keeps key information about | ||||
| SNMP messages. | ||||
| 3. Filter the converted traffic traces to hide or anonymize | 3. Filter the converted traffic traces to hide or anonymize | |||
| sensitive information. | 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. | ||||
| 4. Submit the filtered traffic traces to a repository from where | 4. Submit the filtered traffic traces to a repository from where | |||
| they can be retrieved and analyzed. Such a repository may be | they can be retrieved and analyzed. Such a repository may be | |||
| public, it may be under the control of a research group, or it | public, it may be under the control of a research group, or it | |||
| may be under the control of a network operator who commits to run | may be under the control of a network operator who commits to run | |||
| analysis scripts on the repository on behalf of researchers. | analysis scripts on the repository on behalf of researchers. | |||
| 5. Analyze the traces by creating and executing analysis scripts | 5. Analyze the traces by creating and executing analysis scripts | |||
| which extract and aggregate information. | which extract and aggregate information. | |||
| Several of the steps listed above require the involvement of network | Several of the steps listed above require the involvement of network | |||
| operators supporting the SNMP measurement projects. In many cases, | operators supporting the SNMP measurement projects. In many cases, | |||
| the filtered XML representation of the SNMP traces will be the | the filtered XML and CSV representation of the SNMP traces will be | |||
| binding interface between the researchers writing analysis scripts | the binding interface between the researchers writing analysis | |||
| and the operators involved in the measurement activity. It is | scripts and the operators involved in the measurement activity. It | |||
| therefore important to have a well defined specification of this | is therefore important to have a well defined specification of these | |||
| interfaces. | interfaces. | |||
| This section provides some advise and concrete hints how the steps | This section provides some advice and concrete hints how the steps | |||
| listed above can be carried out efficiently. Some special tools have | listed above can be carried out efficiently. Some special tools have | |||
| been developed to assist network operators and researchers so that | been developed to assist network operators and researchers so that | |||
| the time spend on supporting SNMP traffic measurement projects is | the time spent on supporting SNMP traffic measurement projects is | |||
| limited. The following sections describe the five steps and some | limited. The following sections describe the five steps and some | |||
| tools in more detail. | tools in more detail. | |||
| 2.1. Capturing Traffic Traces | 2.1. Capturing Traffic Traces | |||
| Capturing SNMP traffic traces can be done using packet sniffers such | Capturing SNMP traffic traces can be done using packet sniffers such | |||
| as tcpdump [1], ethereal, or similar applications. Note, care must | as tcpdump [1], ethereal [2], or similar applications. Somce care | |||
| be taken to specify filter expressions that match the SNMP transport | must be taken to specify pcap filter expressions that match the SNMP | |||
| endpoints used to carry SNMP traffic (typically 'udp and (port 161 or | transport endpoints used to carry SNMP traffic (typically 'udp and | |||
| port 162)'). Furthermore, it is necessary to ensure that packets are | (port 161 or port 162)'). Furthermore, it is necessary to ensure | |||
| not truncated (tcpdump option -s 0). Finally, it is necessary to | that full packets are capture, that is packets are not truncated | |||
| carefully select the placement of the probe within the network. | (tcpdump option -s 0). Finally, it is necessary to carefully select | |||
| Especially on bridged LANs, it is important to ensure that all | the placement of the capturing probe within the network. Especially | |||
| management traffic is captured and that the probe has access to all | on bridged LANs, it is important to ensure that all management | |||
| virtual LANs carrying management traffic. This usually requires to | traffic is captured and that the probe has access to all virtual LANs | |||
| place the probe(s) close to the management system(s) and to configure | carrying management traffic. This usually requires to place the | |||
| probe(s) close to the management system(s) and to configure dedicated | ||||
| monitoring ports on bridged networks. | monitoring ports on bridged networks. | |||
| It is recommended to capture at least a full week of data. Operators | It is recommended to capture at least a full week of data. Operators | |||
| are encourages to capture longer traffic traces. Tools such as | are encouraged to capture traces over even longer periods of time. | |||
| tcpslice [1] or pcapmerge [2] can be used to merge or split trace | Tools such as tcpslice [1] or pcapmerge [3] can be used to merge or | |||
| files as needed. | split pcap trace files as needed. | |||
| It is important to note that the raw pcap files should be kept in | It is important to note that the raw pcap files should be kept in | |||
| stable storage (e.g., compressed and encrypted on a CD ROM or DVD). | stable storage (e.g., compressed and encrypted on a CD ROM or DVD). | |||
| To verify measurements, it might be necessary to go back to the | To verify measurements, it might be necessary to go back to the | |||
| original pcap files if for example bugs in the tools described below | original pcap files if for example bugs in the tools described below | |||
| have been detected and fixed. | have been detected and fixed. | |||
| For each captured trace, some meta information should be recorded and | ||||
| made available. Appendix D contains a simple ASCII form that is | ||||
| suggested to be used to describe some basic meta data associated with | ||||
| a traffic trace. | ||||
| 2.2. Converting Traffic Traces | 2.2. Converting Traffic Traces | |||
| Raw traffic traces in pcap format must be converted into a format | Raw traces in pcap format must be converted into a format that is (a) | |||
| that is (a) human readable and (b) machine readable for efficient | human readable and (b) machine readable for efficient post- | |||
| post-processing. Human readability makes it easy for an operator to | processing. Human readability makes it easy for an operator to | |||
| verify that no sensitive data is left in a traffic trace while | verify that no sensitive data is left in a trace while machine | |||
| machine readability is needed to efficiently extract relevant | readability is needed to efficiently extract relevant information. | |||
| information. | ||||
| The natural choice here is to use an XML format since XML is human as | 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 | well as machine readable and there are many tools and high-level | |||
| scripting language programming interfaces that can be used to process | scripting language application programming interfaces (APIs) that can | |||
| XML documents and to extract meaningful information. | be used to process XML documents and to extract meaningful | |||
| information. However, it should be noted that 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. | ||||
| Appendix A of this document defines a RELAX NG [3] schema for | Appendix A of this document defines a [OASISRNG] schema for | |||
| representing SNMP traffic traces in XML. The schema captures all | representing SNMP traffic traces in XML. The schema captures all | |||
| relevant details of an SNMP messages in the XML format. Note that | relevant details of an SNMP messages in the XML format. Note that | |||
| the XML format retains some information about the original ASN.1/BER | the XML format retains some information about the original ASN.1/BER | |||
| encoding to support message size analysis. | encoding to support message size analysis. | |||
| A lightweight alternative to the full blown XML representation based | ||||
| on comma separated values (CSV) is defined in Appendix B. The CSV | ||||
| format only captures the most essential parts of SNMP messages and is | ||||
| thus more compact and faster to process. | ||||
| The snmpdump [4] package has been developed to convert raw pcap files | The snmpdump [4] package has been developed to convert raw pcap files | |||
| into the XML format. The snmpdump program reads pcap files and | into XML and CSV format. The snmpdump program reads either pcap | |||
| produces an XML document which lists the details of the SNMP packets | files or XML files as input and produces XML files or CSV files as | |||
| contained in the traffic trace. The implementation is able to | output. Specific elements can be filtered if that is required to | |||
| correctly deal with IPv4 fragments. | protect sensitive data. The current snmpdump implementation is able | |||
| to correctly deal with IPv4 fragments. | ||||
| 2.3. Filtering Traffic Traces | 2.3. Filtering Traffic Traces | |||
| Filtering sensitive data can be achieved by manipulating the XML | Filtering sensitive data can be achieved by manipulating the XML | |||
| representation of an SNMP trace. Standard XSLT processors such as | representation of an SNMP trace. Standard XSLT processors such as | |||
| xsltproc [5] can be used for this purpose. People familiar with Perl | xsltproc [5] can be used for this purpose. People familiar with Perl | |||
| might also be interested in using the XML::LibXML [6] Perl package to | might also be interested in using the XML::LibXML [6] Perl package to | |||
| manipulate XML documents from within Perl. | manipulate XML documents from within Perl. | |||
| The snmpdump program can filter out sensitive information, e.g., by | The snmpdump program can filter out sensitive information, e.g., by | |||
| deleting or "zeroing" all XML elements matching XPATH expressions. | deleting or clearing all XML elements whose name matches a regular | |||
| The snmpanon program shipped as part of the snmpdump package | expression. Work is in progress to provide data type specific | |||
| implements the same filtering capabilities of snmpdump and allows in | anonymization transformations that maintain lexicographic ordering | |||
| addition to anonymize (portions of) SNMP messages. Work is in | for values that appear in instance identifiers [HS06]. | |||
| progress to provide data type specific anonymization transformations | ||||
| that maintain lexicographic ordering for values that appear in | ||||
| instance identifiers [HS06]. | ||||
| 2.4. Storing Traffic Traces | 2.4. Storing Traffic Traces | |||
| The pcap traces together with the XML formatted traces should be | The pcap traces together with the XML / CSV formatted traces should | |||
| stored in an archive or repository. Such an archive or repository | be stored in a stable archive or repository. Such an archive or | |||
| might either be maintained by research groups (e.g., the NMRG) or by | repository might either be maintained by research groups (e.g., the | |||
| operators. It is, however, of key importance that captured traces | NMRG) or by network operators. It is of key importance that captured | |||
| are not lost or modified as they form the basis of future research | traces are not lost or modified as they may form the basis of future | |||
| projects and may also be needed to verify published research results. | research projects and may also be needed to verify published research | |||
| Access to the archive might be restricted to those who have signed | results. Access to the archive might be restricted to those who have | |||
| some sort of a non-disclosure agreement. | signed some sort of a non-disclosure agreement. | |||
| Note that lossless compression algorithms embodied in programs such | Lossless compression algorithms embodied in programs such as gzip or | |||
| as gzip or bzip2 can be used to compress even large trace files down | bzip2 can be used to compress even large trace files down to a size | |||
| to a size where they can be burned on DVDs for cheap longterm | where they can be burned on DVDs for cheap longterm storage. | |||
| storage. | ||||
| It should be stressed again here that it is important to keep the | It must be stressed again that it is important to keep the original | |||
| original pcap traces in addition to the XML formatted traces as they | pcap traces in addition to the XML / CSV formatted traces since the | |||
| are the most authentic source of information. Improvements in the | pcap traces are the most authentic source of information. | |||
| tool chain may require to go back to the original pcap traces and to | ||||
| rebuild all intermediate formats from them. | Improvements in the tool chain may require to go back to the original | |||
| pcap traces and to rebuild all intermediate formats from them. | ||||
| 2.5. Processing Traffic Traces | 2.5. Processing Traffic Traces | |||
| Scripts that analyze traffic traces must be verified for correctness. | Scripts that analyze traffic traces must be verified for correctness. | |||
| Ideally, all scripts used to analyze traffic traces would be | Ideally, all scripts used to analyze traffic traces would be | |||
| publically accessible so that third parties can verify them. | publically accessible so that third parties can verify them. | |||
| Furthermore, sharing scripts will enable other parties to repeat an | Furthermore, sharing scripts will enable other parties to repeat an | |||
| analysis on other traffic traces and to extend such analysis scripts. | analysis on other traffic traces and to extend such analysis scripts. | |||
| A common versioned repository for analysis scripts might be useful to | ||||
| establish. | ||||
| Due to the availability of XML parsers, trace files can be processed | Due to the availability of XML parsers and the simplicity of the CSV | |||
| with tools written in almost any programming language. However, in | format, trace files can be processed with tools written in almost any | |||
| order to facilitate a common vocabulary and to allow operators to | programming language. However, in order to facilitate a common | |||
| easily read scripts they execute on trace files, it is suggested that | vocabulary and to allow operators to easily read scripts they execute | |||
| analysis scripts are written in the Perl programming language using | on trace files, it is suggested that analysis scripts are written in | |||
| the XML::LibXML [6] Perl package to read the XML format of the trace | the Perl programming language using the XML::LibXML [6] Perl package | |||
| files. Using a scripting language such as Perl instead of system | to read the XML format of the trace files. Using a scripting | |||
| programming languages such as C or C++ has the advantage to reduce | language such as Perl instead of system programming languages such as | |||
| development time and to make scripts more accessible to operators who | C or C++ has the advantage to reduce development time and to make | |||
| may want to verify scripts before running them on trace files which | scripts more accessible to operators who may want to verify scripts | |||
| potentially contain sensitive data. | before running them on trace files which potentially contain | |||
| sensitive data. | ||||
| Appendix B show a simple Perl script which computes some summary | Appendix C show a simple Perl script which computes some summary | |||
| statistics. | statistics. | |||
| It should be noted here that 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 to deal with very large traces efficiently. | ||||
| 3. Analysis of Traffic Traces | 3. Analysis of Traffic Traces | |||
| This section discusses several questions that can be answered by | This section discusses several questions that can be answered by | |||
| analyzing SNMP traffic traces. The questions raised in the following | analyzing SNMP traffic traces. The questions raised in the following | |||
| subsections are meant to be illustrative and no attempt has been made | subsections are meant to be illustrative and no attempt has been made | |||
| to provide a complete list. | to provide a complete list. | |||
| 3.1. Basic Statistics | 3.1. Basic Statistics | |||
| Basic statistics cover things such as the SNMP protocol versions used | Basic statistics cover things such as the SNMP protocol versions used | |||
| or the protocol operations used in a traffic trace. In addition, a | or the protocol operations used in a traffic trace. In addition, a | |||
| rough classification of the data manipulated into 'standardized', | rough classification of the data manipulated into 'standardized', | |||
| 'proprietary', and 'experimental' can be done. Appendix B contains a | 'proprietary', and 'experimental' can be done. Appendix C contains a | |||
| simple analysis script deriving some of these very basic statistics | simple analysis script deriving some of these very basic statistics | |||
| from a traffic trace. | from a traffic trace. | |||
| 3.2. Periodic vs. Aperiodic Traffic | 3.2. Periodic vs. Aperiodic Traffic | |||
| SNMP is used to periodically poll devices as well as to retrieve | SNMP is used to periodically poll devices as well as to retrieve | |||
| information on request of an operator or application. The periodic | information on request of an operator or application. The periodic | |||
| polling leads to periodic traffic pattern while the on demand | polling leads to periodic traffic patterns while the on demand | |||
| information retrieval causes more aperiodic traffic pattern. It is | information retrieval causes more aperiodic traffic patterns. It is | |||
| worthwhile to understand what the relationship is between the amount | worthwhile to understand what the relationship is between the amount | |||
| of periodic and aperiodic traffic. In addition, it will be | of periodic and aperiodic traffic. In addition, it will be | |||
| interesting to research whether there are multiple levels of | interesting to research whether there are multiple levels of | |||
| periodicity at different time scales. | periodicity at different time scales. | |||
| 3.3. Message Size and Latency Distributions | 3.3. Message Size and Latency Distributions | |||
| SNMP messages are size constrained by the transport mappings used and | SNMP messages are size constrained by the transport mappings used and | |||
| the buffers provided by the SNMP engines. For the further evolution | the buffers provided by the SNMP engines. For the further evolution | |||
| of the SNMP framework, it would be useful to know what the actual | of the SNMP framework, it would be useful to know what the actual | |||
| message size distributions are. In addition, it would be useful to | message size distributions are. In addition, it would be useful to | |||
| understand the latency distributions, especially the distribution of | understand the latency distributions, especially the distribution of | |||
| the processing times by SNMP command responders. Some SNMP | the processing times by SNMP command responders. Some SNMP | |||
| implementations approximate networking delays by measuring request- | implementations approximate networking delays by measuring request- | |||
| response times and it would be useful to understand to what extend | response times and it would be useful to understand to what extent | |||
| this is a viable approach. | this is a viable approach. | |||
| 3.4. Concurrency Levels | 3.4. Concurrency Levels | |||
| SNMP allows management stations to retrieve information from multiple | SNMP allows management stations to retrieve information from multiple | |||
| agents concurrently. It will be interesting to identify what the | agents concurrently. It will be interesting to identify what the | |||
| typical concurrency level is that can be observed on production | typical concurrency level is that can be observed on production | |||
| networks or whether management applications prefer more sequential | networks or whether management applications prefer more sequential | |||
| ways of retrieving data. | ways of retrieving data. | |||
| skipping to change at page 9, line 17 ¶ | skipping to change at page 9, line 17 ¶ | |||
| Tables can be read in several different ways. The simplest and most | Tables can be read in several different ways. The simplest and most | |||
| inefficient approach is to retrieve tables cell-by-cell in column-by- | inefficient approach is to retrieve tables cell-by-cell in column-by- | |||
| column order. More advanced approaches try to read tables row-by-row | column order. More advanced approaches try to read tables row-by-row | |||
| or even multiple-rows-by-multiple-rows. In addition, the retrieval | or even multiple-rows-by-multiple-rows. In addition, the retrieval | |||
| of index elements can be suppressed in most cases. It will be useful | of index elements can be suppressed in most cases. It will be useful | |||
| to know which of these approaches are actually used on production | to know which of these approaches are actually used on production | |||
| networks. | networks. | |||
| 3.6. Trap-Directed Polling - Myths or Reality? | 3.6. Trap-Directed Polling - Myths or Reality? | |||
| SNMP is build around a concept called trap-directed polling. | SNMP is built around a concept called trap-directed polling. | |||
| Management applications are responsible to periodically poll SNMP | Management applications are responsible to periodically poll SNMP | |||
| agents to determine their status. SNMP agents can in addition send | agents to determine their status. SNMP agents can in addition send | |||
| traps to notify SNMP managers about events so that SNMP managers can | traps to notify SNMP managers about events so that SNMP managers can | |||
| adopt their polling strategy and basically react faster than normal | adopt their polling strategy and basically react faster than normal | |||
| polling would allow to do. | polling would allow to do. | |||
| Analysis of SNMP traffic traces can identity whether trap-directed | Analysis of SNMP traffic traces can identity whether trap-directed | |||
| polling is actually deployed. In particular, the question that | polling is actually deployed. In particular, the question that | |||
| should be addressed is whether SNMP notifications lead to changes in | should be addressed is whether SNMP notifications lead to changes in | |||
| the short-term polling behavior of management stations. In | the short-term polling behavior of management stations. In | |||
| particular, it should be investigated to which extend SNMP managers | particular, it should be investigated to what extent SNMP managers | |||
| use automated procedures to track down the meaning of the event | use automated procedures to track down the meaning of the event | |||
| conveyed by an SNMP notification. | conveyed by an SNMP notification. | |||
| 3.7. Popular MIB Modules | 3.7. Popular MIB Modules | |||
| An analysis of object identifier prefixes can identify the most | An analysis of object identifier prefixes can identify the most | |||
| popular MIB modules and the most important object types or | popular MIB modules and the most important object types or | |||
| notification types defined by these modules. Such information would | notification types defined by these modules. Such information would | |||
| be very valuable for the further maintenance and development of these | be very valuable for the further maintenance and development of these | |||
| and related MIB modules. | and related MIB modules. | |||
| skipping to change at page 10, line 19 ¶ | skipping to change at page 10, line 19 ¶ | |||
| are sometimes used to estimate SNMP message sizes in order to meet | are sometimes used to estimate SNMP message sizes in order to meet | |||
| transport and buffer size constraints. | transport and buffer size constraints. | |||
| 3.10. Counters and Discontinuities | 3.10. Counters and Discontinuities | |||
| Counters can experience discontinuities [RFC2578]. The default | Counters can experience discontinuities [RFC2578]. The default | |||
| discontinuity indicator is the sysUpTime scalar of the SNMPv2-MIB | discontinuity indicator is the sysUpTime scalar of the SNMPv2-MIB | |||
| [RFC3418], which can also be used to detect counter roll-overs. Some | [RFC3418], which can also be used to detect counter roll-overs. Some | |||
| MIB modules introduce more specific discontinuity indicators, e.g., | MIB modules introduce more specific discontinuity indicators, e.g., | |||
| the ifCounterDiscontinuityTime of the IF-MIB [RFC2863]. It will be | the ifCounterDiscontinuityTime of the IF-MIB [RFC2863]. It will be | |||
| interesting to study to which extend these objects are actually used | interesting to study to what extent these objects are actually used | |||
| by management applications to handle discontinuity events. | by management applications to handle discontinuity events. | |||
| 3.11. Spin Locks | 3.11. Spin Locks | |||
| Cooperating command generators can use advisory locks to coordinate | Cooperating command generators can use advisory locks to coordinate | |||
| their usage of SNMP write operations. The snmpSetSerialNo scalar of | their usage of SNMP write operations. The snmpSetSerialNo scalar of | |||
| the SNMPv2-MIB [RFC3418] is the default course-grain coordination | the SNMPv2-MIB [RFC3418] is the default course-grain coordination | |||
| object. It will interesting to find out whether there are command | object. It will be interesting to find out whether there are command | |||
| generators which coordinate themself using these spin locks. | generators which 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 | Row creation is an operation not natively supported by the protocol | |||
| operations. Instead, conceptual tables supporting row creation | operations. Instead, conceptual tables supporting row creation | |||
| typically provide a control column which uses the RowStatus textual | typically provide a control column which uses the RowStatus textual | |||
| convention defined in the SNMPv2-TC module. The RowStatus itself | convention defined in the SNMPv2-TC module. The RowStatus itself | |||
| supports different row creation modes, namely dribble-mode and one- | supports different row creation modes, namely createAndWait (dribble- | |||
| shot mode. In addition, different approaches can be used to derive | mode) and createAndGo (one-shot mode). In addition, different | |||
| the instance identifier if it does not have special semantics | approaches can be used to derive the instance identifier if it does | |||
| associated. It will be useful to study which of the various row | not have special semantics associated. It will be useful to study | |||
| creation approaches are actually used by management applications on | which of the various row creation approaches are actually used by | |||
| production networks. | management applications on production networks. | |||
| 4. Security Considerations | 4. Security Considerations | |||
| SNMP traffic traces usually contain sensitive information. It is | SNMP traffic traces usually contain sensitive information. It is | |||
| therefore necessary to (a) remove unneeded information and (b) to | therefore necessary to (a) remove unneeded information and (b) to | |||
| anonymize the remaining necessary information before traces are made | anonymize the remaining necessary information before traces are made | |||
| available for analysis. | available for analysis. | |||
| Implementations that generate XML traces from raw pcap files should | Implementations that generate XML traces from raw pcap files should | |||
| have an option to suppress values. Note that instance identifiers of | have an option to suppress values. Note that instance identifiers of | |||
| tables also include values and it might therefore be necessary to | tables also include values and it might therefore be necessary to | |||
| suppress (parts of) the instance identifiers. Similarly, the packet | suppress (parts of) the instance identifiers. Similarly, the packet | |||
| and message headers typically contain sensitive information about the | and message headers typically contain sensitive information about the | |||
| source and destination of SNMP messages as well as authentication | source and destination of SNMP messages as well as authentication | |||
| information (community strings or user names). | information (community strings or user names). | |||
| Anonymization techniques can be applied to keep some more information | Anonymization techniques can be applied to keep more information in | |||
| in anonymized traces. This should follow the filter-in principle | traces which could reveal sensitive information. When using | |||
| which says that only values are added when their data type is known | anonymization, values should only be added when the underlying data | |||
| and an appropriate anonymization transformation is available. For | type is known and an appropriate anonymization transformation is | |||
| values appearing in instance identifiers, it is usually desirable to | available (filter-in principle). For values appearing in instance | |||
| maintain the lexicographic order. Special anonymization | identifiers, it is usually desirable to maintain the lexicographic | |||
| transformations which preserve this property have been developed, | order. Special anonymization transformations which preserve this | |||
| although their anonymization strength is usually reduced compared to | property have been developed, although their anonymization strength | |||
| transformations that do not preserve lexicographic ordering. | is usually reduced compared to transformations that do not preserve | |||
| lexicographic ordering [HS06]. | ||||
| 5. Acknowledgements | 5. Acknowledgements | |||
| This document was influenced by discussions within the Network | This document was influenced by discussions within the Network | |||
| Management Research Group (NMRG). Special thanks to Remco van de | Management Research Group (NMRG). Special thanks to Remco van de | |||
| Meent for writing the initial Perl script that lead to the script | Meent for writing the initial Perl script that lead to the script in | |||
| shown in the Appendix and Matus Harvan for his work on lexicographic | Appendix C and Matus Harvan for his work on lexicographic order | |||
| order preserving anonymization transformations. Aiko Pras | preserving anonymization transformations. Aiko Pras contributed | |||
| contributed to the section which describes sample questions that can | ideas to Section 3 while David Harrington helped to improve the | |||
| be answered by SNMP traffic measurements. | readability of this document. | |||
| Part of this work was funded by the European Commission under grant | ||||
| FP6-2004-IST-4-EMANICS-026854-NOE. | ||||
| 6. References | 6. References | |||
| 6.1. Normative References | 6.1. Normative References | |||
| [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, | [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, | |||
| "Structure of Management Information Version 2 (SMIv2)", | "Structure of Management Information Version 2 (SMIv2)", | |||
| STD 58, RFC 2578, April 1999. | STD 58, RFC 2578, April 1999. | |||
| [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An | [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An | |||
| skipping to change at page 13, line 28 ¶ | skipping to change at page 13, line 28 ¶ | |||
| [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. | [RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. | |||
| Waldbusser, "Version 2 of the Protocol Operations for the | Waldbusser, "Version 2 of the Protocol Operations for the | |||
| Simple Network Management Protocol (SNMP)", STD 62, | Simple Network Management Protocol (SNMP)", STD 62, | |||
| RFC 3416, December 2002. | RFC 3416, December 2002. | |||
| [RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. | [RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. | |||
| Waldbusser, "Management Information Base (MIB) for the | Waldbusser, "Management Information Base (MIB) for the | |||
| Simple Network Management Protocol (SNMP)", STD 62, | Simple Network Management Protocol (SNMP)", STD 62, | |||
| RFC 3418, December 2002. | RFC 3418, December 2002. | |||
| [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. | ||||
| 6.2. Informative References | 6.2. Informative References | |||
| [RFC1052] Cerf, V., "IAB Recommendations for the Development of | [RFC1052] Cerf, V., "IAB Recommendations for the Development of | |||
| Internet Network Management Standards", RFC 1052, | Internet Network Management Standards", RFC 1052, | |||
| April 1998. | April 1998. | |||
| [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for | ||||
| the Internet Protocol using SMIv2", RFC 2011, | ||||
| November 1996. | ||||
| [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group | ||||
| MIB", RFC 2863, June 2000. | ||||
| [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, | [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, | |||
| "Introduction and Applicability Statements for Internet | "Introduction and Applicability Statements for Internet | |||
| Standard Management Framework", RFC 3410, December 2002. | Standard Management Framework", RFC 3410, December 2002. | |||
| [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol | ||||
| (SNMP) over Transmission Control Protocol (TCP) Transport | ||||
| Mapping", RFC 3430, December 2002. | ||||
| [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, | [PDMQ04] Pras, A., Drevers, T., van de Meent, R., and D. Quartel, | |||
| "Comparing the Performance of SNMP and Web Services based | "Comparing the Performance of SNMP and Web Services based | |||
| Management", IEEE electronic Transactions on Network and | Management", IEEE electronic Transactions on Network and | |||
| Service Management 1(2), November 2004. | 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. | ||||
| [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. | ||||
| [PFGL04] Pavlou, G., Flegkas, P., Gouveris, S., and A. Liotta, "On | [PFGL04] Pavlou, G., Flegkas, P., Gouveris, S., and A. Liotta, "On | |||
| Management Technologies and the Potential of Web | Management Technologies and the Potential of Web | |||
| Services", IEEE Communications Magazine 42(7), July 2004. | Services", IEEE Communications Magazine 42(7), July 2004. | |||
| [STBULK] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of MIB | [SM99] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of MIB | |||
| Data", Simple Times 7(1), March 1999. | Data", Simple Times 7(1), March 1999. | |||
| [STBUMP] Malowidzki, M., "GetBulk Worth Fixing", Simple | [Mal02] Malowidzki, M., "GetBulk Worth Fixing", Simple | |||
| Times 10(1), December 2002. | Times 10(1), December 2002. | |||
| [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group | ||||
| MIB", RFC 2863, June 2000. | ||||
| [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for | ||||
| the Internet Protocol using SMIv2", RFC 2011, | ||||
| November 1996. | ||||
| [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol | ||||
| (SNMP) over Transmission Control Protocol (TCP) Transport | ||||
| Mapping", RFC 3430, December 2002. | ||||
| [RFC4022] Raghunarayan, R., "Management Information Base for the | ||||
| Transmission Control Protocol (TCP)", RFC 4022, | ||||
| March 2005. | ||||
| [HS06] Harvan, M. and J. Schoenwaelder, "Prefix- and | [HS06] Harvan, M. and J. Schoenwaelder, "Prefix- and | |||
| Lexicographical-order-preserving IP Address | Lexicographical-order-preserving IP Address | |||
| Anonymization", IEEE/IFIP Network Operations and | Anonymization", IEEE/IFIP Network Operations and | |||
| Management Symposium NOMS 2006, April 2006. | Management Symposium NOMS 2006, April 2006. | |||
| URIs | URIs | |||
| [1] <http://www.tcpdump.org/> | [1] <http://www.tcpdump.org/> | |||
| [2] <http://indev.insu.com/Fwctl/pcapmerge.html> | [2] <http://www.ethereal.com/> | |||
| [3] <http://www.relaxng.org/> | [3] <http://indev.insu.com/Fwctl/pcapmerge.html> | |||
| [4] <https://subversion.eecs.iu-bremen.de/svn/schoenw/src/snmpdump> | [4] <https://subversion.eecs.iu-bremen.de/svn/schoenw/src/snmpdump> | |||
| [5] <http://xmlsoft.org/XSLT/> | [5] <http://xmlsoft.org/XSLT/> | |||
| [6] <http://www.cpan.org/> | [6] <http://www.cpan.org/> | |||
| [7] <http://www.relaxng.org/> | ||||
| Appendix A. RELAX NG Schema Definition | Appendix A. RELAX NG Schema Definition | |||
| 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 [7] can be | ||||
| used to convert RELAX NG compact syntax to other XML schema | ||||
| notations. | ||||
| start = | start = | |||
| element snmptrace { | element snmptrace { | |||
| packet.elem* | packet.elem* | |||
| } | } | |||
| packet.elem = | packet.elem = | |||
| element packet { | element packet { | |||
| attribute date { xsd:dateTime }, | attribute sec { xsd:unsignedInt }, | |||
| attribute delta { xsd:unsignedInt }, | attribute usec { xsd:unsignedInt }, | |||
| element src { addr.attrs }, | element src { addr.attrs }, | |||
| element dst { addr.attrs }, | element dst { addr.attrs }, | |||
| snmp.elem | snmp.elem | |||
| } | } | |||
| snmp.elem = | snmp.elem = | |||
| element snmp { | element snmp { | |||
| length.attrs?, | length.attrs?, | |||
| message.elem | message.elem | |||
| } | } | |||
| message.elem = | message.elem = | |||
| element version { length.attrs, xsd:int }, | element version { length.attrs, xsd:int }, | |||
| element community { length.attrs, text }, | element community { length.attrs, xsd:hexBinary }, | |||
| pdu.elem | pdu.elem | |||
| message.elem |= | message.elem |= | |||
| element version { length.attrs, xsd:int }, | element version { length.attrs, xsd:int }, | |||
| element message { | element message { | |||
| length.attrs, | length.attrs, | |||
| element msg-id { length.attrs, xsd:unsignedInt }, | element msg-id { length.attrs, xsd:unsignedInt }, | |||
| element max-size { length.attrs, xsd:unsignedInt }, | element max-size { length.attrs, xsd:unsignedInt }, | |||
| element flags { length.attrs, text }, | element flags { length.attrs, xsd:hexBinary }, | |||
| element security-model { length.attrs, xsd:unsignedInt }, | element security-model { length.attrs, xsd:unsignedInt } | |||
| usm.elem? | ||||
| }, | }, | |||
| usm.elem?, | ||||
| element scoped-pdu { | element scoped-pdu { | |||
| length.attrs, | length.attrs, | |||
| element context-engine-id { length.attrs, text }, | element context-engine-id { length.attrs, xsd:hexBinary }, | |||
| element context-name { length.attrs, text }, | element context-name { length.attrs, xsd:string }, | |||
| pdu.elem | pdu.elem | |||
| } | } | |||
| usm.elem = | usm.elem = | |||
| element auth-engine-id { length.attrs, text }, | element usm { | |||
| element auth-engine-boots { length.attrs, xsd:unsignedInt }, | length.attrs, | |||
| element auth-engine-time { length.attrs, xsd:unsignedInt }, | element auth-engine-id { length.attrs, xsd:hexBinary }, | |||
| element user { length.attrs, text }, | element auth-engine-boots { length.attrs, xsd:unsignedInt }, | |||
| element auth-params { length.attrs, text }, | element auth-engine-time { length.attrs, xsd:unsignedInt }, | |||
| element priv-params { length.attrs, text } | element user { length.attrs, xsd:hexBinary }, | |||
| element auth-params { length.attrs, xsd:hexBinary }, | ||||
| element priv-params { length.attrs, xsd:hexBinary } | ||||
| } | ||||
| pdu.elem = | pdu.elem = | |||
| element trap { | element trap { | |||
| length.attrs, | length.attrs, | |||
| element enterprise { length.attrs, oid.type }, | element enterprise { length.attrs, oid.type }, | |||
| element agent-addr { length.attrs, ipaddress.type }, | element agent-addr { length.attrs, ipaddress.type }, | |||
| element generic-trap { length.attrs, xsd:int }, | element generic-trap { length.attrs, xsd:int }, | |||
| element specific-trap { length.attrs, xsd:int }, | element specific-trap { length.attrs, xsd:int }, | |||
| element time-stamp { length.attrs, xsd:int }, | element time-stamp { length.attrs, xsd:int }, | |||
| element variable-bindings { length.attrs, varbind.elem* } | element variable-bindings { length.attrs, varbind.elem* } | |||
| skipping to change at page 17, line 42 ¶ | skipping to change at page 17, line 51 ¶ | |||
| name.elem = | name.elem = | |||
| element name { length.attrs, oid.type } | element name { length.attrs, oid.type } | |||
| value.elem = | value.elem = | |||
| element null { length.attrs, empty } | | element null { length.attrs, empty } | | |||
| element integer32 { length.attrs, xsd:int } | | element integer32 { length.attrs, xsd:int } | | |||
| element unsigned32 { length.attrs, xsd:unsignedInt } | | element unsigned32 { length.attrs, xsd:unsignedInt } | | |||
| element unsigned64 { length.attrs, xsd:unsignedLong } | | element unsigned64 { length.attrs, xsd:unsignedLong } | | |||
| element ipaddress { length.attrs, ipaddress.type } | | element ipaddress { length.attrs, ipaddress.type } | | |||
| element octet-string { length.attrs, text } | | element octet-string { length.attrs, xsd:hexBinary } | | |||
| element object-identifier { length.attrs, oid.type } | | element object-identifier { length.attrs, oid.type } | | |||
| element (no-such-object | no-such-instance | end-of-mib-view) { empty } | | element (no-such-object | no-such-instance | end-of-mib-view) { empty } | |||
| element value { empty } | ||||
| # The blen attribute indicates the number of bytes used by the BER | # The blen attribute indicates the number of bytes used by the BER | |||
| # encoded tag / length / value triple. The vlen attribute indicates | # encoded tag / length / value triple. The vlen attribute indicates | |||
| # the number of bytes used by the BER encoded value alone. | # the number of bytes used by the BER encoded value alone. | |||
| length.attrs = | length.attrs = | |||
| ( attribute blen { xsd:unsignedShort }, | ( attribute blen { xsd:unsignedShort }, | |||
| attribute vlen { xsd:unsignedShort } )? | attribute vlen { xsd:unsignedShort } )? | |||
| addr.attrs = | addr.attrs = | |||
| attribute ip { ipaddress.type }, | attribute ip { ipaddress.type }, | |||
| attribute port { xsd:unsignedShort } | attribute port { xsd:unsignedShort } | |||
| oid.type = | oid.type = | |||
| xsd:string { | xsd:string { | |||
| pattern = | pattern = | |||
| """[0-2](\.[0-9]+)+""" | """[0-2](\.[0-9]+)+""" | |||
| } | } | |||
| # [XXX] We should extend the regular expression below to cover also | ||||
| # IPv6 addresses (including zone indexes ;-). | ||||
| ipaddress.type = | ipaddress.type = | |||
| xsd:string { | xsd:string { | |||
| pattern = | pattern = | |||
| """[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*""" | """[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*""" | |||
| } | } | |||
| Appendix B. Sample Perl Analysis Script | Appendix B. CSV Format Definition | |||
| The CSV format has been design to capture only the most relevant | ||||
| information about an SNMP message. The CSV format uses the following | ||||
| fields: | ||||
| 1. Time-stamp in the format seconds.microseconds since 1970, for | ||||
| example "1137764769.425484". | ||||
| 2. Source IP address in dotted quad notation (IPv4), for example | ||||
| "127.0.0.1", or compact hexadecimal notation (IPv6), for example | ||||
| "::1". | ||||
| 3. Source port number represented as a decimal number, for example | ||||
| "4242". | ||||
| 4. Destination IP address in dotted quad notation (IPv4), for | ||||
| example "127.0.0.1", or compact hexadecimal notation (IPv6), for | ||||
| example "::1". | ||||
| 5. Destination port number represented as a decimal number, for | ||||
| example "161". | ||||
| 6. Size of the SNMP message (a decimal number) counted in bytes, | ||||
| 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". | ||||
| 8. SNMP protocol operation indicated by one of the keywords get- | ||||
| request, get-next-request, get-bulk-request, set-request, trap, | ||||
| trap2, inform, response, report. | ||||
| 9. SNMP request-id in decimal notation, for example "1511411010". | ||||
| 10. SNMP error-status 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". | ||||
| 13. Object names given as object identifiers in dotted decimal | ||||
| notation, for example "1.3.6.1.2.1.1.3.0". Object names are | ||||
| separated by commas. | ||||
| Appendix C. Sample Perl Analysis Script | ||||
| [XXX] This script probably should go away since it does not scale at | ||||
| all. It seems that we can provide perhaps a series of simple scripts | ||||
| that operate on the CSV format to produce something meaningful. | ||||
| #!/usr/bin/perl | #!/usr/bin/perl | |||
| # This script computes basic statistics from SNMP packet trace files. | # This script computes basic statistics from SNMP packet trace files. | |||
| # | # | |||
| # To run this script: | # To run this script: | |||
| # snmpstat.pl [<filename>] | # snmpstat.pl [<filename>] | |||
| # | # | |||
| # (c) 2002 Remco van de Meent <remco@vandemeent.net> | # (c) 2002 Remco van de Meent <remco@vandemeent.net> | |||
| # (c) 2005 Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> | # (c) 2005 Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> | |||
| skipping to change at page 20, line 37 ¶ | skipping to change at page 21, line 41 ¶ | |||
| printf "%18s: %5d %3d\%\n", "mib-2", | printf "%18s: %5d %3d\%\n", "mib-2", | |||
| $mib2_ctr, ($mib2_ctr/$oid_ctr*100); | $mib2_ctr, ($mib2_ctr/$oid_ctr*100); | |||
| printf "%18s: %5d %3d\%\n", "experimental", | printf "%18s: %5d %3d\%\n", "experimental", | |||
| $experiment_ctr, ($experiment_ctr/$oid_ctr*100); | $experiment_ctr, ($experiment_ctr/$oid_ctr*100); | |||
| printf "%18s: %5d %3d\%\n", "enterprises", | printf "%18s: %5d %3d\%\n", "enterprises", | |||
| $enterprise_ctr, ($enterprise_ctr/$oid_ctr*100); | $enterprise_ctr, ($enterprise_ctr/$oid_ctr*100); | |||
| printf " ---------------------------\n"; | printf " ---------------------------\n"; | |||
| printf "%18s: %5d %3d\%\n\n", "total", $oid_ctr, 100; | printf "%18s: %5d %3d\%\n\n", "total", $oid_ctr, 100; | |||
| } | } | |||
| sub size_stats { | ||||
| my $doc = shift; | ||||
| my @total = $doc->findnodes('//packet/snmp'); | ||||
| printf "SNMP message size statistics:\n\n"; | ||||
| foreach my $op ("get-request", "get-next-request", "get-bulk-request", | ||||
| "set-request", "trap", "trap-v2", "inform", | ||||
| "response", "report") { | ||||
| my $total_ops = 0; | ||||
| my $total_len = 0; | ||||
| foreach my $node ($doc->findnodes("//packet/snmp/$op")) { | ||||
| my @msg_len = $node->find('../@blen'); | ||||
| $total_ops++; | ||||
| # $total_len += $msg_len[0]; | ||||
| # printf "\t%d\t%d\n", @msg_len, $total_len; | ||||
| } | ||||
| printf "%18s: %5d %5d %f\n", $op, $total_ops, $total_len, $total_ops ? $total_len/$total_ops : 0; | ||||
| } | ||||
| printf "\n"; | ||||
| } | ||||
| sub min { | ||||
| if ($_[0]>$_[1]) {return $_[1]} else {return $_[0]}; | ||||
| } | ||||
| sub max { | ||||
| if ($_[0]<$_[1]) {return $_[1]} else {return $_[0]}; | ||||
| } | ||||
| sub varbind_stats { | ||||
| my $doc = shift; | ||||
| my @total = $doc->findnodes('//packet/snmp'); | ||||
| printf "SNMP varbind number statistics:\n\n"; | ||||
| foreach my $op ("get-request", "get-next-request", "get-bulk-request", | ||||
| "set-request", "trap", "trap-v2", "inform", | ||||
| "response", "report") { | ||||
| my ($total_ops, $total_vbs, $total_vbs_min, $total_vbs_max); | ||||
| foreach my $node ($doc->findnodes("//packet/snmp/$op")) { | ||||
| my @varbinds = $node->findnodes("variable-bindings/varbind"); | ||||
| $total_ops++; | ||||
| $total_vbs += $#varbinds + 1; | ||||
| $total_vbs_min = min($total_vbs_min, $#varbinds + 1); | ||||
| $total_vbs_max = max($total_vbs_max, $#varbinds + 1); | ||||
| } | ||||
| printf "%18s: %5d %5d %5.2f %5d %5d\n", $op, $total_ops, $total_vbs, $total_ops ? $total_vbs/$total_ops : 0, $total_vbs_min, $total_vbs_max; | ||||
| } | ||||
| printf "\n"; | ||||
| } | ||||
| @ARGV = ('-') unless @ARGV; | @ARGV = ('-') unless @ARGV; | |||
| while ($ARGV = shift) { | while ($ARGV = shift) { | |||
| my $parser = XML::LibXML->new(); | my $parser = XML::LibXML->new(); | |||
| my $tree = $parser->parse_file($ARGV); | my $tree = $parser->parse_file($ARGV); | |||
| my $doc = $tree->getDocumentElement; | my $doc = $tree->getDocumentElement; | |||
| version_stats($doc); | version_stats($doc); | |||
| operation_stats($doc); | operation_stats($doc); | |||
| oid_stats($doc); | oid_stats($doc); | |||
| size_stats($doc); | ||||
| varbind_stats($doc); | ||||
| } | } | |||
| exit(0); | exit(0); | |||
| Appendix D. Trace Description Form | ||||
| The following ASCII form is suggested to keep track of meta | ||||
| information associated with a traffic trace. | ||||
| Name: [name of the trace] | ||||
| Network: [name of the network] | ||||
| Organization: [name of the organization operating the network] | ||||
| Contact: [name and email address of a contact person] | ||||
| Start-Date: [date in ISO date format] | ||||
| End-Date: [date in ISO date format] | ||||
| Size: [size of the pcap trace in bytes] | ||||
| Description: [description, multiple lines with white space indentation] | ||||
| Author's Address | Author's Address | |||
| Juergen Schoenwaelder | Juergen Schoenwaelder | |||
| International University Bremen | International University Bremen | |||
| Campus Ring 1 | Campus Ring 1 | |||
| 28725 Bremen | 28725 Bremen | |||
| Germany | Germany | |||
| Phone: +49 421 200-3587 | Phone: +49 421 200-3587 | |||
| Email: j.schoenwaelder@iu-bremen.de | Email: j.schoenwaelder@iu-bremen.de | |||
| skipping to change at page 22, line 41 ¶ | skipping to change at page 26, line 41 ¶ | |||
| This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |||
| ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |||
| INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
| Copyright Statement | Copyright Statement | |||
| Copyright (C) The Internet Society (2005). This document is subject | Copyright (C) The Internet Society (2006). This document is subject | |||
| to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
| except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
| Acknowledgment | Acknowledgment | |||
| Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
| Internet Society. | Internet Society. | |||
| End of changes. 68 change blocks. | ||||
| 166 lines changed or deleted | 351 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||