Network Working Group S. Shalunov 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 .................541. 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 open