Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: IPPM

RFC 4656

A One-way Active Measurement Protocol (OWAMP)

Pages: 56
Proposed STD
Updated by:  77177718
Part 2 of 2 – Pages 27 to 56
First   Prev   None

Top   ToC   Page 27   prevText
4.  OWAMP-Test

   This section describes OWAMP-Test protocol.  It runs over UDP, using
   sender and receiver IP and port numbers negotiated during the
   Request-Session exchange.
Top   ToC   Page 28
   As with OWAMP-Control, OWAMP-Test has three modes: unauthenticated,
   authenticated, and encrypted.  All OWAMP-Test sessions that are
   spawned by an OWAMP-Control session inherit its mode.

   OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and
   OWAMP-Test receiver can potentially all be different machines.  (In a
   typical case, we expect that there will be only two machines.)

4.1.  Sender Behavior

4.1.1.  Packet Timings

   Send schedules based on slots, described previously, in conjunction
   with scheduled session start time, enable the sender and the receiver
   to compute the same exact packet sending schedule independently of
   each other.  These sending schedules are independent for different
   OWAMP-Test sessions, even if they are governed by the same OWAMP-
   Control session.

   Consider any OWAMP-Test session.  Once Start-Sessions exchange is
   complete, the sender is ready to start sending packets.  Under normal
   OWAMP use circumstances, the time to send the first packet is in the
   near future (perhaps a fraction of a second away).  The sender SHOULD
   send packets as close as possible to their scheduled time, with the
   following exception: if the scheduled time to send is in the past,
   and is separated from the present by more than Timeout time, the
   sender MUST NOT send the packet.  (Indeed, such a packet would be
   considered lost by the receiver anyway.)  The sender MUST keep track
   of which packets it does not send.  It will use this to tell the
   receiver what packets were not sent by setting Skip Ranges in the
   Stop-Sessions message from the sender to the receiver upon completion
   of the test.  The Skip Ranges are also sent to a Fetch-Client as part
   of the session data results.  These holes in the sending schedule can
   happen if a time in the past was specified in the Request-Session
   command, or if the Start-Sessions exchange took unexpectedly long, or
   if the sender could not start serving the OWAMP-Test session on time
   due to internal scheduling problems of the OS.  Packets that are in
   the past but are separated from the present by less than Timeout
   value SHOULD be sent as quickly as possible.  With normal test rates
   and timeout values, the number of packets in such a burst is limited.
   Nevertheless, hosts SHOULD NOT intentionally schedule sessions so
   that such bursts of packets occur.

   Regardless of any scheduling delays, each packet that is actually
   sent MUST have the best possible approximation of its real time of
   departure as its timestamp (in the packet).
Top   ToC   Page 29
4.1.2.  OWAMP-Test Packet Format and Content

   The sender sends the receiver a stream of packets with the schedule
   specified in the Request-Session command.  The sender SHOULD set the
   TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255.  The
   format of the body of a UDP packet in the stream depends on the mode
   being used.

   For unauthenticated mode:

      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
     |                        Sequence Number                        |
     |                          Timestamp                            |
     |                                                               |
     |        Error Estimate         |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     .                                                               .
     .                         Packet Padding                        .
     .                                                               .
     |                                                               |
Top   ToC   Page 30
   For authenticated and encrypted modes:

      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
     |                        Sequence Number                        |
     |                                                               |
     |                        MBZ (12 octets)                        |
     |                                                               |
     |                          Timestamp                            |
     |                                                               |
     |        Error Estimate         |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                         MBZ (6 octets)                        |
     |                                                               |
     |                       HMAC (16 octets)                        |
     |                                                               |
     |                                                               |
     |                                                               |
     .                                                               .
     .                        Packet Padding                         .
     .                                                               .
     |                                                               |

   The format of the timestamp is the same as in [RFC1305] and is as
   follows: the first 32 bits represent the unsigned integer number of
   seconds elapsed since 0h on 1 January 1900; the next 32 bits
   represent the fractional part of a second that has elapsed since

   So, Timestamp is represented as follows:

      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
     |                   Integer part of seconds                     |
     |                 Fractional part of seconds                    |
Top   ToC   Page 31
   The Error Estimate specifies the estimate of the error and
   synchronization.  It has the following format:

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        |S|Z|   Scale   |   Multiplier  |

   The first bit, S, SHOULD be set if the party generating the timestamp
   has a clock that is synchronized to UTC using an external source
   (e.g., the bit should be set if GPS hardware is used and it indicates
   that it has acquired current position and time or if NTP is used and
   it indicates that it has synchronized to an external source, which
   includes stratum 0 source, etc.).  If there is no notion of external
   synchronization for the time source, the bit SHOULD NOT be set.  The
   next bit has the same semantics as MBZ fields elsewhere: it MUST be
   set to zero by the sender and ignored by everyone else.  The next six
   bits, Scale, form an unsigned integer; Multiplier is an unsigned
   integer as well.  They are interpreted as follows: the error estimate
   is equal to Multiplier*2^(-32)*2^Scale (in seconds).  (Notation
   clarification: 2^Scale is two to the power of Scale.)  Multiplier
   MUST NOT be set to zero.  If Multiplier is zero, the packet SHOULD be
   considered corrupt and discarded.

   Sequence numbers start with zero and are incremented by one for each
   subsequent packet.

   The minimum data segment length is, therefore, 14 octets in
   unauthenticated mode, and 48 octets in both authenticated mode and
   encrypted modes.

   The OWAMP-Test packet layout is the same in authenticated and
   encrypted modes.  The encryption and authentication operations are,
   however, different.  The difference is that in encrypted mode both
   the sequence number and the timestamp are protected to provide
   maximum data confidentiality and integrity protection, whereas in
   authenticated mode the sequence number is protected while the
   timestamp is sent in clear text.  Sending the timestamp in clear text
   in authenticated mode allows one to reduce the time between when a
   timestamp is obtained by a sender and when the packet is shipped out.
   In encrypted mode, the sender has to fetch the timestamp, encrypt it,
   and send it; in authenticated mode, the middle step is removed,
   potentially improving accuracy (the sequence number can be encrypted
   and authenticated before the timestamp is fetched).

   In authenticated mode, the first block (16 octets) of each packet is
   encrypted using AES Electronic Cookbook (ECB) mode.
