idnits 2.17.1 draft-ietf-rtfm-applicability-statement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 81 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2000) is 8834 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1272 (ref. 'ACT-BKG') ** Obsolete normative reference: RFC 2063 (ref. 'RTFM-ARC') (Obsoleted by RFC 2722) ** Obsolete normative reference: RFC 2064 (ref. 'RTFM-MIB') (Obsoleted by RFC 2720) -- Possible downref: Non-RFC (?) normative reference: ref. 'RTFM-NEW' ** Downref: Normative reference to an Informational RFC: RFC 2123 (ref. 'RTFM-NTM') -- Possible downref: Non-RFC (?) normative reference: ref. 'RTFM-SRL' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Nevil Brownlee 2 INTERNET-DRAFT The University of Auckland 4 August 1999 5 Expires February 2000 7 RTFM: Applicability Statement 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC 2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet Draft is a product of the Realtime Traffic Flow 32 Measurement Working Group of the IETF. 34 Abstract 36 This document provides an overview covering all aspects of Realtime 37 Traffic Flow Measurement, including its area of applicability and its 38 limitations. 40 Contents 42 1 The RTFM Documents 2 44 2 Brief Technical Specification (TS) 4 46 3 Applicability Statement (AS) 4 48 4 Limitations 5 50 5 Security Considerations 6 52 6 Policy Considerations 6 54 7 Soundness 7 56 8 Appendix A: WG Report on the Meter MIB 8 58 9 References 9 60 10 Author's Address 9 62 1 The RTFM Documents 64 The RTFM Traffic Measurement System has been developed by the Realtime 65 Traffic Flow Measurement Working Group. It is described in six other 66 documents, as follows: 68 [ACT-BKG] Internet Accounting: Background (Informational) 70 Sets out the requirements for a usage reporting system for 71 network traffic. Sketches out the RTFM Architecture (meters, 72 meter readers and managers) allowing for multiple meters 73 and meter readers, with asynchronous reading from the meters. 74 Proposes methods of classifying traffic flows, the need for 75 flows to be bi-directional (with separate sets of counters 76 for each direction) and the need for each packet to be counted 77 in a single flow (the 'count in one bucket' principle). 79 [RTFM-ARC] RTFM Architecture (Informational) 81 Defines the RTFM Architecture, giving descriptions of each 82 component. Explains how traffic flows are viewed as logical 83 entities described in terms of their address-attribute values, 84 so that each is defined by the attributes of its end-points. 85 Gives a detailed description of the RTFM traffic meter, with 86 full details of how flows are stored in the meter's flow table, 87 and how packets are matched in accordance with rules stored in 88 a ruleset. 90 [RTFM-MIB] RTFM Meter MIB (Proposed Standard) 92 Describes the SNMP Management Information Base for an RTFM 93 meter, including its flow table, rule table (storing the 94 meter's rulesets) and the control tables used for managing 95 a meter and reading flow data from it. 97 [RTFM-SRL] SRL: A Language for Describing Traffic (Informational) 98 Flows and Specifying Actions for Flow Groups 100 An RTFM ruleset is an array of rules, used by the meter to 101 decide which flows are of interest, which end-point is the 102 flow source, and how much detail (i.e. what attribute values) 103 must be saved for each flow. SRL is a high-level language 104 providing a clear, logical way to write rulesets. It should 105 also be useful for other applications which select flows 106 and perform actions upon them, e.g. packet-marking gateways, 107 RSVP policy agents, etc. 109 [RTFM-NEW] RTFM New Attributes (Experimental) 111 There has been considerable interest from users in extending 112 the RTFM Architecture so as to allow a meter to report on 113 an increased number of flow-related measures. This 114 RFC documents work on specifying such measures (the 'new' 115 attributes) and reports on experience of implementing them. 117 [RTFM-NTM] RTFM: Experiences with NeTraMet (Informational) 119 NeTraMet is a free software implementation of the RTFM 120 Architecture which has been available since 1993. This RFC 121 records RTFM implementation experience gained with NeTraMet 122 up to late 1996. One particularly important result is the 123 realisation that groups of rules which test the same attribute 124 using the same mask can be implemented as a single hashed 125 comparison, allowing the meter to rapidly determine whether a 126 packet belongs to one of a large number of networks. 128 2 Brief Technical Specification (TS) 130 RTFM provides for the measurement of network traffic 'flows,' i.e. 132 - a method of specifying traffic flows within 133 a network 134 - a hierarchy of devices (meters, meter readers, managers) 135 for measuring the specified flows 136 - a mechanism for configuring meters and meter readers, 137 and for collecting the flow data from remote meters 139 RTFM provides high time resolution for flow first- and last-packet 140 times. Counters for long-duration flows may be read at intervals 141 determined by a manager. The RTFM Meter is designed so as to do as much 142 data reduction work as possible, which minimizes the amount of data to 143 be read and the amount of processing needed to produce useful reports 144 from it. 146 RTFM flow data can be used for a wide range of purposes, such as usage 147 accounting, long-term recording of network usage (classified by IP 148 address attributes) and real-time analysis of traffic flows at remote 149 metering points. 151 3 Applicability Statement (AS) 153 To use RTFM for collecting network traffic information one must first 154 consider where in the network traffic flows are to be measured. Once 155 that is decided, an RTFM Meter must be installed at each chosen 156 measurement point. 158 At least one Meter Reader is needed to collect the measured data from 159 the meters, and a single Manager is needed to control the meters and 160 meter readers. 162 RTFM Meters may be single- or multi-user hosts running a meter program 163 (one such program is available as free software, a second is under 164 development at IBM Research). Alternatively, meters could be run as 165 firmware in switches or routers. A hybrid approach in which an RTFM 166 meter takes raw traffic data from a router provides another useful 167 implementation path. 169 RTFM Managers are programs running on a host, communicating with meters 170 and meter readers via the network. For this purpose meters are SNMP 171 agents implementing the RTFM Meter MIB, and managers are SNMP clients 172 using the Meter MIB to store and access the flow data. 174 4 Limitations 176 RTFM is designed to measure traffic flows for traffic passing a point in 177 a network. If packets for a flow pass the metering point in both 178 directions the meter will match them up, providing counters for each 179 direction. If packets only pass in one direction the meter can only 180 provide counts for that direction. 182 Users of RTFM should note that installing meters, meter readers and 183 managers merely provides one with the capability to collect flow data. 184 Further installation work will be needed to develop configuration files 185 (RTFM rulesets) for each meter, data processing applications to analyse 186 the flow data, and various scripts, cron jobs, etc. so as to create a 187 useful production-quality measurement system which suits a user's 188 particular needs. 190 One of the strengths of RTFM is its ability to collect flow data at 191 whatever level of detail (or 'granularity') is required. It can be 192 tempting to simply collect 'all possible data,' but there are severe 193 resource constraints. If one tries to save the complete 194 address-attribute value for all attributes of every possible flow a very 195 large amount of data may be produced rapidly, but the meter has only a 196 finite amount of memory for its flow table. A better approach is to 197 save the minimum amount of data required to achieve the measurement 198 system goals. 200 For example, to collect usage data so as to bill subscribers identified 201 by their IP address one could just save the full IP address, nothing 202 more. The RTFM meter would produce flow data for each subscriber IP 203 address, with PDU and Octet counts for data sent and received, which 204 would be the minimum needed to produce bills. In practice one would 205 probably want to save at least part of the Destination IP address, which 206 would allow the production of usage logs showing subscriber activity 207 over time. 209 The simplest way to determine how much detail can be collected is to 210 create an initial ruleset which collects the minimum amount, then to 211 modify it step by step, gradually increasing the amount of information 212 saved for each flow. An RTFM meter ought to provide some measures of 213 its own performance (e.g. number of active flows, percentage idle 214 processor time, packets metered, packets not metered). Such measures 215 will be implementation-specific, but should allow a user to assess the 216 impact of each change to the ruleset. 218 If the network data rate is too high, i.e. the meter reports that it 219 cannot meter all the packets even with the initial ruleset above, one 220 may be able to use other strategies. For example one could 221 - run the meter on a faster computer, e.g. move 222 from a DOS PC to a workstation, or perhaps use a 223 meter implemented in firmware within a switch or router. 225 - use sampling. The details of such sampling are not defined within 226 the RTFM Architecture, but the Meter MIB provides one simple 227 method by allowing one to specify that only every nth packet 228 on an interface will be metered. This would probably not be 229 acceptable for producing billing data, but might well be 230 acceptable for traffic engineering purposes. 232 5 Security Considerations 234 These are discussed in detail in the Architecture and Meter MIB 235 documents. In brief, an RTFM Meter is an SNMP agent which observes a 236 network and collects flow data from it. Since it doesn't control the 237 network directly, it has no direct effect on network security. 239 On the other hand, the flow data itself may well be valuable - to the 240 network operator (as billing data) or to an attacker (who may wish to 241 modify that data, or the meter's ruleset(s)). It is therefore important 242 to take proper precautions to ensure that access to the meter and its 243 data is sufficiently secure. 245 For example, a meter port attached to a network should be passive, so 246 that it cannot respond to login attempts of any kind. Control and data 247 connections to a meter should be via a secure management network. 248 Finally, suitable security should be established for the meter, as it 249 would be for any other SNMP agent. 251 Meters may, like any other network component, be subjected to Denial of 252 Service and other attacks. These are outside the RTFM Architecture - 253 countermeasures for them are available, but are also outside RTFM. 255 6 Policy Considerations 257 When collecting traffic data, one must have well-defined operations 258 policies covering points such as: 260 - Exactly what data is to be collected, at what level of detail? 261 - How long will the data be kept? 262 - What may the data be used for? 263 - Who will be allowed to see the raw data? 264 - May summaries of the data be shown to other people? 266 Policy issues such as these should normally be considered as part of an 267 organisation's Network Security Policy. 269 Other policy issues relating more directly to the traffic data are 270 essentially part of the measurement system design, such as: 272 - How much time resolution is required for the data? 273 (Less resolution implies longer collection intervals, 274 but that may require more memory in the meters to hold 275 flow data between collections). 277 - What level of hardware redundancy is needed? 278 (A single meter and meter reader is generally enough. 279 For greater reliability, meters and meter readers can be 280 duplicated). 282 - Who is allowed to use the system? (Approved users will need 283 permissions to download rulesets to the meters, and to 284 collect their data, possibly via their own meter readers). 286 7 Soundness 288 NeTraMet, the first implementation of the RTFM Architecture, has been in 289 use worldwide since 1994. Currently there are many organisations, large 290 and small, using it to collect traffic data for billing purposes. 292 One example of these is Kawaihiko, the New Zealand Universities' 293 Network, which has seven RTFM meters located at sites throughout New 294 Zealand. One of the sites is NZIX, the New Zealand Internet eXchange at 295 the University of Waikato, where Kawaihiko has a meter (attached to a 296 100baseT network) observing traffic flows across the exchange to each of 297 Kawaihiko's three international Internet Service Providers. 5-minute 298 Octet counts are collected from all the Kawaihiko meters by a single 299 meter reader at Auckland. Traffic data from the meters is used to 300 determine the cost per month for each of the Kawaihiko sites. 302 It is difficult to estimate how many organisations are using RTFM 303 traffic measurement. There are about 250 people on the NeTraMet mailing 304 list, which often carries questions like 'why doesn't this ruleset do 305 what I meant?' Once new users have the system running, however, they 306 tend to simply use it without further comment. 308 >From time to time the list provides useful feedback. For example, early 309 in 1998 there were two very significant user contributions: 311 - Jacek Kowalski (Telstra, Melbourne) described an improved hash 312 algorithm for NeTraMet's flow table, which provided almost an 313 order of magnitude improvement in packet-handling performance. 315 - Kevin Hoadley (JANET, U.K.) reported having problems with very 316 large rulesets. These were resolved, and better methods of 317 downloading rules developed, allowing NeTraMet to work well 318 for rulesets with more than 32,000 rules. 320 Perhaps one reason why there is little discussion of NeTraMet's use in 321 collecting billing data is that users may consider that the way collect 322 their data is a commercially sensitive matter. 324 8 Appendix A: WG Report on the Meter MIB 326 The Meter MIB (in its current form) was developed early in 1996. It was 327 produced as an SNMPv2 MIB, following a number of detailed (and 328 continuing) discussions with David Perkins beginning at the Dallas IETF 329 meeting in December 1995. 331 There are two current implementations: 333 - NeTraMet (Nevil Brownlee, The University of Auckland) 335 - IBM Meter (Sig Handelman & Stephen Stibler, IBM Research, N.Y, 336 Bert Wijnen provided further help with SNMP) 338 The NeTraMet meter is a stand-alone SNMP agent using an SNMPv2C 339 implementation derived from CMU SNMPv2. 341 The IBM meter runs as a sub-agent on an AIX system. All the meter code 342 has been written by Stephen Stibler - it was not derived from the 343 NeTraMet code. Stephen has found it useful to use nifty, one of 344 NeTraMet's manager/reader programs, to test the IBM meter. 346 As indicated above, there have only been two implementors to date, and 347 the Working Group consensus has been very strong. 349 The MIB has one unusual aspect: the method used to read large amounts 350 of data from its Flow Table. An earlier SNMPv1 version of the MIB was 351 in use from 1992 to 1997; it used opaque objects to read column slices 352 from the flow table for flows which had been active since a specified 353 time. This was very non-standard (or at least very 354 application-specific). 356 With the change to SNMPv2 we were able to use 64-bit counters for PDUs 357 and Octets, RowStatus variables for control tables and GETBULK requests 358 to read rows from the flow table. We also use the TimeFilter convention 359 from the RMON2 MIB to select flows to be read; this gives the meter MIB 360 a strong resemblance to RMON2. 362 The current MIB introduces a better way of reading large amounts of data 363 from the flow table. This is the 'DataPackage' convention, which 364 specifies the attribute values to be read from a flow table row. The 365 meter returns the values for each required attribute within a 366 BER-encoded sequence. This means there is only one object identifier 367 for the whole sequence, greatly reducing the number of bytes required to 368 retrieve the data. The combination of 370 TimeFilter: to select the flows to be read 371 DataPackage: to select the attributes required for each flow 372 GetBulk: to read many flows with a single SNMP PDU 374 provides a very effective way to read flow data from a traffic meter. 376 9 References 378 [ACT-BKG] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting 379 Background," RFC 1272, November 1991. 381 [RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow 382 Measurement: Architecture", RFC 2063, January 1997. 384 [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 385 RFC 2064, January 1997. 387 [RTFM-NEW] Handelman, S.W., Brownlee, N., Ruth, G., Stibler, S., 388 "New Attributes for Traffic Flow Measurment," Internet 389 Draft 'Work in progress' to become an Informational RFC 391 [RTFM-NTM] Brownlee, N., "Traffic Flow Measurement: Experiences with 392 NeTraMet," RFC 2123, March 1997. 394 [RTFM-SRL] Brownlee, N., "SRL: A Language for Describing Traffic 395 Flows and Specifying Actions for Flow Groups," Internet 396 Draft 'Work in progress' to become an Informational RFC 398 10 Author's Address 400 Nevil Brownlee 401 Information Technology Systems & Services 402 The University of Auckland 403 Private Bag 92-019 404 Auckland, New Zealand 406 Phone: +64 9 373 7599 x8941 407 E-mail: n.brownlee@auckland.ac.nz 409 Expires February 2000