From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2721.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc2721.txt (limited to 'doc/rfc/rfc2721.txt') diff --git a/doc/rfc/rfc2721.txt b/doc/rfc/rfc2721.txt new file mode 100644 index 0000000..404b928 --- /dev/null +++ b/doc/rfc/rfc2721.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group N. Brownlee +Request for Comments: 2721 The University of Auckland +Category: Informational October 1999 + + + RTFM: Applicability Statement + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + This document provides an overview covering all aspects of Realtime + Traffic Flow Measurement, including its area of applicability and its + limitations. + +Table of Contents + + 1 The RTFM Documents . . . . . . . . . . . . . . . . . . . . . . 2 + 2 Brief Technical Specification (TS) . . . . . . . . . . . . . . 3 + 3 Applicability Statement (AS) . . . . . . . . . . . . . . . . . 3 + 4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5 Security Considerations . . . . . . . . . . . . . . . . . . . 5 + 6 Policy Considerations . . . . . . . . . . . . . . . . . . . . 6 + 7 Soundness . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 8 Appendix A: WG Report on the Meter MIB . . . . . . . . . . . . 8 + 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 + 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 + + + + + + + + + + + + + + + +Brownlee Informational [Page 1] + +RFC 2721 RTFM: Applicability Statement October 1999 + + +1 The RTFM Documents + + The RTFM Traffic Measurement System has been developed by the + Realtime Traffic Flow Measurement Working Group. It is described in + six other documents, as follows: + + [ACT-BKG] Internet Accounting: Background (Informational) + + Sets out the requirements for a usage reporting system for network + traffic. Sketches out the RTFM Architecture (meters, meter + readers and managers) allowing for multiple meters and meter + readers, with asynchronous reading from the meters. Proposes + methods of classifying traffic flows, the need for flows to be + bi-directional (with separate sets of counters for each direction) + and the need for each packet to be counted in a single flow (the ' + count in one bucket' principle). + + [RTFM-ARC] RTFM Architecture (Informational) + + Defines the RTFM Architecture, giving descriptions of each + component. Explains how traffic flows are viewed as logical + entities described in terms of their address-attribute values, so + that each is defined by the attributes of its end-points. Gives a + detailed description of the RTFM traffic meter, with full details + of how flows are stored in the meter's flow table, and how packets + are matched in accordance with rules stored in a ruleset. + + [RTFM-MIB] RTFM Meter MIB (Proposed Standard) + + Describes the SNMP Management Information Base for an RTFM meter, + including its flow table, rule table (storing the meter's + rulesets) and the control tables used for managing a meter and + reading flow data from it. + + [RTFM-SRL] SRL: A Language for Describing Traffic (Informational) + Flows and Specifying Actions for Flow Groups + + An RTFM ruleset is an array of rules, used by the meter to decide + which flows are of interest, which end-point is the flow source, + and how much detail (i.e. what attribute values) must be saved for + each flow. SRL is a high-level language providing a clear, + logical way to write rulesets. It should also be useful for other + applications which select flows and perform actions upon them, + e.g. packet-marking gateways, RSVP policy agents, etc. + + + + + + + +Brownlee Informational [Page 2] + +RFC 2721 RTFM: Applicability Statement October 1999 + + + [RTFM-NEW] RTFM New Attributes (Experimental) + + There has been considerable interest from users in extending the + RTFM Architecture so as to allow a meter to report on an increased + number of flow-related measures. This RFC documents work on + specifying such measures (the 'new' attributes) and reports on + experience of implementing them. + + [RTFM-NTM] RTFM: Experiences with NeTraMet (Informational) + + NeTraMet is a free software implementation of the RTFM + Architecture which has been available since 1993. This RFC + records RTFM implementation experience gained with NeTraMet up to + late 1996. One particularly important result is the realisation + that groups of rules which test the same attribute using the same + mask can be implemented as a single hashed comparison, allowing + the meter to rapidly determine whether a packet belongs to one of + a large number of networks. + +2 Brief Technical Specification (TS) + + RTFM provides for the measurement of network traffic 'flows', i.e. + + - a method of specifying traffic flows within a network + - a hierarchy of devices (meters, meter readers, managers) for + measuring the specified flows + - a mechanism for configuring meters and meter readers, and for + collecting the flow data from remote meters + + RTFM provides high time resolution for flow first- and last-packet + times. Counters for long-duration flows may be read at intervals + determined by a manager. The RTFM Meter is designed so as to do as + much data reduction work as possible, which minimizes the amount of + data to be read and the amount of processing needed to produce useful + reports from it. + + RTFM flow data can be used for a wide range of purposes, such as + usage accounting, long-term recording of network usage (classified by + IP address attributes) and real-time analysis of traffic flows at + remote metering points. + +3 Applicability Statement (AS) + + To use RTFM for collecting network traffic information one must first + consider where in the network traffic flows are to be measured. Once + that is decided, an RTFM Meter must be installed at each chosen + measurement point. + + + + +Brownlee Informational [Page 3] + +RFC 2721 RTFM: Applicability Statement October 1999 + + + At least one Meter Reader is needed to collect the measured data from + the meters, and a single Manager is needed to control the meters and + meter readers. + + RTFM Meters may be single- or multi-user hosts running a meter + program (one such program is available as free software, a second is + under development at IBM Research). Alternatively, meters could be + run as firmware in switches or routers. A hybrid approach in which + an RTFM meter takes raw traffic data from a router provides another + useful implementation path. + + RTFM Managers are programs running on a host, communicating with + meters and meter readers via the network. For this purpose meters + are SNMP agents implementing the RTFM Meter MIB, and managers are + SNMP clients using the Meter MIB to store and access the flow data. + +4 Limitations + + RTFM is designed to measure traffic flows for traffic passing a point + in a network. If packets for a flow pass the metering point in both + directions the meter will match them up, providing counters for each + direction. If packets only pass in one direction the meter can only + provide counts for that direction. + + Users of RTFM should note that installing meters, meter readers and + managers merely provides one with the capability to collect flow + data. Further installation work will be needed to develop + configuration files (RTFM rulesets) for each meter, data processing + applications to analyse the flow data, and various scripts, cron + jobs, etc. so as to create a useful production-quality measurement + system which suits a user's particular needs. + + One of the strengths of RTFM is its ability to collect flow data at + whatever level of detail (or 'granularity') is required. It can be + tempting to simply collect 'all possible data', but there are severe + resource constraints. If one tries to save the complete address- + attribute value for all attributes of every possible flow a very + large amount of data may be produced rapidly, but the meter has only + a finite amount of memory for its flow table. A better approach is + to save the minimum amount of data required to achieve the + measurement system goals. + + For example, to collect usage data so as to bill subscribers + identified by their IP address one could just save the full IP + address, nothing more. The RTFM meter would produce flow data for + each subscriber IP address, with PDU and Octet counts for data sent + and received, which would be the minimum needed to produce bills. In + practice one would probably want to save at least part of the + + + +Brownlee Informational [Page 4] + +RFC 2721 RTFM: Applicability Statement October 1999 + + + Destination IP address, which would allow the production of usage + logs showing subscriber activity over time. + + The simplest way to determine how much detail can be collected is to + create an initial ruleset which collects the minimum amount, then to + modify it step by step, gradually increasing the amount of + information saved for each flow. An RTFM meter ought to provide some + measures of its own performance (e.g. number of active flows, + percentage idle processor time, packets metered, packets not + metered). Such measures will be implementation-specific, but should + allow a user to assess the impact of each change to the ruleset. + + If the network data rate is too high, i.e. the meter reports that it + cannot meter all the packets even with the initial ruleset above, one + may be able to use other strategies. For example one could + + - run the meter on a faster computer, e.g. move from a DOS PC to a + workstation, or perhaps use a meter implemented in firmware within + a switch or router. + + - use sampling. The details of such sampling are not defined within + the RTFM Architecture, but the Meter MIB provides one simple method + by allowing one to specify that only every nth packet on an + interface will be metered. This would probably not be acceptable + for producing billing data, but might well be acceptable for + traffic engineering purposes. + +5 Security Considerations + + These are discussed in detail in the Architecture and Meter MIB + documents. In brief, an RTFM Meter is an SNMP agent which observes a + network and collects flow data from it. Since it doesn't control the + network directly, it has no direct effect on network security. + + On the other hand, the flow data itself may well be valuable - to the + network operator (as billing data) or to an attacker (who may wish to + modify that data, or the meter's ruleset(s)). It is therefore + important to take proper precautions to ensure that access to the + meter and its data is sufficiently secure. + + For example, a meter port attached to a network should be passive, so + that it cannot respond to login attempts of any kind. Control and + data connections to a meter should be via a secure management + network. Finally, suitable security should be established for the + meter, as it would be for any other SNMP agent. + + + + + + +Brownlee Informational [Page 5] + +RFC 2721 RTFM: Applicability Statement October 1999 + + + Meters may, like any other network component, be subjected to Denial + of Service and other attacks. These are outside the RTFM + Architecture - countermeasures for them are available, but are also + outside RTFM. + +6 Policy Considerations + + When collecting traffic data, one must have well-defined operations + policies covering points such as: + + - Exactly what data is to be collected, at what level of detail? + - How long will the data be kept? + - What may the data be used for? + - Who will be allowed to see the raw data? + - May summaries of the data be shown to other people? + + Policy issues such as these should normally be considered as part of + an organisation's Network Security Policy. + + Other policy issues relating more directly to the traffic data are + essentially part of the measurement system design, such as: + + - How much time resolution is required for the data? + (Less resolution implies longer collection intervals, but that may + require more memory in the meters to hold flow data between + collections). + + - What level of hardware redundancy is needed? + (A single meter and meter reader is generally enough. For greater + reliability, meters and meter readers can be duplicated). + + - Who is allowed to use the system? + (Approved users will need permissions to download rulesets to the + meters, and to collect their data, possibly via their own meter + readers). + +7 Soundness + + NeTraMet, the first implementation of the RTFM Architecture, has been + in use worldwide since 1994. Currently there are many organisations, + large and small, using it to collect traffic data for billing + purposes. + + One example of these is Kawaihiko, the New Zealand Universities' + Network, which has seven RTFM meters located at sites throughout New + Zealand. One of the sites is NZIX, the New Zealand Internet eXchange + at the University of Waikato, where Kawaihiko has a meter (attached + to a 100baseT network) observing traffic flows across the exchange to + + + +Brownlee Informational [Page 6] + +RFC 2721 RTFM: Applicability Statement October 1999 + + + each of Kawaihiko's three international Internet Service Providers. + 5-minute Octet counts are collected from all the Kawaihiko meters by + a single meter reader at Auckland. Traffic data from the meters is + used to determine the cost per month for each of the Kawaihiko sites. + + It is difficult to estimate how many organisations are using RTFM + traffic measurement. There are about 250 people on the NeTraMet + mailing list, which often carries questions like 'why doesn't this + ruleset do what I meant'? Once new users have the system running, + however, they tend to simply use it without further comment. + + From time to time the list provides useful feedback. For example, + early in 1998 there were two very significant user contributions: + + - Jacek Kowalski (Telstra, Melbourne) described an improved hash + algorithm for NeTraMet's flow table, which provided almost an order + of magnitude improvement in packet-handling performance. + + - Kevin Hoadley (JANET, U.K.) reported having problems with very + large rulesets. These were resolved, and better methods of + downloading rules developed, allowing NeTraMet to work well for + rulesets with more than 32,000 rules. + + Perhaps one reason why there is little discussion of NeTraMet's use + in collecting billing data is that users may consider that the way + collect their data is a commercially sensitive matter. + + + + + + + + + + + + + + + + + + + + + + + + + +Brownlee Informational [Page 7] + +RFC 2721 RTFM: Applicability Statement October 1999 + + +8 Appendix A: WG Report on the Meter MIB + + The Meter MIB (in its current form) was developed early in 1996. It + was produced as an SNMPv2 MIB, following a number of detailed (and + continuing) discussions with David Perkins beginning at the Dallas + IETF meeting in December 1995. + + There are two current implementations: + + - NeTraMet (Nevil Brownlee, The University of Auckland) + + - IBM Meter (Sig Handelman & Stephen Stibler, IBM Research, N.Y, Bert + Wijnen provided further help with SNMP) + + The NeTraMet meter is a stand-alone SNMP agent using an SNMPv2C + implementation derived from CMU SNMPv2. + + The IBM meter runs as a sub-agent on an AIX system. All the meter + code has been written by Stephen Stibler - it was not derived from + the NeTraMet code. Stephen has found it useful to use nifty, one of + NeTraMet's manager/reader programs, to test the IBM meter. + + As indicated above, there have only been two implementors to date, + and the Working Group consensus has been very strong. + + The MIB has one unusual aspect: the method used to read large + amounts of data from its Flow Table. An earlier SNMPv1 version of + the MIB was in use from 1992 to 1997; it used opaque objects to read + column slices from the flow table for flows which had been active + since a specified time. This was very non-standard (or at least very + application-specific). + + With the change to SNMPv2 we were able to use 64-bit counters for + PDUs and Octets, RowStatus variables for control tables and GETBULK + requests to read rows from the flow table. We also use the + TimeFilter convention from the RMON2 MIB to select flows to be read; + this gives the meter MIB a strong resemblance to RMON2. + + The current MIB introduces a better way of reading large amounts of + data from the flow table. This is the 'DataPackage' convention, + which specifies the attribute values to be read from a flow table + row. The meter returns the values for each required attribute within + a BER-encoded sequence. This means there is only one object + identifier for the whole sequence, greatly reducing the number of + bytes required to retrieve the data. The combination of + + + + + + +Brownlee Informational [Page 8] + +RFC 2721 RTFM: Applicability Statement October 1999 + + + TimeFilter: to select the flows to be read + DataPackage: to select the attributes required for each flow + GetBulk: to read many flows with a single SNMP PDU + + provides a very effective way to read flow data from a traffic meter. + +9 References + + [ACT-BKG] Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting + Background", RFC 1272, November 1991. + + [RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow + Measurement: Architecture", RFC 2722, October 1999. + + [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC + 2720, October 1999. + + [RTFM-NEW] Handelman, S., Stibler, S., Brownlee, N. and G. Ruth, + "RTFM: New Attributes for Traffic Flow Measurement", RFC + 2724, October 1999. + + [RTFM-NTM] Brownlee, N., "Traffic Flow Measurement: Experiences with + NeTraMet", RFC 2123, March 1997. + + [RTFM-SRL] Brownlee, N., "SRL: A Language for Describing Traffic + Flows and Specifying Actions for Flow Groups", RFC 2723, + October 1999. + +10 Author's Address + + Nevil Brownlee + Information Technology Systems & Services + The University of Auckland + Private Bag 92-019 + Auckland, New Zealand + + Phone: +64 9 373 7599 x8941 + EMail: n.brownlee@auckland.ac.nz + + + + + + + + + + + + + +Brownlee Informational [Page 9] + +RFC 2721 RTFM: Applicability Statement October 1999 + + +11 Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Brownlee Informational [Page 10] + -- cgit v1.2.3