Top   ToC   Page 32
   Similarly to each OWAMP-Control session, each OWAMP-Test session has
   two keys: an AES Session-key and an HMAC Session-key.  However, there
   is a difference in how the keys are obtained: in the case of OWAMP-
   Control, the keys are generated by the client and communicated (as
   part of the Token) during connection setup as part of Set-Up-Response
   message; in the case of OWAMP-Test, described here, the keys are
   derived from the OWAMP-Control keys and the SID.

   The OWAMP-Test AES Session-key is obtained as follows: the OWAMP-
   Control AES Session-key (the same AES Session-key as is used for the
   corresponding OWAMP-Control session, where it is used in a different
   chaining mode) is encrypted, using AES, with the 16-octet session
   identifier (SID) as the key; this is a single-block ECB encryption;
   its result is the OWAMP-Test AES Session-key to use in encrypting
   (and decrypting) the packets of the particular OWAMP-Test session.
   Note that all of OWAMP-Test AES Session-key, OWAMP-Control AES
   Session-key, and the SID are comprised of 16 octets.

   The OWAMP-Test HMAC Session-key is obtained as follows: the OWAMP-
   Control HMAC Session-key (the same HMAC Session-key as is used for
   the corresponding OWAMP-Control session) is encrypted, using AES,
   with the 16-octet session identifier (SID) as the key; this is a
   two-block CBC encryption, always performed with IV=0; its result is
   the OWAMP-Test HMAC Session-key to use in authenticating the packets
   of the particular OWAMP-Test session.  Note that all of OWAMP-Test
   HMAC Session-key and OWAMP-Control HMAC Session-key are comprised of
   32 octets, while the SID is 16 octets.

   ECB mode used for encrypting the first block of OWAMP-Test packets in
   authenticated mode does not involve any actual chaining; this way,
   lost, duplicated, or reordered packets do not cause problems with
   deciphering any packet in an OWAMP-Test session.

   In encrypted mode, the first two blocks (32 octets) are encrypted
   using AES CBC mode.  The AES Session-key to use is obtained in the
   same way as the key for authenticated mode.  Each OWAMP-Test packet
   is encrypted as a separate stream, with just one chaining operation;
   chaining does not span multiple packets so that lost, duplicated, or
   reordered packets do not cause problems.  The initialization vector
   for the CBC encryption is a value with all bits equal to zero.

   Implementation note: Naturally, the key schedule for each OWAMP-Test
   session MAY be set up only once per session, not once per packet.
Top   ToC   Page 33
   HMAC in OWAMP-Test only covers the part of the packet that is also
   encrypted.  So, in authenticated mode, HMAC covers the first block
   (16 octets); in encrypted mode, HMAC covers two first blocks (32
   octets).  In OWAMP-Test HMAC is not encrypted (note that this is
   different from OWAMP-Control, where encryption in stream mode is
   used, so everything including the HMAC blocks ends up being

   In unauthenticated mode, no encryption or authentication is applied.

   Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be
   generated independently of any other pseudo-random numbers mentioned
   in this document).  However, implementations MUST provide a
   configuration parameter, an option, or a different means of making
   Packet Padding consist of all zeros.

   The time elapsed between packets is computed according to the slot
   schedule as mentioned in Request-Session command description.  At
   that point, we skipped over the issue of computing exponentially
   distributed pseudo-random numbers in a reproducible fashion.  It is
   discussed later in a separate section.

