draft-ietf-ippm-owdp-reqs-01.txt   draft-ietf-ippm-owdp-reqs-02.txt 
Network Working Group S. Shalunov Network Working Group Stanislav Shalunov
Expiration Date: April 2002 B. Teitelbaum Expiration Date: December 2002 Benjamin Teitelbaum
Advanced Network & Services and Internet2 Advanced Network & Services and Internet2
November 2001 June 2002
A One-way Active Measurement Protocol Requirements A One-way Active Measurement Protocol Requirements
<draft-ietf-ippm-owdp-reqs-01.txt> <draft-ietf-ippm-owdp-reqs-02.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 30 skipping to change at page 2, line 30
time-stamp packets with accuracies substantially better than the time-stamp packets with accuracies substantially better than the
delays seen on the Internet--either directly or through their delays seen on the Internet--either directly or through their
proximity to NTP primary (stratum 1) time servers. By standardizing proximity to NTP primary (stratum 1) time servers. By standardizing
a technique for collecting IPPM one-way active measurements, we hope a technique for collecting IPPM one-way active measurements, we hope
to create an environment where these metrics may be collected across to create an environment where these metrics may be collected across
a far broader mesh of Internet paths than is currently possible. One a far broader mesh of Internet paths than is currently possible. One
particularly compelling vision is of widespread deployment of open particularly compelling vision is of widespread deployment of open
one-way active measurement beacons that would make measurements of one-way active measurement beacons that would make measurements of
one-way delay as commonplace as measurements of round-trip time are one-way delay as commonplace as measurements of round-trip time are
today using ICMP-based tools like ping. Even without very accurate today using ICMP-based tools like ping. Even without very accurate
timestamps one can measure characteristics such as, e.g., loss with timestamps one can measure characteristics such as loss with quality
acceptable for many practical purposes quality. acceptable for many practical purposes, e.g., network operations.
To support interoperability between alternative OWAMP implementations To support interoperability between alternative OWAMP implementations
and make possible a world where "one-way ping" could become and make possible a world where "one-way ping" could become
commonplace, a standard is required that specifies how test streams commonplace, a standard is required that specifies how test streams
are initiated, how test packets are exchanged, and how test results are initiated, how test packets are exchanged, and how test results
are retrieved. Detailed functional requirements are given in the are retrieved. Detailed functional requirements are given in the
subsequent section. subsequent section.
4. Functional Requirements 4. Functional Requirements
skipping to change at page 3, line 21 skipping to change at page 3, line 21
considered practical and not in contradiction to other design goals. considered practical and not in contradiction to other design goals.
4.1. Keeping All Data for Post-processing 4.1. Keeping All Data for Post-processing
To facilitate the broadest possible use of obtained measurement To facilitate the broadest possible use of obtained measurement
results, the protocol(s) should not necessitate any required post- results, the protocol(s) should not necessitate any required post-
processing. (This does not apply to implementation details such as processing. (This does not apply to implementation details such as
converting timestamps from ticks since midnight into a canonical form converting timestamps from ticks since midnight into a canonical form
or applying calibration constants; such details should naturally be or applying calibration constants; such details should naturally be
hidden.) All data obtained during a measurement session should be hidden.) All data obtained during a measurement session should be
available after it is finished if desired by the data consumer so available after the session is finished if desired by the data
that various characteristics can be computed from the raw data using consumer so that various characteristics can be computed from the raw
arbitrary algorithms. data using arbitrary algorithms.
4.2. Result Distribution 4.2. Result Distribution
A means to distribute measurement results (between hosts A means to distribute measurement results (between hosts
participating in a measurement session and beyond) should be participating in a measurement session and beyond) should be
provided. Since there can exist a wide variety of scenarios as to provided. Since there can exist a wide variety of scenarios as to
where the final data destination should be, these should be invoked where the final data destination should be, these should be invoked
separately from measurement requests (e.g., receiver should not have separately from measurement requests (e.g., receiver should not have
to automatically send measurement results to the sender, since it may to automatically send measurement results to the sender, since it may
be the receiver or a third host that are the ultimate data be the receiver or a third host that are the ultimate data
skipping to change at page 3, line 45 skipping to change at page 3, line 45
At the same time, ability to transfer results directly to their At the same time, ability to transfer results directly to their
destination (without need for potentially large intermediate destination (without need for potentially large intermediate
transfers) should be provided. transfers) should be provided.
4.3. Protocol Separation 4.3. Protocol Separation
Since measurement session setup and the actual measurement session Since measurement session setup and the actual measurement session
(i) are different tasks; (ii) require different levels of (i) are different tasks; (ii) require different levels of
functionality, flexibility, and implementation effort; (iii) may need functionality, flexibility, and implementation effort; (iii) may need
to run over different transport protocols, there should exist a to run over different transport protocols, there should exist two
protocol for conducting the actual measurement session on one side protocols: one for conducting the actual measurement session and
and a protocol for session setup/teardown/confirmation/retrieval on another for session setup/teardown/confirmation/retrieval. These
the other. These protocols are further referred to as OWAMP-Test and protocols are further referred to as OWAMP-Test and OWAMP-Control,
OWAMP-Control, respectively. respectively.
It should be possible to use devices that only support OWAMP-Test but It should be possible to use devices that only support OWAMP-Test but
not OWAMP-Control to conduct measurement sessions (such devices will not OWAMP-Control to conduct measurement sessions (such devices will
necessarily need to support one form of session setup protocol or the necessarily need to support one form of session setup protocol or the
other, but it doesn't have to be known to external parties). other, but it doesn't have to be known to external parties).
OWAMP-Control would thus become a common protocol for different OWAMP-Control would thus become a common protocol for different
domains, which may or may not use it for session setup internally. administrative domains, which may or may not use it for session setup
internally.
4.4. Test Protocol 4.4. Test Protocol
The test protocol needs to be implemented on all measurement nodes The test protocol needs to be implemented on all measurement nodes
and should therefore have the following characteristics: and should therefore have the following characteristics:
+ Be lightweight and easy to implement. + Be lightweight and easy to implement.
+ Be suitable for implementation on a wide range of measurement + Be suitable for implementation on a wide range of measurement
nodes. nodes.
+ Allow UDP as the transport protocol, since the protocol needs to + Allow UDP as the transport protocol, since the protocol needs to
be able to measure individual packet delivery times and has to run be able to measure individual packet delivery times and has to run
on various machines. on various machines (see the section "Support for Measurements
with Different Packet Types" below for further discussion).
+ Support varying packet sizes and network services (e.g., DSCP + Support varying packet sizes and network services (e.g., DSCP
marking), as negotiated by OWAMP-Control. marking), as negotiated by OWAMP-Control.
+ Be as simple as possible, but no simpler; the OWAMP-Test packet + Be as simple as possible, but no simpler than necessary to
format should include only universally meaningful fields, and implement requirements set forth in this document; the OWAMP-Test
minimum number of them. packet format should include only universally meaningful fields,
and minimum number of them.
+ It should be possible to generate OWAMP-Test packets small enough, + If practical, it should be possible to generate OWAMP-Test packets
so that when encapsulated, each fits inside a single ATM cell. small enough, so that when encapsulated, each fits inside a single
ATM cell.
+ Data needed to calculate experimental errors on the final result + Data needed to calculate experimental errors on the final result
should be included in the packets. should be included in every OWAMP-Test packet.
4.5. Control Protocol 4.5. Control Protocol
Control protocol needs to provide the capability to: Control protocol needs to provide the capability to:
+ authenticate peers to each other using a common authentication + authenticate peers to each other using a common authentication
method that doesn't require building any new authentication method that doesn't require building any new authentication
infrastructure, such as user ID and a shared secret; infrastructure, such as user ID and a shared secret;
+ schedule zero or more OWAMP-Test sessions (which do not have to be + schedule zero or more OWAMP-Test sessions (which do not have to be
between the peers of OWAMP-Control conversation); between the peers of OWAMP-Control conversation);
+ start sessions simultaneously or at a pre-scheduled per-session + start sessions simultaneously or at a pre-scheduled per-session
times; times;
+ retrieve OWAMP-Test session results (of OWAMP-Test sessions + retrieve OWAMP-Test session results (of OWAMP-Test sessions
scheduled in the current and other OWAMP-Control sessions); scheduled in the current and other OWAMP-Control sessions);
+ confirm graceful completion of sessions and allow either side to + confirm graceful completion of sessions and allow either side to
skipping to change at page 5, line 34 skipping to change at page 5, line 43
decisions narrowing the scope of possible packet types need to be decisions narrowing the scope of possible packet types need to be
made at measurement protocol design stage. Further, measurement with made at measurement protocol design stage. Further, measurement with
packets of certain types, while feasible in more closed settings than packets of certain types, while feasible in more closed settings than
those implied by OWAMP, become very hard to perform in an open inter- those implied by OWAMP, become very hard to perform in an open inter-
domain fashion (e.g., measurements with particular packets with domain fashion (e.g., measurements with particular packets with
broken IP checksum or particular loose source routing options). broken IP checksum or particular loose source routing options).
In addition, very general packet type specification could result in In addition, very general packet type specification could result in
several problems: several problems:
+ Many OWAMP-Test speakers will be Unix or other general purpose + Many OWAMP-Test speakers will be general purpose computers with a
computers. These will inevitably have higher losses when multitasking operating system that includes a socket interface.
listening to raw network traffic. Raw sockets will induce higher These will inevitably have higher losses when listening to raw
loss rate than one would have with UDP measurements. network traffic. Raw sockets will induce higher loss rate than
one would have with UDP measurements.
+ It's not at all clear (short of standardizing tcpdump syntax) how + It's not at all clear (short of standardizing tcpdump syntax) how
to describe formally the filter that a receiver should use to to describe formally the filter that a receiver should use to
listen for test traffic. listen for test traffic.
+ Suppose an identity of an authenticated user becomes compromised. + Suppose an identity of an authenticated user becomes compromised.
Now the attacker could use that to run TCP sessions to the rlogin Now the attacker could use that to run TCP sessions to the rlogin
port of machines around servers that trust this user to perform port of machines around servers that trust this user to perform
measurements (or, less drastically, to send spam from that measurements (or, less drastically, to send spam from that
network). The ability to perform measurements is transformed into network). The ability to perform measurements is transformed into
skipping to change at page 6, line 37 skipping to change at page 7, line 10
design other architectures that are free of scalability deficiencies. design other architectures that are free of scalability deficiencies.
It is the protocol user's responsibility to decide how to use the It is the protocol user's responsibility to decide how to use the
protocol and which measurements to conduct. protocol and which measurements to conduct.
6. Security Considerations 6. Security Considerations
6.1. Modes of Operation 6.1. Modes of Operation
Since the protocol(s) will be used in widely varying circumstances Since the protocol(s) will be used in widely varying circumstances
using widely varying equipment, it is necessary to have more than one using widely varying equipment, it is necessary be able to support
mode of operation security-wise. varying degrees of security modes of operation. The parameters to be
considered include: confidentiality, data origin authentication,
integrity and replay protection.
It should be possible to operate in a completely "open" mode, where It should be possible to operate in a completely "open" mode, where
no security mechanisms are used. We call this "unauthenticated no cryptographic security mechanisms are used. We call this
mode". "unauthenticated mode". In this mode, care must be taken to avoid
denial-of-service attacks.
It should also be possible to operate in a mode where all security It should also be possible to operate in a mode where all security
mechanisms are enabled and security objectives are realized to the mechanisms are enabled and security objectives are realized to the
fullest extent possible. We call this "encrypted mode". fullest extent possible. We call this "encrypted mode".
Since timestamp encryption takes a certain amount of time, which may Since timestamp encryption takes a certain amount of time, which may
be hard to predict on some devices (with a time-sharing OS), a mode be hard to predict on some devices (with a time-sharing OS), a mode
should be provided that is similar to encrypted mode, but in which should be provided that is similar to encrypted mode, but in which
timestamps are not encrypted. In this mode, all security properties timestamps are not encrypted. In this mode, all security properties
of the encrypted mode that can be retained without timestamp of the encrypted mode that can be retained without timestamp
encryption should be present. encryption should be present. We call this "authenticated mode".
To make implementation more manageable, the number of other options To make implementation more manageable, the number of other options
and modes should be kept to the absolute practical minimum. Where and modes should be kept to the absolute practical minimum. Where
choosing a single mechanism for achieving anything related to choosing a single mechanism for achieving anything related to
security is possible, such choice should be made at specification security is possible, such choice should be made at specification
phase and be put into the standard. phase and be put into the standard.
6.2. Being Hard to Interfere with by Applying Special Treatment to 6.2. Being Hard to Interfere with by Applying Special Treatment to
Measurement Packets Measurement Packets
The design of the protocol should make it possible to run sessions The design of the protocol should make it possible to run sessions
that would make it very difficult for any intermediate party to make that would make it very difficult for any intermediate party to make
results appear better than they would be if no interference was results appear better than they would be if no interference was
attempted. attempted.
This is different from cryptographic assurance of data integrity,
because one can manipulate the results without changing any data in
the packets. For example, if OWAMP-Test packets are easy to identify
(e.g., they all come to a well-known port number), an intermediate
party might place OWAMP-Test traffic into a priority queue at a
congested link thus ensuring that the results of the measurement
appear better than what would be experienced by other traffic. It
should not be easy for intermediate parties to identify OWAMP-Test
packets (just as it should not be easy for restaurants to identify
restaurant critics).
6.3. Secrecy/Confidentiality 6.3. Secrecy/Confidentiality
It should be possible to make it infeasible for any outside party It should be possible to make it infeasible for any outside party
without knowledge of the shared secret being used to learn what without knowledge of the shared secret being used to learn what
information is exchanged using OWAMP-Control by inspecting an OWAMP- information is exchanged using OWAMP-Control by inspecting an OWAMP-
Control stream or actively modifying it. Control stream or actively modifying it.
(It is recognized that some information will inevitably leak from the (It is recognized that some information will inevitably leak from the
mere fact of communication and from the presence and timing of mere fact of communication and from the presence and timing of
concurrent and subsequent OWAMP-Test traffic.) concurrent and subsequent OWAMP-Test traffic.)
skipping to change at page 9, line 20 skipping to change at page 10, line 4
9. Authors' Addresses 9. Authors' Addresses
Stanislav Shalunov Stanislav Shalunov
Internet2 Internet2
200 Business Park Drive, Suite 307 200 Business Park Drive, Suite 307
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1182 Phone: +1 914 765 1182
EMail: shalunov@internet2.edu EMail: shalunov@internet2.edu
Benjamin Teitelbaum Benjamin Teitelbaum
Advanced Network & Services Advanced Network & Services
200 Business Park Drive, Suite 307 200 Business Park Drive, Suite 307
Armonk, NY 10504 Armonk, NY 10504
USA USA
Phone: +1 914 765 1118 Phone: +1 914 765 1118
EMail: ben@advanced.org EMail: ben@advanced.org
Expiration date: April 2002 Expiration date: December 2002
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/