Request for Comments: 4656 B. Teitelbaum
Category: Standards Track A. Karp
J. Boote
M. Zekauskas
Internet2
September 2006
A One-way Active Measurement Protocol (OWAMP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The One-Way Active Measurement Protocol (OWAMP) measures
unidirectional characteristics such as one-way delay and one-way
loss. High-precision measurement of these one-way IP performance
metrics became possible with wider availability of good time sources
(such as GPS and CDMA). OWAMP enables the interoperability of these
measurements.
Table of Contents
1. Introduction ....................................................2
1.1. Relationship of Test and Control Protocols .................3
1.2. Logical Model ..............................................4
2. Protocol Overview ...............................................5
3. OWAMP-Control ...................................................6
3.1. Connection Setup ...........................................6
3.2. Integrity Protection (HMAC) ...............................11
3.3. Values of the Accept Field ................................11
3.4. OWAMP-Control Commands ....................................12
3.5. Creating Test Sessions ....................................13
3.6. Send Schedules ............................................18
3.7. Starting Test Sessions ....................................19
3.8. Stop-Sessions .............................................20
3.9. Fetch-Session .............................................24
4. OWAMP-Test .....................................................27
4.1. Sender Behavior ...........................................28
4.1.1. Packet Timings .....................................28
4.1.2. OWAMP-Test Packet Format and Content ...............29
4.2. Receiver Behavior .........................................33
5. Computing Exponentially Distributed Pseudo-Random Numbers ......35
5.1. High-Level Description of the Algorithm ...................35
5.2. Data Types, Representation, and Arithmetic ................36
5.3. Uniform Random Quantities .................................37
6. Security Considerations ........................................38
6.1. Introduction ..............................................38
6.2. Preventing Third-Party Denial of Service ..................38
6.3. Covert Information Channels ...............................39
6.4. Requirement to Include AES in Implementations .............39
6.5. Resource Use Limitations ..................................39
6.6. Use of Cryptographic Primitives in OWAMP ..................40
6.7. Cryptographic Primitive Replacement .......................42
6.8. Long-term Manually Managed Keys ...........................43
6.9. (Not) Using Time as Salt ..................................44
6.10. The Use of AES-CBC and HMAC ..............................44
7. Acknowledgements ...............................................45
8. IANA Considerations ............................................45
9. Internationalization Considerations ............................46
10. References ....................................................46
10.1. Normative References .....................................46
10.2. Informative References ...................................47
Appendix A: Sample C Code for Exponential Deviates ................49
Appendix B: Test Vectors for Exponential Deviates .................54
1. Introduction
The IETF IP Performance Metrics (IPPM) working group has defined
metrics for one-way packet delay [RFC2679] and loss [RFC2680] across
Internet paths. Although there are now several measurement platforms
that implement collection of these metrics [SURVEYOR] [SURVEYOR-INET]
[RIPE] [BRIX], there is not currently a standard that would permit
initiation of test streams or exchange of packets to collect
singleton metrics in an interoperable manner.
With the increasingly wide availability of affordable global
positioning systems (GPS) and CDMA-based time sources, hosts
increasingly have available to them very accurate time sources,
either directly or through their proximity to Network Time Protocol
(NTP) primary (stratum 1) time servers. By standardizing a technique
for collecting IPPM one-way active measurements, we hope to create an
environment where IPPM metrics may be collected across a far broader
mesh of Internet paths than is currently possible. One particularly
compelling vision is of widespread deployment of open OWAMP servers
that would make measurement of one-way delay as commonplace as
measurement of round-trip time using an ICMP-based tool like ping.
Additional design goals of OWAMP include: being hard to detect and
manipulate, security, logical separation of control and test
functionality, and support for small test packets. (Being hard to
detect makes interference with measurements more difficult for
intermediaries in the middle of the network.)
OWAMP test traffic is hard to detect because it is simply a stream of
UDP packets from and to negotiated port numbers, with potentially
nothing static in the packets (size is negotiated, as well). OWAMP
also supports an encrypted mode that further obscures the traffic and
makes it impossible to alter timestamps undetectably.
Security features include optional authentication and/or encryption
of control and test messages. These features may be useful to
prevent unauthorized access to results or man-in-the-middle attacks
that attempt to provide special treatment to OWAMP test streams or
that attempt to modify sender-generated timestamps to falsify test
results.
In this document, the key words "MUST", "REQUIRED", "SHOULD",
"RECOMMENDED", and "MAY" are to be interpreted as described in
[RFC2119].
1.1. Relationship of Test and Control Protocols
OWAMP actually consists of two inter-related protocols: OWAMP-Control
and OWAMP-Test. OWAMP-Control is used to initiate, start, and stop
test sessions and to fetch their results, whereas OWAMP-Test is used
to exchange test packets between two measurement nodes.
Although OWAMP-Test may be used in conjunction with a control
protocol other than OWAMP-Control, the authors have deliberately
chosen to include both protocols in the same RFC to encourage the
implementation and deployment of OWAMP-Control as a common
denominator control protocol for one-way active measurements. Having
a complete and open one-way active measurement solution that is
simple to implement and deploy is crucial to ensuring a future in
which inter-domain one-way active measurement could become as
commonplace as ping. We neither anticipate nor recommend that
OWAMP-Control form the foundation of a general-purpose extensible
measurement and monitoring control protocol.
OWAMP-Control is designed to support the negotiation of one-way
active measurement sessions and results retrieval in a
straightforward manner. At session initiation, there is a
negotiation of sender and receiver addresses and port numbers,
session start time, session length, test packet size, the mean
Poisson sampling interval for the test stream, and some attributes of
the very general [RFC 2330] notion of packet type, including packet
size and per-hop behavior (PHB) [RFC2474], which could be used to
support the measurement of one-way network characteristics across
differentiated services networks. Additionally, OWAMP-Control
supports per-session encryption and authentication for both test and
control traffic, measurement servers that can act as proxies for test
stream endpoints, and the exchange of a seed value for the pseudo-
random Poisson process that describes the test stream generated by
the sender.
We believe that OWAMP-Control can effectively support one-way active
measurement in a variety of environments, from publicly accessible
measurement beacons running on arbitrary hosts to network monitoring
deployments within private corporate networks. If integration with
Simple Network Management Protocol (SNMP) or proprietary network
management protocols is required, gateways may be created.
1.2. Logical Model
Several roles are logically separated to allow for broad flexibility
in use. Specifically, we define the following:
Session-Sender The sending endpoint of an OWAMP-Test session;
Session-Receiver The receiving endpoint of an OWAMP-Test session;
Server An end system that manages one or more OWAMP-Test
sessions, is capable of configuring per-session
state in session endpoints, and is capable of
returning the results of a test session;
Control-Client An end system that initiates requests for
OWAMP-Test sessions, triggers the start of a set
of sessions, and may trigger their termination;
and
Fetch-Client An end system that initiates requests to fetch
the results of completed OWAMP-Test sessions.
One possible scenario of relationships between these roles is shown
below.
+----------------+ +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+ +------------------+
^ ^
| |
| |
| |
| +----------------+<----------------+
| | Server |<-------+
| +----------------+ |
| ^ |
| | |
| OWAMP-Control OWAMP-Control
| | |
v v v
+----------------+ +-----------------+
| Control-Client | | Fetch-Client |
+----------------+ +-----------------+
(Unlabeled links in the figure are unspecified by this document and
may be proprietary protocols.)
Different logical roles can be played by the same host. For example,
in the figure above, there could actually be only two hosts: one
playing the roles of Control-Client, Fetch-Client, and Session-
Sender, and the other playing the roles of Server and Session-
Receiver. This is shown below.
+-----------------+ +------------------+
| Control-Client |<--OWAMP-Control-->| Server |
| Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+
Finally, because many Internet paths include segments that transport
IP over ATM, delay and loss measurements can include the effects of
ATM segmentation and reassembly (SAR). Consequently, OWAMP has been
designed to allow for small test packets that would fit inside the
payload of a single ATM cell (this is only achieved in
unauthenticated mode).
2. Protocol Overview
As described above, OWAMP consists of two inter-related protocols:
OWAMP-Control and OWAMP-Test. The former is layered over TCP and is
used to initiate and control measurement sessions and to fetch their
results. The latter protocol is layered over UDP and is used to send
singleton measurement packets along the Internet path under test.
The initiator of the measurement session establishes a TCP connection
to a well-known port, 861, on the target point and this connection
remains open for the duration of the OWAMP-Test sessions. An OWAMP
server SHOULD listen to this well-known port.
OWAMP-Control messages are transmitted only before OWAMP-Test
sessions are actually started and after they are completed (with the
possible exception of an early Stop-Sessions message).
The OWAMP-Control and OWAMP-Test protocols support three modes of
operation: unauthenticated, authenticated, and encrypted. The
authenticated or encrypted modes require that endpoints possess a
shared secret.
All multi-octet quantities defined in this document are represented
as unsigned integers in network byte order unless specified
otherwise.
3. OWAMP-Control
The type of each OWAMP-Control message can be found after reading the
first 16 octets. The length of each OWAMP-Control message can be
computed upon reading its fixed-size part. No message is shorter
than 16 octets.
An implementation SHOULD expunge unused state to prevent denial-of-
service attacks, or unbounded memory usage, on the server. For
example, if the full control message is not received within some
number of minutes after it is expected, the TCP connection associated
with the OWAMP-Control session SHOULD be dropped. In absence of
other considerations, 30 minutes seems like a reasonable upper bound.
3.1. Connection Setup
Before either a Control-Client or a Fetch-Client can issue commands
to a Server, it has to establish a connection to the server.
First, a client opens a TCP connection to the server on a well-known
port 861. The server responds with a server greeting:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Salt (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following Mode values are meaningful: 1 for unauthenticated, 2
for authenticated, and 4 for encrypted. The value of the Modes field
sent by the server is the bit-wise OR of the mode values that it is
willing to support during this session. Thus, the last three bits of
the Modes 32-bit value are used. The first 29 bits MUST be zero. A
client MUST ignore the values in the first 29 bits of the Modes
value. (This way, the bits are available for future protocol
extensions. This is the only intended extension mechanism.)
Challenge is a random sequence of octets generated by the server; it
is used subsequently by the client to prove possession of a shared
secret in a manner prescribed below.
Salt and Count are parameters used in deriving a key from a shared
secret as described below.
Salt MUST be generated pseudo-randomly (independently of anything
else in this document).
Count MUST be a power of 2. Count MUST be at least 1024. Count
SHOULD be increased as more computing power becomes common.
If the Modes value is zero, the server does not wish to communicate
with the client and MAY close the connection immediately. The client
SHOULD close the connection if it receives a greeting with Modes
equal to zero. The client MAY close the connection if the client’s
desired mode is unavailable.
Otherwise, the client MUST respond with the following Set-Up-Response
message:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. KeyID (80 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Token (64 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Client-IV (16 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here Mode is the mode that the client chooses to use during this
OWAMP-Control session. It will also be used for all OWAMP-Test
sessions started under control of this OWAMP-Control session. In
Mode, one or zero bits MUST be set within last three bits. If it is
one bit that is set within the last three bits, this bit MUST
indicate a mode that the server agreed to use (i.e., the same bit