4.2.  Receiver Behavior

   The receiver knows when the sender will send packets.  The following
   parameter is defined: Timeout (from Request-Session).  Packets that
   are delayed by more than Timeout are considered lost (or "as good as
   lost").  Note that there is never an actual assurance of loss by the
   network: a "lost" packet might still be delivered at any time.  The
   original specification for IPv4 required that packets be delivered
   within TTL seconds or never (with TTL having a maximum value of 255).
   To the best of the authors' knowledge, this requirement was never
   actually implemented (and, of course, only a complete and universal
   implementation would ensure that packets do not travel for longer
   than TTL seconds).  In fact, in IPv6, the name of this field has
   actually been changed to Hop Limit.  Further, IPv4 specification
   makes no claims about the time it takes the packet to traverse the
   last link of the path.

   The choice of a reasonable value of Timeout is a problem faced by a
   user of OWAMP protocol, not by an implementor.  A value such as two
   minutes is very safe.  Note that certain applications (such as
   interactive "one-way ping" might wish to obtain the data faster than

   As packets are received,

   +  timestamp the received packet;
Top   ToC   Page 34
   +  in authenticated or encrypted mode, decrypt and authenticate as
      necessary (packets for which authentication fails MUST be
      discarded); and

   +  store the packet sequence number, send time, receive time, and the
      TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for
      the results to be transferred.

   Packets not received within the Timeout are considered lost.  They
   are recorded with their true sequence number, presumed send time,
   receive time value with all bits being zero, and a TTL (or Hop Limit)
   of 255.

   Implementations SHOULD fetch the TTL/Hop Limit value from the IP
   header of the packet.  If an implementation does not fetch the actual
   TTL value (the only good reason not to do so is an inability to
   access the TTL field of arriving packets), it MUST record the TTL
   value as 255.

   Packets that are actually received are recorded in the order of
   arrival.  Lost packet records serve as indications of the send times
   of lost packets.  They SHOULD be placed either at the point where the
   receiver learns about the loss or at any later point; in particular,
   one MAY place all the records that correspond to lost packets at the
   very end.

   Packets that have send time in the future MUST be recorded normally,
   without changing their send timestamp, unless they have to be
   discarded.  (Send timestamps in the future would normally indicate
   clocks that differ by more than the delay.  Some data -- such as
   jitter -- can be extracted even without knowledge of time difference.
   For other kinds of data, the adjustment is best handled by the data
   consumer on the basis of the complete information in a measurement
   session, as well as, possibly, external data.)

   Packets with a sequence number that was already observed (duplicate
   packets) MUST be recorded normally.  (Duplicate packets are sometimes
   introduced by IP networks.  The protocol has to be able to measure

   If any of the following is true, the packet MUST be discarded:

   +  Send timestamp is more than Timeout in the past or in the future.

   +  Send timestamp differs by more than Timeout from the time when the
      packet should have been sent according to its sequence number.

   +  In authenticated or encrypted mode, HMAC verification fails.
Top   ToC   Page 35
5.  Computing Exponentially Distributed Pseudo-Random Numbers

   Here we describe the way exponential random quantities used in the
   protocol are generated.  While there is a fair number of algorithms
   for generating exponential random variables, most of them rely on
   having logarithmic function as a primitive, resulting in potentially
   different values, depending on the particular implementation of the
   math library.  We use algorithm 3.4.1.S from [KNUTH], which is free
   of the above-mentioned problem, and which guarantees the same output
   on any implementation.  The algorithm belongs to the ziggurat family
   developed in the 1970s by G. Marsaglia, M. Sibuya, and J. H. Ahrens
   [ZIGG].  It replaces the use of logarithmic function by clever bit
   manipulation, still producing the exponential variates on output.

5.1.  High-Level Description of the Algorithm

   For ease of exposition, the algorithm is first described with all
   arithmetic operations being interpreted in their natural sense.
   Later, exact details on data types, arithmetic, and generation of the
   uniform random variates used by the algorithm are given.  It is an
   almost verbatim quotation from [KNUTH], p.133.

   Algorithm S: Given a real positive number "mu", produce an
   exponential random variate with mean "mu".

   First, the constants

   Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!),  1 <= k <= 11

   are computed in advance.  The exact values which MUST be used by all
   implementations are given in the next section.  This is necessary to
   ensure that exactly the same pseudo-random sequences are produced by
   all implementations.

   S1. [Get U and shift.] Generate a 32-bit uniform random binary

             U = (.b0 b1 b2 ... b31)    [note the binary point]

   Locate the first zero bit b_j and shift off the leading (j+1) bits,
   setting U <- (.b_{j+1} ... b31)

   Note: In the rare case that the zero has not been found, it is
   prescribed that the algorithm return (mu*32*ln2).

   S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and
   terminate the algorithm. (Note that Q[1] = ln2.)
Top   ToC   Page 36
   S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k
   new uniform random binary fractions U1,...,Uk and set V <-

   S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2.

5.2.  Data Types, Representation, and Arithmetic

   The high-level algorithm operates on real numbers, typically
   represented as floating point numbers.  This specification prescribes
   that unsigned 64-bit integers be used instead.

   u_int64_t integers are interpreted as real numbers by placing the
   decimal point after the first 32 bits.  In other words, conceptually,
   the interpretation is given by the following map:

          u_int64_t u;

          u  |--> (double)u / (2**32)

   The algorithm produces a sequence of such u_int64_t integers that,
   for any given value of SID, is guaranteed to be the same on any

   We specify that the u_int64_t representations of the first 11 values
   of the Q array in the high-level algorithm MUST be as follows:

   #1      0xB17217F8,
   #2      0xEEF193F7,
   #3      0xFD271862,
   #4      0xFF9D6DD0,
   #5      0xFFF4CFD0,
   #6      0xFFFEE819,
   #7      0xFFFFE7FF,
   #8      0xFFFFFE2B,
   #9      0xFFFFFFE0,
   #10     0xFFFFFFFE,
   #11     0xFFFFFFFF

   For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32)
   = 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF.

   Small integer j in the high-level algorithm is represented as
   u_int64_t value j * (2**32).

   Operation of addition is done as usual on u_int64_t numbers; however,
   the operation of multiplication in the high-level algorithm should be
   replaced by
Top   ToC   Page 37
      (u, v) |---> (u * v) >> 32.

   Implementations MUST compute the product (u * v) exactly.  For
   example, a fragment of unsigned 128-bit arithmetic can be implemented
   for this purpose (see the sample implementation in Appendix A).

5.3.  Uniform Random Quantities

   The procedure for obtaining a sequence of 32-bit random numbers (such
   as U in algorithm S) relies on using AES encryption in counter mode.
   To describe the exact working of the algorithm, we introduce two
   primitives from Rijndael.  Their prototypes and specification are
   given below, and they are assumed to be provided by the supporting
   Rijndael implementation, such as [RIJN].

   +  A function that initializes a Rijndael key with bytes from seed
      (the SID will be used as the seed):

      void KeyInit(unsigned char seed[16]);

   +  A function that encrypts the 16-octet block inblock with the
      specified key, returning a 16-octet encrypted block.  Here,
      keyInstance is an opaque type used to represent Rijndael keys:

      void BlockEncrypt(keyInstance key, unsigned char inblock[16]);

   Algorithm Unif: given a 16-octet quantity seed, produce a sequence of
   unsigned 32-bit pseudo-random uniformly distributed integers.  In
   OWAMP, the SID (session ID) from Control protocol plays the role of

   U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an
   unsigned 16-octet (network byte order) counter] c <- 0

   U2. [Need more random bytes?]  Set i <- c mod 4.  If (i == 0) set s
   <- BlockEncrypt(key, c)

   U3. [Increment the counter as unsigned 16-octet quantity] c <- c + 1

   U4. [Do output] Output the i_th quartet of octets from s starting
   from high-order octets, converted to native byte order and
   represented as OWPNum64 value (as in 3.b).

   U5. [Loop] Go to step U2.
