draft-ietf-ippm-owdp-16.txt   rfc4656.txt 
Network Working Group Stanislav Shalunov Network Working Group S. Shalunov
Internet Draft Benjamin Teitelbaum Request for Comments: 4656 B. Teitelbaum
Expiration Date: August 2006 Anatoly Karp Category: Standards Track A. Karp
Jeff W. Boote J. Boote
Matthew J. Zekauskas M. Zekauskas
Internet2 Internet2
February 2006 September 2006
A One-way Active Measurement Protocol (OWAMP) A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-16.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
With growing availability of good time sources to network nodes, it The One-Way Active Measurement Protocol (OWAMP) measures
becomes increasingly possible to measure one-way IP performance unidirectional characteristics such as one-way delay and one-way
metrics with high precision. To do so in an interoperable manner, a loss. High-precision measurement of these one-way IP performance
common protocol for such measurements is required. The One-Way metrics became possible with wider availability of good time sources
Active Measurement Protocol (OWAMP) can measure one-way delay, as (such as GPS and CDMA). OWAMP enables the interoperability of these
well as other unidirectional characteristics, such as one-way loss. measurements.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Relationship of Test and Control Protocols . . . . . . 4 1.1. Relationship of Test and Control Protocols .................3
1.2. Logical Model . . . . . . . . . . . . . . . . . . . . 5 1.2. Logical Model ..............................................4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview ...............................................5
3. OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . 7 3. OWAMP-Control ...................................................6
3.1. Connection Setup . . . . . . . . . . . . . . . . . . . 7 3.1. Connection Setup ...........................................6
3.2. Integrity Protection (HMAC) . . . . . . . . . . . . . 12 3.2. Integrity Protection (HMAC) ...............................11
3.3. Values of the Accept Field . . . . . . . . . . . . . . 12 3.3. Values of the Accept Field ................................11
3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 13 3.4. OWAMP-Control Commands ....................................12
3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 14 3.5. Creating Test Sessions ....................................13
3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 19 3.6. Send Schedules ............................................18
3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 20 3.7. Starting Test Sessions ....................................19
3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 21 3.8. Stop-Sessions .............................................20
3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 24 3.9. Fetch-Session .............................................24
4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 29
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 29
4.1.2. OWAMP-Test Packet Format and Content . . . . . . 30
4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 34
5. Computing Exponentially Distributed Pseudo-Random Numbers . 35
5.1. High-Level Description of the Algorithm . . . . . . . 36
5.2. Data Types, Representation, and Arithmetic . . . . . . 36
5.3. Uniform Random Quantities . . . . . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . . 39
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 39
6.2. Preventing Third-Party Denial of Service . . . . . . . 39
6.3. Covert Information Channels . . . . . . . . . . . . . 40
6.4. Requirement to Include AES in Implementations . . . . 40
6.5. Resource Use Limitations . . . . . . . . . . . . . . . 40
6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 41
6.7. Cryptographic primitive replacement . . . . . . . . . 43
6.8. Long-term manually managed keys . . . . . . . . . . . 44
6.9. (Not) Using Time as Salt . . . . . . . . . . . . . . . 45
6.10. The Use of AES-CBC and HMAC . . . . . . . . . . . . . 45
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46
8. Internationalization Considerations . . . . . . . . . . . . 46
9. Appendix A: Sample C Code for Exponential Deviates . . . . 47
10. Appendix B: Test Vectors for Exponential Deviates . . . . 52
11. Normative References . . . . . . . . . . . . . . . . . . . 52
12. Informative References . . . . . . . . . . . . . . . . . . 53
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 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
The IETF IP Performance Metrics (IPPM) working group has proposed 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has defined
metrics for one-way packet delay [RFC2679] and loss [RFC2680] across metrics for one-way packet delay [RFC2679] and loss [RFC2680] across
Internet paths. Although there are now several measurement platforms Internet paths. Although there are now several measurement platforms
that implement collection of these metrics [SURVEYOR] [RIPE] [BRIX], that implement collection of these metrics [SURVEYOR] [SURVEYOR-INET]
there is not currently a standard that would permit initiation of [RIPE] [BRIX], there is not currently a standard that would permit
test streams or exchange of packets to collect singleton metrics in initiation of test streams or exchange of packets to collect
an interoperable manner. singleton metrics in an interoperable manner.
With the increasingly wide availability of affordable global With the increasingly wide availability of affordable global
positioning systems (GPS) and CDMA-based time sources, hosts positioning systems (GPS) and CDMA-based time sources, hosts
increasingly have available to them very accurate time increasingly have available to them very accurate time sources,
sources--either directly or through their proximity to Network Time either directly or through their proximity to Network Time Protocol
Protocol (NTP) primary (stratum 1) time servers. By standardizing a (NTP) primary (stratum 1) time servers. By standardizing a technique
technique for collecting IPPM one-way active measurements, we hope to for collecting IPPM one-way active measurements, we hope to create an
create an environment where IPPM metrics may be collected across a environment where IPPM metrics may be collected across a far broader
far broader mesh of Internet paths than is currently possible. One mesh of Internet paths than is currently possible. One particularly
particularly compelling vision is of widespread deployment of open compelling vision is of widespread deployment of open OWAMP servers
OWAMP servers that would make measurement of one-way delay as that would make measurement of one-way delay as commonplace as
commonplace as measurement of round-trip time using an ICMP-based measurement of round-trip time using an ICMP-based tool like ping.
tool like ping.
Additional design goals of OWAMP include: being hard to detect and Additional design goals of OWAMP include: being hard to detect and
manipulate, security, logical separation of control and test manipulate, security, logical separation of control and test
functionality, and support for small test packets. (Being hard to functionality, and support for small test packets. (Being hard to
detect makes interference with measurements more difficult for detect makes interference with measurements more difficult for
intermediaries in the middle of the network.) intermediaries in the middle of the network.)
OWAMP test traffic is hard to detect because it is simply a stream of OWAMP test traffic is hard to detect because it is simply a stream of
UDP packets from and to negotiated port numbers, with potentially UDP packets from and to negotiated port numbers, with potentially
nothing static in the packets (size is negotiated, as well). OWAMP nothing static in the packets (size is negotiated, as well). OWAMP
also supports an encrypted mode that further obscures the traffic, at also supports an encrypted mode that further obscures the traffic and
the same time making it impossible to alter timestamps undetectably. makes it impossible to alter timestamps undetectably.
Security features include optional authentication and/or encryption Security features include optional authentication and/or encryption
of control and test messages. These features may be useful to of control and test messages. These features may be useful to
prevent unauthorized access to results or man-in-the-middle attackers prevent unauthorized access to results or man-in-the-middle attacks
who attempt to provide special treatment to OWAMP test streams or who that attempt to provide special treatment to OWAMP test streams or
attempt to modify sender-generated timestamps to falsify test that attempt to modify sender-generated timestamps to falsify test
results. results.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" In this document, the key words "MUST", "REQUIRED", "SHOULD",
in this document are to be interpreted as described in [RFC2119]. "RECOMMENDED", and "MAY" are to be interpreted as described in
[RFC2119].
1.1. Relationship of Test and Control Protocols 1.1. Relationship of Test and Control Protocols
OWAMP actually consists of two inter-related protocols: OWAMP-Control OWAMP actually consists of two inter-related protocols: OWAMP-Control
and OWAMP-Test. OWAMP-Control is used to initiate, start, and stop and OWAMP-Test. OWAMP-Control is used to initiate, start, and stop
test sessions and fetch their results, while OWAMP-Test is used to test sessions and to fetch their results, whereas OWAMP-Test is used
exchange test packets between two measurement nodes. to exchange test packets between two measurement nodes.
Although OWAMP-Test may be used in conjunction with a control Although OWAMP-Test may be used in conjunction with a control
protocol other than OWAMP-Control, the authors have deliberately protocol other than OWAMP-Control, the authors have deliberately
chosen to include both protocols in the same draft to encourage the chosen to include both protocols in the same RFC to encourage the
implementation and deployment of OWAMP-Control as a common implementation and deployment of OWAMP-Control as a common
denominator control protocol for one-way active measurements. Having denominator control protocol for one-way active measurements. Having
a complete and open one-way active measurement solution that is a complete and open one-way active measurement solution that is
simple to implement and deploy is crucial to assuring a future in simple to implement and deploy is crucial to ensuring a future in
which inter-domain one-way active measurement could become as which inter-domain one-way active measurement could become as
commonplace as ping. We neither anticipate nor recommend that commonplace as ping. We neither anticipate nor recommend that
OWAMP-Control form the foundation of a general-purpose extensible OWAMP-Control form the foundation of a general-purpose extensible
measurement and monitoring control protocol. measurement and monitoring control protocol.
OWAMP-Control is designed to support the negotiation of one-way OWAMP-Control is designed to support the negotiation of one-way
active measurement sessions and results retrieval in a active measurement sessions and results retrieval in a
straightforward manner. At session initiation, there is a negotiation straightforward manner. At session initiation, there is a
of sender and receiver addresses and port numbers, session start negotiation of sender and receiver addresses and port numbers,
time, session length, test packet size, the mean Poisson sampling session start time, session length, test packet size, the mean
interval for the test stream, and some attributes of the very general Poisson sampling interval for the test stream, and some attributes of
RFC 2330 notion of packet type, including packet size and per-hop the very general [RFC 2330] notion of packet type, including packet
behavior (PHB) [RFC2474], which could be used to support the size and per-hop behavior (PHB) [RFC2474], which could be used to
measurement of one-way network characteristics across differentiated support the measurement of one-way network characteristics across
services networks. Additionally, OWAMP-Control supports per-session differentiated services networks. Additionally, OWAMP-Control
encryption and authentication for both test and control traffic, supports per-session encryption and authentication for both test and
measurement servers that can act as proxies for test stream control traffic, measurement servers that can act as proxies for test
endpoints, and the exchange of a seed value for the pseudo-random stream endpoints, and the exchange of a seed value for the pseudo-
Poisson process that describes the test stream generated by the random Poisson process that describes the test stream generated by
sender. the sender.
We believe that OWAMP-Control can effectively support one-way active We believe that OWAMP-Control can effectively support one-way active
measurement in a variety of environments, from publicly accessible measurement in a variety of environments, from publicly accessible
measurement beacons running on arbitrary hosts to network monitoring measurement beacons running on arbitrary hosts to network monitoring
deployments within private corporate networks. If integration with deployments within private corporate networks. If integration with
Simple Network Management Protocol (SNMP) or proprietary network Simple Network Management Protocol (SNMP) or proprietary network
management protocols is required, gateways may be created. management protocols is required, gateways may be created.
1.2. Logical Model 1.2. Logical Model
Several roles are logically separated to allow for broad flexibility Several roles are logically separated to allow for broad flexibility
in use. Specifically, we define: in use. Specifically, we define the following:
Session-Sender the sending endpoint of an OWAMP-Test session; Session-Sender The sending endpoint of an OWAMP-Test session;
Session-Receiver the receiving 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 Server An end system that manages one or more OWAMP-Test
sessions, is capable of configuring per-session sessions, is capable of configuring per-session
state in session endpoints, and is capable of state in session endpoints, and is capable of
returning the results of a test session; returning the results of a test session;
Control-Client an end system that initiates requests for Control-Client An end system that initiates requests for
OWAMP-Test sessions, triggers the start of a set OWAMP-Test sessions, triggers the start of a set
of sessions, and may trigger their termination; and of sessions, and may trigger their termination;
and
Fetch-Client an end system that initiates requests to fetch Fetch-Client An end system that initiates requests to fetch
the results of completed OWAMP-Test sessions. the results of completed OWAMP-Test sessions.
One possible scenario of relationships between these roles is shown One possible scenario of relationships between these roles is shown
below. below.
+----------------+ +------------------+ +----------------+ +------------------+
| Session-Sender |--OWAMP-Test-->| Session-Receiver | | Session-Sender |--OWAMP-Test-->| Session-Receiver |
+----------------+ +------------------+ +----------------+ +------------------+
^ ^ ^ ^
| | | |
skipping to change at page 5, line 48 skipping to change at page 5, line 27
| +----------------+ | | +----------------+ |
| ^ | | ^ |
| | | | | |
| OWAMP-Control OWAMP-Control | OWAMP-Control OWAMP-Control
| | | | | |
v v v v v v
+----------------+ +-----------------+ +----------------+ +-----------------+
| Control-Client | | Fetch-Client | | Control-Client | | Fetch-Client |
+----------------+ +-----------------+ +----------------+ +-----------------+
(Unlabeled links in the figure are unspecified by this draft and may (Unlabeled links in the figure are unspecified by this document and
be proprietary protocols.) may be proprietary protocols.)
Different logical roles can be played by the same host. For example, Different logical roles can be played by the same host. For example,
in the figure above, there could actually be only two hosts: one in the figure above, there could actually be only two hosts: one
playing the roles of Control-Client, Fetch-Client, and playing the roles of Control-Client, Fetch-Client, and Session-
Session-Sender, and the other playing the roles of Server and Sender, and the other playing the roles of Server and Session-
Session-Receiver. This is shown below. Receiver. This is shown below.
+-----------------+ +------------------+ +-----------------+ +------------------+
| Control-Client |<--OWAMP-Control-->| Server | | Control-Client |<--OWAMP-Control-->| Server |
| Fetch-Client | | | | Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver | | Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+ +-----------------+ +------------------+
Finally, because many Internet paths include segments that transport Finally, because many Internet paths include segments that transport
IP over ATM, delay and loss measurements can include the effects of IP over ATM, delay and loss measurements can include the effects of
ATM segmentation and reassembly (SAR). Consequently, OWAMP has been ATM segmentation and reassembly (SAR). Consequently, OWAMP has been
designed to allow for small test packets that would fit inside the designed to allow for small test packets that would fit inside the
payload of a single ATM cell (this is only achieved in payload of a single ATM cell (this is only achieved in
unauthenticated mode). unauthenticated mode).
2. Protocol Overview 2. Protocol Overview
As described above, OWAMP consists of two inter-related protocols: As described above, OWAMP consists of two inter-related protocols:
OWAMP-Control and OWAMP-Test. The former is layered over TCP and is OWAMP-Control and OWAMP-Test. The former is layered over TCP and is
used to initiate and control measurement sessions and to fetch their used to initiate and control measurement sessions and to fetch their
results. The latter protocol is layered over UDP and is used to send results. The latter protocol is layered over UDP and is used to send
singleton measurement packets along the Internet path under test. singleton measurement packets along the Internet path under test.
The initiator of the measurement session establishes a TCP connection The initiator of the measurement session establishes a TCP connection
to a well-known port XXX on the target point and this 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 remains open for the duration of the OWAMP-Test sessions. An OWAMP
server SHOULD listen to this well-known port. [RFC Editor: IANA is server SHOULD listen to this well-known port.
requested to allocate a well-known port number for OWAMP-Control
sessions. Please replace ``XXX'' with the value assigned by IANA.]
OWAMP-Control messages are transmitted only before OWAMP-Test OWAMP-Control messages are transmitted only before OWAMP-Test
sessions are actually started and after they complete (with the sessions are actually started and after they are completed (with the
possible exception of an early Stop-Sessions message). possible exception of an early Stop-Sessions message).
The OWAMP-Control and OWAMP-Test protocols support three modes of The OWAMP-Control and OWAMP-Test protocols support three modes of
operation: unauthenticated, authenticated, and encrypted. The operation: unauthenticated, authenticated, and encrypted. The
authenticated or encrypted modes require endpoints to possess a authenticated or encrypted modes require that endpoints possess a
shared secret. shared secret.
All multi-octet quantities defined in this document are represented All multi-octet quantities defined in this document are represented
as unsigned integers in network byte order unless specified as unsigned integers in network byte order unless specified
otherwise. otherwise.
3. OWAMP-Control 3. OWAMP-Control
Each type of OWAMP-Control message has a fixed length. The recipient The type of each OWAMP-Control message can be found after reading the
will know the full length of a message after examining the first 16 first 16 octets. The length of each OWAMP-Control message can be
octets of it. No message is shorter than 16 octets. computed upon reading its fixed-size part. No message is shorter
than 16 octets.
An implementation SHOULD expunge unused state to prevent denial-of- An implementation SHOULD expunge unused state to prevent denial-of-
service attacks, or unbounded memory usage, on the server. For service attacks, or unbounded memory usage, on the server. For
example, if the full control message is not received within some example, if the full control message is not received within some
number of minutes after it is expected, the TCP connection associated number of minutes after it is expected, the TCP connection associated
with the OWAMP-Control session SHOULD be dropped. In absence of with the OWAMP-Control session SHOULD be dropped. In absence of
other considerations, 30 minutes seems like a reasonable upper bound. other considerations, 30 minutes seems like a reasonable upper bound.
3.1. Connection Setup 3.1. Connection Setup
Before either a Control-Client or a Fetch-Client can issue commands Before either a Control-Client or a Fetch-Client can issue commands
of a Server, it has to establish a connection to the server. 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 First, a client opens a TCP connection to the server on a well-known
port XXX. The server responds with a server greeting: [RFC Editor: port 861. The server responds with a server greeting:
Please replace ``XXX'' with the well-known port value assigned by
IANA.]
0 1 2 3 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 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) | | Unused (12 octets) |
| | | |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes | | Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 9, line 5 skipping to change at page 8, line 5
Salt and Count are parameters used in deriving a key from a shared Salt and Count are parameters used in deriving a key from a shared
secret as described below. secret as described below.
Salt MUST be generated pseudo-randomly (independently of anything Salt MUST be generated pseudo-randomly (independently of anything
else in this document). else in this document).
Count MUST be a power of 2. Count MUST be at least 1024. Count Count MUST be a power of 2. Count MUST be at least 1024. Count
SHOULD be increased as more computing power becomes common. SHOULD be increased as more computing power becomes common.
If Modes value is zero, the server does not wish to communicate with If the Modes value is zero, the server does not wish to communicate
the client and MAY close the connection immediately. The client with the client and MAY close the connection immediately. The client
SHOULD close the connection if it receives a greeting with Modes SHOULD close the connection if it receives a greeting with Modes
equal to zero. The client MAY close the connection if the client's equal to zero. The client MAY close the connection if the client's
desired mode is unavailable. desired mode is unavailable.
Otherwise, the client MUST respond with the following Set-Up-Response Otherwise, the client MUST respond with the following Set-Up-Response
message: message:
0 1 2 3 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 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 | | Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. KeyID (80 octets) . . KeyID (80 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Token (32 octets) . . Token (64 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Client-IV (16 octets) . . Client-IV (16 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 4 skipping to change at page 9, line 6
one bit that is set within the last three bits, this bit MUST 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 indicate a mode that the server agreed to use (i.e., the same bit
MUST have been set by the server in the server greeting). The first MUST have been set by the server in the server greeting). The first
29 bits of Mode MUST be zero. A server MUST ignore the values of the 29 bits of Mode MUST be zero. A server MUST ignore the values of the
first 29 bits. If zero Mode bits are set by the client, the client first 29 bits. If zero Mode bits are set by the client, the client
indicates that it will not continue with the session; in this case, indicates that it will not continue with the session; in this case,
the client and the server SHOULD close the TCP connection associated the client and the server SHOULD close the TCP connection associated
with the OWAMP-Control session. with the OWAMP-Control session.
In unauthenticated mode, KeyID, Token, and Client-IV are unused. In unauthenticated mode, KeyID, Token, and Client-IV are unused.
Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the
string is shorter, it is padded with zero octets), that tells the string is shorter, it is padded with zero octets), that tells the
server which shared secret the client wishes to use to authenticate server which shared secret the client wishes to use to authenticate
or encrypt, while Token is the concatenation of a 16-octet challenge or encrypt, while Token is the concatenation of a 16-octet challenge,
and a 16-octet Session-key, encrypted using the AES (Advanced a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-
Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption SHA1 Session-key used for authentication. The token itself is
MUST be performed using an Initialization Vector (IV) of zero and a encrypted using the AES (Advanced Encryption Standard) [AES] in
key derived from the shared secret associated with KeyID. (Both the Cipher Block Chaining (CBC). Encryption MUST be performed using an
server and the client use the same mappings from KeyIDs to shared Initialization Vector (IV) of zero and a key derived from the shared
secrets. The server, being prepared to conduct sessions with more secret associated with KeyID. (Both the server and the client use
than one client, uses KeyIDs to choose the appropriate secret key; a the same mappings from KeyIDs to shared secrets. The server, being
client would typically have different secret keys for different prepared to conduct sessions with more than one client, uses KeyIDs
servers. The situation is analogous to that with passwords.) to choose the appropriate secret key; a client would typically have
different secret keys for different servers. The situation is
analogous to that with passwords.)
The shared secret is a passphrase; it MUST not contain newlines. The The shared secret is a passphrase; it MUST not contain newlines. The
secret key is derived from the passphrase using a password-based key secret key is derived from the passphrase using a password-based key
derivation function PBKDF2 (PKCS #5) [RFC2898]. The PBKDF2 function derivation function PBKDF2 (PKCS #5) [RFC2898]. The PBKDF2 function
requires several parameters: the PRF is HMAC-SHA1 [RFC2104]; the salt requires several parameters: the PRF is HMAC-SHA1 [RFC2104]; the salt
and count are as transmitted by the server. and count are as transmitted by the server.
Session-key and Client-IV are generated randomly by the client. AES Session-key, HMAC Session-key and Client-IV are generated
Session-key MUST be generated with sufficient entropy not to reduce randomly by the client. AES Session-key and HMAC Session-key MUST be
the security of the underlying cipher [RFC4086]. Client-IV merely generated with sufficient entropy not to reduce the security of the
needs to be unique (i.e., it MUST never be repeated for different underlying cipher [RFC4086]. Client-IV merely needs to be unique
sessions using the same secret key; a simple way to achieve that (i.e., it MUST never be repeated for different sessions using the
without the use of cumbersome state is to generate the Client-IV same secret key; a simple way to achieve that without the use of
values using a cryptographically secure pseudo-random number source: cumbersome state is to generate the Client-IV values using a
if this is done, the first repetition is unlikely to occur before cryptographically secure pseudo-random number source: if this is
2^64 sessions with the same secret key are conducted). done, the first repetition is unlikely to occur before 2^64 sessions
with the same secret key are conducted).
The server MUST respond with the following Server-Start message: The server MUST respond with the following Server-Start message:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MBZ (15 octets) | | MBZ (15 octets) |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
skipping to change at page 11, line 27 skipping to change at page 10, line 29
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time (Timestamp) | | Start-Time (Timestamp) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MBZ parts MUST be zero. The client MUST ignore their value. MBZ The MBZ parts MUST be zero. The client MUST ignore their value. MBZ
(MUST be zero) fields here and hereafter have the same semantics: the (MUST be zero) fields here and after have the same semantics: the
party that sends the message MUST set the field so that all bits are party that sends the message MUST set the field so that all bits are
equal to zero; the party that interprets the message MUST ignore the equal to zero; the party that interprets the message MUST ignore the
value. (This way the field could be used for future extensions.) value. (This way, the field could be used for future extensions.)
Server-IV is generated randomly by the server. In unauthenticated Server-IV is generated randomly by the server. In unauthenticated
mode, Server-IV is unused. mode, Server-IV is unused.
The Accept field indicates the server's willingness to continue The Accept field indicates the server's willingness to continue
communication. A zero value in the Accept field means that the communication. A zero value in the Accept field means that the
server accepts the authentication and is willing to conduct further server accepts the authentication and is willing to conduct further
transactions. Non-zero values indicate that the server does not transactions. Non-zero values indicate that the server does not
accept the authentication or, for some other reason, is not willing accept the authentication or, for some other reason, is not willing
to conduct further transactions in this OWAMP-Control session. The to conduct further transactions in this OWAMP-Control session. The
full list of available Accept values is described in Section 3.3, full list of available Accept values is described in Section 3.3,
``Values of the Accept Field''. "Values of the Accept Field".
If a negative (non-zero) response is sent, the server MAY and the If a negative (non-zero) response is sent, the server MAY (and the
client SHOULD close the connection after this message. client SHOULD) close the connection after this message.
Start-Time is a timestamp representing the time when the current Start-Time is a timestamp representing the time when the current
instantiation of the server started operating. (For example, in a instantiation of the server started operating. (For example, in a
multi-user general purpose operating system (OS), it could be the multi-user general purpose operating system, it could be the time
time when the server process was started.) If Accept is non-zero, when the server process was started.) If Accept is non-zero, Start-
Start-Time SHOULD be set so that all of its bits are zeros. In Time SHOULD be set so that all of its bits are zeros. In
authenticated and encrypted modes, Start-Time is encrypted as authenticated and encrypted modes, Start-Time is encrypted as
described in the next section, unless Accept is non-zero. described in Section 3.4, "OWAMP-Control Commands", unless Accept is
(Authenticated and encrypted mode cannot be entered unless the non-zero. (Authenticated and encrypted mode cannot be entered unless
control connection can be initialized.) the control connection can be initialized.)
Timestamp format is described in Section 4.1.2. The same Timestamp format is described in Section 4.1.2. The same
instantiation of the server SHOULD report the same exact Start-Time instantiation of the server SHOULD report the same exact Start-Time
value to each client in each session. value to each client in each session.
The previous transactions constitute connection setup. The previous transactions constitute connection setup.
3.2. Integrity Protection (HMAC) 3.2. Integrity Protection (HMAC)
Authentication of each message (also referred to as a command in this Authentication of each message (also referred to as a command in this
document) in OWAMP-Control is accomplished by adding an HMAC to it. document) in OWAMP-Control is accomplished by adding an HMAC to it.
The HMAC that OWAMP uses is HMAC-SHA1 truncated to 128 bits. Thus, The HMAC that OWAMP uses is HMAC-SHA1 truncated to 128 bits. Thus,
all HMAC fields are 16 octets. An HMAC needs a key. The same key all HMAC fields are 16 octets. An HMAC needs a key. The HMAC
used for AES encryption is used for HMAC authentication. Each HMAC Session-key is communicated along with the AES Session-key during
sent covers everything sent in a given direction between the previous OWAMP-Control connection setup. The HMAC Session-key SHOULD be
HMAC (but not including it) and up to the beginning of the new HMAC. derived independently of the AES Session-key (an implementation, of
This way, once encryption is set up, each bit of the OWAMP-Control course, MAY use the same mechanism to generate the random bits for
connection is authenticated by an HMAC exactly once. both keys). Each HMAC sent covers everything sent in a given
direction between the previous HMAC (but not including it) and up to
the beginning of the new HMAC. This way, once encryption is set up,
each bit of the OWAMP-Control connection is authenticated by an HMAC
exactly once.
When encrypting, authentication happens before encryption, so HMAC When encrypting, authentication happens before encryption, so HMAC
blocks are encrypted along with the rest of the stream. When blocks are encrypted along with the rest of the stream. When
decrypting, the order, of course, is reversed: first one decrypts, decrypting, the order, of course, is reversed: first one decrypts,
then one checks the HMAC, then one proceeds to use the data. then one checks the HMAC, then one proceeds to use the data.
The HMAC MUST be checked as early as possible to avoid using and The HMAC MUST be checked as early as possible to avoid using and
propagating corrupt data. propagating corrupt data.
In open mode, the HMAC fields are unused and have the same semantics In open mode, the HMAC fields are unused and have the same semantics
as MBZ fields. as MBZ fields.
3.3. Values of the Accept Field 3.3. Values of the Accept Field
Accept values are used throughout the OWAMP-Control protocol to Accept values are used throughout the OWAMP-Control protocol to
communicate the server response to client requests. The full set of communicate the server response to client requests. The full set of
valid Accept field values are: valid Accept field values are as follows:
0 OK. 0 OK.
1 Failure, reason unspecified (catch-all). 1 Failure, reason unspecified (catch-all).
2 Internal error. 2 Internal error.
3 Some aspect of request is not supported. 3 Some aspect of request is not supported.
4 Cannot perform request due to permanent resource limitations. 4 Cannot perform request due to permanent resource limitations.
5 Cannot perform request due to temporary resource limitations. 5 Cannot perform request due to temporary resource limitations.
All other values are reserved. The sender of the message MAY use the All other values are reserved. The sender of the message MAY use the
value of 1 for all non-zero Accept values. A message sender SHOULD value of 1 for all non-zero Accept values. A message sender SHOULD
use the correct Accept value if it is going to use other values. The use the correct Accept value if it is going to use other values. The
message receiver MUST interpret all values of Accept other than these message receiver MUST interpret all values of Accept other than these
reserved values as 1. This way, other values are available for reserved values as 1. This way, other values are available for
future extensions. future extensions.
3.4. OWAMP-Control Commands 3.4. OWAMP-Control Commands
In authenticated or encrypted mode (which are identical as far as In authenticated or encrypted mode (which are identical as far as
OWAMP-Control is concerned, and only differ in OWAMP-Test) all OWAMP-Control is concerned, and only differ in OWAMP-Test), all
further communications are encrypted with the Session-key, using CBC further communications are encrypted with the AES Session-key (using
mode. The client encrypts everything it sends through the just- CBC mode) and authenticated with HMAC Session-key. The client
established OWAMP-Control connection using stream encryption with encrypts everything it sends through the just-established OWAMP-
Client-IV as the IV. Correspondingly, the server encrypts its side Control connection using stream encryption with Client-IV as the IV.
of the connection using Server-IV as the IV. Correspondingly, the server encrypts its side of the connection using
Server-IV as the IV.
The IVs themselves are transmitted in cleartext. Encryption starts The IVs themselves are transmitted in cleartext. Encryption starts
with the block immediately following the block containing the IV. with the block immediately following the block containing the IV.
The two streams (one going from the client to the server and one The two streams (one going from the client to the server and one
going back) are encrypted independently, each with its own IV, but going back) are encrypted independently, each with its own IV, but
using the same key (the session key). using the same key (the AES Session-key).
The following commands are available for the client: Request-Session, The following commands are available for the client: Request-Session,
Start-Sessions, Stop-Sessions, and Fetch-Session. The command Start-Sessions, Stop-Sessions, and Fetch-Session. The command Stop-
Stop-Sessions is available to both the client and the server. (The Sessions is available to both the client and the server. (The server
server can also send other messages in response to commands it can also send other messages in response to commands it receives.)
receives.)
After the client sends the Start-Sessions command and until it both After the client sends the Start-Sessions command and until it both
sends and receives (in an unspecified order) the Stop-Sessions sends and receives (in an unspecified order) the Stop-Sessions
command, it is said to be conducting active measurements. Similarly, command, it is said to be conducting active measurements. Similarly,
the server is said to be conducting active measurements after it the server is said to be conducting active measurements after it
receives the Start-Sessions command and until it both sends and receives the Start-Sessions command and until it both sends and
receives (in an unspecified order) the Stop-Sessions command. receives (in an unspecified order) the Stop-Sessions command.
While conducting active measurements, the only command available is While conducting active measurements, the only command available is
Stop-Sessions. Stop-Sessions.
These commands are described in detail below. These commands are described in detail below.
3.5. Creating Test Sessions 3.5. Creating Test Sessions
Individual one-way active measurement sessions are established using Individual one-way active measurement sessions are established using
a simple request/response protocol. An OWAMP client MAY issue zero or a simple request/response protocol. An OWAMP client MAY issue zero
more Request-Session messages to an OWAMP server, which MUST respond or more Request-Session messages to an OWAMP server, which MUST
to each with an Accept-Session message. An Accept-Session message respond to each with an Accept-Session message. An Accept-Session
MAY refuse a request. message MAY refuse a request.
The format of Request-Session message is as follows: The format of Request-Session message is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver | | 1 | MBZ | IPVN | Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots | | Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 5 skipping to change at page 15, line 7
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by one or more schedule slot This is immediately followed by one or more schedule slot
descriptions (the number of schedule slots is specified in the descriptions (the number of schedule slots is specified in the
`Number of Schedule Slots' field above): "Number of Schedule Slots" field above):
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Type | | | Slot Type | |
+-+-+-+-+-+-+-+-+ MBZ (7 octets) | +-+-+-+-+-+-+-+-+ MBZ (7 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Parameter (Timestamp) | | Slot Parameter (Timestamp) |
| | | |
skipping to change at page 16, line 29 skipping to change at page 15, line 31
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these messages comprise one logical message: the Request-Session All these messages constitute one logical message: the Request-
command. Session command.
Above, the first octet (1) indicates that this is Request-Session Above, the first octet (1) indicates that this is the Request-Session
command. command.
IPVN is the IP version numbers for Sender and Receiver. When the IP IPVN is the IP version numbers for Sender and Receiver. When the IP
version number is 4, 12 octets follow the 4-octet IPv4 address stored version number is 4, 12 octets follow the 4-octet IPv4 address stored
in Sender Address and Receiver Address. These octets MUST be set to in Sender Address and Receiver Address. These octets MUST be set to
zero by the client and MUST be ignored by the server. Currently zero by the client and MUST be ignored by the server. Currently
meaningful IPVN values are 4 and 6. meaningful IPVN values are 4 and 6.
Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client. Conf-Sender and Conf-Receiver MUST be set to 0 or 1 by the client.
The server MUST interpret any non-zero value as 1. If the value is The server MUST interpret any non-zero value as 1. If the value is
skipping to change at page 17, line 39 skipping to change at page 16, line 41
Start Time is the time when the session is to be started (but not Start Time is the time when the session is to be started (but not
before Start-Sessions command is issued). This timestamp is in the before Start-Sessions command is issued). This timestamp is in the
same format as OWAMP-Test timestamps. same format as OWAMP-Test timestamps.
Timeout (or a loss threshold) is an interval of time (expressed as a Timeout (or a loss threshold) is an interval of time (expressed as a
timestamp). A packet belonging to the test session that is being set timestamp). A packet belonging to the test session that is being set
up by the current Request-Session command will be considered lost if up by the current Request-Session command will be considered lost if
it is not received during Timeout seconds after it is sent. it is not received during Timeout seconds after it is sent.
Type-P Descriptor covers only a subset of (very large) Type-P space. Type-P Descriptor covers only a subset of (very large) Type-P space.
If the first two bits of the Type-P Descriptor are 00, then If the first two bits of the Type-P Descriptor are 00, then the
subsequent six bits specify the requested Differentiated Services subsequent six bits specify the requested Differentiated Services
Codepoint (DSCP) value of sent OWAMP-Test packets, as defined in Codepoint (DSCP) value of sent OWAMP-Test packets, as defined in
RFC 2474. If the first two bits of Type-P descriptor are 01, then [RFC2474]. If the first two bits of Type-P descriptor are 01, then
the subsequent 16 bits specify the requested PHB Identification Code the subsequent 16 bits specify the requested PHB Identification Code
(PHB ID), as defined in RFC 2836. (PHB ID), as defined in [RFC2836].
Therefore, the value of all zeros specifies the default best-effort Therefore, the value of all zeros specifies the default best-effort
service. service.
If Conf-Sender is set, the Type-P Descriptor is to be used to If Conf-Sender is set, the Type-P Descriptor is to be used to
configure the sender to send packets according to its value. If configure the sender to send packets according to its value. If
Conf-Sender is not set, the Type-P Descriptor is a declaration of how Conf-Sender is not set, the Type-P Descriptor is a declaration of how
the sender will be configured. the sender will be configured.
If Conf-Sender is set and the server does not recognize the Type-P If Conf-Sender is set and the server does not recognize the Type-P
Descriptor, or it cannot or does not wish to set the corresponding Descriptor, or it cannot or does not wish to set the corresponding
attributes on OWAMP-Test packets, it SHOULD reject the session attributes on OWAMP-Test packets, it SHOULD reject the session
request. If Conf-Sender is not set, the server SHOULD accept or request. If Conf-Sender is not set, the server SHOULD accept or
reject the session paying no attention to the value of the Type-P reject the session, paying no attention to the value of the Type-P
Descriptor. Descriptor.
To each Request-Session message, an OWAMP server MUST respond with an To each Request-Session message, an OWAMP server MUST respond with an
Accept-Session message: Accept-Session message:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | MBZ | Port | | Accept | MBZ | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
skipping to change at page 18, line 39 skipping to change at page 17, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this message, zero in the Accept field means that the server is In this message, zero in the Accept field means that the server is
willing to conduct the session. A non-zero value indicates rejection willing to conduct the session. A non-zero value indicates rejection
of the request. The full list of available Accept values is of the request. The full list of available Accept values is
described in Section 3.3, ``Values of the Accept Field''. described in Section 3.3, "Values of the Accept Field".
If the server rejects a Request-Session message, it SHOULD not close If the server rejects a Request-Session message, it SHOULD not close
the TCP connection. The client MAY close it if it receives negative the TCP connection. The client MAY close it if it receives a
response to the Request-Session message. negative response to the Request-Session message.
The meaning of Port in the response depends on the values of The meaning of Port in the response depends on the values of Conf-
Conf-Sender and Conf-Receiver in the query that solicited the Sender and Conf-Receiver in the query that solicited the response.
response. If both were set, the Port field is unused. If only If both were set, the Port field is unused. If only Conf-Sender was
Conf-Sender was set, Port is the port from which to expect OWAMP-Test set, Port is the port from which to expect OWAMP-Test packets. If
packets. If only Conf-Receiver was set, Port is the port to which only Conf-Receiver was set, Port is the port to which OWAMP-Test
OWAMP-Test packets are sent. packets are sent.
If only Conf-Sender was set, the SID field in the response is unused. If only Conf-Sender was set, the SID field in the response is unused.
Otherwise, SID is a unique server-generated session identifier. It Otherwise, SID is a unique server-generated session identifier. It
can be used later as handle to fetch the results of a session. can be used later as handle to fetch the results of a session.
SIDs SHOULD be constructed by concatenation of the 4-octet IPv4 IP SIDs SHOULD be constructed by concatenation of the 4-octet IPv4 IP
number belonging to the generating machine, an 8-octet timestamp, and number belonging to the generating machine, an 8-octet timestamp, and
a 4-octet random value. To reduce the probability of collisions, if a 4-octet random value. To reduce the probability of collisions, if
the generating machine has any IPv4 addresses (with the exception of the generating machine has any IPv4 addresses (with the exception of
loopback), one of them SHOULD be used for SID generation, even if all loopback), one of them SHOULD be used for SID generation, even if all
communication is IPv6-based. If it has no IPv4 addresses at all, the communication is IPv6-based. If it has no IPv4 addresses at all, the
last four octets of an IPv6 address MAY be used instead. Note that last four octets of an IPv6 address MAY be used instead. Note that
SID is always chosen by the receiver. If truly random values are not SID is always chosen by the receiver. If truly random values are not
available, it is important that the SID be made unpredictable, as available, it is important that the SID be made unpredictable, as
knowledge of the SID might be used for access control. knowledge of the SID might be used for access control.
3.6. Send Schedules 3.6. Send Schedules
The sender and the receiver both need to know the same send schedule. The sender and the receiver both need to know the same send schedule.
This way, when packets are lost, the receiver knows when they were This way, when packets are lost, the receiver knows when they were
supposed to be sent. It is desirable to compress common schedules supposed to be sent. It is desirable to compress common schedules
and still to be able to use an arbitrary one for the test sessions. and still to be able to use an arbitrary one for the test sessions.
In many cases, the schedule will consist of repeated sequences of In many cases, the schedule will consist of repeated sequences of
packets: this way, the sequence performs some test, and the test is packets: this way, the sequence performs some test, and the test is
repeated a number of times to gather statistics. repeated a number of times to gather statistics.
To implement this, we have a schedule with a given number of slots. To implement this, we have a schedule with a given number of slots.
Each slot has a type and a parameter. Two types are supported: Each slot has a type and a parameter. Two types are supported:
exponentially distributed pseudo-random quantity (denoted by a code exponentially distributed pseudo-random quantity (denoted by a code
of 0) and a fixed quantity (denoted by a code of 1). The parameter of 0) and a fixed quantity (denoted by a code of 1). The parameter
is expressed as a timestamp and specifies a time interval. For a is expressed as a timestamp and specifies a time interval. For a
type 0 slot (exponentially distributed pseudo-random quantity) this type 0 slot (exponentially distributed pseudo-random quantity), this
interval is the mean value (or 1/lambda if the distribution density interval is the mean value (or 1/lambda if the distribution density
function is expressed as lambda*exp(-lambda*x) for positive values of function is expressed as lambda*exp(-lambda*x) for positive values of
x). For a type 1 (fixed quantity) slot, the parameter is the delay x). For a type 1 (fixed quantity) slot, the parameter is the delay
itself. The sender starts with the beginning of the schedule, and itself. The sender starts with the beginning of the schedule and
executes the instructions in the slots: for a slot of type 0, wait an executes the instructions in the slots: for a slot of type 0, wait an
exponentially distributed time with a mean of the specified parameter exponentially distributed time with a mean of the specified parameter
and then send a test packet (and proceed to the next slot); for a and then send a test packet (and proceed to the next slot); for a
slot of type 1, wait the specified time and send a test packet (and slot of type 1, wait the specified time and send a test packet (and
proceed to the next slot). The schedule is circular: when there are proceed to the next slot). The schedule is circular: when there are
no more slots, the sender returns to the first slot. no more slots, the sender returns to the first slot.
The sender and the receiver need to be able to reproducibly execute The sender and the receiver need to be able to reproducibly execute
the entire schedule (so, if a packet is lost, the receiver can still the entire schedule (so, if a packet is lost, the receiver can still
attach a send timestamp to it). Slots of type 1 are trivial to attach a send timestamp to it). Slots of type 1 are trivial to
reproducibly execute. To reproducibly execute slots of type 0, we reproducibly execute. To reproducibly execute slots of type 0, we
need to be able to generate pseudo-random exponentially distributed need to be able to generate pseudo-random exponentially distributed
quantities in a reproducible manner. The way this is accomplished is quantities in a reproducible manner. The way this is accomplished is
discussed later. discussed later in Section 5, "Computing Exponentially Distributed
Pseudo-Random Numbers".
Using this mechanism one can easily specify common testing scenarios. Using this mechanism, one can easily specify common testing
Some examples include: scenarios. The following are some examples:
+ Poisson stream: a single slot of type 0; + Poisson stream: a single slot of type 0.
+ Periodic stream: a single slot of type 1; + Periodic stream: a single slot of type 1.
+ Poisson stream of back-to-back packet pairs: two slots -- type 0 + Poisson stream of back-to-back packet pairs: two slots, type 0
with a non-zero parameter and type 1 with a zero parameter. with a non-zero parameter and type 1 with a zero parameter.
Further, a completely arbitrary schedule can be specified (albeit Further, a completely arbitrary schedule can be specified (albeit
inefficiently) by making the number of test packets equal to the inefficiently) by making the number of test packets equal to the
number of schedule slots. In this case, the complete schedule is number of schedule slots. In this case, the complete schedule is
transmitted in advance of an OWAMP-Test session. transmitted in advance of an OWAMP-Test session.
3.7. Starting Test Sessions 3.7. Starting Test Sessions
Having requested one or more test sessions and received affirmative Having requested one or more test sessions and received affirmative
Accept-Session responses, an OWAMP client MAY start the execution of Accept-Session responses, an OWAMP client MAY start the execution of
the requested test sessions by sending a Start-Sessions message to the requested test sessions by sending a Start-Sessions message to
the server. the server.
The format of this message is as follows: The format of this message is as follows:
0 1 2 3 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 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
skipping to change at page 20, line 47 skipping to change at page 19, line 50
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server MUST respond with an Start-Ack message (which SHOULD be The server MUST respond with an Start-Ack message (which SHOULD be
sent as quickly as possible). Start-Ack messages have the following sent as quickly as possible). Start-Ack messages have the following
format: format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | | | Accept | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) | | MBZ (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If Accept is non-zero, the Start-Sessions request was rejected; zero If Accept is non-zero, the Start-Sessions request was rejected; zero
means that the command was accepted. The full list of available means that the command was accepted. The full list of available
Accept values is described in Section 3.3, ``Values of the Accept Accept values is described in Section 3.3, "Values of the Accept
Field''. The server MAY, and the client SHOULD, close the connection Field". The server MAY, and the client SHOULD, close the connection
in the case of a rejection. in the case of a rejection.
The server SHOULD start all OWAMP-Test streams immediately after it The server SHOULD start all OWAMP-Test streams immediately after it
sends the response or immediately after their specified start times, sends the response or immediately after their specified start times,
whichever is later. If the client represents a Sender, the client whichever is later. If the client represents a Sender, the client
SHOULD start its OWAMP-Test streams immediately after it sees the SHOULD start its OWAMP-Test streams immediately after it sees the
Start-Ack response from the Server (if the Start-Sessions command was Start-Ack response from the Server (if the Start-Sessions command was
accepted) or immediately after their specified start times, whichever accepted) or immediately after their specified start times, whichever
is later. See more on OWAMP-Test sender behavior in a separate is later. See more on OWAMP-Test sender behavior in a separate
section below. section below.
3.8. Stop-Sessions 3.8. Stop-Sessions
The Stop-Sessions message may be issued by either the Control-Client The Stop-Sessions message may be issued by either the Control-Client
or the Server. The format of this command is as follows: or the Server. The format of this command is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | Accept | MBZ | | 3 | Accept | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions | | Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by zero or more session description This is immediately followed by zero or more session description
records (the number of session description records is specified in records (the number of session description records is specified in
the ``Number of Sessions'' field above). The session description the "Number of Sessions" field above). The session description
record is used to indicate which packets were actually sent by the record is used to indicate which packets were actually sent by the
sender process (rather than skipped). The header of the session sender process (rather than skipped). The header of the session
description record is as follows: description record is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno | | Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges | | Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by zero or more Skip Range descriptions This is immediately followed by zero or more Skip Range descriptions
as specified by the ``Number of Skip Ranges'' field above. Skip as specified by the "Number of Skip Ranges" field above. Skip Ranges
Ranges are simply two sequence numbers that, together, indicate a are simply two sequence numbers that, together, indicate a range of
range of packets that were not sent: packets that were not sent:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped | | First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped | | Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Skip Ranges MUST be in order. The last (possibly full, possibly Skip Ranges MUST be in order. The last (possibly full, possibly
incomplete) block (16 octets) of data MUST be padded with zeros, if incomplete) block (16 octets) of data MUST be padded with zeros, if
necessary. This ensures that the next session description record necessary. This ensures that the next session description record
starts on a block boundary. starts on a block boundary.
Finally, a single block (16 octets) of HMAC is concatenated on the Finally, a single block (16 octets) of HMAC is concatenated on the
end to complete the Stop-Sessions message. end to complete the Stop-Sessions message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these records comprise one logical message: the Stop-Sessions All these records comprise one logical message: the Stop-Sessions
command. command.
Above, the first octet (3) indicates that this is the Stop-Sessions Above, the first octet (3) indicates that this is the Stop-Sessions
command. command.
Non-zero Accept values indicate a failure of some sort. Zero values Non-zero Accept values indicate a failure of some sort. Zero values
indicate normal (but possibly premature) completion. The full list indicate normal (but possibly premature) completion. The full list
of available Accept values is described in Section 3.3, ``Values of of available Accept values is described in Section 3.3, "Values of
the Accept Field''. the Accept Field".
If Accept had a non-zero value (from either party), results of all If Accept had a non-zero value (from either party), results of all
OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be
considered invalid, even if a Fetch-Session with SID from this considered invalid, even if a Fetch-Session with SID from this
session works for a different OWAMP-Control session. If Accept was session works for a different OWAMP-Control session. If Accept was
not transmitted at all (for whatever reason, including the TCP not transmitted at all (for whatever reason, including the TCP
connection used for OWAMP-Control breaking), the results of all connection used for OWAMP-Control breaking), the results of all
OWAMP-Test sessions spawned by this OWAMP-control session MAY be OWAMP-Test sessions spawned by this OWAMP-control session MAY be
considered invalid. considered invalid.
Number of Sessions indicates the number of session description Number of Sessions indicates the number of session description
records that immediately follow the Stop-Sessions header. records that immediately follow the Stop-Sessions header.
Number of Sessions MUST contain the number of send sessions started Number of Sessions MUST contain the number of send sessions started
by the local side of the control connection that have not been by the local side of the control connection that have not been
previously terminated by a Stop-Sessions command (i.e., the previously terminated by a Stop-Sessions command (i.e., the Control-
Control-Client MUST account for each accepted Request-Session where Client MUST account for each accepted Request-Session where Conf-
Conf-Receiver was set; the Control-Server MUST account for each Receiver was set; the Control-Server MUST account for each accepted
accepted Request-Session where Conf-Sender was set). If the Request-Session where Conf-Sender was set). If the Stop-Sessions
Stop-Sessions message does not account for exactly the send sessions message does not account for exactly the send sessions controlled by
controlled by that side, then it is to be considered invalid and the that side, then it is to be considered invalid and the connection
connection SHOULD be closed and any results obtained considered SHOULD be closed and any results obtained considered invalid.
invalid.
Each session description record represents one OWAMP-Test session. Each session description record represents one OWAMP-Test session.
SID is the session identifier (SID) used to indicate which send SID is the session identifier (SID) used to indicate which send
session is being described. session is being described.
Next Seqno indicates the next sequence number that would have been Next Seqno indicates the next sequence number that would have been
sent from this send session. For completed sessions, this will equal sent from this send session. For completed sessions, this will equal
NumPackets from the Request-Session. NumPackets from the Request-Session.
Number of Skip Ranges indicates the number of holes that actually Number of Skip Ranges indicates the number of holes that actually
occurred in the sending process. This is a range of packets that were occurred in the sending process. This is a range of packets that
never actually sent by the sending process. For example, if a send were never actually sent by the sending process. For example, if a
session is started too late for the first 10 packets to be sent and send session is started too late for the first 10 packets to be sent
this is the only hole in the schedule, then ``Number of Skip Ranges'' and this is the only hole in the schedule, then "Number of Skip
would be 1. The single Skip Range description will have First Seqno Ranges" would be 1. The single Skip Range description will have
Skipped equal to 0 and Last Seqno Skipped equal to 9. This is First Seqno Skipped equal to 0 and Last Seqno Skipped equal to 9.
described further in the ``Sender Behavior'' section. This is described further in the "Sender Behavior" section.
If the OWAMP-Control connection breaks when the Stop-Sessions command If the OWAMP-Control connection breaks when the Stop-Sessions command
is sent, the receiver MAY not completely invalidate the session is sent, the receiver MAY not completely invalidate the session
results. It MUST discard all record of packets that follow (in other results. It MUST discard all record of packets that follow (in other
words, have greater sequence number than) the last packet that was words, that have greater sequence number than) the last packet that
actually received before before any lost packet records. This will was actually received before any lost packet records. This will help
help differentiate between packet losses that occurred in the network differentiate between packet losses that occurred in the network and
and packets the sending process may have never sent. packets the sending process may have never sent.
If a receiver of an OWAMP-Test session learns, through an OWAMP- If a receiver of an OWAMP-Test session learns, through an OWAMP-
Control Stop-Sessions message, that the OWAMP-Test sender's last Control Stop-Sessions message, that the OWAMP-Test sender's last
sequence number is lower than any sequence number actually received, sequence number is lower than any sequence number actually received,
the results of the complete OWAMP-Test session MUST be invalidated. the results of the complete OWAMP-Test session MUST be invalidated.
A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control A receiver of an OWAMP-Test session, upon receipt of an OWAMP-Control
Stop-Sessions command, MUST discard any packet records -- including Stop-Sessions command, MUST discard any packet records -- including
lost packet records -- with a (computed) send time that falls between lost packet records -- with a (computed) send time that falls between
the current time minus Timeout and the current time. This ensures the current time minus Timeout and the current time. This ensures
statistical consistency for the measurement of loss and duplicates in statistical consistency for the measurement of loss and duplicates in
the event that the Timeout is greater than the time it takes for the the event that the Timeout is greater than the time it takes for the
Stop-Sessions command to take place. Stop-Sessions command to take place.
To effect complete sessions, each side of the control connection To effect complete sessions, each side of the control connection
SHOULD wait until all sessions are complete before sending the SHOULD wait until all sessions are complete before sending the Stop-
Stop-Sessions message. The completed time of each sessions is Sessions message. The completed time of each session is determined
determined as Timeout after the scheduled time for the last sequence as Timeout after the scheduled time for the last sequence number.
number. Endpoints MAY add a small increment to the computed Endpoints MAY add a small increment to the computed completed time
completed time for send endpoints to ensure the Stop-Sessions message for send endpoints to ensure that the Stop-Sessions message reaches
reaches the receiver endpoint after Timeout. the receiver endpoint after Timeout.
To effect a premature stop of sessions, the party that initiates this To effect a premature stop of sessions, the party that initiates this
command MUST stop its OWAMP-Test send streams to send the Session command MUST stop its OWAMP-Test send streams to send the Session
Packets Sent values before sending this command. That party SHOULD Packets Sent values before sending this command. That party SHOULD
wait until receiving the response Stop-Sessions message before wait until receiving the response Stop-Sessions message before
stopping the receiver streams so that it can use the values from the stopping the receiver streams so that it can use the values from the
received Stop-Sessions message to validate the data. received Stop-Sessions message to validate the data.
3.9. Fetch-Session 3.9. Fetch-Session
The format of this client command is as follows: The format of this client command is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | | | 4 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| MBZ (7 octets) | | MBZ (7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 33 skipping to change at page 24, line 37
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Begin Seq is the sequence number of the first requested packet. End Begin Seq is the sequence number of the first requested packet. End
Seq is the sequence number of the last requested packet. If Begin Seq is the sequence number of the last requested packet. If Begin
Seq is all zeros and End Seq is all ones, complete session is said to Seq is all zeros and End Seq is all ones, complete session is said to
be requested. be requested.
If a complete session is requested and the session is still in If a complete session is requested and the session is still in
progress, or has terminated in any way other than normal, the request progress or has terminated in any way other than normally, the
to fetch session results MUST be denied. If an incomplete session is request to fetch session results MUST be denied. If an incomplete
requested, all packets received so far that fall into the requested session is requested, all packets received so far that fall into the
range SHOULD be returned. Note that, since no commands can be issued requested range SHOULD be returned. Note that, since no commands can
between Start-Sessions and Stop-Sessions, incomplete requests can be issued between Start-Sessions and Stop-Sessions, incomplete
only happen on a different OWAMP-Control connection (from the same or requests can only happen on a different OWAMP-Control connection
different host as Control-Client). (from the same or different host as Control-Client).
The server MUST respond with a Fetch-Ack message. The format of this The server MUST respond with a Fetch-Ack message. The format of this
server response is as follows: server response is as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Finished | MBZ (2 octets) | | Accept | Finished | MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno | | Next Seqno |
skipping to change at page 26, line 24 skipping to change at page 25, line 27
| Number of Records | | Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| HMAC (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again, non-zero in the Accept field means a rejection of command. Again, non-zero in the Accept field means a rejection of command.
The server MUST specify zero for all remaining fields if Accept is The server MUST specify zero for all remaining fields if Accept is
non-zero. The client MUST ignore all remaining fields (except for the non-zero. The client MUST ignore all remaining fields (except for
HMAC) if Accept is non-zero. The full list of available Accept the HMAC) if Accept is non-zero. The full list of available Accept
values is described in Section 3.3, ``Values of the Accept Field''. values is described in Section 3.3, "Values of the Accept Field".
Finished is non-zero if the OWAMP-Test session has terminated. Finished is non-zero if the OWAMP-Test session has terminated.
Next Seqno indicates the next sequence number that would have been Next Seqno indicates the next sequence number that would have been
sent from this send session. For completed sessions, this will equal sent from this send session. For completed sessions, this will equal
NumPackets from the Request-Session. This information is only NumPackets from the Request-Session. This information is only
available if the session has terminated. If Finished is zero, then available if the session has terminated. If Finished is zero, then
Next Seqno MUST be set to zero by the server. Next Seqno MUST be set to zero by the server.
Number of Skip Ranges indicates the number of holes that actually Number of Skip Ranges indicates the number of holes that actually
occurred in the sending process. This information is only available occurred in the sending process. This information is only available
if the session has terminated. If Finished is zero, then Skip Ranges if the session has terminated. If Finished is zero, then Skip Ranges
MUST be set to zero by the server. MUST be set to zero by the server.
Number of Records is the number of packet records that fall within Number of Records is the number of packet records that fall within
the requested range. This number might be less than the Number of the requested range. This number might be less than the Number of
Packets in the reproduction of the Request-Session command because of Packets in the reproduction of the Request-Session command because of
a session that ended prematurely or it might be greater because of a session that ended prematurely, or it might be greater because of
duplicates. duplicates.
If Accept was non-zero, this concludes the response to the Fetch- If Accept was non-zero, this concludes the response to the Fetch-
Session message. If Accept was 0, the server then MUST immediately Session message. If Accept was 0, the server then MUST immediately
send the OWAMP-Test session data in question. send the OWAMP-Test session data in question.
The OWAMP-Test session data consists of the following (concatenated): The OWAMP-Test session data consists of the following (concatenated):
+ A reproduction of the Request-Session command that was used to + A reproduction of the Request-Session command that was used to
start the session; it is modified so that actual sender and start the session; it is modified so that actual sender and
receiver port numbers that were used by the OWAMP-Test session receiver port numbers that were used by the OWAMP-Test session
always appear in the reproduction. always appear in the reproduction.
+ Zero or more (as specified) Skip Range descriptions. The last + Zero or more (as specified) Skip Range descriptions. The last
(possibly full, possibly incomplete) block (16 octets) of Skip (possibly full, possibly incomplete) block (16 octets) of Skip
Range descriptions is padded with zeros if necessary. Range descriptions is padded with zeros, if necessary.
+ 16 octets of HMAC. + 16 octets of HMAC.
+ Zero or more (as specified) packet records. The last (possibly + Zero or more (as specified) packet records. The last (possibly
full, possibly incomplete) block (16 octets) of data is padded full, possibly incomplete) block (16 octets) of data is padded
with zeros if necessary. with zeros, if necessary.
+ 16 octets of HMAC. + 16 octets of HMAC.
Skip Range descriptions are simply two sequence numbers that, Skip Range descriptions are simply two sequence numbers that,
together, indicate a range of packets that were not sent: together, indicate a range of packets that were not sent:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped | | First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped | | Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Skip Range descriptions should be sent out in order, as sorted by Skip Range descriptions should be sent out in order, as sorted by
First Seqno. If any Skip Ranges overlap, or are out of order, the First Seqno. If any Skip Ranges overlap or are out of order, the
session data is to be considered invalid and the connection SHOULD be session data is to be considered invalid and the connection SHOULD be
closed and any results obtained considered invalid. closed and any results obtained considered invalid.
Each packet record is 25 octets, and includes 4 octets of sequence Each packet record is 25 octets and includes 4 octets of sequence
number, 8 octets of send timestamp, 2 octets of send timestamp error number, 8 octets of send timestamp, 2 octets of send timestamp error
estimate, 8 octets of receive timestamp, 2 octets of receive estimate, 8 octets of receive timestamp, 2 octets of receive
timestamp error estimate, and 1 octet of Time To Live (TTL), or Hop timestamp error estimate, and 1 octet of Time To Live (TTL), or Hop
Limit in IPv6: Limit in IPv6:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
00| Seq Number | 00| Seq Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 5 skipping to change at page 27, line 45
+ A normal receive error estimate as determined by the error of the + A normal receive error estimate as determined by the error of the
clock being used to declare the packet lost. (It is declared lost clock being used to declare the packet lost. (It is declared lost
if it is not received by the Timeout after the presumed send time, if it is not received by the Timeout after the presumed send time,
as determined by the receiver's clock.) as determined by the receiver's clock.)
+ A receive timestamp consisting of all zero bits. + A receive timestamp consisting of all zero bits.
+ A TTL value of 255. + A TTL value of 255.
4. OWAMP-Test 4. OWAMP-Test
This section describes OWAMP-Test protocol. It runs over UDP using This section describes OWAMP-Test protocol. It runs over UDP, using
sender and receiver IP and port numbers negotiated during the sender and receiver IP and port numbers negotiated during the
Request-Session exchange. Request-Session exchange.
As with OWAMP-Control, OWAMP-Test has three modes: unauthenticated, As with OWAMP-Control, OWAMP-Test has three modes: unauthenticated,
authenticated, and encrypted. All OWAMP-Test sessions that are authenticated, and encrypted. All OWAMP-Test sessions that are
spawned by an OWAMP-Control session inherit its mode. spawned by an OWAMP-Control session inherit its mode.
OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and OWAMP-Control client, OWAMP-Control server, OWAMP-Test sender, and
OWAMP-Test receiver can potentially all be different machines. (In a OWAMP-Test receiver can potentially all be different machines. (In a
typical case, we expect that there will be only two machines.) typical case, we expect that there will be only two machines.)
4.1. Sender Behavior 4.1. Sender Behavior
4.1.1. Packet Timings 4.1.1. Packet Timings
Send schedules based on slots, described previously, in conjunction Send schedules based on slots, described previously, in conjunction
with scheduled session start time, enable the sender and the receiver with scheduled session start time, enable the sender and the receiver
to compute the same exact packet sending schedule independently of to compute the same exact packet sending schedule independently of
each other. These sending schedules are independent for different each other. These sending schedules are independent for different
OWAMP-Test sessions, even if they are governed by the same OWAMP-Test sessions, even if they are governed by the same OWAMP-
OWAMP-Control session. Control session.
Consider any OWAMP-Test session. Once Start-Sessions exchange is Consider any OWAMP-Test session. Once Start-Sessions exchange is
complete, the sender is ready to start sending packets. Under normal complete, the sender is ready to start sending packets. Under normal
OWAMP use circumstances, the time to send the first packet is in the 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 near future (perhaps a fraction of a second away). The sender SHOULD
send packets as close as possible to their scheduled time, with the send packets as close as possible to their scheduled time, with the
following exception: if the scheduled time to send is in the past, following exception: if the scheduled time to send is in the past,
and separated from the present by more than Timeout time, the sender and is separated from the present by more than Timeout time, the
MUST NOT send the packet. (Indeed, such a packet would be considered sender MUST NOT send the packet. (Indeed, such a packet would be
lost by the receiver anyway.) The sender MUST keep track of which considered lost by the receiver anyway.) The sender MUST keep track
packets it does not send. It will use this to tell the receiver what of which packets it does not send. It will use this to tell the
packets were not sent by setting Skip Ranges in the Stop-Sessions receiver what packets were not sent by setting Skip Ranges in the
message from the sender to the receiver upon completion of the test. Stop-Sessions message from the sender to the receiver upon completion
The Skip Ranges are also sent to a Fetch-Client as part of the of the test. The Skip Ranges are also sent to a Fetch-Client as part
session data results. These holes in the sending schedule can happen of the session data results. These holes in the sending schedule can
if a time in the past was specified in the Request-Session command, happen if a time in the past was specified in the Request-Session
or if the Start-Sessions exchange took unexpectedly long, or if the command, or if the Start-Sessions exchange took unexpectedly long, or
sender could not start serving the OWAMP-Test session on time due to if the sender could not start serving the OWAMP-Test session on time
internal scheduling problems of the OS. Packets in the past, but due to internal scheduling problems of the OS. Packets that are in
separated from the present by less than Timeout value, SHOULD be sent the past but are separated from the present by less than Timeout
as quickly as possible. With normal test rates and timeout values, value SHOULD be sent as quickly as possible. With normal test rates
the number of packets in such a burst is limited. Nevertheless, and timeout values, the number of packets in such a burst is limited.
hosts SHOULD NOT intentionally schedule sessions so that such bursts Nevertheless, hosts SHOULD NOT intentionally schedule sessions so
of packets occur. that such bursts of packets occur.
Regardless of any scheduling delays, each packet that is actually Regardless of any scheduling delays, each packet that is actually
sent MUST have the best possible approximation of its real time of sent MUST have the best possible approximation of its real time of
departure as its timestamp (in the packet). departure as its timestamp (in the packet).
4.1.2. OWAMP-Test Packet Format and Content 4.1.2. OWAMP-Test Packet Format and Content
The sender sends the receiver a stream of packets with the schedule The sender sends the receiver a stream of packets with the schedule
specified in the Request-Session command. The sender SHOULD set the 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 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 format of the body of a UDP packet in the stream depends on the mode
being used. being used.
For unauthenticated mode: For unauthenticated mode:
0 1 2 3 0 1 2 3
skipping to change at page 31, line 34 skipping to change at page 30, line 36
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the timestamp is the same as in [RFC1305] and is as The format of the timestamp is the same as in [RFC1305] and is as
follows: first 32 bits represent the unsigned integer number of follows: the first 32 bits represent the unsigned integer number of
seconds elapsed since 0h on 1 January 1900; next 32 bits represent seconds elapsed since 0h on 1 January 1900; the next 32 bits
the fractional part of a second that has elapsed since then. represent the fractional part of a second that has elapsed since
then.
So, Timestamp is represented as follows: So, Timestamp is represented as follows:
0 1 2 3 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 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 | | Integer part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fractional part of seconds | | Fractional part of seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Estimate specifies the estimate of the error and The Error Estimate specifies the estimate of the error and
synchronization. It has the following format: synchronization. It has the following format:
skipping to change at page 32, line 11 skipping to change at page 31, line 14
The Error Estimate specifies the estimate of the error and The Error Estimate specifies the estimate of the error and
synchronization. It has the following format: synchronization. It has the following format:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|Z| Scale | Multiplier | |S|Z| Scale | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first bit S SHOULD be set if the party generating the timestamp 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 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 (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 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 it indicates that it has synchronized to an external source, which
includes stratum 0 source, etc.); if there is no notion of external includes stratum 0 source, etc.). If there is no notion of external
synchronization for the time source, the bit SHOULD NOT be set. The 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 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 set to zero by the sender and ignored by everyone else. The next six
bits, Scale, form an unsigned integer; Multiplier is an unsigned bits, Scale, form an unsigned integer; Multiplier is an unsigned
integer as well. They are interpreted as follows: the error estimate integer as well. They are interpreted as follows: the error estimate
is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation is equal to Multiplier*2^(-32)*2^Scale (in seconds). (Notation
clarification: 2^Scale is two to the power of Scale.] Multiplier 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 MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be
considered corrupt and discarded. considered corrupt and discarded.
Sequence numbers start with zero and are incremented by one for each Sequence numbers start with zero and are incremented by one for each
subsequent packet. subsequent packet.
The minimum data segment length is, therefore, 14 octets in The minimum data segment length is, therefore, 14 octets in
unauthenticated mode, and 48 octets in both authenticated mode and unauthenticated mode, and 48 octets in both authenticated mode and
encrypted modes. encrypted modes.
The OWAMP-Test packet layout is the same in authenticated and The OWAMP-Test packet layout is the same in authenticated and
encrypted modes. The encryption and authentication operations are, encrypted modes. The encryption and authentication operations are,
however, different. The difference is that in encrypted mode both however, different. The difference is that in encrypted mode both
the sequence number and the timestamp are protected to provide the sequence number and the timestamp are protected to provide
maximum data confidentiality and integrity protection while in maximum data confidentiality and integrity protection, whereas in
authenticated mode the sequence number is protected while the authenticated mode the sequence number is protected while the
timestamp is sent in clear text. Sending the timestamp in clear text timestamp is sent in clear text. Sending the timestamp in clear text
in authenticated mode allows one to reduce the time between when a 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. 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, In encrypted mode, the sender has to fetch the timestamp, encrypt it,
and send it; in authenticated mode, the middle step is removed, and send it; in authenticated mode, the middle step is removed,
potentially improving accuracy (the sequence number can be encrypted potentially improving accuracy (the sequence number can be encrypted
and authenticated before the timestamp is fetched). and authenticated before the timestamp is fetched).
In authenticated mode, the first block (16 octets) of each packet is In authenticated mode, the first block (16 octets) of each packet is
encrypted using AES Electronic Cookbook (ECB) mode. encrypted using AES Electronic Cookbook (ECB) mode.
The key to use is obtained as follows: the 16-octet session Similarly to each OWAMP-Control session, each OWAMP-Test session has
identifier (SID) is encrypted with the same session key as is used two keys: an AES Session-key and an HMAC Session-key. However, there
for the corresponding OWAMP-Control session (where it is used in a is a difference in how the keys are obtained: in the case of OWAMP-
different chaining mode); this is a single-block ECB encryption; its Control, the keys are generated by the client and communicated (as
result is the key to use in encrypting (and decrypting) the packets part of the Token) during connection setup as part of Set-Up-Response
of the particular OWAMP-Test session. 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 ECB mode used for encrypting the first block of OWAMP-Test packets in
authenticated mode does not involve any actual chaining; this way, authenticated mode does not involve any actual chaining; this way,
lost, duplicated, or reordered packets do not cause problems with lost, duplicated, or reordered packets do not cause problems with
deciphering any packet in an OWAMP-Test session. deciphering any packet in an OWAMP-Test session.
In encrypted mode, the first two blocks (32 octets) are encrypted In encrypted mode, the first two blocks (32 octets) are encrypted
using AES CBC mode. The key to use is obtained in the same way as using AES CBC mode. The AES Session-key to use is obtained in the
the key for authenticated mode. Each OWAMP-Test packet is encrypted same way as the key for authenticated mode. Each OWAMP-Test packet
as a separate stream, with just one chaining operation; chaining does is encrypted as a separate stream, with just one chaining operation;
not span multiple packets so that lost, duplicated, or reordered chaining does not span multiple packets so that lost, duplicated, or
packets do not cause problems. The initialization vector for the CBC reordered packets do not cause problems. The initialization vector
encryption is a value with all bits equal to zero. for the CBC encryption is a value with all bits equal to zero.
Implementation note: Naturally, the key schedule for each OWAMP-Test Implementation note: Naturally, the key schedule for each OWAMP-Test
session MAY only be set up once per session, not once per packet. session MAY be set up only once per session, not once per packet.
HMAC in OWAMP-Test only covers the part of the packet that is also HMAC in OWAMP-Test only covers the part of the packet that is also
encrypted. So, in authenticated mode, HMAC covers the first block encrypted. So, in authenticated mode, HMAC covers the first block
(16 octets); in encrypted mode, HMAC covers two first blocks (32 (16 octets); in encrypted mode, HMAC covers two first blocks (32
octets). In OWAMP-Test HMAC is not encrypted (note that this is octets). In OWAMP-Test HMAC is not encrypted (note that this is
different from OWAMP-Control, where encryption is stream mode is different from OWAMP-Control, where encryption in stream mode is
used, so everything including the HMAC blocks ends up being used, so everything including the HMAC blocks ends up being
encrypted). The key for HMAC (authentication) is the same as the key encrypted).
for AES (encryption).
In unauthenticated mode, no encryption or authentication is applied. In unauthenticated mode, no encryption or authentication is applied.
Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be
generated independently of any other pseudo-random numbers mentioned generated independently of any other pseudo-random numbers mentioned
in this document). However, implementations MUST provide a in this document). However, implementations MUST provide a
configuration parameter, an option, or a different means of making configuration parameter, an option, or a different means of making
Packet Padding consist of all zeros. Packet Padding consist of all zeros.
The time elapsed between packets is computed according to the slot The time elapsed between packets is computed according to the slot
schedule as mentioned in Request-Session command description. At schedule as mentioned in Request-Session command description. At
that point, we skipped over the issue of computing exponentially that point, we skipped over the issue of computing exponentially
distributed pseudo-random numbers in a reproducible fashion. It is distributed pseudo-random numbers in a reproducible fashion. It is
discussed later in a separate section. discussed later in a separate section.
4.2. Receiver Behavior 4.2. Receiver Behavior
The receiver knows when the sender will send packets. The following The receiver knows when the sender will send packets. The following
parameter is defined: Timeout (from Request-Session). Packets that parameter is defined: Timeout (from Request-Session). Packets that
are delayed by more than Timeout are considered lost (or `as good as 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 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 network: a "lost" packet might still be delivered at any time. The
original specification for IPv4 required that packets be delivered original specification for IPv4 required that packets be delivered
within TTL seconds or never (with TTL having a maximum value of 255). within TTL seconds or never (with TTL having a maximum value of 255).
To the best of the authors' knowledge, this requirement was never To the best of the authors' knowledge, this requirement was never
actually implemented (and, of course, only a complete and universal actually implemented (and, of course, only a complete and universal
implementation would ensure that packets do not travel for longer implementation would ensure that packets do not travel for longer
than TTL seconds). In fact, in IPv6, the name of this field has than TTL seconds). In fact, in IPv6, the name of this field has
actually been changed to Hop Limit. Further, IPv4 specification actually been changed to Hop Limit. Further, IPv4 specification
makes no claims about the time it takes the packet to traverse the makes no claims about the time it takes the packet to traverse the
last link of the path. last link of the path.
The choice of a reasonable value of Timeout is a problem faced by a 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 user of OWAMP protocol, not by an implementor. A value such as two
minutes is very safe. Note that certain applications (such as minutes is very safe. Note that certain applications (such as
interactive `one-way ping') might wish to obtain the data faster than interactive "one-way ping" might wish to obtain the data faster than
that. that.
As packets are received, As packets are received,
+ Timestamp the received packet. + timestamp the received packet;
+ in authenticated or encrypted mode, decrypt and authenticate as
+ In authenticated or encrypted mode, decrypt and authenticate as
necessary (packets for which authentication fails MUST be necessary (packets for which authentication fails MUST be
discarded). discarded); and
+ Store the packet sequence number, send time, receive time, and the + 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 TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for
the results to be transferred. the results to be transferred.
+ Packets not received within the Timeout are considered lost. They Packets not received within the Timeout are considered lost. They
are recorded with their true sequence number, presumed send time, are recorded with their true sequence number, presumed send time,
receive time value with all bits being zero, and TTL (or Hop receive time value with all bits being zero, and a TTL (or Hop Limit)
Limit) of 255. of 255.
Implementations SHOULD fetch the TTL/Hop Limit value from the IP Implementations SHOULD fetch the TTL/Hop Limit value from the IP
header of the packet. If an implementation does not fetch the actual header of the packet. If an implementation does not fetch the actual
TTL value (the only good reason to not do so is inability to access TTL value (the only good reason not to do so is an inability to
the TTL field of arriving packets), it MUST record the TTL value as access the TTL field of arriving packets), it MUST record the TTL
255. value as 255.
Packets that are actually received are recorded in the order of Packets that are actually received are recorded in the order of
arrival. Lost packet records serve as indications of the send times arrival. Lost packet records serve as indications of the send times
of lost packets. They SHOULD be placed either at the point where the 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, 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 one MAY place all the records that correspond to lost packets at the
very end. very end.
Packets that have send time in the future MUST be recorded normally, Packets that have send time in the future MUST be recorded normally,
without changing their send timestamp, unless they have to be without changing their send timestamp, unless they have to be
skipping to change at page 35, line 33 skipping to change at page 35, line 5
If any of the following is true, the packet MUST be discarded: 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 is more than Timeout in the past or in the future.
+ Send timestamp differs by more than Timeout from the time when the + Send timestamp differs by more than Timeout from the time when the
packet should have been sent according to its sequence number. packet should have been sent according to its sequence number.
+ In authenticated or encrypted mode, HMAC verification fails. + In authenticated or encrypted mode, HMAC verification fails.
5. Computing Exponentially Distributed Pseudo-Random Numbers 5. Computing Exponentially Distributed Pseudo-Random Numbers
Here we describe the way exponential random quantities used in the Here we describe the way exponential random quantities used in the
protocol are generated. While there is a fair number of algorithms protocol are generated. While there is a fair number of algorithms
for generating exponential random variables, most of them rely on for generating exponential random variables, most of them rely on
having logarithmic function as a primitive, resulting in potentially having logarithmic function as a primitive, resulting in potentially
different values, depending on the particular implementation of the different values, depending on the particular implementation of the
math library. We use algorithm 3.4.1.S in [KNUTH], which is free math library. We use algorithm 3.4.1.S from [KNUTH], which is free
of the above-mentioned problem, and guarantees the same output on any of the above-mentioned problem, and which guarantees the same output
implementation. The algorithm belongs to the ziggurat family on any implementation. The algorithm belongs to the ziggurat family
developed in the 1970s by G. Marsaglia, M. Sibuya and J. H. Ahrens developed in the 1970s by G. Marsaglia, M. Sibuya, and J. H. Ahrens
[ZIGG]. It replaces the use of logarithmic function by clever bit [ZIGG]. It replaces the use of logarithmic function by clever bit
manipulation, still producing the exponential variates on output. manipulation, still producing the exponential variates on output.
5.1. High-Level Description of the Algorithm 5.1. High-Level Description of the Algorithm
For ease of exposition, the algorithm is first described with all For ease of exposition, the algorithm is first described with all
arithmetic operations being interpreted in their natural sense. arithmetic operations being interpreted in their natural sense.
Later, exact details on data types, arithmetic, and generation of the Later, exact details on data types, arithmetic, and generation of the
uniform random variates used by the algorithm are given. It is an uniform random variates used by the algorithm are given. It is an
almost verbatim quotation from [KNUTH], p.133. almost verbatim quotation from [KNUTH], p.133.
Algorithm S: Given a real positive number 'mu', produce an Algorithm S: Given a real positive number "mu", produce an
exponential random variate with mean 'mu'. exponential random variate with mean "mu".
First, the constants First, the constants
Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11 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 are computed in advance. The exact values which MUST be used by all
implementations are given in the next section. This is necessary to implementations are given in the next section. This is necessary to
insure that exactly the same pseudo-random sequences are produced by ensure that exactly the same pseudo-random sequences are produced by
all implementations. all implementations.
S1. [Get U and shift.] Generate a 32-bit uniform random binary S1. [Get U and shift.] Generate a 32-bit uniform random binary
fraction fraction
U = (.b0 b1 b2 ... b31) [note the binary point] U = (.b0 b1 b2 ... b31) [note the binary point]
Locate the first zero bit b_j, and shift off the leading (j+1) bits, Locate the first zero bit b_j and shift off the leading (j+1) bits,
setting U <- (.b_{j+1} ... b31) setting U <- (.b_{j+1} ... b31)
Note: In the rare case that the zero has not been found, it is Note: In the rare case that the zero has not been found, it is
prescribed that the algorithm return (mu*32*ln2). prescribed that the algorithm return (mu*32*ln2).
S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and S2. [Immediate acceptance?] If U < ln2, set X <- mu*(j*ln2 + U) and
terminate the algorithm. (Note that Q[1] = ln2.) terminate the algorithm. (Note that Q[1] = ln2.)
S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k S3. [Minimize.] Find the least k >= 2 such that U < Q[k]. Generate k
new uniform random binary fractions U1,...,Uk and set V <- new uniform random binary fractions U1,...,Uk and set V <-
min(U1,...,Uk). min(U1,...,Uk).
S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2. S4. [Deliver the answer.] Set X <- mu*(j + V)*ln2.
5.2. Data Types, Representation, and Arithmetic 5.2. Data Types, Representation, and Arithmetic
The high-level algorithm operates on real numbers -- typically The high-level algorithm operates on real numbers, typically
represented as floating point numbers. This specification prescribes represented as floating point numbers. This specification prescribes
that unsigned 64-bit integers be used instead. that unsigned 64-bit integers be used instead.
u_int64_t integers are interpreted as real numbers by placing the u_int64_t integers are interpreted as real numbers by placing the
decimal point after the first 32 bits. In other words, conceptually, decimal point after the first 32 bits. In other words, conceptually,
the interpretation is given by the map: the interpretation is given by the following map:
u_int64_t u; u_int64_t u;
u |--> (double)u / (2**32) u |--> (double)u / (2**32)
The algorithm produces a sequence of such u_int64_t integers that, 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 for any given value of SID, is guaranteed to be the same on any
implementation. implementation.
We specify that the u_int64_t representations of the first 11 values We specify that the u_int64_t representations of the first 11 values
skipping to change at page 37, line 39 skipping to change at page 37, line 4
For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32) For example, Q[1] = ln2 is indeed approximated by 0xB17217F8/(2**32)
= 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF. = 0.693147180601954; for j > 11, Q[j] is 0xFFFFFFFF.
Small integer j in the high-level algorithm is represented as Small integer j in the high-level algorithm is represented as
u_int64_t value j * (2**32). u_int64_t value j * (2**32).
Operation of addition is done as usual on u_int64_t numbers; however, Operation of addition is done as usual on u_int64_t numbers; however,
the operation of multiplication in the high-level algorithm should be the operation of multiplication in the high-level algorithm should be
replaced by replaced by
(u, v) |---> (u * v) >> 32. (u, v) |---> (u * v) >> 32.
Implementations MUST compute the product (u * v) exactly. For Implementations MUST compute the product (u * v) exactly. For
example, a fragment of unsigned 128-bit arithmetic can be implemented example, a fragment of unsigned 128-bit arithmetic can be implemented
for this purpose (see sample implementation below). for this purpose (see the sample implementation in Appendix A).
5.3. Uniform Random Quantities 5.3. Uniform Random Quantities
The procedure for obtaining a sequence of 32-bit random numbers (such 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. as U in algorithm S) relies on using AES encryption in counter mode.
To describe the exact working of the algorithm, we introduce two To describe the exact working of the algorithm, we introduce two
primitives from Rijndael. Their prototypes and specification are primitives from Rijndael. Their prototypes and specification are
given below, and they are assumed to be provided by the supporting given below, and they are assumed to be provided by the supporting
Rijndael implementation, such as [RIJN]. Rijndael implementation, such as [RIJN].
+ A function that initializes a Rijndael key with bytes from seed + A function that initializes a Rijndael key with bytes from seed
(the SID will be used as the seed): (the SID will be used as the seed):
void KeyInit(unsigned char seed[16]); void KeyInit(unsigned char seed[16]);
+ A function that encrypts the 16-octet block inblock with the + A function that encrypts the 16-octet block inblock with the
specified key, returning a 16-octet encrypted block. Here specified key, returning a 16-octet encrypted block. Here,
keyInstance is an opaque type used to represent Rijndael keys: keyInstance is an opaque type used to represent Rijndael keys:
void BlockEncrypt(keyInstance key, unsigned char inblock[16]); void BlockEncrypt(keyInstance key, unsigned char inblock[16]);
Algorithm Unif: given a 16-octet quantity seed, produce a sequence of Algorithm Unif: given a 16-octet quantity seed, produce a sequence of
unsigned 32-bit pseudo-random uniformly distributed integers. In unsigned 32-bit pseudo-random uniformly distributed integers. In
OWAMP, the SID (session ID) from Control protocol plays the role of OWAMP, the SID (session ID) from Control protocol plays the role of
seed. seed.
U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an U1. [Initialize Rijndael key] key <- KeyInit(seed) [Initialize an
unsigned 16-octet (network byte order) counter] c <- 0 U2. [Need unsigned 16-octet (network byte order) counter] c <- 0
more random bytes?] Set i <- c mod 4. If (i == 0) set s <-
BlockEncrypt(key, c) 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 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 U4. [Do output] Output the i_th quartet of octets from s starting
from high-order octets, converted to native byte order and from high-order octets, converted to native byte order and
represented as OWPNum64 value (as in 3.b). represented as OWPNum64 value (as in 3.b).
U5. [Loop] Go to step U2. U5. [Loop] Go to step U2.
6. Security Considerations 6. Security Considerations
6.1. Introduction 6.1. Introduction
The goal of authenticated mode to let one passphrase-protect the The goal of authenticated mode is to let one passphrase-protect the
service provided by a particular OWAMP-Control server. One can service provided by a particular OWAMP-Control server. One can
imagine a variety of circumstances where this could be useful. imagine a variety of circumstances where this could be useful.
Authenticated mode is designed to prohibit theft of service. Authenticated mode is designed to prohibit theft of service.
An additional design objective of the authenticated mode was to make An additional design objective of the authenticated mode was to make
it impossible for an attacker who cannot read traffic between OWAMP- it impossible for an attacker who cannot read traffic between OWAMP-
Test sender and receiver to tamper with test results in a fashion Test sender and receiver to tamper with test results in a fashion
that affects the measurements, but not other traffic. that affects the measurements, but not other traffic.
The goal of encrypted mode is quite different: to make it hard for a 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 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 they should be. This is especially true if one of client and server
does not coincide with either sender or receiver. does not coincide with either sender or receiver.
Encryption of OWAMP-Control using AES CBC mode with blocks of HMAC Encryption of OWAMP-Control using AES CBC mode with blocks of HMAC
after each message aims to achieve two goals: (i) to provide secrecy after each message aims to achieve two goals: (i) to provide secrecy
of exchange; (ii) to provide authentication of each message. of exchange, and (ii) to provide authentication of each message.
6.2. Preventing Third-Party Denial of Service 6.2. Preventing Third-Party Denial of Service
OWAMP-Test sessions directed at an unsuspecting party could be used OWAMP-Test sessions directed at an unsuspecting party could be used
for denial of service (DoS) attacks. In unauthenticated mode, for denial of service (DoS) attacks. In unauthenticated mode,
servers SHOULD limit receivers to hosts they control or to the OWAMP- servers SHOULD limit receivers to hosts they control or to the OWAMP-
Control client. Control client.
Unless otherwise configured, the default behavior of servers MUST be Unless otherwise configured, the default behavior of servers MUST be
to decline requests where the Receiver Address field is not equal to to decline requests where the Receiver Address field is not equal to
the address that the control connection was initiated from or an the address that the control connection was initiated from or an
address of the server (or an address of a host it controls). Given address of the server (or an address of a host it controls). Given
the TCP handshake procedure and sequence numbers in the control the TCP handshake procedure and sequence numbers in the control
connection, this ensures that the hosts that make such requests are connection, this ensures that the hosts that make such requests are
actually those hosts themselves, or at least on the path towards actually those hosts themselves, or at least on the path towards
them. If either this test or the handshake procedure were omitted, them. If either this test or the handshake procedure were omitted,
it would become possible for attackers anywhere in the Internet to it would become possible for attackers anywhere in the Internet to
request large amounts of test packets be directed against victim request that large amounts of test packets be directed against victim
nodes somewhere else. nodes somewhere else.
In any case, OWAMP-Test packets with a given source address MUST only 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., be sent from the node that has been assigned that address (i.e.,
address spoofing is not permitted). address spoofing is not permitted).
6.3. Covert Information Channels 6.3. Covert Information Channels
OWAMP-Test sessions could be used as covert channels of information. OWAMP-Test sessions could be used as covert channels of information.
Environments that are worried about covert channels should take this Environments that are worried about covert channels should take this
into consideration. into consideration.
6.4. Requirement to Include AES in Implementations 6.4. Requirement to Include AES in Implementations
Notice that AES, in counter mode, is used for pseudo-random number Notice that AES, in counter mode, is used for pseudo-random number
generation, so implementation of AES MUST be included even in a generation, so implementation of AES MUST be included even in a
server that only supports unauthenticated mode. server that only supports unauthenticated mode.
6.5. Resource Use Limitations 6.5. Resource Use Limitations
An OWAMP server can consume resources of various kinds. The two most An OWAMP server can consume resources of various kinds. The two most
important kinds of resources are network capacity and memory (primary important kinds of resources are network capacity and memory (primary
or secondary) for storing test results. or secondary) for storing test results.
Any implementation of OWAMP server MUST include technical mechanisms Any implementation of OWAMP server MUST include technical mechanisms
to limit the use of network capacity and memory. Mechanisms for to limit the use of network capacity and memory. Mechanisms for
managing the resources consumed by unauthenticated users and users managing the resources consumed by unauthenticated users and users
authenticated with a KeyID and passphrase SHOULD be separate. The authenticated with a KeyID and passphrase SHOULD be separate. The
default configuration of an implementation MUST enable these default configuration of an implementation MUST enable these
mechanisms and set the resource use limits to conservatively low mechanisms and set the resource use limits to conservatively low
values. values.
One way to design the resource limitation mechanisms is as follows: One way to design the resource limitation mechanisms is as follows:
assign each session to a user class. User classes are partially assign each session to a user class. User classes are partially
ordered with ``includes'' relation, with one class (``all users'') ordered with "includes" relation, with one class ("all users") that
that is always present and that includes any other class. The is always present and that includes any other class. The assignment
assignment of a session to a user class can be based on the presence of a session to a user class can be based on the presence of
of authentication of the session, the KeyID, IP address range, time authentication of the session, the KeyID, IP address range, time of
of day, and, perhaps, other factors. Each user class would have a day, and, perhaps, other factors. Each user class would have a limit
limit for usage of network capacity (specified in units of for usage of network capacity (specified in units of bit/second) and
bit/second) and memory for storing test results (specified in units memory for storing test results (specified in units of octets).
of octets). Along with the limits for resource use, current use Along with the limits for resource use, current use would be tracked
would be tracked by the server. When a session is requested by a by the server. When a session is requested by a user in a specific
user in a specific user class, the resources needed for this session user class, the resources needed for this session are computed: the
are computed: the average network capacity use (based on the sending average network capacity use (based on the sending schedule) and the
schedule) and the maximum memory use (based on the number of packets maximum memory use (based on the number of packets and number of
and number of octets each packet would need to be stored internally octets each packet would need to be stored internally -- note that
-- note that outgoing sessions would not require any memory use). outgoing sessions would not require any memory use). These resource
These resource use numbers are added to the current resource use use numbers are added to the current resource use numbers for the
numbers for the given user class; if such addition would take the given user class; if such addition would take the resource use
resource use outside of the limits for the given user class, the outside of the limits for the given user class, the session is
session is rejected. When resources are reclaimed, corresponding rejected. When resources are reclaimed, corresponding measures are
measures are subtracted from the current use. Network capacity is subtracted from the current use. Network capacity is reclaimed as
reclaimed as soon as the session ends. Memory is reclaimed when the soon as the session ends. Memory is reclaimed when the data is
data is deleted. For unauthenticated sessions, memory consumed by an deleted. For unauthenticated sessions, memory consumed by an OWAMP-
OWAMP-Test session SHOULD be reclaimed after the OWAMP-Control Test session SHOULD be reclaimed after the OWAMP-Control connection
connection that initiated the session is closed (gracefully or that initiated the session is closed (gracefully or otherwise). For
otherwise). For authenticated sessions, the administrator who authenticated sessions, the administrator who configures the service
configures the service should be able to decide the exact policy, but should be able to decide the exact policy, but useful policy
useful policy mechanisms that MAY be implemented are the ability to mechanisms that MAY be implemented are the ability to automatically
automatically reclaim memory when the data is retrieved and the reclaim memory when the data is retrieved and the ability to reclaim
ability to reclaim memory after a certain configurable (based on user memory after a certain configurable (based on user class) period of
class) period of time passes after the OWAMP-Test session terminates. time passes after the OWAMP-Test session terminates.
6.6. Use of Cryptographic Primitives in OWAMP 6.6. Use of Cryptographic Primitives in OWAMP
At an early stage in designing the protocol, we considered using At an early stage in designing the protocol, we considered using
Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401] Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401]
as cryptographic security mechanisms for OWAMP; later, we also as cryptographic security mechanisms for OWAMP; later, we also
considered DTLS. The disadvantages of those are as follows (not an considered DTLS. The disadvantages of those are as follows (not an
exhaustive list): exhaustive list):
Regarding TLS: Regarding TLS:
+ TLS could be used to secure TCP-based OWAMP-Control, but it would + 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 be difficult to use it to secure UDP-based OWAMP-Test: OWAMP-Test
packets, if lost, are not resent, so packets have to be packets, if lost, are not resent, so packets have to be
(optionally) encrypted and authenticated while retaining (optionally) encrypted and authenticated while retaining
individual usability. Stream-based TLS cannot be easily used for individual usability. Stream-based TLS cannot be easily used for
this. this.
+ Dealing with streams, TLS does not authenticate individual + Dealing with streams, TLS does not authenticate individual
messages (even in OWAMP-Control). The easiest way out would be to messages (even in OWAMP-Control). The easiest way out would be to
add some known-format padding to each message and verify that the add some known-format padding to each message and to verify that
format of the padding is intact before using the message. The the format of the padding is intact before using the message. The
solution would thus lose some of its appeal (``just use TLS''); it solution would thus lose some of its appeal ("just use TLS"). It
would also be much more difficult to evaluate the security of this would also be much more difficult to evaluate the security of this
scheme with the various modes and options of TLS -- it would scheme with the various modes and options of TLS; it would almost
almost certainly not be secure with all. The capacity of an certainly not be secure with all. The capacity of an attacker to
attacker to replace parts of messages (namely, the end) with replace parts of messages (namely, the end) with random garbage
random garbage could have serious security implications and would could have serious security implications and would need to be
need to be analyzed carefully: suppose, for example, that a analyzed carefully. Suppose, for example, that a parameter that
parameter that is used in some form to control the rate were is used in some form to control the rate were replaced by random
replaced by random garbage -- chances are the result (an unsigned garbage; chances are that the result (an unsigned integer) would
integer) would be quite large. be quite large.
+ Dependent on the mode of use, one can end up with a requirement + 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 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. accept that PKI is desirable, there just isn't a usable one today.
+ TLS requires a fairly large implementation. OpenSSL, for example, + TLS requires a fairly large implementation. OpenSSL, for example,
is larger than our implementation of OWAMP as a whole. This can is larger than our implementation of OWAMP as a whole. This can
matter for embedded implementations. matter for embedded implementations.
Regarding DTLS: Regarding DTLS:
+ Duplication and, similarly, reordering are network phenomena that + Duplication and, similarly, reordering are network phenomena that
OWAMP needs to be able to measure; yet anti-replay measures and OWAMP needs to be able to measure; yet anti-replay measures and
reordering protection of DTLS would prevent the duplicated and reordering protection of DTLS would prevent the duplicated and
reordered packets from reaching the relevant part of the OWAMP reordered packets from reaching the relevant part of the OWAMP
code. One could, of course, modify DTLS so that these protections code. One could, of course, modify DTLS so that these protections
are weakened, or even specify examining the messages in a are weakened or even specify examining the messages in a carefully
carefully crafted sequence somewhere in between of DTLS checks, crafted sequence somewhere in between DTLS checks; but then, of
but then, of course, the advantage of using an existing protocol course, the advantage of using an existing protocol would not be
would not be realized. realized.
+ In authenticated mode the timestamp is in the clear and not + In authenticated mode, the timestamp is in the clear and is not
protected cryptographically in any way, while the rest of the protected cryptographically in any way, while the rest of the
message has the same protection as in encrypted mode. This mode message has the same protection as in encrypted mode. This mode
allows one to trade off cryptographic protection against accuracy allows one to trade off cryptographic protection against accuracy
of timestamps. For example, the APAN hardware implementation of of timestamps. For example, the APAN hardware implementation of
OWAMP [APAN-OWAMP] is capable of supporting authenticated mode. OWAMP [APAN] is capable of supporting authenticated mode. The
The accuracy of these measurements is in sub-microsecond range. accuracy of these measurements is in the sub-microsecond range.
The errors in OWAMP measurements of Abilene [Abilene-OWAMP] (done The errors in OWAMP measurements of Abilene [Abilene] (done using
using a software implementation, in its encrypted mode) exceed a software implementation, in its encrypted mode) exceed 10us.
10us. Users in different environments have different concerns, Users in different environments have different concerns, and some
and some might very well care about every last microsecond of might very well care about every last microsecond of accuracy. At
accuracy; at the same time, users in these same environments might the same time, users in these same environments might care about
care about access control to the service. Authenticated mode access control to the service. Authenticated mode permits them to
permits them to control access to the server, yet use unprotected control access to the server yet to use unprotected timestamps,
timestamps, perhaps generated by a hardware device. perhaps generated by a hardware device.
Regarding IPsec: Regarding IPsec:
+ What we now call authenticated mode would not be possible (in + What we now call authenticated mode would not be possible (in
IPsec you can't authenticate part of a packet). IPsec you can't authenticate part of a packet).
+ The deployment paths of IPsec and OWAMP could be separate if OWAMP + 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% does not depend on IPsec. After nine years of IPsec, only 0.05%
of traffic on an advanced backbone network such as Abilene uses of traffic on an advanced backbone network, such as Abilene, uses
IPsec (for comparison purposes with encryption above layer 4, SSH 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 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 of a number of different be able to deploy OWAMP on as large a number of different
platforms as possible. platforms as possible.
+ The deployment problems of a protocol dependent on IPsec would be + The deployment problems of a protocol dependent on IPsec would be
especially acute in the case of lightweight embedded devices. especially acute in the case of lightweight embedded devices.
Ethernet switches, DSL ``modems,'' and other such devices mostly Ethernet switches, DSL "modems", and other such devices mostly do
do not support IPsec. not support IPsec.
+ The API for manipulating IPsec from an application is currently + The API for manipulating IPsec from an application is currently
poorly understood. Writing a program that needs to encrypt some poorly understood. Writing a program that needs to encrypt some
packets, authenticate some packets, and leave some open -- for the packets, to authenticate some packets, and to leave some open --
same destination -- would become more of an exercise in IPsec for the same destination -- would become more of an exercise in
rather than in IP measurement. IPsec than in IP measurement.
For the enumerated reasons, we decided to use a simple cryptographic For the enumerated reasons, we decided to use a simple cryptographic
protocol (based on a block cipher in CBC mode) that is different from protocol (based on a block cipher in CBC mode) that is different from
TLS and IPsec. TLS and IPsec.
6.7. Cryptographic primitive replacement 6.7. Cryptographic Primitive Replacement
It might become necessary in the future to replace AES, or the way it 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 is used in OWAMP, with a new cryptographic primitive, or to make
other security-related changes to the protocol. OWAMP provides a other security-related changes to the protocol. OWAMP provides a
well-defined point of extensibility: the Modes word in the server well-defined point of extensibility: the Modes word in the server
greeting and the Mode response in the Set-Up-Response message. For greeting and the Mode response in the Set-Up-Response message. For
example, if a simple replacement of AES with a different block cipher example, if a simple replacement of AES with a different block cipher
with a 128-bit block is needed, this could be accomplished as 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 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 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 and another one to indicate authenticated
mode with the new cipher. (Bit consumption could, in fact, be 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 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 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 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 the server) or selected (in the case of the client) and continue to
use already allocated bits for authenticated and encrypted modes; use already allocated bits for authenticated and encrypted modes;
this optimization is unimportant conceptually, but could be useful in this optimization is unimportant conceptually, but it could be useful
practice to make the best use of bits.) Then, if the new cipher is in practice to make the best use of bits.) Then, if the new cipher
negotiated, all subsequent operations simply use it instead of AES. is negotiated, all subsequent operations simply use it instead of
Note that the normal transition sequence would be used in such a AES. Note that the normal transition sequence would be used in such
case: implementations would probably first start supporting and a case: implementations would probably first start supporting and
preferring the new cipher, and then drop support for the old preferring the new cipher, and then drop support for the old cipher
(presumably no longer considered secure) cipher. (presumably no longer considered secure).
If the need arises to make more extensive changes (perhaps replace 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 AES with a 256-bit-block cipher), this would be more difficult and
would require changing the layout of the messages. However, the would require changing the layout of the messages. However, the
change can still be conducted within the framework of OWAMP change can still be conducted within the framework of OWAMP
extensibility using the Modes/Mode words. (The semantics of the new extensibility using the Modes/Mode words. The semantics of the new
bits [or single bit, if the optimization described above is used] bits (or single bit, if the optimization described above is used)
would include the change to message layout as well as the change in would include the change to message layout as well as the change in
the cryptographic primitive.) the cryptographic primitive.
Each of the bits in the Modes word can be used for an independent Each of the bits in the Modes word can be used for an independent
extension. The extensions signaled by various bits are orthogonal: extension. The extensions signaled by various bits are orthogonal;
for example, one bit might be allocated to change from AES-128 to 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 some other cipher, another bit might be allocated to add a protocol
feature (such as, e.g., support for measuring over multicast), yet feature (such as, e.g., support for measuring over multicast), yet
another might be allocated to change a key derivation function, etc. another might be allocated to change a key derivation function, etc.
The progression of versions is not a linear order, but rather partial The progression of versions is not a linear order, but rather a
order. An implementation can implement any subset of these features partial order. An implementation can implement any subset of these
(of course, features can be made mandatory to implement---e.g., new features (of course, features can be made mandatory to implement,
more secure ciphers if they are needed). e.g., new more secure ciphers if they are needed).
Should a cipher with a different key size, say a 256-bit key, become 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 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 be needed. The semantics of change in the cipher SHOULD then in the
future be tied to semantics of change in the key derivation function future be tied to the semantics of change in the key derivation
(KDF). One KDF that might be considered for the purpose might be a function (KDF). One KDF that might be considered for the purpose
pseudo-random function (PRF) with appropriately sized output, such as might be a pseudo-random function (PRF) with appropriately sized
256 bits (perhaps HMAC-SHA256, if it is then still considered a output, such as 256 bits (perhaps HMAC-SHA256, if it is then still
secure PRF), which could then be used to derive the OWAMP-Test considered a secure PRF), which could then be used to derive the
session keys from the OWAMP-Control session key by using the OWAMP- OWAMP-Test session keys from the OWAMP-Control session key by using
Control session key as the HMAC key and the SID as HMAC message. the OWAMP-Control session key as the HMAC key and the SID as HMAC
message.
Note that the replacement scheme outlined above is trivially Note that the replacement scheme outlined above is trivially
susceptible to downgrade attacks: a malicious party in the middle can susceptible to downgrade attacks: a malicious party in the middle can
flip modes bits as the mode is negotiated so that the oldest and 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 weakest mode supported by the two parties is used. If this is deemed
problematic at the time of cryptographic primitive replacement, the problematic at the time of cryptographic primitive replacement, the
scheme might be augmented with a measure to prevent such an attack scheme might be augmented with a measure to prevent such an attack
(by perhaps exchanging the modes again once a secure communications (by perhaps exchanging the modes again once a secure communications
channel is established, comparing the two sets of mode words, and channel is established, comparing the two sets of mode words, and
dropping the connection should they not match). dropping the connection should they not match).
6.8. Long-term manually managed keys 6.8. Long-term Manually Managed Keys
OWAMP-Control uses long-term keys with manual management. These keys OWAMP-Control uses long-term keys with manual management. These keys
are used to automatically negotiate session keys for each OWAMP- are used to automatically negotiate session keys for each OWAMP-
Control session running in authenticated or encrypted mode. The Control session running in authenticated or encrypted mode. The
number of these keys managed by a server scales linearly with (and, number of these keys managed by a server scales linearly with (and,
in fact, is equal to) the number of administratively different users in fact, is equal to) the number of administratively different users
(perhaps particular humans, roles, or robots representing sites) that (perhaps particular humans, roles, or robots representing sites) that
need to connect to this server. Similarly, the number of different need to connect to this server. Similarly, the number of different
manual keys managed by each client is the number of different servers 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 that the client needs to connect to. This use of manual long-term
keys is compliant with [BCP107]. keys is compliant with [BCP107].
6.9. (Not) Using Time as Salt 6.9. (Not) Using Time as Salt
A natural idea is to use the current time as salt when deriving A natural idea is to use the current time as salt when deriving
session keys. Unfortunately, this appears too limiting. session keys. Unfortunately, this appears to be too limiting.
While OWAMP is often run on hosts with well-synchronized clocks, it Although OWAMP is often run on hosts with well-synchronized clocks,
is also possible to run it on hosts with clocks completely untrained. it is also possible to run it on hosts with clocks completely
The delays obtained thusly are, of course, not directly usable; untrained. The delays obtained thus are, of course, not directly
however, some metrics, such as unidirectional loss, reordering, usable; however, some metrics, such as unidirectional loss,
measures of congestion such as the median delay minus minimum, and reordering, measures of congestion such as the median delay minus
many others are usable directly and immediately (and improve upon the minimum, and many others are usable directly and immediately (and
information that would have been provided by a round-trip improve upon the information that would have been provided by a
measurement); further, even delay information can be useful with round-trip measurement). Further, even delay information can be
appropriate post-processing---indeed, one can even argue that running useful with appropriate post-processing. Indeed, one can even argue
the clocks free and post-processing the results of a mesh of that running the clocks free and post-processing the results of a
measurements will result in better accuracy, as more information is mesh of measurements will result in better accuracy, as more
available a posteriori and correlation of data from different hosts information is available a posteriori and correlation of data from
is possible in post-processing, but not with online clock training. different hosts is possible in post-processing, but not with online
clock training.
Given this, time is not used as salt in key derivation. Given this, time is not used as salt in key derivation.
6.10. The Use of AES-CBC and HMAC 6.10. The Use of AES-CBC and HMAC
OWAMP relies on AES-CBC for confidentiality and on HMAC-SHA1 OWAMP relies on AES-CBC for confidentiality and on HMAC-SHA1
truncated to 128 bits for message authentication. Random IV choice truncated to 128 bits for message authentication. Random IV choice
is important for prevention of a codebook attack on the first block 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 (it should also be noted that, with its 128-bit block size, AES is
more resistant to codebook attacks than ciphers with shorter blocks; more resistant to codebook attacks than are ciphers with shorter
we use random IV anyway). blocks; we use random IV anyway).
HMAC MUST verify. It is crucial to check for this before using the HMAC MUST verify. It is crucial to check for this before using the
message, otherwise existential forgery becomes possible. The message; otherwise, existential forgery becomes possible. The
complete message for which HMAC verification fails MUST be discarded complete message for which HMAC verification fails MUST be discarded
(for both short messages consisting of a few blocks and potentially (both for short messages consisting of a few blocks and potentially
long messages, such as a response to the Fetch-Session command); if for long messages, such as a response to the Fetch-Session command).
such a message is part of OWAMP-Control, the connection MUST be If such a message is part of OWAMP-Control, the connection MUST be
dropped. dropped.
Since OWAMP messages can have different numbers of blocks, the Since OWAMP messages can have different numbers of blocks, the
existential forgery attack described in example 9.62 of [MENEZES] existential forgery attack described in example 9.62 of [MENEZES]
becomes a concern. To prevent it (and to simplify implementation), becomes a concern. To prevent it (and to simplify implementation),
the length of any message becomes known after decrypting the first the length of any message becomes known after decrypting its first
block of it. block.
A special case is the first (fixed-length) message sent by the A special case is the first (fixed-length) message sent by the
client. There, the token is a concatenation of the 128-bit challenge client. There, the token is a concatenation of the 128-bit challenge
(transmitted by the server in the clear) and a 128-bit session key (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. (generated randomly by the client, encrypted with AES-CBC with IV=0),
Since IV=0, the challenge (a single cipher block) is simply encrypted and a 256-bit HMAC-SHA1 Session-key used for authentication. Since
with the secret key. Therefore, we rely on resistance of AES to IV=0, the challenge (a single cipher block) is simply encrypted with
chosen plaintext attacks (as the challenge could be substituted by an 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 attacker). It should be noted that the number of blocks of chosen
plaintext an attacker can have encrypted with the secret key is plaintext an attacker can have encrypted with the secret key is
limited by the number of sessions the client wants to initiate. An limited by the number of sessions the client wants to initiate. An
attacker who knows the encryption of a server's challenge can produce attacker who knows the encryption of a server's challenge can produce
an existential forgery of the session key and thus disrupt the an existential forgery of the session key and thus disrupt the
session; however, any attacker can disrupt a session by corrupting session; however, any attacker can disrupt a session by corrupting
the protocol messages in an arbitrary fashion, therefore no new the protocol messages in an arbitrary fashion. Therefore, no new
threat is created here; nevertheless, we require that the server threat is created here; nevertheless, we require that the server
never issues the same challenge twice (if challenges are generated never issues the same challenge twice. (If challenges are generated
randomly, a repetition would occur, on average, after 2^64 sessions; randomly, a repetition would occur, on average, after 2^64 sessions;
we deem this satisfactory as this is enough even for an implausibly 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 busy server that participates in 1,000,000 sessions per second to go
without repetitions for more than 500 centuries). With respect to without repetitions for more than 500 centuries.) With respect to
the second part of the token, an attacker can produce an existential the second part of the token, an attacker can produce an existential
forgery of the session key by modifying the second half of the forgery of the session key by modifying the second half of the
client's token while leaving the first part intact. This forgery, client's token while leaving the first part intact. This forgery,
however, would be immediately discovered by the client when the HMAC however, would be immediately discovered by the client when the HMAC
on the server's next message (acceptance or rejection of the on the server's next message (acceptance or rejection of the
connection) does not verify. connection) does not verify.
7. IANA Considerations 7. Acknowledgements
IANA is requested to allocate a well-known TCP port number for the We would like to thank Guy Almes, Mark Allman, Jari Arkko, Hamid
OWAMP-Control part of the OWAMP protocol. 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. Internationalization Considerations 8. IANA Considerations
IANA has allocated a well-known TCP port number (861) for the OWAMP-
Control part of the OWAMP protocol.
9. Internationalization Considerations
The protocol does not carry any information in a natural language, The protocol does not carry any information in a natural language,
with the possible exception of the KeyID in OWAMP-Control, which is with the possible exception of the KeyID in OWAMP-Control, which is
encoded in UTF-8. encoded in UTF-8.
9. Appendix A: Sample C Code for Exponential Deviates 10. References
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.
/* 10.1. Normative References
** 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 [AES] Advanced Encryption Standard (AES),
** (as the shared secret in OWAMP, for example) http://csrc.nist.gov/encryption/aes/
** unsigned char seed[16];
** OWPrand_context next; [BCP107] Bellovin, S. and R. Housley, "Guidelines for
Cryptographic Key Management", BCP 107, RFC 4107,
June 2005.
** (initialize state) [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
** OWPrand_context_init(&next, seed); Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
** (generate a sequence of exponential variates) [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
** while (1) { Requirement Levels", BCP 14, RFC 2119, March 1997.
** u_int64_t num = OWPexp_rand64(&next);
<do something with num here>
...
** }
*/
#include <stdlib.h> [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May
1998.
typedef u_int64_t u_int64_t; [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.
/* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */ [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-
#define K 12 way Delay Metric for IPPM", RFC 2679, September 1999.
#define BIT31 0x80000000UL /* See if first bit in the lower [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-
32 bits is zero. */ way Packet Loss Metric for IPPM", RFC 2680, September
#define MASK32(n) ((n) & 0xFFFFFFFFUL) 1999.
#define EXP2POW32 0x100000000ULL [RFC2836] Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop
Behavior Identification Codes", RFC 2836, May 2000.
typedef struct OWPrand_context { [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
unsigned char counter[16]; /* Counter (network byte order). */ Specification Version 2.0", RFC 2898, September 2000.
keyInstance key; /* Key to encrypt the counter. */
unsigned char out[16]; /* The encrypted block. */
} OWPrand_context; 10.2. Informative References
/* [APAN] Z. Shu and K. Kobayashi, "HOTS: An OWAMP-Compliant
** The array has been computed according to the formula: Hardware Packet Timestamper", In Proceedings of PAM
** 2005, http://www.springerlink.com/index/
** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!) W4GBD39YWC11GQTN.pdf
**
** 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. */
0xB17217F8,
0xEEF193F7,
0xFD271862,
0xFF9D6DD0,
0xFFF4CFD0,
0xFFFEE819,
0xFFFFE7FF,
0xFFFFFE2B,
0xFFFFFFE0,
0xFFFFFFFE,
0xFFFFFFFF
};
/* this element represents ln2 */ [BRIX] Brix Networks, http://www.brixnet.com/
#define LN2 Q[1]
/* [ZIGG] J. H. Ahrens, U. Dieter, "Computer methods for
** Convert an unsigned 32-bit integer into a u_int64_t number. sampling from the exponential and normal
*/ distributions", Communications of ACM, volume 15,
u_int64_t issue 10, 873-882, 1972.
OWPulong2num64(u_int32_t a) http://doi.acm.org/10.1145/355604.361593
{
return ((u_int64_t)1 << 32) * a;
}
/* [MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A.
** Arithmetic functions on u_int64_t numbers. Vanstone, Handbook of Applied Cryptography, CRC
*/ Press, revised reprint with updates, 1997.
/* [KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd
** Addition. edition, 1998.
*/
u_int64_t
OWPnum64_add(u_int64_t x, u_int64_t y)
{
return x + y;
}
/* [Abilene] One-way Latency Measurement (OWAMP),
** Multiplication. Allows overflow. Straightforward implementation http://e2epi.internet2.edu/owamp/
** of Algorithm 4.3.1.M (p.268) from [KNUTH].
*/
u_int64_t
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; [RIJN] Reference ANSI C Implementation of Rijndael,
u_int64_t k, t, ret; http://www.esat.kuleuven.ac.be/~rijmen/
rijndael/rijndaelref.zip
xdec[0] = MASK32(x); [RIPE] RIPE NCC Test-Traffic Measurements home,
xdec[1] = MASK32(x>>32); http://www.ripe.net/test-traffic/.
ydec[0] = MASK32(y);
ydec[1] = MASK32(y>>32);
for (j = 0; j < 4; j++) [SURVEYOR] Surveyor Home Page,
w[j] = 0; http://www.advanced.org/surveyor/.
for (j = 0; j < 2; j++) { [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, "Surveyor: An
k = 0; Infrastructure for Network Performance Measurements",
for (i = 0; ; ) { Proceedings of INET'99, June 1999.
t = k + (xdec[i]*ydec[j]) + w[i + j]; http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
w[i + j] = t%EXP2POW32;
k = t/EXP2POW32;
if (++i < 2)
continue;
else {
w[j + 2] = k;
break;
}
}
}
ret = w[2]; [RFC1305] Mills, D., "Network Time Protocol (Version 3)
ret <<= 32; Specification, Implementation and Analysis", RFC
return w[1] + ret; 1305, March 1992.
}
/* [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
** Seed the random number generator using a 16-byte quantity 'seed' 1.0", RFC 2246, January 1999.
** (== the session ID in OWAMP). This function implements step U1
** of algorithm Unif.
*/
void [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
OWPrand_context_init(OWPrand_context *next, unsigned char *seed) the Internet Protocol", RFC 2401, November 1998.
{
int i;
/* Initialize the key */ [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D.,
rijndaelKeyInit(next->key, seed); Mikkelsen, J., and T. Wright, "Transport Layer
Security (TLS) Extensions", RFC 3546, June 2003.
/* Initialize the counter with zeros */ [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
memset(next->out, 0, 16); "Randomness Requirements for Security", BCP 106, RFC
for (i = 0; i < 16; i++) 4086, June 2005.
next->counter[i] = 0UL;
}
/* Appendix A: Sample C Code for Exponential Deviates
** Random number generating functions.
*/
/* The values in array Q[] are the exact values that MUST be used by all
** Generate and return a 32-bit uniform random value (saved in the less implementations (see Sections 5.1 and 5.2). This appendix only
** significant half of the u_int64_t). This function implements steps serves for illustrative purposes.
** U2-U4 of the algorithm Unif.
*/
u_int64_t
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; ** Example usage: generate a stream of exponential (mean 1)
if (!i) ** random quantities (ignoring error checking during initialization).
rijndaelEncrypt(next->key, next->counter, next->out); ** 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.
/* Step U3. Increment next.counter as a 16-octet single ** Assume that a 16-octet 'seed' has been initialized
quantity in network byte order for AES counter mode. */ ** (as the shared secret in OWAMP, for example)
for (j = 15; j >= 0; j--) ** unsigned char seed[16];
if (++next->counter[j])
break;
/* Step U4. Do output. The last 4 bytes of ret now contain the ** OWPrand_context next;
random integer in network byte order */
buf = &next->out[4*i];
for (j=0; j<4; j++) {
ret <<= 8;
ret += *buf++;
}
return ret;
}
/* ** (initialize state)
** Generate an exponential deviate with mean 1. ** OWPrand_context_init(&next, seed);
*/
u_int64_t
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 */ ** (generate a sequence of exponential variates)
U = OWPunif_rand64(next); ** while (1) {
** u_int64_t num = OWPexp_rand64(&next);
<do something with num here>
...
** }
*/
while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */ #include <stdlib.h>
U <<= 1;
j++;
}
/* Remove the 0 itself. */
U <<= 1;
U = MASK32(U); /* Keep only the fractional part. */ typedef u_int64_t u_int64_t;
J = OWPulong2num64(j);
/* Step S2. Immediate acceptance? */ /* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */
if (U < LN2) /* return (j*ln2 + U) */ #define K 12
return OWPnum64_add(OWPnum64_mul(J, LN2), U);
/* Step S3. Minimize. */ #define BIT31 0x80000000UL /* See if first bit in the lower
for (k = 2; k < K; k++) 32 bits is zero. */
if (U < Q[k]) #define MASK32(n) ((n) & 0xFFFFFFFFUL)
break;
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 */ #define EXP2POW32 0x100000000ULL
return OWPnum64_mul(OWPnum64_add(J, V), LN2);
}
10. Appendix B: Test Vectors for Exponential Deviates 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.*/
It is important that the test schedules generated by different } OWPrand_context;
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) ** 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. */
0xB17217F8,
0xEEF193F7,
0xFD271862,
0xFF9D6DD0,
0xFFF4CFD0,
0xFFFEE819,
0xFFFFE7FF,
0xFFFFFE2B,
0xFFFFFFE0,
0xFFFFFFFE,
0xFFFFFFFF
};
SID = 0x0102030405060708090a0b0c0d0e0f00 /* this element represents ln2 */
SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds) #define LN2 Q[1]
SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef /*
SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds) ** Convert an unsigned 32-bit integer into a u_int64_t number.
*/
u_int64_t
OWPulong2num64(u_int32_t a)
{
return ((u_int64_t)1 << 32) * a;
}
SID = 0xfeed0feed1feed2feed3feed4feed5ab /*
SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds) ** Arithmetic functions on u_int64_t numbers.
*/
11. Normative References /*
** Addition.
*/
u_int64_t
OWPnum64_add(u_int64_t x, u_int64_t y)
{
return x + y;
}
[AES] Advanced Encryption Standard (AES), /*
http://csrc.nist.gov/encryption/aes/ ** Multiplication. Allows overflow. Straightforward implementation
** of Algorithm 4.3.1.M (p.268) from [KNUTH].
*/
u_int64_t
OWPnum64_mul(u_int64_t x, u_int64_t y)
{
unsigned long w[4];
u_int64_t xdec[2];
u_int64_t ydec[2];
[BCP107] S. Bellovin, R. Housley, `Guidelines for Cryptographic Key int i, j;
Management', RFC 4107, June 2005. u_int64_t k, t, ret;
[RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3', xdec[0] = MASK32(x);
RFC 2026, October 1996. xdec[1] = MASK32(x>>32);
ydec[0] = MASK32(y);
ydec[1] = MASK32(y>>32);
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, `HMAC: Keyed-Hashing for (j = 0; j < 4; j++)
for Message Authentication', RFC2104, February 1997. w[j] = 0;
[RFC2119] S. Bradner, `Key words for use in RFCs to Indicate for (j = 0; j < 2; j++) {
Requirement Levels', RFC 2119, March 1997. 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)
continue;
else {
w[j + 2] = k;
break;
}
}
}
[RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for ret = w[2];
IP Performance Metrics' RFC 2330, May 1998. ret <<= 32;
return w[1] + ret;
}
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, `Definition of /*
the Differentiated Services Field (DS Field) in the IPv4 and ** Seed the random number generator using a 16-byte quantity 'seed'
IPv6 Headers', RFC 2474, December 1998. ** (== the session ID in OWAMP). This function implements step U1
** of algorithm Unif.
*/
[RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay void
Metric for IPPM', RFC 2679, September 1999. OWPrand_context_init(OWPrand_context *next, unsigned char *seed)
{
int i;
[RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet /* Initialize the key */
Loss Metric for IPPM', RFC 2680, September 1999. rijndaelKeyInit(next->key, seed);
[RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior /* Initialize the counter with zeros */
Identification Codes', RFC 2836, May 2000. memset(next->out, 0, 16);
for (i = 0; i < 16; i++)
next->counter[i] = 0UL;
}
[RFC2898] B. Kaliski, `PKCS #5: Password-Based Cryptography /*
Specification, Version 2.0', RFC 2898, September 2000. ** Random number generating functions.
*/
12. Informative References /*
** 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.
*/
u_int64_t
OWPunif_rand64(OWPrand_context *next)
{
int j;
u_int8_t *buf;
u_int64_t ret = 0;
[APAN-OWAMP] Z. Shu and K. Kobayashi, HOTS: An OWAMP-Compliant /* step U2 */
Hardware Packet Timestamper, In Proceedings of PAM 2005, u_int8_t i = next->counter[15] & (u_int8_t)3;
http://www.pam2005.org/PDF/34310360.pdf if (!i)
rijndaelEncrypt(next->key, next->counter, next->out);
[BRIX] Brix Networks, http://www.brixnet.com/ /* 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])
break;
[ZIGG] G. Marsaglia, M. Sibuya, and J. H. Ahrens, Communications of /* Step U4. Do output. The last 4 bytes of ret now contain
ACM, 15 (1972), 876-877. the random integer in network byte order */
buf = &next->out[4*i];
for (j=0; j<4; j++) {
ret <<= 8;
ret += *buf++;
}
return ret;
}
[MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, /*
Handbook of Applied Cryptography, CRC Press, revised reprint ** Generate an exponential deviate with mean 1.
with updates, 1997. */
u_int64_t
OWPexp_rand64(OWPrand_context *next)
{
unsigned long i, k;
u_int32_t j = 0;
u_int64_t U, V, J, tmp;
[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd /* Step S1. Get U and shift */
edition, 1998. U = OWPunif_rand64(next);
[Abilene-OWAMP] One-way Latency Measurement (OWAMP), while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */
http://e2epi.internet2.edu/owamp/ U <<= 1;
j++;
}
/* Remove the 0 itself. */
U <<= 1;
[RIJN] Reference ANSI C Implementation of Rijndael U = MASK32(U); /* Keep only the fractional part. */
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip J = OWPulong2num64(j);
[RIPE] RIPE NCC Test-Traffic Measurements home, /* Step S2. Immediate acceptance? */
http://www.ripe.net/test-traffic/. if (U < LN2) /* return (j*ln2 + U) */
return OWPnum64_add(OWPnum64_mul(J, LN2), U);
[RIPE-NLUUG] H. Uijterwaal and O. Kolkman, `Internet Delay /* Step S3. Minimize. */
Measurements Using Test-Traffic', Spring 1998 Dutch Unix User for (k = 2; k < K; k++)
Group Meeting, if (U < Q[k])
http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz. break;
V = OWPunif_rand64(next);
for (i = 2; i <= k; i++) {
tmp = OWPunif_rand64(next);
if (tmp < V)
V = tmp;
}
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. /* Step S4. Return (j+V)*ln2 */
return OWPnum64_mul(OWPnum64_add(J, V), LN2);
}
[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An Appendix B: Test Vectors for Exponential Deviates
Infrastructure for Network Performance Measurements',
Proceedings of INET'99, June 1999.
http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
[RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification, It is important that the test schedules generated by different
Implementation and Analysis', RFC 1305, March 1992. 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.
[RFC2246] T. Dierks, C. Allen, `The TLS Protocol Version 1.0', SID = 0x2872979303ab47eeac028dab3829dab2
January 1999. SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds)
[RFC2401] S. Kent, R. Atkinson, `Security Architecture for the SID = 0x0102030405060708090a0b0c0d0e0f00
Internet Protocol', November 1998. SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds)
[RFC3546] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef
Wright, `Transport Layer Security (TLS) Extensions', June 2003. SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)
[RFC4086] D. Eastlake 3rd, J. Schiller, S. Crocker, `Randomness SID = 0xfeed0feed1feed2feed3feed4feed5ab
Recommendations for Security', June 2005. SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)
13. Authors' Addresses Authors' Addresses
Stanislav Shalunov Stanislav Shalunov
Internet2 Internet2
1000 Oakbrook Drive, Suite 300 1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104 Ann Arbor, MI 48104
Email: shalunov@internet2.edu
SIP: shalunov@internet2.edu EMail: shalunov@internet2.edu
WWW: http://www.internet2.edu/~shalunov/
Benjamin Teitelbaum Benjamin Teitelbaum
Internet2 Internet2
1000 Oakbrook Drive, Suite 300 1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104 Ann Arbor, MI 48104
Email: ben@internet2.edu
SIP: ben@internet2.edu EMail: ben@internet2.edu
WWW: http://people.internet2.edu/~ben/
Anatoly Karp Anatoly Karp
4710 Regent St, Apt 81B Computer Sciences Department
Madison, WI 53705 University of Wisconsin-Madison
Telephone: +1-608-347-6255 Madison, WI 53706
Email: ankarp@charter.net
EMail: akarp@cs.wisc.edu
Jeff W. Boote Jeff W. Boote
Internet2 Internet2
1000 Oakbrook Drive, Suite 300 1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104 Ann Arbor, MI 48104
Email: boote@internet2.edu
SIP: boote@internet2.edu EMail: boote@internet2.edu
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
1000 Oakbrook Drive, Suite 300 1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104 Ann Arbor, MI 48104
Email: matt@internet2.edu
SIP: matt@internet2.edu EMail: matt@internet2.edu
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be found on the procedures with respect to rights in RFC documents can be
in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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.
Acknowledgments
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.
Expiration date: August 2006 Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 287 change blocks. 
854 lines changed or deleted 882 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/