draft-ietf-rtfm-applicability-statement-00.txt   draft-ietf-rtfm-applicability-statement-01.txt 
Internet Engineering Task Force Nevil Brownlee Internet Engineering Task Force Nevil Brownlee
INTERNET-DRAFT The University of Auckland INTERNET-DRAFT The University of Auckland
September 1998 October 1998
RTFM: Applicability Statement RTFM: Applicability Statement
<draft-ietf-rtfm-applicability-statement-00.txt> <draft-ietf-rtfm-applicability-statement-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet-Drafts. This Internet Draft is a product of the documents as Internet-Drafts. This Internet Draft is a product of the
Realtime Traffic Flow Measurement Working Group of the IETF. Realtime Traffic Flow Measurement Working Group of the IETF.
Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts are draft documents valid for a maximum of six months.
skipping to change at page 2, line ? skipping to change at page 2, line ?
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document provides an overview covering all aspects of Realtime This document provides an overview covering all aspects of Realtime
Traffic Flow Measurement, including its area of applicability and its Traffic Flow Measurement, including its area of applicability and its
limitations. limitations.
Contents Contents
1 The RTFM Documents . . . . . . . . . . . . . . . 2 1 The RTFM Documents 2
2 Brief Technical Specification (TS) . . . . . . . . . . 3 2 Brief Technical Specification (TS) 3
3 Applicability Statement (AS) . . . . . . . . . . . . 4 3 Applicability Statement (AS) 4
4 Limitations . . . . . . . . . . . . . . . . . . 5 4 Limitations 4
5 Security Considerations . . . . . . . . . . . . . . 6 5 Security Considerations 6
6 Policy Considerations . . . . . . . . . . . . . . 6 6 Policy Considerations 6
7 Soundness . . . . . . . . . . . . . . . . . . 7 7 Soundness 7
8 Appendix A: WG Report on the Meter MIB . . . . . . . . . 8 8 Appendix A: WG Report on the Meter MIB 8
9 References . . . . . . . . . . . . . . . . . . 9 9 References 9
10 Author's Address . . . . . . . . . . . . . . . . 9 10 Author's Address 9
1 The RTFM Documents 1 The RTFM Documents
The RTFM Traffic Measurement System has been developed by the Realtime The RTFM Traffic Measurement System has been developed by the Realtime
Traffic Flow Measurement Working Group. It is described in six other Traffic Flow Measurement Working Group. It is described in six other
documents (references [1] to [6]), as follows: documents (references [1] to [6]), as follows:
[1] Internet Accounting: Background (Informational) [1] Internet Accounting: Background (Informational)
Sets out the requirements for a usage reporting system for Sets out the requirements for a usage reporting system for
skipping to change at page 4, line 5 skipping to change at page 4, line 5
RTFM provides for the measurement of network traffic 'flows,' i.e. RTFM provides for the measurement of network traffic 'flows,' i.e.
- a method of specifying traffic flows within - a method of specifying traffic flows within
a network a network
- a hierarchy of devices (meters, meter readers, managers) - a hierarchy of devices (meters, meter readers, managers)
for measuring the specified flows for measuring the specified flows
- a mechanism for configuring meters and meter readers, - a mechanism for configuring meters and meter readers,
and for collecting the flow data from remote meters and for collecting the flow data from remote meters
The RTFM Meter is designed so as to do as much data reduction work as RTFM provides high time resolution for flow first- and last-packet
possible. This minimizes the amount of data to be read and the amount times. Counters for long-duration flows may be read at intervals
of processing needed to produce useful reports from it. 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 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 accounting, long-term recording of network usage (classified by IP
address attributes) and real-time analysis of traffic flows at remote address attributes) and real-time analysis of traffic flows at remote
metering points. metering points.
3 Applicability Statement (AS) 3 Applicability Statement (AS)
To use RTFM for collecting network traffic information one must first To use RTFM for collecting network traffic information one must first
consider where in the network traffic flows are to be measured. Once consider where in the network traffic flows are to be measured. Once
skipping to change at page 4, line 32 skipping to change at page 4, line 35
the meters, and a single Manager is needed to control the meters and the meters, and a single Manager is needed to control the meters and
meter readers. meter readers.
RTFM Meters may be single- or multi-user hosts running a meter program 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 (one such program is available as free software, a second is under
development at IBM Research). Alternatively, meters could be run as development at IBM Research). Alternatively, meters could be run as
firmware in switches or routers. A hybrid approach in which an RTFM firmware in switches or routers. A hybrid approach in which an RTFM
meter takes raw traffic data from a router provides another useful meter takes raw traffic data from a router provides another useful
implementation path. implementation path.
RTFM Managers are programs running on a Unix host, communicating with RTFM Managers are programs running on a host, communicating with meters
meters and meter readers via the network. In principle any protocol and meter readers via the network. For this purpose meters are SNMP
could be used for this, but current implementations use the RTFM Meter agents implementing the RTFM Meter MIB, and managers are SNMP clients
MIB to store and access the flow data. This will require networks using using the Meter MIB to store and access the flow data.
RTFM to implement the IP protocol so as to send and receive SNMP
requests carried in UDP datagrams.
As indicated above, a meter must support SNMP over UDP. If it runs on a
dedicated host it must also respond to ARP requests. To aid in
troubleshooting, it should respond to ICMP echo (ping) requests. These
remarks also apply to RTFM Meter Readers and Managers.
(The paragraphs above describe the current implementations of RTFM. Its
architecture is not limited to having the meter be an SNMP agent - other
communication and storage methods could be used. For example,
configuration data could be downloaded via FTP, data could be stored in
an SQL database and meter readers could get it via SQL requests.)
4 Limitations 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 Users of RTFM should note that installing meters, meter readers and
managers merely provides one with the capability to collect flow data. managers merely provides one with the capability to collect flow data.
Further installation work will be needed to develop configuration files Further installation work will be needed to develop configuration files
(RTFM rulesets) for each meter, data processing applications to analyse (RTFM rulesets) for each meter, data processing applications to analyse
the flow data, and various scripts, cron jobs, etc. so as to create a the flow data, and various scripts, cron jobs, etc. so as to create a
useful production-quality measurement system which suits a user's useful production-quality measurement system which suits a user's
particular needs. particular needs.
One of the strengths of RTFM is its ability to collect flow data at 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 whatever level of detail (or 'granularity') is required. It can be
tempting to simply collect 'all possible data,' but there are severe tempting to simply collect 'all possible data,' but there are severe
resource constraints. If one tries to save the complete resource constraints. If one tries to save the complete
address-attribute value for all attributes of every possible flow a address-attribute value for all attributes of every possible flow a very
'combinatorial explosion' of data may result, but the meter has only a 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 finite amount of memory for its flow table. A better approach is to
save the minimum amount of data required to achieve the measurement save the minimum amount of data required to achieve the measurement
system goals. system goals.
For example, to collect usage data so as to bill subscribers identified 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 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 more. The RTFM meter would produce flow data for each subscriber IP
address, with PDU and Octet counts for data sent and received, which address, with PDU and Octet counts for data sent and received, which
would be the minimum needed to produce bills. In practice one would would be the minimum needed to produce bills. In practice one would
probably want to save at least part of the Destination IP address, which probably want to save at least part of the Destination IP address, which
would allow the production of usage logs showing subscriber activity would allow the production of usage logs showing subscriber activity
over time. over time.
The simplest way to determine how much detail can be collected is to The simplest way to determine how much detail can be collected is to
create an initial ruleset which collects the minimum amount, then to create an initial ruleset which collects the minimum amount, then to
modify it step by step, gradually increasing the amount of information modify it step by step, gradually increasing the amount of information
saved for each flow. An RTFM meter will provide some measures of its saved for each flow. An RTFM meter ought to provide some measures of
own performance (e.g. number of active flows, percentage idle processor its own performance (e.g. number of active flows, percentage idle
time, packets metered, packets not metered) allowing one to assess the 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. impact of each change to the ruleset.
If the network data rate is too high, i.e. the meter reports that it 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 cannot meter all the packets even with the initial ruleset above, one
may be able to use other strategies. For example one could may be able to use other strategies. For example one could
- run the meter on a faster computer, e.g. move - run the meter on a faster computer, e.g. move
from a DOS PC to a Unix workstation, or perhaps use a from a DOS PC to a workstation, or perhaps use a
meter implemented in firmware within a switch or router. meter implemented in firmware within a switch or router.
- use sampling. The Meter MIB allows one to specify that - use sampling. The details of such sampling are not defined within
only every nth packet on an interface will be metered. the RTFM Architecture, but the Meter MIB provides one simple
This would probably not be acceptable for producing billing method by allowing one to specify that only every nth packet
data, but might well be acceptable for traffic engineering on an interface will be metered. This would probably not be
purposes. acceptable for producing billing data, but might well be
acceptable for traffic engineering purposes.
5 Security Considerations 5 Security Considerations
These are discussed in detail in the Architecture and Meter MIB These are discussed in detail in the Architecture and Meter MIB
documents. In brief, an RTFM Meter is an SNMP agent which observes a documents. In brief, an RTFM Meter is an SNMP agent which observes a
network and collects flow data from is. Since it doesn't control the network and collects flow data from it. Since it doesn't control the
network directly, it has no direct effect on network security. network directly, it has no direct effect on network security.
On the other hand, the flow data may well be valuable - to the network On the other hand, the flow data itself may well be valuable - to the
operator (as billing data) or to an attacker (who may wish to modify network operator (as billing data) or to an attacker (who may wish to
that data, or the meter's ruleset(s). It is therefore important to take modify that data, or the meter's ruleset(s). It is therefore important
proper precautions to ensure that access to the meter and its data is to take proper precautions to ensure that access to the meter and its
sufficiently secure. data is sufficiently secure.
For example, a meter port attached to a network should be passive, so 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 that it cannot respond to login attempts of any kind. Control and data
connections to a meter should be via a secure management network. connections to a meter should be via a secure management network.
Finally, suitable security should be established for the meter, as it Finally, suitable security should be established for the meter, as it
would be for any other SNMP agent. would be for any other SNMP agent.
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 6 Policy Considerations
When collecting traffic data, one must have well-defined operations When collecting traffic data, one must have well-defined operations
policies covering points such as: policies covering points such as:
- Exactly what data is to be collected, at what level of detail? - Exactly what data is to be collected, at what level of detail?
- How long will the data be kept? - How long will the data be kept?
- What may the data be used for? - What may the data be used for?
- Who will be allowed to see the raw data? - Who will be allowed to see the raw data?
- May summaries of the data be shown to other people? - May summaries of the data be shown to other people?
Policy issues such as these should normally be considered as part of an Policy issues such as these should normally be considered as part of an
organisation's Network Security Policy. organisation's Network Security Policy.
Other policy issues relating more directly to the traffic data are Other policy issues relating more directly to the traffic data are
essentially part of the measurement system design, such as: essentially part of the measurement system design, such as:
- How much time resolution is required for the data? - How much time resolution is required for the data?
(Less resolution allows longer collection intervals, (Less resolution implies longer collection intervals,
but that requires more memory in the meters). but that may require more memory in the meters to hold
flow data between collections).
- What level of hardware redundancy is needed? - What level of hardware redundancy is needed?
(A single meter and meter reader is generally enough. For (A single meter and meter reader is generally enough.
greater reliability, meters and meter readers can be duplicated). For greater reliability, meters and meter readers can be
duplicated).
- Who is allowed to use the system? (Approved users will need - Who is allowed to use the system? (Approved users will need
permissions to download rulesets to the meters, and to permissions to download rulesets to the meters, and to
collect their data, possibly via their own meter readers). collect their data, possibly via their own meter readers).
7 Soundness 7 Soundness
NeTraMet, the first implementation of the RTFM Architecture, has been in NeTraMet, the first implementation of the RTFM Architecture, has been in
use worldwide since 1994. Currently there are many organisations, large use worldwide since 1994. Currently there are many organisations, large
and small, using it to collect traffic data for billing purposes. and small, using it to collect traffic data for billing purposes.
skipping to change at page 7, line 50 skipping to change at page 8, line 5
- Kevin Hoadley (JANET, U.K.) reported having problems with very - Kevin Hoadley (JANET, U.K.) reported having problems with very
large rulesets. These were resolved, and better methods of large rulesets. These were resolved, and better methods of
downloading rules developed, allowing NeTraMet to work well downloading rules developed, allowing NeTraMet to work well
for rulesets with more than 32,000 rules. for rulesets with more than 32,000 rules.
Perhaps one reason why there is little discussion of NeTraMet's use in 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 collecting billing data is that users may consider that the way collect
their data is a commercially sensitive matter. their data is a commercially sensitive matter.
We believe the fact that users are developing improvements to NeTraMet
and communicating them via the mailing list certainly demonstrates that
they are using it for real-world work!
8 Appendix A: WG Report on the Meter MIB 8 Appendix A: WG Report on the Meter MIB
The Meter MIB (in its current form) was developed early in 1996. It was 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 produced as an SNMPv2 MIB, following a number of detailed (and
continuing) discussions with David Perkins beginning at the Dallas IETF continuing) discussions with David Perkins beginning at the Dallas IETF
meeting in December 1995. meeting in December 1995.
There are two current implementations: There are two current implementations:
- NeTraMet (Nevil Brownlee, The University of Auckland) - NeTraMet (Nevil Brownlee, The University of Auckland)
skipping to change at page 9, line 22 skipping to change at page 9, line 18
provides a very effective way to read flow data from a traffic meter. provides a very effective way to read flow data from a traffic meter.
9 References 9 References
[1] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting [1] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting
Background", RFC 1272, Bolt Beranek and Newman Inc., Background", RFC 1272, Bolt Beranek and Newman Inc.,
Meridian Technology Corporation, November 1991. Meridian Technology Corporation, November 1991.
[2] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow [2] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow
Measurement: Architecture", RFC 2063, The University of Measurement: Architecture", RFC 2063, The University of
Auckland, Bolt Beranek and Newman Inc., GTE Laboratories Inc, Auckland, Bolt Beranek and Newman Inc., GTE Laboratories
January 1997. Inc., January 1997.
[3] Brownlee, N., "Traffic Flow Measurement: Meter MIB", [3] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
RFC 2064, The University of Auckland, January 1997. RFC 2064, The University of Auckland, January 1997.
[4] Brownlee, N., "SRL: A Language for Describing Traffic Flows [4] Brownlee, N., "SRL: A Language for Describing Traffic Flows
and Specifying Actions for Flow Groups," Internet Draft, and Specifying Actions for Flow Groups," Internet Draft,
'Working draft' to become an Informational RFC, 'Working draft' to become an Informational RFC,
The University of Auckland. The University of Auckland.
[5] Handelman, S.W., Brownlee, N., Ruth, G., Stibler, S., [5] Handelman, S.W., Brownlee, N., Ruth, G., Stibler, S.,
 End of changes. 17 change blocks. 
59 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/