Top   ToC   Page 38
6.  Security Considerations

6.1.  Introduction

   The goal of authenticated mode is to let one passphrase-protect the
   service provided by a particular OWAMP-Control server.  One can
   imagine a variety of circumstances where this could be useful.
   Authenticated mode is designed to prohibit theft of service.

   An additional design objective of the authenticated mode was to make
   it impossible for an attacker who cannot read traffic between OWAMP-
   Test sender and receiver to tamper with test results in a fashion
   that affects the measurements, but not other traffic.

   The goal of encrypted mode is quite different: to make it hard for a
   party in the middle of the network to make results look "better" than
   they should be.  This is especially true if one of client and server
   does not coincide with either sender or receiver.

   Encryption of OWAMP-Control using AES CBC mode with blocks of HMAC
   after each message aims to achieve two goals: (i) to provide secrecy
   of exchange, and (ii) to provide authentication of each message.

6.2.  Preventing Third-Party Denial of Service

   OWAMP-Test sessions directed at an unsuspecting party could be used
   for denial of service (DoS) attacks.  In unauthenticated mode,
   servers SHOULD limit receivers to hosts they control or to the OWAMP-
   Control client.

   Unless otherwise configured, the default behavior of servers MUST be
   to decline requests where the Receiver Address field is not equal to
   the address that the control connection was initiated from or an
   address of the server (or an address of a host it controls).  Given
   the TCP handshake procedure and sequence numbers in the control
   connection, this ensures that the hosts that make such requests are
   actually those hosts themselves, or at least on the path towards
   them.  If either this test or the handshake procedure were omitted,
   it would become possible for attackers anywhere in the Internet to
   request that large amounts of test packets be directed against victim
   nodes somewhere else.

   In any case, OWAMP-Test packets with a given source address MUST only
   be sent from the node that has been assigned that address (i.e.,
   address spoofing is not permitted).
Top   ToC   Page 39
6.3.  Covert Information Channels

   OWAMP-Test sessions could be used as covert channels of information.
   Environments that are worried about covert channels should take this
   into consideration.

6.4.  Requirement to Include AES in Implementations

   Notice that AES, in counter mode, is used for pseudo-random number
   generation, so implementation of AES MUST be included even in a
   server that only supports unauthenticated mode.

6.5.  Resource Use Limitations

   An OWAMP server can consume resources of various kinds.  The two most
   important kinds of resources are network capacity and memory (primary
   or secondary) for storing test results.

   Any implementation of OWAMP server MUST include technical mechanisms
   to limit the use of network capacity and memory.  Mechanisms for
   managing the resources consumed by unauthenticated users and users
   authenticated with a KeyID and passphrase SHOULD be separate.  The
   default configuration of an implementation MUST enable these
   mechanisms and set the resource use limits to conservatively low

   One way to design the resource limitation mechanisms is as follows:
   assign each session to a user class.  User classes are partially
   ordered with "includes" relation, with one class ("all users") that
   is always present and that includes any other class.  The assignment
   of a session to a user class can be based on the presence of
   authentication of the session, the KeyID, IP address range, time of
   day, and, perhaps, other factors.  Each user class would have a limit
   for usage of network capacity (specified in units of bit/second) and
   memory for storing test results (specified in units of octets).
   Along with the limits for resource use, current use would be tracked
   by the server.  When a session is requested by a user in a specific
   user class, the resources needed for this session are computed: the
   average network capacity use (based on the sending schedule) and the
   maximum memory use (based on the number of packets and number of
   octets each packet would need to be stored internally -- note that
   outgoing sessions would not require any memory use).  These resource
   use numbers are added to the current resource use numbers for the
   given user class; if such addition would take the resource use
   outside of the limits for the given user class, the session is
   rejected.  When resources are reclaimed, corresponding measures are
   subtracted from the current use.  Network capacity is reclaimed as
   soon as the session ends.  Memory is reclaimed when the data is
Top   ToC   Page 40
   deleted.  For unauthenticated sessions, memory consumed by an OWAMP-
   Test session SHOULD be reclaimed after the OWAMP-Control connection
   that initiated the session is closed (gracefully or otherwise).  For
   authenticated sessions, the administrator who configures the service
   should be able to decide the exact policy, but useful policy
   mechanisms that MAY be implemented are the ability to automatically
   reclaim memory when the data is retrieved and the ability to reclaim
   memory after a certain configurable (based on user class) period of
   time passes after the OWAMP-Test session terminates.

