< draft-ietf-ippm-owdp-10.txt   draft-ietf-ippm-owdp-11.txt >
Network Working Group Stanislav Shalunov Network Working Group Stanislav Shalunov
Internet Draft Benjamin Teitelbaum Internet Draft Benjamin Teitelbaum
Expiration Date: February 2005 Anatoly Karp Expiration Date: April 2005 Anatoly Karp
Jeff W. Boote Jeff W. Boote
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
August 2004 October 2004
A One-way Active Measurement Protocol (OWAMP) A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-10.txt> <draft-ietf-ippm-owdp-11.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 9 skipping to change at page 2, line 9
becomes increasingly possible to measure one-way IP performance becomes increasingly possible to measure one-way IP performance
metrics with high precision. To do so in an interoperable manner, a metrics with high precision. To do so in an interoperable manner, a
common protocol for such measurements is required. The One-Way common protocol for such measurements is required. The One-Way
Active Measurement Protocol (OWAMP) can measure one-way delay, as Active Measurement Protocol (OWAMP) can measure one-way delay, as
well as other unidirectional characteristics, such as one-way loss. well as other unidirectional characteristics, such as one-way loss.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship of Test and Control Protocols . . . . . . 4 1.1. Relationship of Test and Control Protocols . . . . . . 4
1.2. Logical Model . . . . . . . . . . . . . . . . . . . . 4 1.2. Logical Model . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6
3. OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . 7 3. OWAMP-Control . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Connection Setup . . . . . . . . . . . . . . . . . . . 7 3.1. Connection Setup . . . . . . . . . . . . . . . . . . . 7
3.2. OWAMP-Control Commands . . . . . . . . . . . . . . . . 10 3.2. Values of the Accept Field . . . . . . . . . . . . . . 10
3.3. Creating Test Sessions . . . . . . . . . . . . . . . . 11 3.3. OWAMP-Control Commands . . . . . . . . . . . . . . . . 11
3.4. Send Schedules . . . . . . . . . . . . . . . . . . . . 16 3.4. Creating Test Sessions . . . . . . . . . . . . . . . . 11
3.5. Starting Test Sessions . . . . . . . . . . . . . . . . 17 3.5. Send Schedules . . . . . . . . . . . . . . . . . . . . 16
3.6. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19 3.6. Starting Test Sessions . . . . . . . . . . . . . . . . 17
3.7. Fetch-Session . . . . . . . . . . . . . . . . . . . . 21 3.7. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19
4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 24 3.8. Fetch-Session . . . . . . . . . . . . . . . . . . . . 22
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 24 4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 24 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 26
4.1.2. Packet Format and Content . . . . . . . . . . . . 25 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 26
4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 28 4.1.2. Packet Format and Content . . . . . . . . . . . . 27
5. Computing Exponentially Distributed Pseudo-Random Numbers . 30 4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 30
5.1. High-Level Description of the Algorithm . . . . . . . 30 5. Computing Exponentially Distributed Pseudo-Random Numbers . 32
5.2. Data Types, Representation and Arithmetic . . . . . . 31 5.1. High-Level Description of the Algorithm . . . . . . . 32
5.3. Uniform Random Quantities . . . . . . . . . . . . . . 32 5.2. Data Types, Representation, and Arithmetic . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . 33 5.3. Uniform Random Quantities . . . . . . . . . . . . . . 34
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 33 6. Security Considerations . . . . . . . . . . . . . . . . . . 35
6.2. Preventing Third-Party Denial of Service . . . . . . . 34 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 35
6.3. Covert Information Channels . . . . . . . . . . . . . 34 6.2. Preventing Third-Party Denial of Service . . . . . . . 35
6.4. Requirement to Include AES in Implementations . . . . 34 6.3. Covert Information Channels . . . . . . . . . . . . . 35
6.5. Resource Use Limitations . . . . . . . . . . . . . . . 34 6.4. Requirement to Include AES in Implementations . . . . 35
6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 35 6.5. Resource Use Limitations . . . . . . . . . . . . . . . 36
6.7. Required Properties of MD5 . . . . . . . . . . . . . . 36 6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 37
6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 38 6.7. Required Properties of MD5 . . . . . . . . . . . . . . 38
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 39
8. Internationalization Considerations . . . . . . . . . . . . 39 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40
9. Appendix A: Sample C Code for Exponential Deviates . . . . 39 8. Internationalization Considerations . . . . . . . . . . . . 40
10. Appendix B: Test Vectors for Exponential Deviates . . . . 44 9. Appendix A: Sample C Code for Exponential Deviates . . . . 41
11. Normative References . . . . . . . . . . . . . . . . . . . 45 10. Appendix B: Test Vectors for Exponential Deviates . . . . 46
12. Informative References . . . . . . . . . . . . . . . . . . 45 11. Normative References . . . . . . . . . . . . . . . . . . . 46
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 46 12. Informative References . . . . . . . . . . . . . . . . . . 47
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has proposed The IETF IP Performance Metrics (IPPM) working group has proposed
draft standard metrics for one-way packet delay [RFC2679] and loss draft standard metrics for one-way packet delay [RFC2679] and loss
[RFC2680] across Internet paths. Although there are now several [RFC2680] across Internet paths. Although there are now several
measurement platforms that implement collection of these metrics measurement platforms that implement collection of these metrics
[SURVEYOR], [RIPE], there is not currently a standard that would [SURVEYOR], [RIPE], there is not currently a standard that would
permit initiation of test streams or exchange of packets to collect permit initiation of test streams or exchange of packets to collect
singleton metrics in 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 system (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--either directly or through their proximity to NTP primary sources--either directly or through their proximity to Network Time
(stratum 1) time servers. By standardizing a technique for Protocol (NTP) primary (stratum 1) time servers. By standardizing a
collecting IPPM one-way active measurements, we hope to create an technique for collecting IPPM one-way active measurements, we hope to
environment where IPPM metrics may be collected across a far broader create an environment where IPPM metrics may be collected across a
mesh of Internet paths than is currently possible. One particularly far broader mesh of Internet paths than is currently possible. One
compelling vision is of widespread deployment of open OWAMP servers particularly compelling vision is of widespread deployment of open
that would make measurement of one-way delay as commonplace as OWAMP servers that would make measurement of one-way delay as
measurement of round-trip time using an ICMP-based tool like ping. commonplace as measurement of round-trip time using an ICMP-based
tool like ping.
Additional design goals of OWAMP include being hard to detect and 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. functionality, and support for small test packets.
OWAMP test traffic is hard to detect, because it is simply a stream OWAMP test traffic is hard to detect because it is simply a stream of
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, too). nothing static in the packets (size is negotiated, as well). OWAMP
Additionally, OWAMP supports an encrypted mode, that further obscures also supports an encrypted mode that further obscures the traffic, at
the traffic, at the same time making it impossible to alter the same time making it impossible to alter timestamps undetectably.
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 attackers
who attempt to provide special treatment to OWAMP test streams or who who attempt to provide special treatment to OWAMP test streams or who
attempt to modify sender-generated timestamps to falsify test attempt to modify sender-generated timestamps to falsify test
results. results.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC2119]. in this document 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 fetch their results, while OWAMP-Test is used to
exchange test packets between two measurement nodes. 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 draft 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 assuring a future in
skipping to change at page 4, line 30 skipping to change at page 4, line 30
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 negotiation
of sender and receiver addresses and port numbers, session start of sender and receiver addresses and port numbers, session start
time, session length, test packet size, the mean Poisson sampling time, session length, test packet size, the mean Poisson sampling
interval for the test stream, and some attributes of the very general interval for the test stream, and some attributes of the very general
RFC 2330 notion of `packet type', including packet size and per-hop RFC 2330 notion of packet type, including packet size and per-hop
behavior (PHB) [RFC2474], which could be used to support the behavior (PHB) [RFC2474], which could be used to support the
measurement of one-way active across diff-serv networks. measurement of one-way network characteristics across differentiated
Additionally, OWAMP-Control supports per-session encryption and services networks. Additionally, OWAMP-Control supports per-session
authentication for both test and control traffic, measurement servers encryption and authentication for both test and control traffic,
which may act as proxies for test stream endpoints, and the exchange measurement servers that can act as proxies for test stream
of a seed value for the pseudo-random Poisson process that describes endpoints, and the exchange of a seed value for the pseudo-random
the test stream generated by the sender. Poisson process that describes the test stream generated by 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 measurement beacons running on arbitrary hosts to network monitoring
monitoring deployments within private corporate networks. If deployments within private corporate networks. If integration with
integration with SNMP or proprietary network management protocols is Simple Network Management Protocol (SNMP) or proprietary network
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:
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; 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 7, line 8 skipping to change at page 7, line 8
authenticated or encrypted modes require endpoints to possess a authenticated or encrypted modes require endpoints to 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 Each type of OWAMP-Control message has a fixed length. The recipient
will know the full length of a message after examining first 16 will know the full length of a message after examining the first 16
octets of it. No message is shorter than 16 octets. octets of it. No message is shorter than 16 octets.
If the full message is not received within 30 minutes after it is If the full message is not received within 30 minutes after it is
expected, connection SHOULD be dropped. expected, connection SHOULD be dropped.
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 must establish a connection to the server. of 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. The server responds with a server greeting: port. The server responds with a server greeting:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Challenge (16 octets) | | Challenge (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following mode values are meaningful: 1 for unauthenticated, 2 The following Mode values are meaningful: 1 for unauthenticated, 2
for authenticated, 4 for encrypted. The value of the Modes field for authenticated, and 4 for encrypted. The value of the Modes field
sent by the server is the bit-wise OR of the mode values that it is sent by the server is the bit-wise OR of the mode values that it is
willing to support during this session. Thus, last three bits of the willing to support during this session. Thus, the last three bits of
Modes 32-bit value are used. The first 29 bits MUST be zero. A the Modes 32-bit value are used. The first 29 bits MUST be zero. A
client MUST ignore the values in the first 29 bits of the Modes client MUST ignore the values in the first 29 bits of the Modes
value. (This way, the bits are available for future protocol value. (This way, the bits are available for future protocol
extensions. This is the only intended extension mechanism.) extensions. This is the only intended extension mechanism.)
Challenge is a random sequence of octets generated by the server; it Challenge is a random sequence of octets generated by the server; it
is used subsequently by the client to prove possession of a shared is used subsequently by the client to prove possession of a shared
secret in a manner prescribed below. secret in a manner prescribed below.
If Modes value is zero, the server doesn't wish to communicate with If Modes value is zero, the server does not wish to communicate with
the client and MAY close the connection immediately. The client the client and MAY close the connection immediately. The client
SHOULD close the connection if it gets a greeting with Modes equal to SHOULD close the connection if it receives a greeting with Modes
zero. The client MAY close the connection if the client's desired equal to zero. The client MAY close the connection if the client's
mode is unavailable. desired mode is unavailable.
Otherwise, the client MUST respond with the following message: Otherwise, the client MUST respond with the following 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
skipping to change at page 8, line 43 skipping to change at page 8, line 43
Here Mode is the mode that the client chooses to use during this Here Mode is the mode that the client chooses to use during this
OWAMP-Control session. It will also be used for all OWAMP-Test OWAMP-Control session. It will also be used for all OWAMP-Test
sessions started under control of this OWAMP-Control session. In sessions started under control of this OWAMP-Control session. In
Mode, one or zero bits MUST be set within last three bits. The first Mode, one or zero bits MUST be set within last three bits. 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. first 29 bits.
In unauthenticated mode, Username, Token, and Client-IV are unused. In unauthenticated mode, Username, Token, and Client-IV are unused.
Otherwise, Username is a 16-octet indicator of which shared secret Otherwise, Username is a 16-octet indicator that tells the server
the client wishes to use to authenticate or encrypt and Token is the which shared secret the client wishes to use to authenticate or
concatenation of a 16-octet challenge and a 16-octet Session-key, encrypt, while Token is the concatenation of a 16-octet challenge and
encrypted using the AES (Advanced Encryption Standard) [AES] in a 16-octet Session-key, encrypted using the AES (Advanced Encryption
Cipher Block Chaining (CBC). Encryption MUST be performed using an Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be
Initialization Vector (IV) of zero and a key value that is the shared performed using an Initialization Vector (IV) of zero and a key value
secret associated with Username. (Both the server and the client use that is the shared secret associated with Username. (Both the server
the same mappings from user names to secret keys; the server, being and the client use the same mappings from user names to secret keys.
prepared to conduct sessions with more than one client, uses user The server, being prepared to conduct sessions with more than one
names to choose the appropriate secret key; a client would typically client, uses user names to choose the appropriate secret key; a
have different secret keys for different servers. The situation is client would typically have different secret keys for different
analogous to that of passwords, except that secret keys, rather than servers. The situation is analogous to that of passwords, except
being the typical low-entropy passwords, are suitable for use as AES that secret keys, rather than being the typical low-entropy
keys.) The shared secret will typically be provided as a passphrase; passwords, are suitable for use as AES keys.) The shared secret will
in this case, the MD5 sum [RFC1321] of the passphrase (without typically be provided as a passphrase; in this case, the MD5 sum
possible newline character(s) at the end of the passphrase) SHOULD be [RFC1321] of the passphrase (without possible newline character(s) at
used as a key for encryption by the client and decryption by the the end of the passphrase) SHOULD be used as a key for encryption by
server (the passphrase also SHOULD NOT contain newlines in the the client and decryption by the server (the passphrase also SHOULD
middle). NOT contain newlines in the middle).
Session-key and Client-IV are generated randomly by the client. Session-key and Client-IV are generated randomly by the client.
Session-key MUST be generated with sufficient entropy not to reduce Session-key MUST be generated with sufficient entropy not to reduce
the security of the underlying cipher. Client-IV merely needs to be the security of the underlying cipher. Client-IV merely needs to be
unique (i.e., it MUST never be repeated for different sessions using unique (i.e., it MUST never be repeated for different sessions using
the same secret key; a simple way to achieve that without the use of the same secret key; a simple way to achieve that without the use of
cumbersome state is to generate the Client-IV strings using a cumbersome state is to generate the Client-IV strings using a
cryptographically secure pseudo-random number source: if this is cryptographically secure pseudo-random number source: if this is
done, the first repetition is unlikely to occur before 2^64 sessions done, the first repetition is unlikely to occur before 2^64 sessions
with the same secret key are conducted). with the same secret key are conducted).
skipping to change at page 9, line 44 skipping to change at page 9, line 44
| | Accept | | | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Server-IV (16 octets) | | Server-IV (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime (Timestamp) | | Uptime (Timestamp) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integrity Zero Padding (8 octets) | | IZP (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Unused 15-octet part MUST be zero. The client MUST ignore its The Unused 15-octet part MUST be zero. The client MUST ignore its
value. MBZ (MUST be zero) fields here and hereafter have the same value. MBZ (MUST be zero) fields here and hereafter have the same
semantics: the party that sends the message MUST set the field to a semantics: the party that sends the message MUST set the field to a
string of zero bits; the party that interprets the message MUST string of zero bits; the party that interprets the message MUST
ignore the value. (This way the field could be used for future ignore the value. (This way the field could be used for future
extensions.) 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.
A zero value in the Accept field means that the server accepts the The Accept field indicates the server's willingness to continue
authentication and is willing to conduct further transactions. A communication. A zero value in the Accept field means that the
value of 1 means that the server does not accept the authentication server accepts the authentication and is willing to conduct further
provided by the client or, for some other reason, is not willing to transactions. Non-zero values indicate that the server does not
conduct further transactions in this OWAMP-Control session. All accept the authentication or, for some other reason, is not willing
other values are reserved. The client MUST interpret all values of to conduct further transactions in this OWAMP-Control session. The
Accept other than 0 and 1 as 1. This way, other values are available full list of available Accept values is described in the ``Values of
for future extensions. If a negative response is sent, the server the Accept Field'' section.
MAY and the client SHOULD close the connection after this message.
If a negative (non-zero) response is sent, the server MAY and the
client SHOULD close the connection after this message.
Uptime is a timestamp representing the time when the current Uptime 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, it could be the time multi-user general purpose operating system (OS), it could be the
when the server process was started.) If Accept is non-zero, Uptime time when the server process was started.) If Accept is non-zero,
SHOULD be set to a string of zeros. In authenticated and encrypted Uptime SHOULD be set to a string of zeros. In authenticated and
modes, Uptime is encrypted as described in the next section, unless encrypted modes, Uptime is encrypted as described in the next
Accept is non-zero. (authenticated and encrypted mode can not be section, unless Accept is non-zero. (Authenticated and encrypted mode
entered unless the control connection can be initialized.) cannot be entered unless the control connection can be initialized.)
Timestamp format is described in `Sender Behavior' section below. Timestamp format is described in ``Sender Behavior'' section below.
The same instantiation of the server SHOULD report the same exact The same instantiation of the server SHOULD report the same exact
Uptime value to each client in each session. Uptime value to each client in each session.
Integrity Zero Padding is treated the same way as Integrity Zero Integrity Zero Padding (IZP) is treated the same way as IZP in the
Padding in the next section and beyond. next section and beyond.
The previous transactions constitute connection setup. The previous transactions constitute connection setup.
3.2. OWAMP-Control Commands 3.2. Values of the Accept Field
Accept values are used throughout the OWAMP-Control protocol to
communicate the server response to client requests. The full set of
valid Accept field values are:
0 OK.
1 Failure, reason unspecified (catch-all).
2 Internal error.
3 Some aspect of request is not supported.
4 Cannot perform request due to permanent resource limitations.
5 Cannot perform request due to temporary resource limitations.
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
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
reserved values as 1. This way, other values are available for
future extensions.
3.3. 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 Session-key, using CBC
mode. The client encrypts its stream using Client-IV. The server mode. The client encrypts its stream using Client-IV. The server
encrypts its stream using Server-IV. encrypts its stream using Server-IV.
The following commands are available for the client: Request-Session, The following commands are available for the client: Request-Session,
Start-Sessions, Stop-Sessions, Fetch-Session. The command Start-Sessions, Stop-Sessions, and Fetch-Session. The command
Stop-Sessions is available to both the client and the server. (The Stop-Sessions is available to both the client and the server. (The
server can also send other messages in response to commands it server can also send other messages in response to commands it
receives.) receives.)
After Start-Sessions is sent/received by the client/server, and After Start-Sessions is sent/received by the client/server, and
before it both sends and receives Stop-Sessions (order unspecified), before it both sends and receives Stop-Sessions (order unspecified),
it is said to be conducting active measurements. it is said to be conducting active measurements.
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.3. Creating Test Sessions 3.4. 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 or
more Request-Session messages to an OWAMP server, which MUST respond more Request-Session messages to an OWAMP server, which MUST respond
to each with an Accept-Session message. An Accept-Session message to each with an Accept-Session message. An Accept-Session message
MAY refuse a request. 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
skipping to change at page 12, line 47 skipping to change at page 12, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout | | Timeout |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor | | Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ | | MBZ |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Integrity Zero Padding (16 octets) | | IZP (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 | +-+-+-+-+-+-+-+-+ MBZ |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Parameter (Timestamp) | | Slot Parameter (Timestamp) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are immediately followed by Integrity Zero Padding: These are immediately followed by IZP:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Integrity Zero Padding (16 octets) | | IZP (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these messages comprise one logical message: the Request-Session All these messages comprise one logical message: the Request-Session
command. command.
Above, the first octet (1) indicates that this is Request-Session Above, the first octet (1) indicates that this is Request-Session
command. command.
IPVN is the IP version numbers for Sender and Receiver. In the case IPVN is the IP version numbers for Sender and Receiver. When the IP
of IP version number being 4, twelve octets follow the four-octet version number is 4, 12 octets follow the 4-octet IPv4 address stored
IPv4 address stored in Sender Address and Receiver address. These in Sender Address and Receiver Address. These octets MUST be set to
octets MUST be set to zero by the client and MUST be ignored by the zero by the client and MUST be ignored by the server. Currently
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
1, the server is being asked to configure the corresponding agent 1, the server is being asked to configure the corresponding agent
(sender or receiver). In this case, the corresponding Port value (sender or receiver). In this case, the corresponding Port value
SHOULD be disregarded by the server. At least one of Conf-Sender and SHOULD be disregarded by the server. At least one of Conf-Sender and
Conf-Receiver MUST be 1. (Both can be set, in which case the server Conf-Receiver MUST be 1. (Both can be set, in which case the server
is being asked to perform a session between two hosts it can is being asked to perform a session between two hosts it can
configure.) configure.)
Number of Schedule Slots, as mentioned before, specifies the number Number of Schedule Slots, as mentioned before, specifies the number
of slot records that go between the two blocks of Integrity Zero of slot records that go between the two blocks of IZP. It is used by
Padding. It is used by the sender to determine when to send test the sender to determine when to send test packets (see next section).
packets (see next section).
Number of Packets is the number of active measurement packets to be Number of Packets is the number of active measurement packets to be
sent during this OWAMP-Test session (note that both server and client sent during this OWAMP-Test session (note that both server and client
can abort the session early). can abort the session early).
If Conf-Sender is not set, Sender Port is the UDP port OWAMP-Test If Conf-Sender is not set, Sender Port is the UDP port from which
packets will be sent from. If Conf-Receiver is not set, Receiver OWAMP-Test packets will be sent. If Conf-Receiver is not set,
Port is the UDP port OWAMP-Test packets are requested to be sent to. Receiver Port is the UDP port OWAMP-Test to which packets are
requested to be sent.
The Sender Address and Receiver Address fields contain respectively The Sender Address and Receiver Address fields contain, respectively,
the sender and receiver addresses of the end points of the Internet the sender and receiver addresses of the end points of the Internet
path over which an OWAMP test session is requested. path over which an OWAMP test session is requested.
SID is the session identifier. It can be used in later sessions as SID is the session identifier. It can be used in later sessions as
an argument for Fetch-Session command. It is meaningful only if an argument for the Fetch-Session command. It is meaningful only if
Conf-Receiver is 0. This way, the SID is always generated by the Conf-Receiver is 0. This way, the SID is always generated by the
receiving side. See the end of the section for information on how receiving side. See the end of the section for information on how
the SID is generated. the SID is generated.
Padding length is the number of octets to be appended to normal Padding length is the number of octets to be appended to the normal
OWAMP-Test packet (see more on padding in discussion of OWAMP-Test). OWAMP-Test packet (see more on padding in discussion of OWAMP-Test).
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 Type-P Descriptor are 00, then subsequent 6 If the first two bits of the Type-P Descriptor are 00, then
bits specify the requested Differentiated Services Codepoint (DSCP) subsequent six bits specify the requested Differentiated Services
value of sent OWAMP-Test packets as defined in RFC 2474. If the Codepoint (DSCP) value of sent OWAMP-Test packets, as defined in
first two bits of Type-P descriptor are 01, then subsequent 16 bits RFC 2474. If the first two bits of Type-P descriptor are 01, then
specify the requested Per Hop Behavior Identification Code (PHB ID) the subsequent 16 bits specify the requested PHB Identification Code
as defined in RFC 2836. (PHB ID), as defined in RFC 2836.
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, Type-P Descriptor is to be used to configure If Conf-Sender is set, the Type-P Descriptor is to be used to
the sender to send packets according to its value. If Conf-Sender is configure the sender to send packets according to its value. If
not set, Type-P Descriptor is a declaration of how the sender will be Conf-Sender is not set, the Type-P Descriptor is a declaration of how
configured. the sender will be configured.
If Conf-Sender is set and the server doesn't recognize Type-P If Conf-Sender is set and the server does not recognize the Type-P
Descriptor, 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 the request. If Conf-Sender is not set, the server SHOULD accept or
session regardless of the value of Type-P Descriptor. reject the session paying no attention to the value of the Type-P
Descriptor.
Integrity Zero Padding MUST be all zeros in this and all subsequent IZP MUST be all zeros in this and all messages that use IZP. The
messages that use zero padding. The recipient of a message where recipient of a message where IZP is not zero MUST reject the message,
zero padding is not zero MUST reject the message as it is an as it is an indication of tampering with the content of the message
indication of tampering with the content of the message by an by an intermediary (or brokenness). If the message is part of
intermediary (or brokenness). If the message is part of
OWAMP-Control, the session MUST be terminated and results OWAMP-Control, the session MUST be terminated and results
invalidated. If the message is part of OWAMP-Test, it MUST be invalidated. If the message is part of OWAMP-Test, it MUST be
silently ignored. This will ensure data integrity. In silently ignored. This will ensure data integrity. In
unauthenticated mode, Integrity Zero Padding is nothing more than a unauthenticated mode, IZP is nothing more than a simple check. In
simple check. In authenticated and encrypted modes, however, it authenticated and encrypted modes, however, it ensures, in
ensures, in conjunction with properties of CBC chaining mode, that conjunction with properties of CBC chaining mode, that everything
everything received before was not tampered with. For this reason, received before was not tampered with. For this reason, it is
it is important to check the Integrity Zero Padding Field as soon as important to check the IZP field as soon as possible, so that bad
possible, so that bad data doesn't get propagated. data doesn't get propagated.
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 | Unused | Port | | Accept | Unused | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Integrity Zero Padding (12 octets) | | IZP (12 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 value of 1 indicates rejection of willing to conduct the session. A non-zero value indicates rejection
the request. All other values are reserved. of the request. The full list of available Accept values is
described in the ``Values of the Accept Field'' section.
If the server rejects a Request-Session command, 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 gets negative the TCP connection. The client MAY close it if it receives negative
response to Request-Session. 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-Sender and Conf-Receiver in the query that solicited the Conf-Sender and Conf-Receiver in the query that solicited the
response. If both were set, Port field is unused. If only response. If both were set, the Port field is unused. If only
Conf-Sender was set, Port is the port to expect OWAMP-Test packets Conf-Sender was set, Port is the port from which to expect OWAMP-Test
from. If only Conf-Receiver was set, Port is the port to send packets. If only Conf-Receiver was set, Port is the port to which
OWAMP-Test packets to. OWAMP-Test packets are sent.
If only Conf-Sender was set, 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 4-octet IPv4 IP number SIDs SHOULD be constructed by concatenation of the 4-octet IPv4 IP
belonging to the generating machine, 8-octet timestamp, and 4-octet number belonging to the generating machine, an 8-octet timestamp, and
random value. To reduce the probability of collisions, if the a 4-octet random value. To reduce the probability of collisions, if
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 4 octets of an IPv6 address MAY be used instead. Note that SID last four octets of an IPv6 address MAY be used instead. Note that
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 SID be made unpredictable as available, it is important that the SID be made unpredictable, as
knowledge of SID might be used for access control. knowledge of the SID might be used for access control.
3.4. Send Schedules 3.5. Send Schedules
The sender and the receiver need to both 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 slot, the parameter is the delay itself. The x). For a type 1 (fixed quantity) slot, the parameter is the delay
sender starts with the beginning of the schedule, and `executes' the itself. The sender starts with the beginning of the schedule, and
instructions in the slots: for a slot of type 0, wait exponentially executes the instructions in the slots: for a slot of type 0, wait an
distributed time with mean of the specified parameter and then send a exponentially distributed time with a mean of the specified parameter
test packet (and proceed to the next slot); for a slot of type 1, and then send a test packet (and proceed to the next slot); for a
wait the specified time and send a test packet (and proceed to the slot of type 1, wait the specified time and send a test packet (and
next slot). The schedule is circular: when there are no more slots, proceed to the next slot). The schedule is circular: when there are
the sender returns to the first slot. no more slots, the sender returns to the first slot.
The sender and the receiver must be able to reproducibly execute the The sender and the receiver need to be able to reproducibly execute
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.
Using this mechanism one can easily specify common testing scenarios. Using this mechanism one can easily specify common testing scenarios.
Some examples include: Some examples include:
+ Poisson stream: a single slot of type 0; + Poisson stream: a single slot of type 0;
skipping to change at page 17, line 28 skipping to change at page 17, line 29
+ 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.5. Starting Test Sessions 3.6. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | | | 2 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Unused (15 octets) | | Unused (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Integrity Zero Padding (16 octets) | | IZP (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server MUST respond with an Control-Ack message (which SHOULD be The server MUST respond with an Start-Ack message (which SHOULD be
sent as quickly as possible). Control-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 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Unused (15 octets) | | Unused (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Integrity Zero Padding (16 octets) | | IZP (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If Accept is 1, the Start-Sessions request was rejected; zero means If Accept is non-zero, the Start-Sessions request was rejected; zero
that the command was accepted. All other values are reserved. The means that the command was accepted. The full list of available
server MAY and the client SHOULD close the connection in the case of Accept values is described in the ``Values of the Accept Field''
a rejection. section. The server MAY, and the client SHOULD, close the connection
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
Control-Ack response from the Server (if the Start-Sessions command Start-Ack response from the Server (if the Start-Sessions command was
was accepted) or immediately after their specified start times, accepted) or immediately after their specified start times, whichever
whichever is later. See more on OWAMP-Test sender behavior in a is later. See more on OWAMP-Test sender behavior in a separate
separate section below. section below.
3.6. Stop-Sessions 3.7. 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 | Unused | | 3 | Accept | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Sessions | | Number of Sessions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused (8 octets) | | Unused (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Zero Padding (16 octets) |
| |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by 0 or more session packets sent This is immediately followed by zero or more session description
descriptions (the number of session packets sent records is specified records (the number of session description records is specified in
in the 'Number of Sessions' field above): the ``Number of Sessions'' field above). The session description
record is used to indicate which packets were actually sent by the
sender process (rather than skipped). The header of the session
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) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Packets Sent | | Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by zero or more Skip Range descriptions
as specified by the ``Number of Skip Ranges'' field above. Skip
Ranges are simply two sequence numbers that, together, indicate a
range of packets that were not sent:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The last (possibly full, possibly incomplete) block (16 octets) of
data MUST be padded with zeros, if necessary. This ensures that the
next session description record starts on a block boundary.
Finally, a single block (16 octets) of IZP is concatenated on the end
to complete the Stop-Sessions message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Integrity Zero Padding (12 octets) | | IZP (16 octets) |
| |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these messages 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.
Accept values of 1 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. All other indicate normal (but possibly premature) completion. The full list
values are reserved. of available Accept values is described in the ``Values of the Accept
Field'' section.
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 packets sent Number of Sessions indicates the number of session description
records that immediately follow the Stop-Sessions message. 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-Client MUST account for each accepted Request-Session where Control-Client MUST account for each accepted Request-Session where
Conf-Receiver was set. The Control-Server MUST account for each Conf-Receiver was set; the Control-Server MUST account for each
accepted Request-Session where Conf-Sender was set). If the accepted Request-Session where Conf-Sender was set). If the
Stop-Sessions message does not account for all the send sessions Stop-Sessions message does not account for exactly the send sessions
controlled by that side, then it is to be considered invalid and the controlled by that side, then it is to be considered invalid and the
connection SHOULD be closed and any results obtained considered connection SHOULD be closed and any results obtained considered
invalid. invalid.
Each session packets sent record represents one OWAMP-Test session Each session description record represents one OWAMP-Test session.
and contains the session identifier (SID) and the number of packets
sent in that session. For completed sessions, Session Packets Sent
will equal NumPackets from the Request-Session. Session Packets Sent
MAY be all ones (0xFFFFFFFF); in this case, the sender of the
Stop-Sessions command could not determine the number of packets sent
(perhaps, due to some internal error such as a process crash); this
special value SHOULD NOT be sent under normal operating conditions.
If the OWAMP-Control connection associated with an OWAMP-Test SID is the session identifier (SID) used to indicate which send
receiver receives the (0xFFFFFFFF) special value for the Session session is being described.
Packets Sent, or if the OWAMP-Control connection breaks when the
Stop-Sessions command is sent, the receiver MAY not completely
invalidate the session results. It MUST discard any records of lost
packets that follow (in other words, have greater sequence number
than) the last packet that was actually received. This will help
differentiate between packet losses that occurred in the network and
the sender crashing. When the results of such an OWAMP-Test session
or an OWAMP-Test session that was prematurely aborted successfully
(with confirmation) are later fetched using Fetch-Session, the
original number of packets MUST be supplied in the reproduction of
the Request-Session command.
If a receiver of an OWAMP-Test session learns through OWAMP-Control Next Seqno indicates the next sequence number that would have been
Stop-Sessions message that the OWAMP-Test sender's last sequence sent from this send session. For completed sessions, this will equal
number is lower than any sequence number actually received, the NumPackets from the Request-Session.
results of the complete OWAMP-Test session MUST be invalidated.
Number of Skip Ranges indicates the number of holes that actually
occurred in the sending process. This is a range of packets that were
never actually sent by the sending process. For example, if a send
session is started too late for the first 10 packets to be sent and
this is the only hole in the schedule, then ``Number of Skip Ranges''
would be 1. The single Skip Range description will have First Seqno
Skipped equal to 0 and Last Seqno Skipped equal to 9. This is
described further in the ``Sender Behavior'' section.
If the OWAMP-Control connection breaks when the Stop-Sessions command
is sent, the receiver MAY not completely invalidate the session
results. It MUST discard all record of packets that follow (in other
words, have greater sequence number than) the last packet that was
actually received before before any lost packet records. This will
help differentiate between packet losses that occurred in the network
and packets the sending process may have never sent.
If a receiver of an OWAMP-Test session learns, through an OWAMP-
Control Stop-Sessions message, that the OWAMP-Test sender's last
sequence number is lower than any sequence number actually received,
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-Sessions message. The completed time of each sessions is Stop-Sessions message. The completed time of each sessions is
determined as Timeout after the scheduled time for the last sequence determined as Timeout after the scheduled time for the last sequence
number. Endpoints MAY add a small increment to the computed number. Endpoints MAY add a small increment to the computed
completed time for send endpoints to ensure the Stop-Sessions message completed time for send endpoints to ensure the Stop-Sessions message
reaches the receiver endpoint after Timeout. reaches 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.7. Fetch-Session 3.8. 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 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Unused (7 octets) | | Unused (7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin Seq | | Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Seq | | End Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Integrity Zero Padding (16 octets) | | IZP (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 normal, the request
to fetch session results MUST be denied. If an incomplete session is to fetch session results MUST be denied. If an incomplete session is
requested, all packets received so far that fall into the requested requested, all packets received so far that fall into the requested
range SHOULD be returned. Note that since no commands can be issued range SHOULD be returned. Note that, since no commands can be issued
between Start-Sessions and Stop-Sessions, incomplete requests can between Start-Sessions and Stop-Sessions, incomplete requests can
only happen on a different OWAMP-Control connection (from the same or only happen on a different OWAMP-Control connection (from the same or
different host as Control-Client). different host as Control-Client).
The server MUST respond with a Control-Ack message. Again, 1 in the The server MUST respond with a Fetch-Ack message. The format of this
Accept field means rejection of command. Zero means that data will server response is as follows:
follow. All other values are reserved.
If Accept was 0, the server then MUST send the OWAMP-Test session 0 1 2 3
data in question, followed by 16 octets of Integrity Zero Padding. 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 | Complete | Unused (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IZP (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again, non-zero in the Accept field means a rejection of command.
The server MUST specify zero for all remaining fields if Accept is
non-zero. The client MUST ignore all remaining fields (except for the
IZP) if Accept is non-zero. The full list of available Accept values
is described in the ``Values of the Accept Field'' section.
Complete is non-zero if the OWAMP-Test session has terminated.
Next Seqno indicates the next sequence number that would have been
sent from this send session. For completed sessions, this will equal
NumPackets from the Request-Session.
Number of Skip Ranges indicates the number of holes that actually
occurred in the sending process.
Number of Records is the number of packet records that fall within
the requested range. This number might be less than the Number of
Packets in the reproduction of the Request-Session command because of
a session that ended prematurely or it might be greater because of
duplicates.
If Accept was non-zero, this concludes the response to the Fetch-
Session message. If Accept was 0, the server then MUST immediately
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.
+ The number of packet records that will follow represented as an + 16 octets of IZP.
unsigned 4-octet integer. This number might be less than the
Number of Packets in the reproduction of the Request-Session
command because of a session that ended prematurely; or it might
be greater because of duplicates.
+ 12 octets of Integrity Zero Padding. + Zero or more (as specified) Skip Range descriptions. The last
(possibly full, possibly incomplete) block (16 octets) of Skip
Range descriptions is padded with zeros if necessary. (These
zeros are simple padding and should be distinguished from the 16
octets of IZP that follow.)
+ Zero or more (as specified) packet records. + 16 octets of IZP.
+ Zero or more (as specified) packet records. The last (possibly
full, possibly incomplete) block (16 octets) of data is padded
with zeros if necessary. (These zeros are simple padding and
should be distinguished from the 16 octets of IZP that follow.)
+ 16 octets of IZP.
Skip Range descriptions are simply two sequence numbers that,
together, indicate a range of packets that were not sent:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
session data is to be considered invalid and the connection SHOULD be
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, and 2 octets of receive estimate, 8 octets of receive timestamp, 2 octets of receive
timestamp error estimate and 1 octet of TTL (or Hop Limit in IPv6): timestamp error estimate, and 1 octet of Time To Live (TTL), or Hop
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
04| Send Timestamp | 04| Send Error Estimate | Receive Error Estimate |
08| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12| Send Error Estimate | Receive Error Estimate | 08| Send Timestamp |
12| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16| Receive Timestamp | 16| Receive Timestamp |
20| | 20| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24| TTL | 24| TTL |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Packet records are sent out in the same order they are made when the Packet records are sent out in the same order the actual packets were
results of the session are recorded. Therefore, the data is in received. Therefore, the data is in arrival order.
arrival order.
Note that lost packets (if any losses were detected during the Note that lost packets (if any losses were detected during the
OWAMP-Test session) MUST appear in the sequence of packets. They can OWAMP-Test session) MUST appear in the sequence of packets. They can
appear either at the point when the loss was detected or at any later appear either at the point when the loss was detected or at any later
point. Lost packet records are distinguished as follows: point. Lost packet records are distinguished as follows:
+ A send timestamp filled with the presumed send time (as computed + A send timestamp filled with the presumed send time (as computed
by the send schedule). by the send schedule).
+ A send error estimate filled with Multiplier=1, Scale=64, and S=0 + A send error estimate filled with Multiplier=1, Scale=64, and S=0
(see the OWAMP-Test description for definition of these quantities (see the OWAMP-Test description for definition of these quantities
and explanation of timestamp format and error estimate format). and explanation of timestamp format and error estimate format).
+ 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 MUST be declared clock being used to declare the packet lost. (It is declared lost
lost if it is not received Timeout after the presumed send time as if it is not received by the Timeout after the presumed send time,
determined by the receivers 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.
The last (possibly full, possibly incomplete) block (16 octets) of
data is padded with zeros if necessary. (These zeros are simple
padding and should be distinguished from the 16 octets of Integrity
Zero Padding that follow the session data and conclude the response
to Fetch-Session.)
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 sender and receiver IP and port numbers negotiated during the
Request-Session exchange. Request-Session exchange.
As 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 spawned by an authenticated, and encrypted. All OWAMP-Test sessions that are
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-Control session. OWAMP-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 separated from the present by more than Timeout time, the sender
MUST NOT send the packet. (Indeed, such a packet would be considered MUST NOT send the packet. (Indeed, such a packet would be considered
lost by the receiver anyway.) This could happen if a time in the lost by the receiver anyway.) The sender MUST keep track of which
past was specified in the Request-Session command, or if the packets it does not send. It will use this to tell the receiver what
Start-Sessions exchange took unexpectedly long, or if the sender packets were not sent by setting Skip Ranges in the Stop-Sessions
could not start serving the OWAMP-Test session on time due to message from the sender to the receiver upon completion of the test.
The Skip Ranges are also sent to a Fetch-Client as part of the
session data results. These holes in the sending schedule can happen
if a time in the past was specified in the Request-Session command,
or if the Start-Sessions exchange took unexpectedly long, or if the
sender could not start serving the OWAMP-Test session on time due to
internal scheduling problems of the OS. Packets in the past, but internal scheduling problems of the OS. Packets in the past, but
separated from the present by less than Timeout value, SHOULD be sent separated from the present by less than Timeout value, SHOULD be sent
as quickly as possible. With normal test rates and timeout values, as quickly as possible. With normal test rates and timeout values,
the number of packets in such a burst is limited. Nevertheless, the number of packets in such a burst is limited. Nevertheless,
hosts SHOULD NOT intentionally schedule sessions so that such bursts hosts SHOULD NOT intentionally schedule sessions so that such bursts
of packets occur. 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. Packet Format and Content 4.1.2. Packet Format and Content
The sender sends the receiver a stream of packets with schedule as 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
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 26, line 30 skipping to change at page 28, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For authenticated and encrypted modes: For authenticated and encrypted modes:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Integrity Zero Padding (12 octets) | | IZP (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Integrity Zero Padding (6 octets) | | IZP (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the timestamp is the same as in [RFC 1305] and is as The format of the timestamp is the same as in [RFC 1305] and is as
follows: first 32 bits represent the unsigned integer number of follows: first 32 bits represent the unsigned integer number of
skipping to change at page 27, line 31 skipping to change at page 29, line 11
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 0 and are incremented by 1 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 32 octets in authenticated mode and unauthenticated mode, and 32 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 operations are, however, different. encrypted modes. The encryption operations are, however, different.
The difference is that in encrypted mode both the sequence number and The difference is that in encrypted mode both the sequence number and
the timestamp are encrypted to provide maximum data integrity the timestamp are encrypted to provide maximum data integrity
protection while in authenticated mode the sequence number is protection while in authenticated mode the sequence number is
encrypted and the timestamp is sent in clear text. Sending the encrypted and the timestamp is sent in clear text. Sending the
timestamp in clear text in authenticated mode allows to reduce the timestamp in clear text in authenticated mode allows one to reduce
time between a timestamp is obtained by a sender and the packet is the time between when a timestamp is obtained by a sender and when
shipped out. In encrypted mode, the sender has to fetch the the packet is shipped out. In encrypted mode, the sender has to
timestamp, encrypt it, and send it; in authenticated mode, the middle fetch the timestamp, encrypt it, and send it; in authenticated mode,
step is removed improving accuracy (the sequence number can be the middle step is removed, improving accuracy (the sequence number
encrypted before the timestamp is fetched). can be encrypted 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 ECB mode. The key to use is the same key as is encrypted using AES Electronic Cookbook (ECB) mode. The key to use
used for the corresponding OWAMP-Control session (where it is used in is the same key as is used for the corresponding OWAMP-Control
a different chaining mode). Electronic Cookbook (ECB) mode does not session (where it is used in a different chaining mode). ECB mode
involve any actual chaining; this way, lost, duplicated, or reordered does not involve any actual chaining; this way, lost, duplicated, or
packets do not cause problems with deciphering any packet in an reordered packets do not cause problems with deciphering any packet
OWAMP-Test session. 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 the same key as is used for using AES CBC mode. The key to use is the same key as is used for
the corresponding OWAMP-Control session. Each OWAMP-Test packet is the corresponding OWAMP-Control session. Each OWAMP-Test packet is
encrypted as a separate stream, with just one chaining operation; encrypted as a separate stream, with just one chaining operation;
chaining does not span multiple packets so that lost, duplicated, or chaining does not span multiple packets so that lost, duplicated, or
reordered packets do not cause problems. reordered packets do not cause problems.
In unauthenticated mode, no encryption is applied. In unauthenticated mode, no encryption 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
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 don't travel for longer than implementation would ensure that packets do not travel for longer
TTL seconds). In fact, in IPv6 the name of this field has actually than TTL seconds). In fact, in IPv6, the name of this field has
been changed to Hop Limit. Further, IPv4 specification makes no actually been changed to Hop Limit. Further, IPv4 specification
claims about the time it takes the packet to traverse the last link makes no claims about the time it takes the packet to traverse the
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 first block (16 + In authenticated or encrypted mode, decrypt the first block (16
octets) of packet body. octets) of the packet body.
+ 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 seqno, presumed send time, receive are recorded with their true sequence number, presumed send time,
time consisting of a string of zero bits, and TTL (or Hop Limit) receive time consisting of a string of zero bits, and TTL (or Hop
of 255. Limit) 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 to not do so is inability to access
the TTL field of arriving packets), it MUST record the TTL value as the TTL field of arriving packets), it MUST record the TTL value as
255. 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
skipping to change at page 29, line 50 skipping to change at page 31, line 30
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
discarded. (Send timestamps in the future would normally indicate discarded. (Send timestamps in the future would normally indicate
clocks that differ by more than the delay. Some data -- such as clocks that differ by more than the delay. Some data -- such as
jitter -- can be extracted even without knowledge of time difference. jitter -- can be extracted even without knowledge of time difference.
For other kinds of data, the adjustment is best handled by the data For other kinds of data, the adjustment is best handled by the data
consumer on the basis of the complete information in a measurement consumer on the basis of the complete information in a measurement
session as well as possibly external data.) session, as well as, possibly, external data.)
Packets with a sequence number that was already observed (duplicate Packets with a sequence number that was already observed (duplicate
packets) MUST be recorded normally. (Duplicate packets are sometimes packets) MUST be recorded normally. (Duplicate packets are sometimes
introduced by IP networks. The protocol has to be able to measure introduced by IP networks. The protocol has to be able to measure
duplication.) duplication.)
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 seqno. packet should have been sent according to its sequence number.
+ In authenticated or encrypted mode, any of the bits of zero + In authenticated or encrypted mode, any of the bits of zero
padding inside the first 16 octets of packet body is non-zero. padding inside the first 16 octets of packet body is non-zero.
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 in [KNUTH], which is free
of the above mentioned problem, and guarantees the same output on any of the above-mentioned problem, and guarantees the same output on any
implementation. The algorithm belongs to the 'ziggurat' family 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.
skipping to change at page 31, line 11 skipping to change at page 32, line 42
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 reference code (see Appendix A). implementations are given in the reference code (see Appendix A).
This is necessary to insure that exactly the same pseudo-random This is necessary to insure that exactly the same pseudo-random
sequences are produced by all implementations. sequences are produced by 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 decimal 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 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 which is The algorithm produces a sequence of such u_int64_t integers that,
guaranteed to be the same on any implementation. Any further for any given value of SID, is guaranteed to be the same on any
interpretation (such as given by (1)) is done by the application, and implementation.
is not part of this specification.
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
of the Q array in the high-level algorithm be as follows: of the Q array in the high-level algorithm be as follows:
#1 0xB17217F8, #1 0xB17217F8,
#2 0xEEF193F7, #2 0xEEF193F7,
#3 0xFD271862, #3 0xFD271862,
#4 0xFF9D6DD0, #4 0xFF9D6DD0,
#5 0xFFF4CFD0, #5 0xFFF4CFD0,
#6 0xFFFEE819, #6 0xFFFEE819,
#7 0xFFFFE7FF, #7 0xFFFFE7FF,
#8 0xFFFFFE2B, #8 0xFFFFFE2B,
#9 0xFFFFFFE0, #9 0xFFFFFFE0,
#10 0xFFFFFFFE, #10 0xFFFFFFFE,
#11 0xFFFFFFFF #11 0xFFFFFFFF
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 (u * v) exactly. For example, a Implementations MUST compute the product (u * v) exactly. For
fragment of unsigned 128-bit arithmetic can be implemented for this example, a fragment of unsigned 128-bit arithmetic can be implemented
purpose (see sample implementation below). for this purpose (see sample implementation below).
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 as U in algorithm S) relies on using AES encryption in counter mode.
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].
+ This function 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):
void KeyInit(unsigned char seed[16]); void KeyInit(unsigned char seed[16]);
+ This function encrypts the 16-octet block 'inblock' with the 'key' + A function that encrypts the 16-octet block inblock with the
returning a 16-octet encrypted block. Here 'keyInstance' is an specified key, returning a 16-octet encrypted block. Here
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 U2. [Need
skipping to change at page 33, line 32 skipping to change at page 35, line 14
6. Security Considerations 6. Security Considerations
6.1. Introduction 6.1. Introduction
The goal of authenticated mode to let one passphrase-protect service The goal of authenticated mode to let one passphrase-protect service
provided by a particular OWAMP-Control server. One can imagine a provided by a particular OWAMP-Control server. One can imagine a
variety of circumstances where this could be useful. Authenticated variety of circumstances where this could be useful. Authenticated
mode is designed to prohibit theft of service. mode is designed to prohibit theft of service.
Additional design objective of authenticated mode was to make it An additional design objective of the authenticated mode was to make
impossible for an attacker who cannot read traffic between OWAMP-Test it impossible for an attacker who cannot read traffic between OWAMP-
sender and receiver to tamper with test results in a fashion that Test sender and receiver to tamper with test results in a fashion
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
doesn't coincide with neither sender nor receiver. does not coincide with either sender or receiver.
Encryption of OWAMP-Control using AES CBC mode with blocks of zeros Encryption of OWAMP-Control using AES CBC mode with blocks of zeros
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; (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 servers for denial of service (DoS) attacks. In unauthenticated mode,
should limits receivers to hosts they control or to the OWAMP-Control servers SHOULD limit receivers to hosts they control or to the OWAMP-
client. Control client.
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
skipping to change at page 35, line 26 skipping to change at page 37, line 7
connection that initiated the session is closed (gracefully or connection that initiated the session is closed (gracefully or
otherwise). For authenticated sessions, the administrator who otherwise). For authenticated sessions, the administrator who
configures the service should be able to decide the exact policy, but configures the service should be able to decide the exact policy, but
useful policy mechanisms that MAY be implemented are the ability to useful policy mechanisms that MAY be implemented are the ability to
automatically reclaim memory when the data is retrieved and the automatically reclaim memory when the data is retrieved and the
ability to reclaim memory after a certain configurable (based on user ability to reclaim memory after a certain configurable (based on user
class) period of time passes after the OWAMP-Test session terminates. class) period of 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 TLS At an early stage in designing the protocol, we considered using
and IPsec as cryptographic security mechanisms for OWAMP. The Transport Layer Security (TLS) and IPsec as cryptographic security
disadvantages of those are as follows (not an exhaustive list): mechanisms for OWAMP. The disadvantages of those are as follows (not
an exhaustive list):
Regarding TLS: Regarding TLS:
+ While TLS could be used to secure TCP-based OWAMP-Control, but + While TLS could be used to secure TCP-based OWAMP-Control, but
difficult to use to secure UDP-based OWAMP-Test: OWAMP-Test difficult to use 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 is not conducive of this. individual usability. Stream-based TLS is not conducive of this.
+ Dealing with streams, does not authenticate individual messages + Dealing with streams, does not authenticate individual messages
(even in OWAMP-Control). The easiest way out would be to add some (even in OWAMP-Control). The easiest way out would be to add some
known-format padding to each message and verify that the format of known-format padding to each message and verify that the format of
the padding is intact before using the message. The solution the padding is intact before using the message. The solution
would thus lose some of its appeal (``just use TLS''); it would would thus lose some of its appeal (``just use TLS''); it would
also be much more difficult to evaluate the security of this also be much more difficult to evaluate the security of this
scheme with the various modes and options of TLS---it would almost scheme with the various modes and options of TLS -- it would
certainly not be secure with all. The capacity of an attacker to almost certainly not be secure with all. The capacity of an
replace parts of messages (namely, the end) with random garbage attacker to replace parts of messages (namely, the end) with
could have serious security implications and would need to be random garbage could have serious security implications and would
analyzed carefully: suppose, for example, that a parameter that is need to be analyzed carefully: suppose, for example, that a
used in some form to control the rate were replaced by random parameter that is used in some form to control the rate were
garbage---chances are the result (an unsigned integer) would be replaced by random garbage -- chances are the result (an unsigned
quite large. integer) would 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 IPsec: Regarding IPsec:
skipping to change at page 36, line 34 skipping to change at page 38, line 15
be able to deploy OWAMP on as large of a number of different be able to deploy OWAMP on as large of 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 not support IPsec. do not support IPsec.
+ The API for manipulation IPsec from an application is currently + The API for manipulation 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, authenticate some packets, and leave some open -- for the
same destination---would become more of an exercise in IPsec same destination -- would become more of an exercise in IPsec
rather than IP measurement. rather than 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. Required Properties of MD5 6.7. Required Properties of MD5
The protocol makes use of the MD5 hash function to convert a The protocol makes use of the MD5 hash function to convert a
user-supplied passphrase into a key that will be used to encrypt a user-supplied passphrase into a key that will be used to encrypt a
skipping to change at page 37, line 13 skipping to change at page 38, line 39
In this document we use cryptographic terminology of [MENEZES]. In this document we use cryptographic terminology of [MENEZES].
It has long been suspected, and has been conclusively shown recently It has long been suspected, and has been conclusively shown recently
that MD5 is not a collision-resistant hash function. Since collision that MD5 is not a collision-resistant hash function. Since collision
resistance was one of design goals of MD5, this casts strong resistance was one of design goals of MD5, this casts strong
suspicion on the other design goals of MD5, namely preimage suspicion on the other design goals of MD5, namely preimage
resistance and 2nd preimage resistance. resistance and 2nd preimage resistance.
OWAMP does not rely on any of these properties. OWAMP does not rely on any of these properties.
The properties of MD5 that are necessary are as follows: (1) it's a The properties of MD5 that are necessary are as follows: (1) it is a
function that maps arbitrary length inputs into 128-bit outputs function that maps arbitrary length inputs into 128-bit outputs
[fixed-length hash function], (2) a change in any bit of the input [fixed-length hash function], (2) a change in any bit of the input
usually results in a change of a few bits of output [weakened usually results in a change of a few bits of output [weakened
avalanche property], (3) many 128-bit strings have preimages [almost avalanche property], (3) many 128-bit strings have preimages [almost
surjective], and (4) the visible special structure of surjective], and (4) the visible special structure of
natural-language text possibly present in the passphrase is concealed natural-language text possibly present in the passphrase is concealed
after application of the function. These are very weak requirements after application of the function. These are very weak requirements
that many functions satisfy. Something resembling CRC-128 would work that many functions satisfy. Something resembling CRC-128 would work
just as well. just as well.
skipping to change at page 38, line 9 skipping to change at page 39, line 37
using MD5. (Note that the performance advantages of MD5 are using MD5. (Note that the performance advantages of MD5 are
irrelevant for this application, as the hash is computed on a irrelevant for this application, as the hash is computed on a
relatively short human-supplied string only once per OWAMP-Control relatively short human-supplied string only once per OWAMP-Control
session, so if the Miyaguchi-Preneel construction were documented in session, so if the Miyaguchi-Preneel construction were documented in
an RFC, we might just as well have used that.) an RFC, we might just as well have used that.)
6.8. The Use of AES-CBC-MAC 6.8. The Use of AES-CBC-MAC
OWAMP relies on AES-CBC-MAC for message authentication. Random IV OWAMP relies on AES-CBC-MAC for message authentication. Random IV
choice is important for prevention of a codebook attack on the first choice is important for prevention of a codebook attack on the first
block, it is unimportant for the purposes of CBC-MAC authentication block; it is unimportant for the purposes of CBC-MAC authentication
(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 ciphers with shorter blocks;
we use random IV anyway). we use random IV anyway).
Integrity zero padding, when decrypted, MUST be zero. It is crucial IZP, when decrypted, MUST be zero. It is crucial to check for this
to check for this before using the message, otherwise existential before using the message, otherwise existential forgery becomes
forgery becomes possible. The complete message for which integrity possible. The complete message for which IZP is decrypted to non-
zero padding is decrypted to non-zero MUST be discarded (for both zero MUST be discarded (for both short messages consisting of a few
short messages consisting of a few blocks and potentially long blocks and potentially long messages, such as a response to the
messages, such as a response to the Fetch-Session command). Fetch-Session command).
Since OWAMP messages can have different numbers of blocks, 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 the first
block of it. block of it.
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) and a 128-bit 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 Since IV=0, the challenge (a single cipher block) is simply encrypted
skipping to change at page 38, line 50 skipping to change at page 40, line 30
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 however, would be immediately discovered by the client when the IZP
integrity zero padding on the server's next message (acceptance or on the server's next message (acceptance or rejection of the
rejection of the connection) does not verify. connection) does not verify.
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate a well-known TCP port number for the IANA is requested to allocate a well-known TCP port number for the
OWAMP-Control part of the OWAMP protocol. OWAMP-Control part of the OWAMP protocol.
8. Internationalization Considerations 8. Internationalization Considerations
The protocol does not carry any information in a natural language. The protocol does not carry any information in a natural language.
skipping to change at page 46, line 5 skipping to change at page 47, line 36
[ZIGG] G. Marsaglia, M. Sibuya, and J. H. Ahrens, Communications of [ZIGG] G. Marsaglia, M. Sibuya, and J. H. Ahrens, Communications of
ACM, 15 (1972), 876-877. ACM, 15 (1972), 876-877.
[MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone, [MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone,
Handbook of Applied Cryptography, CRC Press, revised reprint Handbook of Applied Cryptography, CRC Press, revised reprint
with updates, 1997. with updates, 1997.
[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd [KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd
edition, 1998. edition, 1998.
[RIJN] Reference ANSI C implementation of Rijndael [RIJN] Reference ANSI C Implementation of Rijndael
http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip http://www.esat.kuleuven.ac.be/~rijmen/rijndael/rijndaelref.zip
[RIPE] RIPE NCC Test-Traffic Measurements home, [RIPE] RIPE NCC Test-Traffic Measurements home,
http://www.ripe.net/test-traffic/. http://www.ripe.net/test-traffic/.
[RIPE-NLUUG] H. Uijterwaal and O. Kolkman, `Internet Delay [RIPE-NLUUG] H. Uijterwaal and O. Kolkman, `Internet Delay
Measurements Using Test-Traffic', Spring 1998 Dutch Unix User Measurements Using Test-Traffic', Spring 1998 Dutch Unix User
Group Meeting, Group Meeting,
http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz. http://www.ripe.net/test-traffic/Talks/9805_nluug.ps.gz.
skipping to change at page 46, line 41 skipping to change at page 48, line 25
SIP: shalunov@internet2.edu SIP: shalunov@internet2.edu
Benjamin Teitelbaum Benjamin Teitelbaum
Internet2 Internet2
3025 Boardwalk Dr, Suite 200 3025 Boardwalk Dr, Suite 200
Ann Arbor, MI 48108 Ann Arbor, MI 48108
Email: ben@internet2.edu Email: ben@internet2.edu
SIP: ben@internet2.edu SIP: ben@internet2.edu
Anatoly Karp Anatoly Karp
4710 Regent St Apt 81B 4710 Regent St, Apt 81B
Madison, WI 53705 Madison, WI 53705
Telephone: +1-608-347-6255 Telephone: +1-608-347-6255
Email: ankarp@charter.net Email: ankarp@charter.net
Jeff W. Boote Jeff W. Boote
Internet2 Internet2
3025 Boardwalk Dr, Suite 200 3025 Boardwalk Dr, Suite 200
Ann Arbor, MI 48108 Ann Arbor, MI 48108
Email: boote@internet2.edu Email: boote@internet2.edu
SIP: boote@internet2.edu SIP: boote@internet2.edu
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
3025 Boardwalk Dr, Suite 200 3025 Boardwalk Dr, Suite 200
skipping to change at page 48, line 4 skipping to change at page 49, line 31
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgments Acknowledgments
We would like to thank Bernard Aboba, Guy Almes, Hamid Asgari, Steven We would like to thank Guy Almes, Hamid Asgari, Steven Van den
Van den Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen Donnelly,
Donnelly, Kaynam Hedayat, Petri Helenius, Kitamura Yasuichi, Daniel Kaynam Hedayat, Petri Helenius, Kitamura Yasuichi, Daniel H. T. R.
H. T. R. Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin, Al Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin, Al Morton,
Morton, Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy Scherrer, Henk
Scherrer, Henk Uijterwaal, and Sam Weiler for their comments, Uijterwaal, and Sam Weiler for their comments, suggestions, reviews,
suggestions, reviews, helpful discussion and proof-reading. helpful discussion and proof-reading.
Expiration date: February 2005 Expiration date: April 2005
 End of changes. 147 change blocks. 
397 lines changed or deleted 520 lines changed or added

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