draft-ietf-rtfm-applicability-statement-03.txt   draft-ietf-rtfm-applicability-statement-04.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
Expires December 1999
August 1999
Expires February 2000
RTFM: Applicability Statement RTFM: Applicability Statement
<draft-ietf-rtfm-applicability-statement-03.txt> <draft-ietf-rtfm-applicability-statement-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
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 10 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, as follows:
[1] Internet Accounting: Background (Informational) [ACT-BKG] Internet Accounting: Background (Informational)
Sets out the requirements for a usage reporting system for Sets out the requirements for a usage reporting system for
network traffic. Sketches out the RTFM Architecture (meters, network traffic. Sketches out the RTFM Architecture (meters,
meter readers and managers) allowing for multiple meters meter readers and managers) allowing for multiple meters
and meter readers, with asynchronous reading from the meters. and meter readers, with asynchronous reading from the meters.
Proposes methods of classifying traffic flows, the need for Proposes methods of classifying traffic flows, the need for
flows to be bi-directional (with separate sets of counters flows to be bi-directional (with separate sets of counters
for each direction) and the need for each packet to be counted for each direction) and the need for each packet to be counted
in a single flow (the 'count in one bucket' principle). in a single flow (the 'count in one bucket' principle).
[2] RTFM Architecture (Informational) [RTFM-ARC] RTFM Architecture (Informational)
Defines the RTFM Architecture, giving descriptions of each Defines the RTFM Architecture, giving descriptions of each
component. Explains how traffic flows are viewed as logical component. Explains how traffic flows are viewed as logical
entities described in terms of their address-attribute values, entities described in terms of their address-attribute values,
so that each is defined by the attributes of its end-points. so that each is defined by the attributes of its end-points.
Gives a detailed description of the RTFM traffic meter, with Gives a detailed description of the RTFM traffic meter, with
full details of how flows are stored in the meter's flow table, full details of how flows are stored in the meter's flow table,
and how packets are matched in accordance with rules stored in and how packets are matched in accordance with rules stored in
a ruleset. a ruleset.
[3] RTFM Meter MIB (Proposed Standard) [RTFM-MIB] RTFM Meter MIB (Proposed Standard)
Describes the SNMP Management Information Base for an RTFM Describes the SNMP Management Information Base for an RTFM
meter, including its flow table, rule table (storing the meter, including its flow table, rule table (storing the
meter's rulesets) and the control tables used for managing meter's rulesets) and the control tables used for managing
a meter and reading flow data from it. a meter and reading flow data from it.
[4] SRL: A Language for Describing Traffic Flows (Informational) [RTFM-SRL] SRL: A Language for Describing Traffic (Informational)
and Specifying Actions for Flow Groups Flows and Specifying Actions for Flow Groups
An RTFM ruleset is an array of rules, used by the meter to An RTFM ruleset is an array of rules, used by the meter to
decide which flows are of interest, which end-point is the decide which flows are of interest, which end-point is the
flow source, and how much detail (i.e. what attribute values) flow source, and how much detail (i.e. what attribute values)
must be saved for each flow. SRL is a high-level language must be saved for each flow. SRL is a high-level language
providing a clear, logical way to write rulesets. It should providing a clear, logical way to write rulesets. It should
also be useful for other applications which select flows also be useful for other applications which select flows
and perform actions upon them, e.g. packet-marking gateways, and perform actions upon them, e.g. packet-marking gateways,
RSVP policy agents, etc. RSVP policy agents, etc.
[5] RTFM New Attributes (Experimental) [RTFM-NEW] RTFM New Attributes (Experimental)
There has been considerable interest from users in extending There has been considerable interest from users in extending
the RTFM Architecture so as to allow a meter to report on the RTFM Architecture so as to allow a meter to report on
an increased number of flow-related measures. This an increased number of flow-related measures. This
RFC documents work on specifying such measures (the 'new' RFC documents work on specifying such measures (the 'new'
attributes) and reports on experience of implementing them. attributes) and reports on experience of implementing them.
[6] RTFM: Experiences with NeTraMet (Informational) [RTFM-NTM] RTFM: Experiences with NeTraMet (Informational)
NeTraMet is a free software implementation of the RTFM NeTraMet is a free software implementation of the RTFM
Architecture which has been available since 1993. This RFC Architecture which has been available since 1993. This RFC
records RTFM implementation experience gained with NeTraMet records RTFM implementation experience gained with NeTraMet
up to late 1996. One particularly important result is the up to late 1996. One particularly important result is the
realisation that groups of rules which test the same attribute realisation that groups of rules which test the same attribute
using the same mask can be implemented as a single hashed using the same mask can be implemented as a single hashed
comparison, allowing the meter to rapidly determine whether a comparison, allowing the meter to rapidly determine whether a
packet belongs to one of a large number of networks. packet belongs to one of a large number of networks.
skipping to change at page 6, line 24 skipping to change at page 6, line 24
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 it. 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 itself may well be valuable - to the 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 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 modify that data, or the meter's ruleset(s)). It is therefore important
important to take proper precautions to ensure that access to the meter to take proper precautions to ensure that access to the meter and its
and its data is 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 Meters may, like any other network component, be subjected to Denial of
Service and other attacks. These are outside the RTFM Architecture - Service and other attacks. These are outside the RTFM Architecture -
countermeasures for them are available, but are also outside RTFM. countermeasures for them are available, but are also outside RTFM.
skipping to change at page 9, line 27 skipping to change at page 9, line 18
retrieve the data. The combination of retrieve the data. The combination of
TimeFilter: to select the flows to be read TimeFilter: to select the flows to be read
DataPackage: to select the attributes required for each flow DataPackage: to select the attributes required for each flow
GetBulk: to read many flows with a single SNMP PDU GetBulk: to read many flows with a single SNMP PDU
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 [ACT-BKG] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting
Background", RFC 1272, Bolt Beranek and Newman Inc., Background," RFC 1272, November 1991.
Meridian Technology Corporation, November 1991.
[2] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow [RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
Measurement: Architecture", RFC 2063, The University of Measurement: Architecture", RFC 2063, January 1997.
Auckland, GTE Laboratories Inc, January 1997.
[3] Brownlee, N., "Traffic Flow Measurement: Meter MIB", [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB",
RFC 2064, The University of Auckland, January 1997. RFC 2064, January 1997.
[4] Brownlee, N., "SRL: A Language for Describing Traffic Flows [RTFM-NEW] Handelman, S.W., Brownlee, N., Ruth, G., Stibler, S.,
and Specifying Actions for Flow Groups," Internet Draft, "New Attributes for Traffic Flow Measurment," Internet
'Working draft' to become an Informational RFC, Draft 'Work in progress' to become an Informational RFC
The University of Auckland.
[5] Handelman, S.W., Brownlee, N., Ruth, G., Stibler, S., [RTFM-NTM] Brownlee, N., "Traffic Flow Measurement: Experiences with
"New Attributes for Traffic Flow Measurment," Internet Draft, NeTraMet," RFC 2123, March 1997.
'Working draft' to become an Experimental RFC,
IBM, The University of Auckland, GTE Laboratories Inc, IBM.
[6] Brownlee, N., "Traffic Flow Measurement: Experiences with [RTFM-SRL] Brownlee, N., "SRL: A Language for Describing Traffic
NeTraMet," RFC 2123, The University of Auckland, March 1997. Flows and Specifying Actions for Flow Groups," Internet
Draft 'Work in progress' to become an Informational RFC
10 Author's Address 10 Author's Address
Nevil Brownlee Nevil Brownlee
Information Technology Systems & Services Information Technology Systems & Services
The University of Auckland The University of Auckland
Private Bag 92-019
Auckland, New Zealand
Phone: +64 9 373 7599 x8941 Phone: +64 9 373 7599 x8941
E-mail: n.brownlee@auckland.ac.nz E-mail: n.brownlee@auckland.ac.nz
Expires December 1999 Expires February 2000
 End of changes. 19 change blocks. 
32 lines changed or deleted 32 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/