6.6.  Use of Cryptographic Primitives in OWAMP

   At an early stage in designing the protocol, we considered using
   Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401]
   as cryptographic security mechanisms for OWAMP; later, we also
   considered DTLS.  The disadvantages of those are as follows (not an
   exhaustive list):

   Regarding TLS:

   +  TLS could be used to secure TCP-based OWAMP-Control, but it would
      be difficult to use it to secure UDP-based OWAMP-Test: OWAMP-Test
      packets, if lost, are not resent, so packets have to be
      (optionally) encrypted and authenticated while retaining
      individual usability.  Stream-based TLS cannot be easily used for

   +  Dealing with streams, TLS does not authenticate individual
      messages (even in OWAMP-Control).  The easiest way out would be to
      add some known-format padding to each message and to verify that
      the format of the padding is intact before using the message.  The
      solution would thus lose some of its appeal ("just use TLS").  It
      would also be much more difficult to evaluate the security of this
      scheme with the various modes and options of TLS; it would almost
      certainly not be secure with all.  The capacity of an attacker to
      replace parts of messages (namely, the end) with random garbage
      could have serious security implications and would need to be
      analyzed carefully.  Suppose, for example, that a parameter that
      is used in some form to control the rate were replaced by random
      garbage; chances are that the result (an unsigned integer) would
      be quite large.

   +  Dependent on the mode of use, one can end up with a requirement
      for certificates for all users and a PKI.  Even if one is to
      accept that PKI is desirable, there just isn't a usable one today.
