返回首页

RFC 4656 - A One-way Active Measurement Protocol (OWAMP)

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroup S.Shalunov RequestforComments:4656B.Teitelbaum Category:StandardsTrack A.Karp J.Boote M.Zekauskas Internet2 September2006 AOne-wayActiveMeasurementProtocol(OWAMP) StatusofThisMemo ThisdocumentspecifiesanInternetstandardstrackproto
  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 .................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
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容