Tech-invite3GPPspaceIETFspace
9796959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4656

A One-way Active Measurement Protocol (OWAMP)

Pages: 56
Proposed Standard
Updated by:  771777188545
Part 1 of 2 – Pages 1 to 27
None   None   Next

Top   ToC   RFC4656 - Page 1
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
Top   ToC   RFC4656 - Page 2
   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
Top   ToC   RFC4656 - Page 3
   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
Top   ToC   RFC4656 - Page 4
   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.
Top   ToC   RFC4656 - Page 5
   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).
Top   ToC   RFC4656 - Page 6

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