Top   ToC   Page 41
   +  TLS requires a fairly large implementation.  OpenSSL, for example,
      is larger than our implementation of OWAMP as a whole.  This can
      matter for embedded implementations.

   Regarding DTLS:

   +  Duplication and, similarly, reordering are network phenomena that
      OWAMP needs to be able to measure; yet anti-replay measures and
      reordering protection of DTLS would prevent the duplicated and
      reordered packets from reaching the relevant part of the OWAMP
      code.  One could, of course, modify DTLS so that these protections
      are weakened or even specify examining the messages in a carefully
      crafted sequence somewhere in between DTLS checks; but then, of
      course, the advantage of using an existing protocol would not be

   +  In authenticated mode, the timestamp is in the clear and is not
      protected cryptographically in any way, while the rest of the
      message has the same protection as in encrypted mode.  This mode
      allows one to trade off cryptographic protection against accuracy
      of timestamps.  For example, the APAN hardware implementation of
      OWAMP [APAN] is capable of supporting authenticated mode.  The
      accuracy of these measurements is in the sub-microsecond range.
      The errors in OWAMP measurements of Abilene [Abilene] (done using
      a software implementation, in its encrypted mode) exceed 10us.
      Users in different environments have different concerns, and some
      might very well care about every last microsecond of accuracy.  At
      the same time, users in these same environments might care about
      access control to the service.  Authenticated mode permits them to
      control access to the server yet to use unprotected timestamps,
      perhaps generated by a hardware device.

   Regarding IPsec:

   +  What we now call authenticated mode would not be possible (in
      IPsec you can't authenticate part of a packet).

   +  The deployment paths of IPsec and OWAMP could be separate if OWAMP
      does not depend on IPsec.  After nine years of IPsec, only 0.05%
      of traffic on an advanced backbone network, such as Abilene, uses
      IPsec (for comparison purposes with encryption above layer 4, SSH
      use is at 2-4% and HTTPS use is at 0.2-0.6%).  It is desirable to
      be able to deploy OWAMP on as large a number of different
      platforms as possible.
Top   ToC   Page 42
   +  The deployment problems of a protocol dependent on IPsec would be
      especially acute in the case of lightweight embedded devices.
      Ethernet switches, DSL "modems", and other such devices mostly do
      not support IPsec.

   +  The API for manipulating IPsec from an application is currently
      poorly understood.  Writing a program that needs to encrypt some
      packets, to authenticate some packets, and to leave some open --
      for the same destination -- would become more of an exercise in
      IPsec than in IP measurement.

   For the enumerated reasons, we decided to use a simple cryptographic
   protocol (based on a block cipher in CBC mode) that is different from
   TLS and IPsec.

6.7.  Cryptographic Primitive Replacement

   It might become necessary in the future to replace AES, or the way it
   is used in OWAMP, with a new cryptographic primitive, or to make
   other security-related changes to the protocol.  OWAMP provides a
   well-defined point of extensibility: the Modes word in the server
   greeting and the Mode response in the Set-Up-Response message.  For
   example, if a simple replacement of AES with a different block cipher
   with a 128-bit block is needed, this could be accomplished as
   follows: take two bits from the reserved (MBZ) part of the Modes word
   of the server greeting; use one of these bits to indicate encrypted
   mode with the new cipher and another one to indicate authenticated
   mode with the new cipher.  (Bit consumption could, in fact, be
   reduced from two to one, if the client is allowed to return a mode
   selection with more than a single bit set: one could designate a
   single bit to mean that the new cipher is supported (in the case of
   the server) or selected (in the case of the client) and continue to
   use already allocated bits for authenticated and encrypted modes;
   this optimization is unimportant conceptually, but it could be useful
   in practice to make the best use of bits.)  Then, if the new cipher
   is negotiated, all subsequent operations simply use it instead of
   AES.  Note that the normal transition sequence would be used in such
   a case: implementations would probably first start supporting and
   preferring the new cipher, and then drop support for the old cipher
   (presumably no longer considered secure).
Top   ToC   Page 43
   If the need arises to make more extensive changes (perhaps to replace
   AES with a 256-bit-block cipher), this would be more difficult and
   would require changing the layout of the messages.  However, the
   change can still be conducted within the framework of OWAMP
   extensibility using the Modes/Mode words.  The semantics of the new
   bits (or single bit, if the optimization described above is used)
   would include the change to message layout as well as the change in
   the cryptographic primitive.

   Each of the bits in the Modes word can be used for an independent
   extension.  The extensions signaled by various bits are orthogonal;
   for example, one bit might be allocated to change from AES-128 to
   some other cipher, another bit might be allocated to add a protocol
   feature (such as, e.g., support for measuring over multicast), yet
   another might be allocated to change a key derivation function, etc.
   The progression of versions is not a linear order, but rather a
   partial order.  An implementation can implement any subset of these
   features (of course, features can be made mandatory to implement,
   e.g., new more secure ciphers if they are needed).

   Should a cipher with a different key size (say, a 256-bit key) become
   needed, a new key derivation function for OWAMP-Test keys would also
   be needed.  The semantics of change in the cipher SHOULD then in the
   future be tied to the semantics of change in the key derivation
   function (KDF).  One KDF that might be considered for the purpose
   might be a pseudo-random function (PRF) with appropriately sized
   output, such as 256 bits (perhaps HMAC-SHA256, if it is then still
   considered a secure PRF), which could then be used to derive the
   OWAMP-Test session keys from the OWAMP-Control session key by using
   the OWAMP-Control session key as the HMAC key and the SID as HMAC

   Note that the replacement scheme outlined above is trivially
   susceptible to downgrade attacks: a malicious party in the middle can
   flip modes bits as the mode is negotiated so that the oldest and
   weakest mode supported by the two parties is used.  If this is deemed
   problematic at the time of cryptographic primitive replacement, the
   scheme might be augmented with a measure to prevent such an attack
   (by perhaps exchanging the modes again once a secure communications
   channel is established, comparing the two sets of mode words, and
   dropping the connection should they not match).

6.8.  Long-term Manually Managed Keys

   OWAMP-Control uses long-term keys with manual management.  These keys
   are used to automatically negotiate session keys for each OWAMP-
   Control session running in authenticated or encrypted mode.  The
   number of these keys managed by a server scales linearly with (and,
Top   ToC   Page 44
   in fact, is equal to) the number of administratively different users
   (perhaps particular humans, roles, or robots representing sites) that
   need to connect to this server.  Similarly, the number of different
   manual keys managed by each client is the number of different servers
   that the client needs to connect to.  This use of manual long-term
   keys is compliant with [BCP107].

6.9.  (Not) Using Time as Salt

   A natural idea is to use the current time as salt when deriving
   session keys.  Unfortunately, this appears to be too limiting.

   Although OWAMP is often run on hosts with well-synchronized clocks,
   it is also possible to run it on hosts with clocks completely
   untrained.  The delays obtained thus are, of course, not directly
   usable; however, some metrics, such as unidirectional loss,
   reordering, measures of congestion such as the median delay minus
   minimum, and many others are usable directly and immediately (and
   improve upon the information that would have been provided by a
   round-trip measurement).  Further, even delay information can be
   useful with appropriate post-processing.  Indeed, one can even argue
   that running the clocks free and post-processing the results of a
   mesh of measurements will result in better accuracy, as more
   information is available a posteriori and correlation of data from
   different hosts is possible in post-processing, but not with online
   clock training.

   Given this, time is not used as salt in key derivation.

6.10.  The Use of AES-CBC and HMAC

   OWAMP relies on AES-CBC for confidentiality and on HMAC-SHA1
   truncated to 128 bits for message authentication.  Random IV choice
   is important for prevention of a codebook attack on the first block
   (it should also be noted that, with its 128-bit block size, AES is
   more resistant to codebook attacks than are ciphers with shorter
   blocks; we use random IV anyway).

   HMAC MUST verify.  It is crucial to check for this before using the
   message; otherwise, existential forgery becomes possible.  The
   complete message for which HMAC verification fails MUST be discarded
   (both for short messages consisting of a few blocks and potentially
   for long messages, such as a response to the Fetch-Session command).
   If such a message is part of OWAMP-Control, the connection MUST be

   Since OWAMP messages can have different numbers of blocks, the
   existential forgery attack described in example 9.62 of [MENEZES]
Top   ToC   Page 45
   becomes a concern.  To prevent it (and to simplify implementation),
   the length of any message becomes known after decrypting its first

   A special case is the first (fixed-length) message sent by the
   client.  There, the token is a concatenation of the 128-bit challenge
   (transmitted by the server in the clear), a 128-bit AES Session-key
   (generated randomly by the client, encrypted with AES-CBC with IV=0),
   and a 256-bit HMAC-SHA1 Session-key used for authentication.  Since
   IV=0, the challenge (a single cipher block) is simply encrypted with
   the secret key.  Therefore, we rely on resistance of AES to chosen
   plaintext attacks (as the challenge could be substituted by an
   attacker).  It should be noted that the number of blocks of chosen
   plaintext an attacker can have encrypted with the secret key is
   limited by the number of sessions the client wants to initiate.  An
   attacker who knows the encryption of a server's challenge can produce
   an existential forgery of the session key and thus disrupt the
   session; however, any attacker can disrupt a session by corrupting
   the protocol messages in an arbitrary fashion.  Therefore, no new
   threat is created here; nevertheless, we require that the server
   never issues the same challenge twice.  (If challenges are generated
   randomly, a repetition would occur, on average, after 2^64 sessions;
   we deem this satisfactory as this is enough even for an implausibly
   busy server that participates in 1,000,000 sessions per second to go
   without repetitions for more than 500 centuries.)  With respect to
   the second part of the token, an attacker can produce an existential
   forgery of the session key by modifying the second half of the
   client's token while leaving the first part intact.  This forgery,
   however, would be immediately discovered by the client when the HMAC
   on the server's next message (acceptance or rejection of the
   connection) does not verify.

7.  Acknowledgements

   We would like to thank Guy Almes, Mark Allman, Jari Arkko, Hamid
   Asgari, Steven Van den Berghe, Eric Boyd, Robert Cole, Joan
   Cucchiara, Stephen Donnelly, Susan Evett, Sam Hartman, Kaynam
   Hedayat, Petri Helenius, Scott Hollenbeck, Russ Housley, Kitamura
   Yasuichi, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah,
   Allison Mankin, Al Morton, Attila Pasztor, Randy Presuhn, Matthew
   Roughan, Andy Scherrer, Henk Uijterwaal, and Sam Weiler for their
   comments, suggestions, reviews, helpful discussion and proof-reading.

