draft-ietf-ippm-owdp-14.txt   draft-ietf-ippm-owdp-15.txt 
Network Working Group Stanislav Shalunov Network Working Group Stanislav Shalunov
Internet Draft Benjamin Teitelbaum Internet Draft Benjamin Teitelbaum
Expiration Date: June 2005 Anatoly Karp Expiration Date: May 2006 Anatoly Karp
Jeff W. Boote Jeff W. Boote
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
December 2004 November 2005
A One-way Active Measurement Protocol (OWAMP) A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-14.txt> <draft-ietf-ippm-owdp-15.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2004. All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
With growing availability of good time sources to network nodes, it With growing availability of good time sources to network nodes, it
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 . . . . . . . . . . . . . . . . . . . . 5 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. Integrity Zero Padding (IZP) . . . . . . . . . . . . . 11 3.2. Integrity Zero Padding (IZP) . . . . . . . . . . . . . 11
3.3. Values of the Accept Field . . . . . . . . . . . . . . 11 3.3. Values of the Accept Field . . . . . . . . . . . . . . 12
3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 12 3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 12
3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 12 3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 13
3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 17 3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 18
3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 18 3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 19
3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19 3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 20
3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 22 3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 23
4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 27 4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 27 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 28
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 27 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 28
4.1.2. Packet Format and Content . . . . . . . . . . . . 28 4.1.2. Packet Format and Content . . . . . . . . . . . . 29
4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 31 4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 32
5. Computing Exponentially Distributed Pseudo-Random Numbers . 33 5. Computing Exponentially Distributed Pseudo-Random Numbers . 34
5.1. High-Level Description of the Algorithm . . . . . . . 33 5.1. High-Level Description of the Algorithm . . . . . . . 34
5.2. Data Types, Representation, and Arithmetic . . . . . . 34 5.2. Data Types, Representation, and Arithmetic . . . . . . 35
5.3. Uniform Random Quantities . . . . . . . . . . . . . . 35 5.3. Uniform Random Quantities . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . 37
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 36 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 37
6.2. Preventing Third-Party Denial of Service . . . . . . . 37 6.2. Preventing Third-Party Denial of Service . . . . . . . 38
6.3. Covert Information Channels . . . . . . . . . . . . . 37 6.3. Covert Information Channels . . . . . . . . . . . . . 38
6.4. Requirement to Include AES in Implementations . . . . 37 6.4. Requirement to Include AES in Implementations . . . . 38
6.5. Resource Use Limitations . . . . . . . . . . . . . . . 37 6.5. Resource Use Limitations . . . . . . . . . . . . . . . 38
6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 38 6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 39
6.7. Required Properties of MD5 . . . . . . . . . . . . . . 39 6.7. Cryptographic primitive replacement . . . . . . . . . 42
6.8. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . . 41 6.8. (Not) Using Time as Salt . . . . . . . . . . . . . . . 42
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 6.9. Required Properties of MD5 . . . . . . . . . . . . . . 43
8. Internationalization Considerations . . . . . . . . . . . . 42 6.10. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . 44
9. Appendix A: Sample C Code for Exponential Deviates . . . . 42 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45
10. Appendix B: Test Vectors for Exponential Deviates . . . . 47 8. Internationalization Considerations . . . . . . . . . . . . 45
11. Normative References . . . . . . . . . . . . . . . . . . . 48 9. Appendix A: Sample C Code for Exponential Deviates . . . . 45
12. Informative References . . . . . . . . . . . . . . . . . . 48 10. Appendix B: Test Vectors for Exponential Deviates . . . . 50
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 49 11. Normative References . . . . . . . . . . . . . . . . . . . 51
12. Informative References . . . . . . . . . . . . . . . . . . 52
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53
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 metrics for one-way packet delay [RFC2679] and loss [RFC2680] across
[RFC2680] across Internet paths. Although there are now several Internet paths. Although there are now several measurement platforms
measurement platforms that implement collection of these metrics that implement collection of these metrics [SURVEYOR] [RIPE] [BRIX],
[SURVEYOR] [RIPE] [BRIX], there is not currently a standard that there is not currently a standard that would permit initiation of
would permit initiation of test streams or exchange of packets to test streams or exchange of packets to collect singleton metrics in
collect singleton metrics in an interoperable manner. an interoperable manner.
With the increasingly wide availability of affordable global With the increasingly wide availability of affordable global
positioning systems (GPS) and CDMA-based time sources, hosts positioning systems (GPS) and CDMA-based time sources, hosts
increasingly have available to them very accurate time increasingly have available to them very accurate time
sources--either directly or through their proximity to Network Time sources--either directly or through their proximity to Network Time
Protocol (NTP) primary (stratum 1) time servers. By standardizing a Protocol (NTP) primary (stratum 1) time servers. By standardizing a
technique for collecting IPPM one-way active measurements, we hope to technique for collecting IPPM one-way active measurements, we hope to
create an environment where IPPM metrics may be collected across a create an environment where IPPM metrics may be collected across a
far broader mesh of Internet paths than is currently possible. One far broader mesh of Internet paths than is currently possible. One
particularly compelling vision is of widespread deployment of open particularly compelling vision is of widespread deployment of open
skipping to change at page 6, line 19 skipping to change at page 6, line 19
| Control-Client |<--OWAMP-Control-->| Server | | Control-Client |<--OWAMP-Control-->| Server |
| Fetch-Client | | | | Fetch-Client | | |
| Session-Sender |---OWAMP-Test----->| Session-Receiver | | Session-Sender |---OWAMP-Test----->| Session-Receiver |
+-----------------+ +------------------+ +-----------------+ +------------------+
Finally, because many Internet paths include segments that transport Finally, because many Internet paths include segments that transport
IP over ATM, delay and loss measurements can include the effects of IP over ATM, delay and loss measurements can include the effects of
ATM segmentation and reassembly (SAR). Consequently, OWAMP has been ATM segmentation and reassembly (SAR). Consequently, OWAMP has been
designed to allow for small test packets that would fit inside the designed to allow for small test packets that would fit inside the
payload of a single ATM cell (this is only achieved in payload of a single ATM cell (this is only achieved in
unauthenticated and encrypted modes). unauthenticated mode).
2. Protocol Overview 2. Protocol Overview
As described above, OWAMP consists of two inter-related protocols: As described above, OWAMP consists of two inter-related protocols:
OWAMP-Control and OWAMP-Test. The former is layered over TCP and is OWAMP-Control and OWAMP-Test. The former is layered over TCP and is
used to initiate and control measurement sessions and to fetch their used to initiate and control measurement sessions and to fetch their
results. The latter protocol is layered over UDP and is used to send results. The latter protocol is layered over UDP and is used to send
singleton measurement packets along the Internet path under test. singleton measurement packets along the Internet path under test.
The initiator of the measurement session establishes a TCP connection The initiator of the measurement session establishes a TCP connection
to a well-known port on the target point and this connection remains to a well-known port XXX on the target point and this connection
open for the duration of the OWAMP-Test sessions. IANA will be remains open for the duration of the OWAMP-Test sessions. An OWAMP
server SHOULD listen to this well-known port. [RFC Editor: IANA is
requested to allocate a well-known port number for OWAMP-Control requested to allocate a well-known port number for OWAMP-Control
sessions. An OWAMP server SHOULD listen to this well-known port. sessions. Please replace ``XXX'' with the value assigned by IANA.]
OWAMP-Control messages are transmitted only before OWAMP-Test OWAMP-Control messages are transmitted only before OWAMP-Test
sessions are actually started and after they complete (with the sessions are actually started and after they complete (with the
possible exception of an early Stop-Sessions message). possible exception of an early Stop-Sessions message).
The OWAMP-Control and OWAMP-Test protocols support three modes of The OWAMP-Control and OWAMP-Test protocols support three modes of
operation: unauthenticated, authenticated, and encrypted. The operation: unauthenticated, authenticated, and encrypted. The
authenticated or encrypted modes require endpoints to possess a authenticated or encrypted modes require endpoints to possess a
shared secret. shared secret.
skipping to change at page 7, line 24 skipping to change at page 7, line 24
number of minutes after it is expected, the TCP connection associated number of minutes after it is expected, the TCP connection associated
with the OWAMP-Control session SHOULD be dropped. In absence of with the OWAMP-Control session SHOULD be dropped. In absence of
other considerations, 30 minutes seems like a reasonable upper bound. other considerations, 30 minutes seems like a reasonable upper bound.
3.1. Connection Setup 3.1. Connection Setup
Before either a Control-Client or a Fetch-Client can issue commands Before either a Control-Client or a Fetch-Client can issue commands
of a Server, it has to establish a connection to the server. 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 XXX. The server responds with a server greeting: [RFC Editor:
Please replace ``XXX'' with the well-known port value assigned by
IANA.]
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Unused (12 octets) | | Unused (12 octets) |
| | | |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes | | Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 12 skipping to change at page 8, line 14
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 does not 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 receives a greeting with Modes SHOULD close the connection if it receives a greeting with Modes
equal to zero. The client MAY close the connection if the client's equal to zero. The client MAY close the connection if the client's
desired mode is unavailable. desired mode is unavailable.
Otherwise, the client MUST respond with the following message: Otherwise, the client MUST respond with the following Set-Up-Response
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Username (16 octets) . . KeyID (80 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Token (32 octets) . . Token (32 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Client-IV (16 octets) . . Client-IV (16 octets) .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. If it is
one bit that is set within the last three bits, this bit MUST
indicate a mode that the server agreed to use (i.e., the same bit
MUST have been set by the server in the server greeting). The first
29 bits of Mode MUST be zero. A server MUST ignore the values of the 29 bits of Mode MUST be zero. A server MUST ignore the values of the
first 29 bits. If zero Mode bits are set by the client, the client first 29 bits. If zero Mode bits are set by the client, the client
indicates that it will not continue with the session; in this case, indicates that it will not continue with the session; in this case,
the client and the server SHOULD close the TCP connection associated the client and the server SHOULD close the TCP connection associated
with the OWAMP-Control session. with the OWAMP-Control session.
In unauthenticated mode, Username, Token, and Client-IV are unused. In unauthenticated mode, KeyID, Token, and Client-IV are unused.
Otherwise, Username is a 16-octet indicator that tells the server Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the
which shared secret the client wishes to use to authenticate or string is shorter, it is padded with zero octets), that tells the
encrypt, while Token is the concatenation of a 16-octet challenge and server which shared secret the client wishes to use to authenticate
a 16-octet Session-key, encrypted using the AES (Advanced Encryption or encrypt, while Token is the concatenation of a 16-octet challenge
Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be and a 16-octet Session-key, encrypted using the AES (Advanced
performed using an Initialization Vector (IV) of zero and a key value Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption
that is the shared secret associated with Username. (Both the server MUST be performed using an Initialization Vector (IV) of zero and a
and the client use the same mappings from user names to secret keys. key value that is the shared secret associated with KeyID. (Both the
The server, being prepared to conduct sessions with more than one server and the client use the same mappings from KeyIDs to secret
client, uses user names to choose the appropriate secret key; a keys. The server, being prepared to conduct sessions with more than
one client, uses KeyIDs to choose the appropriate secret key; a
client would typically have different secret keys for different client would typically have different secret keys for different
servers. The situation is analogous to that of passwords, except servers. The situation is analogous to that of passwords, except
that secret keys, rather than having the low entropy typical of that secret keys, rather than having the low entropy typical of
passwords, are suitable for use as AES keys.) passwords, are suitable for use as AES keys.)
The shared secret MUST be generated with sufficient entropy not to The shared secret MUST be generated with sufficient entropy not to
reduce the security of the underlying cipher. Typical methods of its reduce the security of the underlying cipher. Typical methods of its
generation might be from a random number generator [RFC1750] or from generation might be from a random number generator [RFC4086] or from
the hash of a passphrase. If the shared secret is provided as a the hash of a passphrase. If the shared secret is provided as a
passphrase (typical for the case of interactive tools) then the MD5 passphrase (typical for the case of interactive tools) then the MD5
sum [RFC1321] of the passphrase (without possible newline sum [RFC1321] of the passphrase (without possible newline
character(s) at the end of the passphrase) MUST be used as the key character(s) at the end of the passphrase) MUST be used as the key
for encryption by the client and decryption by the server (the for encryption by the client and decryption by the server (the
passphrase also MUST NOT contain newlines in the middle). This passphrase also MUST NOT contain newlines in the middle). This
ensures that a passphrase used to generate a secret in one ensures that a passphrase used to generate a secret in one
implementation will generate the same secret in another implementation will generate the same secret in another
implementation and the implementations will, therefore, be implementation and the implementations will, therefore, be
interoperable. interoperable.
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 [RFC1750]. Client-IV merely the security of the underlying cipher [RFC4086]. Client-IV merely
needs to be unique (i.e., it MUST never be repeated for different needs to be unique (i.e., it MUST never be repeated for different
sessions using the same secret key; a simple way to achieve that sessions using the same secret key; a simple way to achieve that
without the use of cumbersome state is to generate the Client-IV without the use of cumbersome state is to generate the Client-IV
strings using a cryptographically secure pseudo-random number source: values using a cryptographically secure pseudo-random number source:
if this is done, the first repetition is unlikely to occur before if this is done, the first repetition is unlikely to occur before
2^64 sessions with the same secret key are conducted). 2^64 sessions with the same secret key are conducted).
The server MUST respond with the following message: The server MUST respond with the following Server-Start message:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MBZ (15 octets) | | MBZ (15 octets) |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | Accept | | | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Server-IV (16 octets) | | Server-IV (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Uptime (Timestamp) | | Start-Time (Timestamp) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IZP (8 octets) | | IZP (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MBZ 15-octet part MUST be zero. The client MUST ignore its The MBZ 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 so
string of zero bits; the party that interprets the message MUST that all bits are equal to zero; the party that interprets the
ignore the value. (This way the field could be used for future message MUST ignore the value. (This way the field could be used for
extensions.) future extensions.)
Server-IV is generated randomly by the server. In unauthenticated Server-IV is generated randomly by the server. In unauthenticated
mode, Server-IV is unused. mode, Server-IV is unused.
The Accept field indicates the server's willingness to continue The Accept field indicates the server's willingness to continue
communication. A zero value in the Accept field means that the communication. A zero value in the Accept field means that the
server accepts the authentication and is willing to conduct further server accepts the authentication and is willing to conduct further
transactions. Non-zero values indicate that the server does not transactions. Non-zero values indicate that the server does not
accept the authentication or, for some other reason, is not willing accept the authentication or, for some other reason, is not willing
to conduct further transactions in this OWAMP-Control session. The to conduct further transactions in this OWAMP-Control session. The
full list of available Accept values is described in Section 3.3, full list of available Accept values is described in Section 3.3,
``Values of the Accept Field''. ``Values of the Accept Field''.
If a negative (non-zero) response is sent, the server MAY and the If a negative (non-zero) response is sent, the server MAY and the
client SHOULD close the connection after this message. client SHOULD close the connection after this message.
Uptime is a timestamp representing the time when the current Start-Time is a timestamp representing the time when the current
instantiation of the server started operating. (For example, in a instantiation of the server started operating. (For example, in a
multi-user general purpose operating system (OS), it could be the multi-user general purpose operating system (OS), it could be the
time when the server process was started.) If Accept is non-zero, time when the server process was started.) If Accept is non-zero,
Uptime SHOULD be set to a string of zeros. In authenticated and Start-Time SHOULD be set so that all of its bits are zeros. In
encrypted modes, Uptime is encrypted as described in the next authenticated and encrypted modes, Start-Time is encrypted as
section, unless Accept is non-zero. (Authenticated and encrypted mode described in the next section, unless Accept is non-zero.
cannot be entered unless the control connection can be initialized.) (Authenticated and encrypted mode cannot be entered unless the
control connection can be initialized.)
Timestamp format is described in Section 4.1.2. The same Timestamp format is described in Section 4.1.2. The same
instantiation of the server SHOULD report the same exact Uptime value instantiation of the server SHOULD report the same exact Start-Time
to each client in each session. value to each client in each session.
Integrity Zero Padding (IZP) is treated the same way as IZP in the Integrity Zero Padding (IZP) is treated the same way as IZP in the
next section and beyond. next section and beyond.
The previous transactions constitute connection setup. The previous transactions constitute connection setup.
3.2. Integrity Zero Padding (IZP) 3.2. Integrity Zero Padding (IZP)
IZP MUST be all zeros in all messages that use IZP. The recipient of IZP MUST be all zeros in all messages that use IZP. The recipient of
a message where IZP is not zero MUST reject the message, as it is an a message where IZP is not zero MUST reject the message, as it is an
indication of tampering with the content of the message by an indication of tampering with the content of the message 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.
The purpose of the IZP field is to ensure data integrity. In
unauthenticated mode, IZP is nothing more than a simple check. In unauthenticated mode, IZP is nothing more than a simple check. In
authenticated and encrypted modes, however, it ensures, in authenticated and encrypted modes, however, it ensures, in
conjunction with properties of CBC chaining mode, that everything conjunction with properties of CBC chaining mode, that everything
received before was not tampered with. For this reason, it is received before was not tampered with. For this reason, it is
important to check the IZP field as soon as possible, so that bad important to check the IZP field as soon as possible, so that bad
data doesn't get propagated. data doesn't get propagated. See section 6.8 for more on the use of
structured redundant messages with CBC mode. (Informally, if a
message is tampered with, the IZP field would decrypt to random
garbage and thus ensure the detection of tampering. If such a field
were not present, then redundance inherent in the messages would have
needed to be used to detect modification; this could allow for
existential forgery of, e.g., last block of a message if that last
block were not redundant. To avoid considering these complications
and specifying the exact redundancy checks for every different
message we, instead, specify the use of IZP, which makes implementing
OWAMP more straightforward.)
3.3. Values of the Accept Field 3.3. Values of the Accept Field
Accept values are used throughout the OWAMP-Control protocol to Accept values are used throughout the OWAMP-Control protocol to
communicate the server response to client requests. The full set of communicate the server response to client requests. The full set of
valid Accept field values are: valid Accept field values are:
0 OK. 0 OK.
1 Failure, reason unspecified (catch-all). 1 Failure, reason unspecified (catch-all).
skipping to change at page 31, line 11 skipping to change at page 32, line 11
authenticated mode does not involve any actual chaining; this way, authenticated mode does not involve any actual chaining; this way,
lost, duplicated, or reordered packets do not cause problems with lost, duplicated, or reordered packets do not cause problems with
deciphering any packet in an OWAMP-Test session. deciphering any packet in an OWAMP-Test session.
In encrypted mode, the first two blocks (32 octets) are encrypted In encrypted mode, the first two blocks (32 octets) are encrypted
using AES CBC mode. The key to use is obtained in the same way as using AES CBC mode. The key to use is obtained in the same way as
the key for authenticated mode. Each OWAMP-Test packet is encrypted the key for authenticated mode. Each OWAMP-Test packet is encrypted
as a separate stream, with just one chaining operation; chaining does as a separate stream, with just one chaining operation; chaining does
not span multiple packets so that lost, duplicated, or reordered not span multiple packets so that lost, duplicated, or reordered
packets do not cause problems. The initialization vector for the CBC packets do not cause problems. The initialization vector for the CBC
encryption is a string of zeros. encryption is a value with all bits equal to zero.
Implementation note: Naturally, the key schedule for each OWAMP-Test Implementation note: Naturally, the key schedule for each OWAMP-Test
session need only be set up once per session, not once per packet. session need only be set up once per session, not once per packet.
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
skipping to change at page 32, line 18 skipping to change at page 33, line 18
+ In authenticated or encrypted mode, decrypt the first block (16 + In authenticated or encrypted mode, decrypt the first block (16
octets) of the 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 sequence number, presumed send time, are recorded with their true sequence number, presumed send time,
receive time consisting of a string of zero bits, and TTL (or Hop receive time value with all bits being zero, and TTL (or Hop
Limit) 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
skipping to change at page 37, line 12 skipping to change at page 38, line 12
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, for denial of service (DoS) attacks. In unauthenticated mode,
servers SHOULD limit receivers to hosts they control or to the OWAMP- servers SHOULD limit receivers to hosts they control or to the OWAMP-
Control client. Control client.
Unless otherwise configured, the default behavior of servers MUST be
to decline requests where the Receiver Address field is not equal to
the address that the control connection was initiated from or an
address of the server (or an address of a host it controls). Given
the TCP handshake procedure and sequence numbers in the control
connection, this ensures that the hosts that make such requests are
actually those hosts themselves, or at least on the path towards
them. If either this test or the handshake procedure were omitted,
it would become possible for attackers anywhere in the Internet to
request large amounts of test packets be directed against victim
nodes somewhere else.
In any case, OWAMP-Test packets with a given source address MUST only
be sent from the node that has been assigned that address (i.e.,
address spoofing is not permitted).
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
skipping to change at page 37, line 33 skipping to change at page 38, line 49
6.5. Resource Use Limitations 6.5. Resource Use Limitations
An OWAMP server can consume resources of various kinds. The two most An OWAMP server can consume resources of various kinds. The two most
important kinds of resources are network capacity and memory (primary important kinds of resources are network capacity and memory (primary
or secondary) for storing test results. or secondary) for storing test results.
Any implementation of OWAMP server MUST include technical mechanisms Any implementation of OWAMP server MUST include technical mechanisms
to limit the use of network capacity and memory. Mechanisms for to limit the use of network capacity and memory. Mechanisms for
managing the resources consumed by unauthenticated users and users managing the resources consumed by unauthenticated users and users
authenticated with a username and passphrase SHOULD be separate. The authenticated with a KeyID and passphrase SHOULD be separate. The
default configuration of an implementation MUST enable these default configuration of an implementation MUST enable these
mechanisms and set the resource use limits to conservatively low mechanisms and set the resource use limits to conservatively low
values. values.
One way to design the resource limitation mechanisms is as follows: One way to design the resource limitation mechanisms is as follows:
assign each session to a user class. User classes are partially assign each session to a user class. User classes are partially
ordered with ``includes'' relation, with one class (``all users'') ordered with ``includes'' relation, with one class (``all users'')
that is always present and that includes any other class. The that is always present and that includes any other class. The
assignment of a session to a user class can be based on the presence assignment of a session to a user class can be based on the presence
of authentication of the session, the user name, IP address range, of authentication of the session, the KeyID, IP address range, time
time of day, and, perhaps, other factors. Each user class would have of day, and, perhaps, other factors. Each user class would have a
a limit for usage of network capacity (specified in units of limit for usage of network capacity (specified in units of
bit/second) and memory for storing test results (specified in units bit/second) and memory for storing test results (specified in units
of octets). Along with the limits for resource use, current use of octets). Along with the limits for resource use, current use
would be tracked by the server. When a session is requested by a would be tracked by the server. When a session is requested by a
user in a specific user class, the resources needed for this session user in a specific user class, the resources needed for this session
are computed: the average network capacity use (based on the sending are computed: the average network capacity use (based on the sending
schedule) and the maximum memory use (based on the number of packets schedule) and the maximum memory use (based on the number of packets
and number of octets each packet would need to be stored internally and number of octets each packet would need to be stored internally
-- note that outgoing sessions would not require any memory use). -- note that outgoing sessions would not require any memory use).
These resource use numbers are added to the current resource use These resource use numbers are added to the current resource use
numbers for the given user class; if such addition would take the numbers for the given user class; if such addition would take the
skipping to change at page 38, line 28 skipping to change at page 39, line 44
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 At an early stage in designing the protocol, we considered using
Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401] Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401]
as cryptographic security mechanisms for OWAMP. The disadvantages of as cryptographic security mechanisms for OWAMP; later, we also
those are as follows (not an exhaustive list): considered DTLS. 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 + TLS could be used to secure TCP-based OWAMP-Control, but it would
difficult to use to secure UDP-based OWAMP-Test: OWAMP-Test be difficult to use it to secure UDP-based OWAMP-Test: OWAMP-Test
packets, if lost, are not resent, so packets have to be packets, if lost, are not resent, so packets have to be
(optionally) encrypted and authenticated while retaining (optionally) encrypted and authenticated while retaining
individual usability. Stream-based TLS is not conducive of this. individual usability. Stream-based TLS cannot be easily used for
this.
+ Dealing with streams, does not authenticate individual messages + Dealing with streams, TLS does not authenticate individual
(even in OWAMP-Control). The easiest way out would be to add some messages (even in OWAMP-Control). The easiest way out would be to
known-format padding to each message and verify that the format of add some known-format padding to each message and verify that the
the padding is intact before using the message. The solution format of the padding is intact before using the message. The
would thus lose some of its appeal (``just use TLS''); it would solution would thus lose some of its appeal (``just use TLS''); it
also be much more difficult to evaluate the security of this would also be much more difficult to evaluate the security of this
scheme with the various modes and options of TLS -- it would scheme with the various modes and options of TLS -- it would
almost certainly not be secure with all. The capacity of an almost certainly not be secure with all. The capacity of an
attacker to replace parts of messages (namely, the end) with attacker to replace parts of messages (namely, the end) with
random garbage could have serious security implications and would random garbage could have serious security implications and would
need to be analyzed carefully: suppose, for example, that a need to be analyzed carefully: suppose, for example, that a
parameter that is used in some form to control the rate were parameter that is used in some form to control the rate were
replaced by random garbage -- chances are the result (an unsigned replaced by random garbage -- chances are the result (an unsigned
integer) would be 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 DTLS:
+ Duplication and, similarly, reordering are network phenomena that
OWAMP needs to be able to measure; yet anti-replay measures and
reordering protection of DTLS would prevent the duplicated and
reordered packets from reaching the relevant part of the OWAMP
code. One could, of course, modify DTLS so that these protections
are weakened, or even specify examining the messages in a
carefully crafted sequence somewhere in between of DTLS checks,
but then, of course, the advantage of using an existing protocol
would not be realized.
+ In authenticated mode the timestamp is in the clear and not
protected cryptographically in any way, while the rest of the
message has the same protection as in encrypted mode. This mode
allows one to trade off cryptographic protection against accuracy
of timestamps. For example, the APAN hardware implementation of
OWAMP [APAN-OWAMP] is capable of supporting authenticated mode.
The accuracy of these measurements is in sub-microsecond range.
The errors in OWAMP measurements of Abilene [Abilene-OWAMP] (done
using a software implementation, in its encrypted mode) exceed
10us. Users in different environments have different concerns,
and some might very well care about every last microsecond of
accuracy; at the same time, users in these same environments might
care about access control to the service. Authenticated mode
permits them to control access to the server, yet use unprotected
timestamps, perhaps generated by a hardware device.
Regarding IPsec: Regarding IPsec:
+ What we now call authenticated mode would not be possible (in + What we now call authenticated mode would not be possible (in
IPsec you can't authenticate part of a packet). IPsec you can't authenticate part of a packet).
+ The deployment paths of IPsec and OWAMP could be separate if OWAMP + The deployment paths of IPsec and OWAMP could be separate if OWAMP
does not depend on IPsec. After nine years of IPsec, only 0.05% does not depend on IPsec. After nine years of IPsec, only 0.05%
of traffic on an advanced backbone network such as Abilene uses of traffic on an advanced backbone network such as Abilene uses
IPsec (for comparison purposes with encryption above layer 4, SSH IPsec (for comparison purposes with encryption above layer 4, SSH
use is at 2-4% and HTTPS use is at 0.2-0.6%). It is desirable to use is at 2-4% and HTTPS use is at 0.2-0.6%). It is desirable to
skipping to change at page 39, line 43 skipping to change at page 42, line 5
+ The API for manipulating IPsec from an application is currently + The API for manipulating IPsec from an application is currently
poorly understood. Writing a program that needs to encrypt some poorly understood. Writing a program that needs to encrypt some
packets, authenticate some packets, and leave some open -- for the packets, 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 in IP measurement. rather than in IP measurement.
For the enumerated reasons, we decided to use a simple cryptographic For the enumerated reasons, we decided to use a simple cryptographic
protocol (based on a block cipher in CBC mode) that is different from protocol (based on a block cipher in CBC mode) that is different from
TLS and IPsec. TLS and IPsec.
6.7. Required Properties of MD5 6.7. Cryptographic primitive replacement
It might become necessary in the future to replace AES, or the way it
is used in OWAMP, with a new cryptographic primitive---or to make
other security-related changes to the protocol. OWAMP provides a
well-defined point of extensibility: the Modes word in the server
greeting and the Mode response in the Set-Up-Response message. For
example, if a simple replacement of AES with a different block cipher
with a 128-bit block is needed, this could be accomplished as
follows: take two bits from the reserved (MBZ) part of the Modes word
of the server greeting; use one of these bits to indicate encrypted
mode with the new cipher and another one to indicate authenticated
mode with the new cipher. (Bit consumption could, in fact, be
reduced from two to one, if the client is allowed to return a mode
selection with more than a single bit set: one could designate a
single bit to mean that the new cipher is supported [in the case of
the server] or selected [in the case of the client] and continue to
use already allocated bits for authenticated and encrypted modes;
this optimization is unimportant conceptually, but could be useful in
practice to make the best use of bits.) Then, if the new cipher is
negotiated, all subsequent operations simply use it instead of AES.
Note that the normal transition sequence would be used in such a
case: implementations would probably first start supporting and
preferring the new cipher, and then drop support for the old
(presumably no longer considered secure) cipher.
If the need arises to make more extensive changes (perhaps replace
AES with a 256-bit-block cipher), this would be more difficult and
would require changing the layout of the messages. However, the
change can still be conducted within the framework of OWAMP
extensibility using the Modes/Mode words. (The semantics of the new
bits [or single bit, if the optimization described above is used]
would include the change to message layout as well as the change in
the cryptographic primitive.)
6.8. (Not) Using Time as Salt
A natural idea is to use the current time as salt when deriving
session keys. Unfortunately, this appears too limiting.
While OWAMP is often run on hosts with well-synchronized clocks, it
is also possible to run it on hosts with clocks completely untrained.
The delays obtained thusly are, of course, not directly usable;
however, some metrics, such as unidirectional loss, reordering,
measures of congestion such as the median delay minus minimum, and
many others are usable directly and immediately (and improve upon the
information that would have been provided by a round-trip
measurement); further, even delay information can be useful with
appropriate post-processing---indeed, one can even argue that running
the clocks free and post-processing the results of a mesh of
measurements will result in better accuracy, as more information is
available a posteriori and correlation of data from different hosts
is possible in post-processing, but not with online clock training.
Given this, time is not used as salt in key derivation.
6.9. 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
short piece of random data (the session key). short piece of random data (the session key).
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 is 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 values 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.
We chose MD5 here because it has the required properties and is We chose MD5 here because it has the required properties and is
widely implemented, understood, and documented. Alternatives would widely implemented, understood, and documented. Alternatives would
include (1) a non-cryptographic primitive, such as CRC-128, (2) SHA-1 include (1) a non-cryptographic primitive, such as CRC-128, (2) SHA-1
truncated to 128 bits, or (3) a hash function based on AES (using truncated to 128 bits, or (3) a hash function based on AES (using
skipping to change at page 41, line 5 skipping to change at page 44, line 21
preceding paragraph, however, do not call for a cryptographically preceding paragraph, however, do not call for a cryptographically
sound hash function. Just as with CRC-128, this specification would sound hash function. Just as with CRC-128, this specification would
need to define the hash function and provide test vectors (and need to define the hash function and provide test vectors (and
perhaps sample code); we see no advantage in this approach versus perhaps sample code); we see no advantage in this approach versus
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.10. 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).
IZP, when decrypted, MUST be zero. It is crucial to check for this IZP, when decrypted, MUST be zero. It is crucial to check for this
before using the message, otherwise existential forgery becomes before using the message, otherwise existential forgery becomes
skipping to change at page 42, line 12 skipping to change at page 45, line 30
on the server's next message (acceptance or rejection of the on the server's next message (acceptance or rejection of the
connection) does not verify. connection) does not verify.
7. IANA Considerations 7. 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,
with the possible exception of the KeyID in OWAMP-Control, which is
encoded in UTF-8.
9. Appendix A: Sample C Code for Exponential Deviates 9. Appendix A: Sample C Code for Exponential Deviates
The values in array Q[] are the exact values that MUST be used by all The values in array Q[] are the exact values that MUST be used by all
implementations (see sections 5.1 and 5.2). This appendix only implementations (see sections 5.1 and 5.2). This appendix only
serves for illustrative purposes. serves for illustrative purposes.
/* /*
** Example usage: generate a stream of exponential (mean 1) ** Example usage: generate a stream of exponential (mean 1)
** random quantities (ignoring error checking during initialization). ** random quantities (ignoring error checking during initialization).
skipping to change at page 45, line 36 skipping to change at page 49, line 13
memset(next->out, 0, 16); memset(next->out, 0, 16);
for (i = 0; i < 16; i++) for (i = 0; i < 16; i++)
next->counter[i] = 0UL; next->counter[i] = 0UL;
} }
/* /*
** Random number generating functions. ** Random number generating functions.
*/ */
/* /*
** Generate and return a 32-bit uniform random string (saved in the less ** Generate and return a 32-bit uniform random value (saved in the less
** significant half of the u_int64_t). This function implements steps ** significant half of the u_int64_t). This function implements steps
** U2-U4 of the algorithm Unif. ** U2-U4 of the algorithm Unif.
*/ */
u_int64_t u_int64_t
OWPunif_rand64(OWPrand_context *next) OWPunif_rand64(OWPrand_context *next)
{ {
int j; int j;
u_int8_t *buf; u_int8_t *buf;
u_int64_t ret = 0; u_int64_t ret = 0;
skipping to change at page 48, line 37 skipping to change at page 52, line 8
Metric for IPPM', RFC 2679, September 1999. Metric for IPPM', RFC 2679, September 1999.
[RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet [RFC2680] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Packet
Loss Metric for IPPM', RFC 2680, September 1999. Loss Metric for IPPM', RFC 2680, September 1999.
[RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior [RFC2836] S. Brim, B. Carpenter, F. Le Faucheur, `Per Hop Behavior
Identification Codes', RFC 2836, May 2000. Identification Codes', RFC 2836, May 2000.
12. Informative References 12. Informative References
[APAN-OWAMP] Z. Shu and K. Kobayashi, HOTS: An OWAMP-Compliant
Hardware Packet Timestamper, In Proceedings of PAM 2005,
http://www.pam2005.org/PDF/34310360.pdf
[BRIX] Brix Networks, http://www.brixnet.com/ [BRIX] Brix Networks, http://www.brixnet.com/
[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.
[Abilene-OWAMP] One-way Latency Measurement (OWAMP),
http://e2epi.internet2.edu/owamp/
[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 49, line 24 skipping to change at page 52, line 48
[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/. [SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/.
[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An [SURVEYOR-INET] S. Kalidindi and M. Zekauskas, `Surveyor: An
Infrastructure for Network Performance Measurements', Infrastructure for Network Performance Measurements',
Proceedings of INET'99, June 1999. Proceedings of INET'99, June 1999.
http://www.isoc.org/inet99/proceedings/4h/4h_2.htm http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
[RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification, [RFC1305] D. Mills, `Network Time Protocol (Version 3) Specification,
Implementation and Analysis', RFC 1305, March 1992. Implementation and Analysis', RFC 1305, March 1992.
[RFC1750] D. Eastlake 3rd, S. Crocker, J. Schiller, `Randomness
Recommendations for Security', December 1994.
[RFC2246] T. Dierks, C. Allen, `The TLS Protocol Version 1.0', [RFC2246] T. Dierks, C. Allen, `The TLS Protocol Version 1.0',
January 1999. January 1999.
[RFC2401] S. Kent, R. Atkinson, `Security Architecture for the [RFC2401] S. Kent, R. Atkinson, `Security Architecture for the
Internet Protocol', November 1998. Internet Protocol', November 1998.
[RFC3546] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. [RFC3546] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T.
Wright, `Transport Layer Security (TLS) Extensions', June 2003. Wright, `Transport Layer Security (TLS) Extensions', June 2003.
[RFC4086] D. Eastlake 3rd, J. Schiller, S. Crocker, `Randomness
Recommendations for Security', June 2005.
13. Authors' Addresses 13. Authors' Addresses
Stanislav Shalunov Stanislav Shalunov
Internet2 Internet2
1000 Oakbrook Drive, Suite 300 1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104 Ann Arbor, MI 48104
Email: shalunov@internet2.edu Email: shalunov@internet2.edu
SIP: shalunov@internet2.edu SIP: shalunov@internet2.edu
Benjamin Teitelbaum Benjamin Teitelbaum
Internet2 Internet2
1000 Oakbrook Drive, Suite 300 1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104 Ann Arbor, MI 48104
Email: ben@internet2.edu 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
skipping to change at page 51, line 19 skipping to change at page 54, line 38
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 (2005). 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 Guy Almes, Hamid Asgari, Steven Van den We would like to thank Guy Almes, Mark Allman, Jari Arkko, Hamid
Berghe, Eric Boyd, Robert Cole, Joan Cucchiara, Stephen Donnelly, Asgari, Steven Van den Berghe, Eric Boyd, Robert Cole, Joan
Susan Evett, Kaynam Hedayat, Petri Helenius, Kitamura Yasuichi, Cucchiara, Stephen Donnelly, Susan Evett, Sam Hartman, Kaynam
Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah, Allison Mankin, Hedayat, Petri Helenius, Scott Hollenbeck, Russ Housley, Kitamura
Al Morton, Attila Pasztor, Randy Presuhn, Matthew Roughan, Andy Yasuichi, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah,
Scherrer, Henk Uijterwaal, and Sam Weiler for their comments, Allison Mankin, Al Morton, Attila Pasztor, Randy Presuhn, Matthew
suggestions, reviews, helpful discussion and proof-reading. Roughan, Andy Scherrer, Henk Uijterwaal, and Sam Weiler for their
comments, suggestions, reviews, helpful discussion and proof-reading.
Expiration date: June 2005 Expiration date: May 2006
 End of changes. 51 change blocks. 
115 lines changed or deleted 251 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/