8.  IANA Considerations

   IANA has allocated a well-known TCP port number (861) for the OWAMP-
   Control part of the OWAMP protocol.
Top   ToC   Page 46
9.  Internationalization Considerations

   The protocol does not carry any information in a natural language,
   with the possible exception of the KeyID in OWAMP-Control, which is
   encoded in UTF-8.

10.  References

10.1.  Normative References

   [AES]           Advanced Encryption Standard (AES),

   [BCP107]        Bellovin, S. and R. Housley, "Guidelines for
                   Cryptographic Key Management", BCP 107, RFC 4107,
                   June 2005.

   [RFC2104]       Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
                   Keyed-Hashing for Message Authentication", RFC 2104,
                   February 1997.

   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2330]       Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
                   "Framework for IP Performance Metrics", RFC 2330, May

   [RFC2474]       Nichols, K., Blake, S., Baker, F., and D. Black,
                   "Definition of the Differentiated Services Field (DS
                   Field) in the IPv4 and IPv6 Headers", RFC 2474,
                   December 1998.

   [RFC2679]       Almes, G., Kalidindi, S., and M. Zekauskas, "A One-
                   way Delay Metric for IPPM", RFC 2679, September 1999.

   [RFC2680]       Almes, G., Kalidindi, S., and M. Zekauskas, "A One-
                   way Packet Loss Metric for IPPM", RFC 2680, September

   [RFC2836]       Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop
                   Behavior Identification Codes", RFC 2836, May 2000.

   [RFC2898]       Kaliski, B., "PKCS #5: Password-Based Cryptography
                   Specification Version 2.0", RFC 2898, September 2000.
Top   ToC   Page 47
10.2.  Informative References

   [APAN]          Z. Shu and K. Kobayashi, "HOTS: An OWAMP-Compliant
                   Hardware Packet Timestamper", In Proceedings of PAM

   [BRIX]          Brix Networks,

   [ZIGG]          J. H. Ahrens, U. Dieter, "Computer methods for
                   sampling from the exponential and normal
                   distributions", Communications of ACM, volume 15,
                   issue 10, 873-882, 1972.

   [MENEZES]       A. J. Menezes, P. C. van Oorschot, and S. A.
                   Vanstone, Handbook of Applied Cryptography, CRC
                   Press, revised reprint with updates, 1997.

   [KNUTH]         D. Knuth, The Art of Computer Programming, vol.2, 3rd
                   edition, 1998.

   [Abilene]       One-way Latency Measurement (OWAMP),

   [RIJN]          Reference ANSI C Implementation of Rijndael,

   [RIPE]          RIPE NCC Test-Traffic Measurements home,

   [SURVEYOR]      Surveyor Home Page,

   [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, "Surveyor: An
                   Infrastructure for Network Performance Measurements",
                   Proceedings of INET'99, June 1999.

   [RFC1305]       Mills, D., "Network Time Protocol (Version 3)
                   Specification, Implementation and Analysis", RFC
                   1305, March 1992.

   [RFC2246]       Dierks, T. and C. Allen, "The TLS Protocol Version
                   1.0", RFC 2246, January 1999.
Top   ToC   Page 48
   [RFC2401]       Kent, S. and R. Atkinson, "Security Architecture for
                   the Internet Protocol", RFC 2401, November 1998.

   [RFC3546]       Blake-Wilson, S., Nystrom, M., Hopwood, D.,
                   Mikkelsen, J., and T. Wright, "Transport Layer
                   Security (TLS) Extensions", RFC 3546, June 2003.

   [RFC4086]       Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                   "Randomness Requirements for Security", BCP 106, RFC
                   4086, June 2005.
Top   ToC   Page 49
Appendix A: Sample C Code for Exponential Deviates

   The values in array Q[] are the exact values that MUST be used by all
   implementations (see Sections 5.1 and 5.2).  This appendix only
   serves for illustrative purposes.

   ** Example usage: generate a stream of exponential (mean 1)
   ** random quantities (ignoring error checking during initialization).
   ** If a variate with some mean mu other than 1 is desired, the output
   ** of this algorithm can be multiplied by mu according to the rules
   ** of arithmetic we described.

   ** Assume that a 16-octet 'seed' has been initialized
   ** (as the shared secret in OWAMP, for example)
   ** unsigned char seed[16];

   ** OWPrand_context next;

   ** (initialize state)
   ** OWPrand_context_init(&next, seed);

   ** (generate a sequence of exponential variates)
   ** while (1) {
   **    u_int64_t num = OWPexp_rand64(&next);
         <do something with num here>
   ** }

   #include <stdlib.h>

   typedef u_int64_t u_int64_t;

   /* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */
   #define K 12

   #define BIT31   0x80000000UL    /* See if first bit in the lower
                                      32 bits is zero. */
   #define MASK32(n)       ((n) & 0xFFFFFFFFUL)

   #define EXP2POW32       0x100000000ULL

   typedef struct OWPrand_context {
           unsigned char counter[16];/* Counter (network byte order).*/
           keyInstance key;          /* Key to encrypt the counter.*/
           unsigned char out[16];    /* The encrypted block.*/
Top   ToC   Page 50
   } OWPrand_context;

   ** The array has been computed according to the formula:
   **       Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!)
   ** as described in algorithm S. (The values below have been
   ** multiplied by 2^32 and rounded to the nearest integer.)
   ** These exact values MUST be used so that different implementation
   ** produce the same sequences.
   static u_int64_t Q[K] = {
           0,        /* Placeholder - so array indices start from 1. */

   /* this element represents ln2 */
   #define LN2 Q[1]

   ** Convert an unsigned 32-bit integer into a u_int64_t number.
   OWPulong2num64(u_int32_t a)
           return ((u_int64_t)1 << 32) * a;

   ** Arithmetic functions on u_int64_t numbers.

   ** Addition.
   OWPnum64_add(u_int64_t x, u_int64_t y)
Top   ToC   Page 51
           return x + y;

   ** Multiplication.  Allows overflow.  Straightforward implementation
   ** of Algorithm 4.3.1.M (p.268) from [KNUTH].
   OWPnum64_mul(u_int64_t x, u_int64_t y)
           unsigned long w[4];
           u_int64_t xdec[2];
           u_int64_t ydec[2];

           int i, j;
           u_int64_t k, t, ret;

           xdec[0] = MASK32(x);
           xdec[1] = MASK32(x>>32);
           ydec[0] = MASK32(y);
           ydec[1] = MASK32(y>>32);

           for (j = 0; j < 4; j++)
                   w[j] = 0;

           for (j = 0; j < 2; j++) {
                   k = 0;
                   for (i = 0; ; ) {
                           t = k + (xdec[i]*ydec[j]) + w[i + j];
                           w[i + j] = t%EXP2POW32;
                           k = t/EXP2POW32;
                           if (++i < 2)
                           else {
                                   w[j + 2] = k;

           ret = w[2];
           ret <<= 32;
           return w[1] + ret;

Top   ToC   Page 52
   ** Seed the random number generator using a 16-byte quantity 'seed'
   ** (== the session ID in OWAMP). This function implements step U1
   ** of algorithm Unif.

   OWPrand_context_init(OWPrand_context *next, unsigned char *seed)
           int i;

           /* Initialize the key */
           rijndaelKeyInit(next->key, seed);

           /* Initialize the counter with zeros */
           memset(next->out, 0, 16);
           for (i = 0; i < 16; i++)
                   next->counter[i] = 0UL;

   ** Random number generating functions.

   ** Generate and return a 32-bit uniform random value (saved in the
   **less significant half of the u_int64_t).  This function implements
   **steps U2-U4 of the algorithm Unif.
   OWPunif_rand64(OWPrand_context *next)
           int j;
           u_int8_t  *buf;
           u_int64_t  ret = 0;

           /* step U2 */
           u_int8_t i = next->counter[15] & (u_int8_t)3;
           if (!i)
                   rijndaelEncrypt(next->key, next->counter, next->out);

           /* Step U3.  Increment next.counter as a 16-octet single
              quantity in network byte order for AES counter mode. */
           for (j = 15; j >= 0; j--)
                   if (++next->counter[j])

           /* Step U4.  Do output.  The last 4 bytes of ret now contain
Top   ToC   Page 53
              the random integer in network byte order */
           buf = &next->out[4*i];
           for (j=0; j<4; j++) {
                   ret <<= 8;
                   ret += *buf++;
           return ret;

   ** Generate an exponential deviate with mean 1.
   OWPexp_rand64(OWPrand_context *next)
           unsigned long i, k;
           u_int32_t j = 0;
           u_int64_t U, V, J, tmp;

           /* Step S1. Get U and shift */
           U = OWPunif_rand64(next);

           while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */
                   U <<= 1;
           /* Remove the 0 itself. */
           U <<= 1;

           U = MASK32(U);  /* Keep only the fractional part. */
           J = OWPulong2num64(j);

           /* Step S2.  Immediate acceptance? */
           if (U < LN2)       /* return  (j*ln2 + U) */
                   return OWPnum64_add(OWPnum64_mul(J, LN2), U);

           /* Step S3.  Minimize. */
           for (k = 2; k < K; k++)
                   if (U < Q[k])
           V = OWPunif_rand64(next);
           for (i = 2; i <= k; i++) {
                   tmp = OWPunif_rand64(next);
                   if (tmp < V)
                           V = tmp;

           /* Step S4.  Return (j+V)*ln2 */
Top   ToC   Page 54
           return OWPnum64_mul(OWPnum64_add(J, V), LN2);

Appendix B: Test Vectors for Exponential Deviates

   It is important that the test schedules generated by different
   implementations from identical inputs be identical.  The non-trivial
   part is the generation of pseudo-random exponentially distributed
   deviates.  To aid implementors in verifying interoperability, several
   test vectors are provided.  For each of the four given 128-bit values
   of SID represented as hexadecimal numbers, 1,000,000 exponentially
   distributed 64-bit deviates are generated as described above.  As
   they are generated, they are all added to each other.  The sum of all
   1,000,000 deviates is given as a hexadecimal number for each SID.  An
   implementation MUST produce exactly these hexadecimal numbers.  To
   aid in the verification of the conversion of these numbers to values
   of delay in seconds, approximate values are given (assuming
   lambda=1).  An implementation SHOULD produce delay values in seconds
   that are close to the ones given below.

       SID = 0x2872979303ab47eeac028dab3829dab2
       SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds)

       SID = 0x0102030405060708090a0b0c0d0e0f00
       SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds)

       SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef
       SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)

       SID = 0xfeed0feed1feed2feed3feed4feed5ab
       SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)
Top   ToC   Page 55
Authors' Addresses

   Stanislav Shalunov
   1000 Oakbrook Drive, Suite 300
   Ann Arbor, MI 48104


   Benjamin Teitelbaum
   1000 Oakbrook Drive, Suite 300
   Ann Arbor, MI 48104


   Anatoly Karp
   Computer Sciences Department
   University of Wisconsin-Madison
   Madison, WI 53706


   Jeff W. Boote
   1000 Oakbrook Drive, Suite 300
   Ann Arbor, MI 48104


   Matthew J. Zekauskas
   1000 Oakbrook Drive, Suite 300
   Ann Arbor, MI 48104

Top   ToC   Page 56
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).