draft-ietf-ippm-owdp-15.txt   draft-ietf-ippm-owdp-16.txt 
Network Working Group Stanislav Shalunov Network Working Group Stanislav Shalunov
Internet Draft Benjamin Teitelbaum Internet Draft Benjamin Teitelbaum
Expiration Date: May 2006 Anatoly Karp Expiration Date: August 2006 Anatoly Karp
Jeff W. Boote Jeff W. Boote
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
November 2005 February 2006
A One-way Active Measurement Protocol (OWAMP) A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-15.txt> <draft-ietf-ippm-owdp-16.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. 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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 (2005). Copyright (C) The Internet Society (2006).
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 Protection (HMAC) . . . . . . . . . . . . . 12
3.3. Values of the Accept Field . . . . . . . . . . . . . . 12 3.3. Values of the Accept Field . . . . . . . . . . . . . . 12
3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 12 3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 13
3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 13 3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 14
3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 18 3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 19
3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 19 3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 20
3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 20 3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 21
3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 23 3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 24
4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 28 4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 28 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 29
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 28 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 29
4.1.2. Packet Format and Content . . . . . . . . . . . . 29 4.1.2. OWAMP-Test Packet Format and Content . . . . . . 30
4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 32 4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 34
5. Computing Exponentially Distributed Pseudo-Random Numbers . 34 5. Computing Exponentially Distributed Pseudo-Random Numbers . 35
5.1. High-Level Description of the Algorithm . . . . . . . 34 5.1. High-Level Description of the Algorithm . . . . . . . 36
5.2. Data Types, Representation, and Arithmetic . . . . . . 35 5.2. Data Types, Representation, and Arithmetic . . . . . . 36
5.3. Uniform Random Quantities . . . . . . . . . . . . . . 36 5.3. Uniform Random Quantities . . . . . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . . 39
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 37 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 39
6.2. Preventing Third-Party Denial of Service . . . . . . . 38 6.2. Preventing Third-Party Denial of Service . . . . . . . 39
6.3. Covert Information Channels . . . . . . . . . . . . . 38 6.3. Covert Information Channels . . . . . . . . . . . . . 40
6.4. Requirement to Include AES in Implementations . . . . 38 6.4. Requirement to Include AES in Implementations . . . . 40
6.5. Resource Use Limitations . . . . . . . . . . . . . . . 38 6.5. Resource Use Limitations . . . . . . . . . . . . . . . 40
6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 39 6.6. Use of Cryptographic Primitives in OWAMP . . . . . . . 41
6.7. Cryptographic primitive replacement . . . . . . . . . 42 6.7. Cryptographic primitive replacement . . . . . . . . . 43
6.8. (Not) Using Time as Salt . . . . . . . . . . . . . . . 42 6.8. Long-term manually managed keys . . . . . . . . . . . 44
6.9. Required Properties of MD5 . . . . . . . . . . . . . . 43 6.9. (Not) Using Time as Salt . . . . . . . . . . . . . . . 45
6.10. The Use of AES-CBC-MAC . . . . . . . . . . . . . . . 44 6.10. The Use of AES-CBC and HMAC . . . . . . . . . . . . . 45
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46
8. Internationalization Considerations . . . . . . . . . . . . 45 8. Internationalization Considerations . . . . . . . . . . . . 46
9. Appendix A: Sample C Code for Exponential Deviates . . . . 45 9. Appendix A: Sample C Code for Exponential Deviates . . . . 47
10. Appendix B: Test Vectors for Exponential Deviates . . . . 50 10. Appendix B: Test Vectors for Exponential Deviates . . . . 52
11. Normative References . . . . . . . . . . . . . . . . . . . 51 11. Normative References . . . . . . . . . . . . . . . . . . . 52
12. Informative References . . . . . . . . . . . . . . . . . . 52 12. Informative References . . . . . . . . . . . . . . . . . . 53
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
The IETF IP Performance Metrics (IPPM) working group has proposed The IETF IP Performance Metrics (IPPM) working group has proposed
metrics for one-way packet delay [RFC2679] and loss [RFC2680] across metrics for one-way packet delay [RFC2679] and loss [RFC2680] across
Internet paths. Although there are now several measurement platforms Internet paths. Although there are now several measurement platforms
that implement collection of these metrics [SURVEYOR] [RIPE] [BRIX], that implement collection of these metrics [SURVEYOR] [RIPE] [BRIX],
there is not currently a standard that would permit initiation of there is not currently a standard that would permit initiation of
test streams or exchange of packets to collect singleton metrics in test streams or exchange of packets to collect singleton metrics in
an interoperable manner. an interoperable manner.
skipping to change at page 7, line 42 skipping to change at page 8, line 18
| Unused (12 octets) | | Unused (12 octets) |
| | | |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes | | Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Challenge (16 octets) | | Challenge (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Salt (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following Mode values are meaningful: 1 for unauthenticated, 2 The following Mode values are meaningful: 1 for unauthenticated, 2
for authenticated, and 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, the last three bits of willing to support during this session. Thus, the last three bits of
the Modes 32-bit value are used. The first 29 bits MUST be zero. A 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.
Salt and Count are parameters used in deriving a key from a shared
secret as described below.
Salt MUST be generated pseudo-randomly (independently of anything
else in this document).
Count MUST be a power of 2. Count MUST be at least 1024. Count
SHOULD be increased as more computing power becomes common.
If 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 Set-Up-Response Otherwise, the client MUST respond with the following Set-Up-Response
message: message:
0 1 2 3 0 1 2 3
skipping to change at page 9, line 15 skipping to change at page 10, line 12
In unauthenticated mode, KeyID, Token, and Client-IV are unused. In unauthenticated mode, KeyID, Token, and Client-IV are unused.
Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the
string is shorter, it is padded with zero octets), that tells the string is shorter, it is padded with zero octets), that tells the
server which shared secret the client wishes to use to authenticate server which shared secret the client wishes to use to authenticate
or encrypt, while Token is the concatenation of a 16-octet challenge or encrypt, while Token is the concatenation of a 16-octet challenge
and a 16-octet Session-key, encrypted using the AES (Advanced and a 16-octet Session-key, encrypted using the AES (Advanced
Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption Encryption Standard) [AES] in Cipher Block Chaining (CBC). Encryption
MUST be performed using an Initialization Vector (IV) of zero and a MUST be performed using an Initialization Vector (IV) of zero and a
key value that is the shared secret associated with KeyID. (Both the key derived from the shared secret associated with KeyID. (Both the
server and the client use the same mappings from KeyIDs to secret server and the client use the same mappings from KeyIDs to shared
keys. The server, being prepared to conduct sessions with more than secrets. The server, being prepared to conduct sessions with more
one client, uses KeyIDs to choose the appropriate secret key; a 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 with passwords.)
that secret keys, rather than having the low entropy typical of
passwords, are suitable for use as AES keys.)
The shared secret MUST be generated with sufficient entropy not to The shared secret is a passphrase; it MUST not contain newlines. The
reduce the security of the underlying cipher. Typical methods of its secret key is derived from the passphrase using a password-based key
generation might be from a random number generator [RFC4086] or from derivation function PBKDF2 (PKCS #5) [RFC2898]. The PBKDF2 function
the hash of a passphrase. If the shared secret is provided as a requires several parameters: the PRF is HMAC-SHA1 [RFC2104]; the salt
passphrase (typical for the case of interactive tools) then the MD5 and count are as transmitted by the server.
sum [RFC1321] of the passphrase (without possible newline
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
passphrase also MUST NOT contain newlines in the middle). This
ensures that a passphrase used to generate a secret in one
implementation will generate the same secret in another
implementation and the implementations will, therefore, be
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 [RFC4086]. 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
values 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).
skipping to change at page 10, line 22 skipping to change at page 11, line 22
| | Accept | | | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Server-IV (16 octets) | | Server-IV (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time (Timestamp) | | Start-Time (Timestamp) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IZP (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MBZ 15-octet part MUST be zero. The client MUST ignore its The MBZ parts MUST be zero. The client MUST ignore their value. MBZ
value. MBZ (MUST be zero) fields here and hereafter have the same (MUST be zero) fields here and hereafter have the same semantics: the
semantics: the party that sends the message MUST set the field so party that sends the message MUST set the field so that all bits are
that all bits are equal to zero; the party that interprets the equal to zero; the party that interprets the message MUST ignore the
message MUST ignore the value. (This way the field could be used for value. (This way the field could be used for future 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
skipping to change at page 11, line 13 skipping to change at page 12, line 12
Start-Time SHOULD be set so that all of its bits are zeros. In Start-Time SHOULD be set so that all of its bits are zeros. In
authenticated and encrypted modes, Start-Time is encrypted as authenticated and encrypted modes, Start-Time is encrypted as
described in the next section, unless Accept is non-zero. described in the next section, unless Accept is non-zero.
(Authenticated and encrypted mode cannot be entered unless the (Authenticated and encrypted mode cannot be entered unless the
control connection can be initialized.) control connection can be initialized.)
Timestamp format is described in Section 4.1.2. The same Timestamp format is described in Section 4.1.2. The same
instantiation of the server SHOULD report the same exact Start-Time instantiation of the server SHOULD report the same exact Start-Time
value to each client in each session. value to each client in each session.
Integrity Zero Padding (IZP) is treated the same way as IZP in the
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 Protection (HMAC)
IZP MUST be all zeros in all messages that use IZP. The recipient of Authentication of each message (also referred to as a command in this
a message where IZP is not zero MUST reject the message, as it is an document) in OWAMP-Control is accomplished by adding an HMAC to it.
indication of tampering with the content of the message by an The HMAC that OWAMP uses is HMAC-SHA1 truncated to 128 bits. Thus,
intermediary (or brokenness). If the message is part of all HMAC fields are 16 octets. An HMAC needs a key. The same key
OWAMP-Control, the session MUST be terminated and results used for AES encryption is used for HMAC authentication. Each HMAC
invalidated. If the message is part of OWAMP-Test, it MUST be sent covers everything sent in a given direction between the previous
silently ignored. HMAC (but not including it) and up to the beginning of the new HMAC.
This way, once encryption is set up, each bit of the OWAMP-Control
connection is authenticated by an HMAC exactly once.
The purpose of the IZP field is to ensure data integrity. In When encrypting, authentication happens before encryption, so HMAC
unauthenticated mode, IZP is nothing more than a simple check. In blocks are encrypted along with the rest of the stream. When
authenticated and encrypted modes, however, it ensures, in decrypting, the order, of course, is reversed: first one decrypts,
conjunction with properties of CBC chaining mode, that everything then one checks the HMAC, then one proceeds to use the data.
received before was not tampered with. For this reason, it is
important to check the IZP field as soon as possible, so that bad The HMAC MUST be checked as early as possible to avoid using and
data doesn't get propagated. See section 6.8 for more on the use of propagating corrupt data.
structured redundant messages with CBC mode. (Informally, if a
message is tampered with, the IZP field would decrypt to random In open mode, the HMAC fields are unused and have the same semantics
garbage and thus ensure the detection of tampering. If such a field as MBZ fields.
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 12, line 35 skipping to change at page 13, line 21
use the correct Accept value if it is going to use other values. The use the correct Accept value if it is going to use other values. The
message receiver MUST interpret all values of Accept other than these message receiver MUST interpret all values of Accept other than these
reserved values as 1. This way, other values are available for reserved values as 1. This way, other values are available for
future extensions. future extensions.
3.4. OWAMP-Control Commands 3.4. OWAMP-Control Commands
In authenticated or encrypted mode (which are identical as far as In authenticated or encrypted mode (which are identical as far as
OWAMP-Control is concerned, and only differ in OWAMP-Test) all OWAMP-Control is concerned, and only differ in OWAMP-Test) all
further communications are encrypted with the Session-key, using CBC further communications are encrypted with the Session-key, using CBC
mode. The client encrypts its stream using Client-IV. The server mode. The client encrypts everything it sends through the just-
encrypts its stream using Server-IV. established OWAMP-Control connection using stream encryption with
Client-IV as the IV. Correspondingly, the server encrypts its side
of the connection using Server-IV as the IV.
The IVs themselves are transmitted in cleartext. Encryption starts
with the block immediately following the block containing the IV.
The two streams (one going from the client to the server and one
going back) are encrypted independently, each with its own IV, but
using the same key (the session key).
The following commands are available for the client: Request-Session, The following commands are available for the client: Request-Session,
Start-Sessions, Stop-Sessions, and Fetch-Session. The command Start-Sessions, Stop-Sessions, and Fetch-Session. The command
Stop-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 the client sends the Start-Sessions command and until it both After the client sends the Start-Sessions command and until it both
sends and receives (in an unspecified order) the Stop-Sessions sends and receives (in an unspecified order) the Stop-Sessions
command, it is said to be conducting active measurements. Similarly, command, it is said to be conducting active measurements. Similarly,
skipping to change at page 14, line 47 skipping to change at page 15, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout, (8 octets) | | Timeout, (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor | | Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) | | MBZ (8 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is immediately followed by one or more schedule slot This is immediately followed by one or more schedule slot
descriptions (the number of schedule slots is specified in the descriptions (the number of schedule slots is specified in the
`Number of Schedule Slots' field above): `Number of Schedule Slots' field above):
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Type | | | Slot Type | |
+-+-+-+-+-+-+-+-+ MBZ (15 octets) | +-+-+-+-+-+-+-+-+ MBZ (7 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slot Parameter (Timestamp) | | Slot Parameter (Timestamp) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These are immediately followed by IZP: These are immediately followed by HMAC:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | HMAC (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.
skipping to change at page 15, line 51 skipping to change at page 16, line 51
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 IZP. It is used by of slot records that go between the two blocks of HMAC. It is used
the sender to determine when to send test packets (see next section). by the sender to determine when to send test 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 either the server or sent during this OWAMP-Test session (note that either the server or
the client can abort the session early). the client can abort the session early).
If Conf-Sender is not set, Sender Port is the UDP port from which If Conf-Sender is not set, Sender Port is the UDP port from which
OWAMP-Test packets will be sent. If Conf-Receiver is not set, OWAMP-Test packets will be sent. If Conf-Receiver is not set,
Receiver Port is the UDP port OWAMP-Test to which packets are Receiver Port is the UDP port OWAMP-Test to which packets are
requested to be sent. requested to be sent.
skipping to change at page 17, line 26 skipping to change at page 18, line 27
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | MBZ | Port | | Accept | MBZ | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (12 octets) | | MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this message, zero in the Accept field means that the server is In this message, zero in the Accept field means that the server is
willing to conduct the session. A non-zero value indicates rejection willing to conduct the session. A non-zero value indicates rejection
of the request. The full list of available Accept values is of the request. The full list of available Accept values is
described in Section 3.3, ``Values of the Accept Field''. described in Section 3.3, ``Values of the Accept Field''.
If the server rejects a Request-Session message, it SHOULD not close If the server rejects a Request-Session message, it SHOULD not close
the TCP connection. The client MAY close it if it receives negative the TCP connection. The client MAY close it if it receives negative
skipping to change at page 19, line 36 skipping to change at page 20, line 41
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 | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) | | MBZ (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The server MUST respond with an Start-Ack message (which SHOULD be The server MUST respond with an Start-Ack message (which SHOULD be
sent as quickly as possible). Start-Ack messages have the following sent as quickly as possible). Start-Ack messages have the following
format: format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | | | Accept | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| MBZ (15 octets) | | MBZ (15 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If Accept is non-zero, the Start-Sessions request was rejected; zero If Accept is non-zero, the Start-Sessions request was rejected; zero
means that the command was accepted. The full list of available means that the command was accepted. The full list of available
Accept values is described in Section 3.3, ``Values of the Accept Accept values is described in Section 3.3, ``Values of the Accept
Field''. The server MAY, and the client SHOULD, close the connection Field''. The server MAY, and the client SHOULD, close the connection
in the case of a rejection. in the case of a rejection.
skipping to change at page 21, line 41 skipping to change at page 22, line 41
| First Seqno Skipped | | First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped | | Last Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Skip Ranges MUST be in order. The last (possibly full, possibly Skip Ranges MUST be in order. The last (possibly full, possibly
incomplete) block (16 octets) of data MUST be padded with zeros, if incomplete) block (16 octets) of data MUST be padded with zeros, if
necessary. This ensures that the next session description record necessary. This ensures that the next session description record
starts on a block boundary. starts on a block boundary.
Finally, a single block (16 octets) of IZP is concatenated on the end Finally, a single block (16 octets) of HMAC is concatenated on the
to complete the Stop-Sessions message. end to complete the Stop-Sessions message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these records comprise one logical message: the Stop-Sessions All these records comprise one logical message: the Stop-Sessions
command. command.
Above, the first octet (3) indicates that this is the Stop-Sessions Above, the first octet (3) indicates that this is the Stop-Sessions
command. command.
skipping to change at page 24, line 22 skipping to change at page 25, line 22
| Begin Seq | | Begin Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Seq | | End Seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| SID (16 octets) | | SID (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | HMAC (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
skipping to change at page 25, line 17 skipping to change at page 26, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept | Finished | MBZ (2 octets) | | Accept | Finished | MBZ (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Seqno | | Next Seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Skip Ranges | | Number of Skip Ranges |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Records | | Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | HMAC (16 octets) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again, non-zero in the Accept field means a rejection of command. Again, non-zero in the Accept field means a rejection of command.
The server MUST specify zero for all remaining fields if Accept is The server MUST specify zero for all remaining fields if Accept is
non-zero. The client MUST ignore all remaining fields (except for the non-zero. The client MUST ignore all remaining fields (except for the
IZP) if Accept is non-zero. The full list of available Accept values HMAC) if Accept is non-zero. The full list of available Accept
is described in Section 3.3, ``Values of the Accept Field''. values is described in Section 3.3, ``Values of the Accept Field''.
Finished is non-zero if the OWAMP-Test session has terminated. Finished is non-zero if the OWAMP-Test session has terminated.
Next Seqno indicates the next sequence number that would have been Next Seqno indicates the next sequence number that would have been
sent from this send session. For completed sessions, this will equal sent from this send session. For completed sessions, this will equal
NumPackets from the Request-Session. This information is only NumPackets from the Request-Session. This information is only
available if the session has terminated. If Finished is zero, then available if the session has terminated. If Finished is zero, then
Next Seqno MUST be set to zero by the server. Next Seqno MUST be set to zero by the server.
Number of Skip Ranges indicates the number of holes that actually Number of Skip Ranges indicates the number of holes that actually
skipping to change at page 26, line 12 skipping to change at page 27, line 12
The OWAMP-Test session data consists of the following (concatenated): The OWAMP-Test session data consists of the following (concatenated):
+ A reproduction of the Request-Session command that was used to + A reproduction of the Request-Session command that was used to
start the session; it is modified so that actual sender and start the session; it is modified so that actual sender and
receiver port numbers that were used by the OWAMP-Test session receiver port numbers that were used by the OWAMP-Test session
always appear in the reproduction. always appear in the reproduction.
+ Zero or more (as specified) Skip Range descriptions. The last + Zero or more (as specified) Skip Range descriptions. The last
(possibly full, possibly incomplete) block (16 octets) of Skip (possibly full, possibly incomplete) block (16 octets) of Skip
Range descriptions is padded with zeros if necessary. (These Range descriptions is padded with zeros if necessary.
zeros are simple padding and should be distinguished from the 16
octets of IZP that follow.)
+ 16 octets of IZP. + 16 octets of HMAC.
+ Zero or more (as specified) packet records. The last (possibly + Zero or more (as specified) packet records. The last (possibly
full, possibly incomplete) block (16 octets) of data is padded full, possibly incomplete) block (16 octets) of data is padded
with zeros if necessary. (These zeros are simple padding and with zeros if necessary.
should be distinguished from the 16 octets of IZP that follow.)
+ 16 octets of IZP. + 16 octets of HMAC.
Skip Range descriptions are simply two sequence numbers that, Skip Range descriptions are simply two sequence numbers that,
together, indicate a range of packets that were not sent: together, indicate a range of packets that were not sent:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| First Seqno Skipped | | First Seqno Skipped |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Seqno Skipped | | Last Seqno Skipped |
skipping to change at page 29, line 11 skipping to change at page 30, line 11
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. OWAMP-Test Packet Format and Content
The sender sends the receiver a stream of packets with the schedule The sender sends the receiver a stream of packets with the schedule
specified in the Request-Session command. The sender SHOULD set the specified in the Request-Session command. The sender SHOULD set the
TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The TTL in IPv4 (or Hop Limit in IPv6) in the UDP packet to 255. The
format of the body of a UDP packet in the stream depends on the mode format of the body of a UDP packet in the stream depends on the mode
being used. being used.
For unauthenticated mode: For unauthenticated mode:
0 1 2 3 0 1 2 3
skipping to change at page 30, line 11 skipping to change at page 31, 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (12 octets) | | MBZ (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | | | Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| IZP (6 octets) | | MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Packet Padding . . Packet Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the timestamp is the same as in [RFC1305] and is as The format of the timestamp is the same as in [RFC1305] and is as
follows: first 32 bits represent the unsigned integer number of follows: first 32 bits represent the unsigned integer number of
skipping to change at page 31, line 22 skipping to change at page 32, line 31
integer as well. They are interpreted as follows: the error estimate integer as well. They are interpreted as follows: the error estimate
is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation is equal to Multiplier*2^(-32)*2^Scale (in seconds). [Notation
clarification: 2^Scale is two to the power of Scale.] Multiplier clarification: 2^Scale is two to the power of Scale.] Multiplier
MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be MUST NOT be set to zero. If Multiplier is zero, the packet SHOULD be
considered corrupt and discarded. considered corrupt and discarded.
Sequence numbers start with zero and are incremented by one for each Sequence numbers start with zero and are incremented by one for each
subsequent packet. subsequent packet.
The minimum data segment length is, therefore, 14 octets in The minimum data segment length is, therefore, 14 octets in
unauthenticated mode, and 32 octets in both authenticated mode and unauthenticated mode, and 48 octets in both authenticated mode and
encrypted modes. encrypted modes.
The OWAMP-Test packet layout is the same in authenticated and The OWAMP-Test packet layout is the same in authenticated and
encrypted modes. The encryption operations are, however, different. encrypted modes. The encryption and authentication operations are,
The difference is that in encrypted mode both the sequence number and however, different. The difference is that in encrypted mode both
the timestamp are encrypted to provide maximum data integrity the sequence number and the timestamp are protected to provide
protection while in authenticated mode the sequence number is maximum data confidentiality and integrity protection while in
encrypted and the timestamp is sent in clear text. Sending the authenticated mode the sequence number is protected while the
timestamp in clear text in authenticated mode allows one to reduce timestamp is sent in clear text. Sending the timestamp in clear text
the time between when a timestamp is obtained by a sender and when in authenticated mode allows one to reduce the time between when a
the packet is shipped out. In encrypted mode, the sender has to timestamp is obtained by a sender and when the packet is shipped out.
fetch the timestamp, encrypt it, and send it; in authenticated mode, In encrypted mode, the sender has to fetch the timestamp, encrypt it,
the middle step is removed, potentially improving accuracy (the and send it; in authenticated mode, the middle step is removed,
sequence number can be encrypted before the timestamp is fetched). potentially improving accuracy (the sequence number can be encrypted
and authenticated before the timestamp is fetched).
In authenticated mode, the first block (16 octets) of each packet is In authenticated mode, the first block (16 octets) of each packet is
encrypted using AES Electronic Cookbook (ECB) mode. encrypted using AES Electronic Cookbook (ECB) mode.
The key to use is obtained as follows: the 16-octet session The key to use is obtained as follows: the 16-octet session
identifier (SID) is encrypted with the same session key as is used identifier (SID) is encrypted with the same session key as is used
for the corresponding OWAMP-Control session (where it is used in a for the corresponding OWAMP-Control session (where it is used in a
different chaining mode); this is a single-block ECB encryption; its different chaining mode); this is a single-block ECB encryption; its
result is the key to use in encrypting (and decrypting) the packets result is the key to use in encrypting (and decrypting) the packets
of the particular OWAMP-Test session. of the particular OWAMP-Test session.
skipping to change at page 32, line 14 skipping to change at page 33, line 23
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 value with all bits equal to zero. 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 MAY only be set up once per session, not once per packet.
In unauthenticated mode, no encryption is applied. HMAC in OWAMP-Test only covers the part of the packet that is also
encrypted. So, in authenticated mode, HMAC covers the first block
(16 octets); in encrypted mode, HMAC covers two first blocks (32
octets). In OWAMP-Test HMAC is not encrypted (note that this is
different from OWAMP-Control, where encryption is stream mode is
used, so everything including the HMAC blocks ends up being
encrypted). The key for HMAC (authentication) is the same as the key
for AES (encryption).
In unauthenticated mode, no encryption or authentication is applied.
Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be Packet Padding in OWAMP-Test SHOULD be pseudo-random (it MUST be
generated independently of any other pseudo-random numbers mentioned generated independently of any other pseudo-random numbers mentioned
in this document). However, implementations MUST provide a in this document). However, implementations MUST provide a
configuration parameter, an option, or a different means of making configuration parameter, an option, or a different means of making
Packet Padding consist of all zeros. Packet Padding consist of all zeros.
The time elapsed between packets is computed according to the slot The time elapsed between packets is computed according to the slot
schedule as mentioned in Request-Session command description. At schedule as mentioned in Request-Session command description. At
that point, we skipped over the issue of computing exponentially that point, we skipped over the issue of computing exponentially
skipping to change at page 33, line 9 skipping to change at page 34, line 32
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 the first block (16 + In authenticated or encrypted mode, decrypt and authenticate as
octets) of the packet body. necessary (packets for which authentication fails MUST be
discarded).
+ Store the packet sequence number, send time, receive time, and the + Store the packet sequence number, send time, receive time, and the
TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for TTL for IPv4 (or Hop Limit for IPv6) from the packet IP header for
the results to be transferred. the results to be transferred.
+ Packets not received within the Timeout are considered lost. They + Packets not received within the Timeout are considered lost. They
are recorded with their true sequence number, presumed send time, are recorded with their true sequence number, presumed send time,
receive time value with all bits being zero, and TTL (or Hop receive time value with all bits being zero, and TTL (or Hop
Limit) of 255. Limit) of 255.
skipping to change at page 34, line 8 skipping to change at page 35, line 31
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 sequence number. 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, HMAC verification fails.
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
skipping to change at page 37, line 44 skipping to change at page 39, line 24
An additional design objective of the authenticated mode was to make An additional design objective of the authenticated mode was to make
it impossible for an attacker who cannot read traffic between OWAMP- it impossible for an attacker who cannot read traffic between OWAMP-
Test sender and receiver to tamper with test results in a fashion Test sender and receiver to tamper with test results in a fashion
that affects the measurements, but not other traffic. that affects the measurements, but not other traffic.
The goal of encrypted mode is quite different: to make it hard for a The goal of encrypted mode is quite different: to make it hard for a
party in the middle of the network to make results look `better' than party in the middle of the network to make results look `better' than
they should be. This is especially true if one of client and server they should be. This is especially true if one of client and server
does not coincide with either sender or receiver. does not coincide with either sender or receiver.
Encryption of OWAMP-Control using AES CBC mode with blocks of zeros Encryption of OWAMP-Control using AES CBC mode with blocks of HMAC
after each message aims to achieve two goals: (i) to provide secrecy after each message aims to achieve two goals: (i) to provide secrecy
of exchange; (ii) to provide authentication of each message. of exchange; (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.
skipping to change at page 38, line 37 skipping to change at page 40, line 14
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 42, line 40 skipping to change at page 44, line 8
If the need arises to make more extensive changes (perhaps replace If the need arises to make more extensive changes (perhaps replace
AES with a 256-bit-block cipher), this would be more difficult and AES with a 256-bit-block cipher), this would be more difficult and
would require changing the layout of the messages. However, the would require changing the layout of the messages. However, the
change can still be conducted within the framework of OWAMP change can still be conducted within the framework of OWAMP
extensibility using the Modes/Mode words. (The semantics of the new extensibility using the Modes/Mode words. (The semantics of the new
bits [or single bit, if the optimization described above is used] bits [or single bit, if the optimization described above is used]
would include the change to message layout as well as the change in would include the change to message layout as well as the change in
the cryptographic primitive.) the cryptographic primitive.)
6.8. (Not) Using Time as Salt Each of the bits in the Modes word can be used for an independent
extension. The extensions signaled by various bits are orthogonal:
for example, one bit might be allocated to change from AES-128 to
some other cipher, another bit might be allocated to add a protocol
feature (such as, e.g., support for measuring over multicast), yet
another might be allocated to change a key derivation function, etc.
The progression of versions is not a linear order, but rather partial
order. An implementation can implement any subset of these features
(of course, features can be made mandatory to implement---e.g., new
more secure ciphers if they are needed).
Should a cipher with a different key size, say a 256-bit key, become
needed, a new key derivation function for OWAMP-Test keys would also
be needed. The semantics of change in the cipher SHOULD then in the
future be tied to semantics of change in the key derivation function
(KDF). One KDF that might be considered for the purpose might be a
pseudo-random function (PRF) with appropriately sized output, such as
256 bits (perhaps HMAC-SHA256, if it is then still considered a
secure PRF), which could then be used to derive the OWAMP-Test
session keys from the OWAMP-Control session key by using the OWAMP-
Control session key as the HMAC key and the SID as HMAC message.
Note that the replacement scheme outlined above is trivially
susceptible to downgrade attacks: a malicious party in the middle can
flip modes bits as the mode is negotiated so that the oldest and
weakest mode supported by the two parties is used. If this is deemed
problematic at the time of cryptographic primitive replacement, the
scheme might be augmented with a measure to prevent such an attack
(by perhaps exchanging the modes again once a secure communications
channel is established, comparing the two sets of mode words, and
dropping the connection should they not match).
6.8. Long-term manually managed keys
OWAMP-Control uses long-term keys with manual management. These keys
are used to automatically negotiate session keys for each OWAMP-
Control session running in authenticated or encrypted mode. The
number of these keys managed by a server scales linearly with (and,
in fact, is equal to) the number of administratively different users
(perhaps particular humans, roles, or robots representing sites) that
need to connect to this server. Similarly, the number of different
manual keys managed by each client is the number of different servers
that the client needs to connect to. This use of manual long-term
keys is compliant with [BCP107].
6.9. (Not) Using Time as Salt
A natural idea is to use the current time as salt when deriving A natural idea is to use the current time as salt when deriving
session keys. Unfortunately, this appears too limiting. session keys. Unfortunately, this appears too limiting.
While OWAMP is often run on hosts with well-synchronized clocks, it While OWAMP is often run on hosts with well-synchronized clocks, it
is also possible to run it on hosts with clocks completely untrained. is also possible to run it on hosts with clocks completely untrained.
The delays obtained thusly are, of course, not directly usable; The delays obtained thusly are, of course, not directly usable;
however, some metrics, such as unidirectional loss, reordering, however, some metrics, such as unidirectional loss, reordering,
measures of congestion such as the median delay minus minimum, and measures of congestion such as the median delay minus minimum, and
many others are usable directly and immediately (and improve upon the many others are usable directly and immediately (and improve upon the
information that would have been provided by a round-trip information that would have been provided by a round-trip
measurement); further, even delay information can be useful with measurement); further, even delay information can be useful with
appropriate post-processing---indeed, one can even argue that running appropriate post-processing---indeed, one can even argue that running
the clocks free and post-processing the results of a mesh of the clocks free and post-processing the results of a mesh of
measurements will result in better accuracy, as more information is measurements will result in better accuracy, as more information is
available a posteriori and correlation of data from different hosts available a posteriori and correlation of data from different hosts
is possible in post-processing, but not with online clock training. is possible in post-processing, but not with online clock training.
Given this, time is not used as salt in key derivation. Given this, time is not used as salt in key derivation.
6.9. Required Properties of MD5 6.10. The Use of AES-CBC and HMAC
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
short piece of random data (the session key).
In this document we use cryptographic terminology of [MENEZES].
It has long been suspected, and has been conclusively shown recently
that MD5 is not a collision-resistant hash function. Since collision
resistance was one of design goals of MD5, this casts strong
suspicion on the other design goals of MD5, namely preimage
resistance and 2nd preimage resistance.
OWAMP does not rely on any of these properties.
The properties of MD5 that are necessary are as follows: (1) it is a
function that maps arbitrary length inputs into 128-bit outputs
[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
avalanche property], (3) many 128-bit values have preimages [almost
surjective], and (4) the visible special structure of
natural-language text possibly present in the passphrase is concealed
after application of the function. These are very weak requirements
that many functions satisfy. Something resembling CRC-128 would work
just as well.
We chose MD5 here because it has the required properties and is
widely implemented, understood, and documented. Alternatives would
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
Matyas-Meyer-Oseas, Davies-Meyer, or Miyaguchi-Preneel constructions;
we would probably gravitate towards the last one if a block-cipher-
based cryptographically secure hash function were required). Note
that option 1 would not have any cryptographically relevant
properties. We chose not to use it because of lack of
well-documented 128-bit checksums; this specification would incur an
unnecessary burden precisely defining one, providing test vectors,
etc., with no advantage over MD5. Option 2, SHA-1, belongs to the
MD4 family that appears to be under suspicion in light of recent
developments. To avoid creating an impression that any potential
future changes in the status of SHA-1 can affect the status of OWAMP
we chose not to use it. Option 3 would result in a hash function
that, with the current state of knowledge, would probably be one of
the most cryptographically sound. Our requirements 1-4 from the
preceding paragraph, however, do not call for a cryptographically
sound hash function. Just as with CRC-128, this specification would
need to define the hash function and provide test vectors (and
perhaps sample code); we see no advantage in this approach versus
using MD5. (Note that the performance advantages of MD5 are
irrelevant for this application, as the hash is computed on a
relatively short human-supplied string only once per OWAMP-Control
session, so if the Miyaguchi-Preneel construction were documented in
an RFC, we might just as well have used that.)
6.10. The Use of AES-CBC-MAC
OWAMP relies on AES-CBC-MAC for message authentication. Random IV OWAMP relies on AES-CBC for confidentiality and on HMAC-SHA1
choice is important for prevention of a codebook attack on the first truncated to 128 bits for message authentication. Random IV choice
block; it is unimportant for the purposes of CBC-MAC authentication is important for prevention of a codebook attack on the first block
(it should also be noted that, with its 128-bit block size, AES is (it should also be noted that, with its 128-bit block size, AES is
more resistant to codebook attacks than ciphers with shorter blocks; more resistant to codebook attacks than 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 HMAC MUST verify. It is crucial to check for this before using the
before using the message, otherwise existential forgery becomes message, otherwise existential forgery becomes possible. The
possible. The complete message for which IZP is decrypted to non- complete message for which HMAC verification fails MUST be discarded
zero MUST be discarded (for both short messages consisting of a few (for both short messages consisting of a few blocks and potentially
blocks and potentially long messages, such as a response to the long messages, such as a response to the Fetch-Session command); if
Fetch-Session command). such a message is part of OWAMP-Control, the connection MUST be
dropped.
Since OWAMP messages can have different numbers of blocks, the Since OWAMP messages can have different numbers of blocks, the
existential forgery attack described in example 9.62 of [MENEZES] existential forgery attack described in example 9.62 of [MENEZES]
becomes a concern. To prevent it (and to simplify implementation), becomes a concern. To prevent it (and to simplify implementation),
the length of any message becomes known after decrypting the first the length of any message becomes known after decrypting 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
skipping to change at page 45, line 19 skipping to change at page 46, line 28
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 IZP however, would be immediately discovered by the client when the HMAC
on the server's next message (acceptance or rejection of the on the server's next message (acceptance or rejection of the
connection) does not verify. connection) does not verify.
7. IANA Considerations 7. 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
skipping to change at page 51, line 27 skipping to change at page 52, line 41
SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds) SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)
SID = 0xfeed0feed1feed2feed3feed4feed5ab SID = 0xfeed0feed1feed2feed3feed4feed5ab
SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds) SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)
11. Normative References 11. Normative References
[AES] Advanced Encryption Standard (AES), [AES] Advanced Encryption Standard (AES),
http://csrc.nist.gov/encryption/aes/ http://csrc.nist.gov/encryption/aes/
[RFC1321] R. Rivest, `The MD5 Message-Digest Algorithm', RFC 1321, [BCP107] S. Bellovin, R. Housley, `Guidelines for Cryptographic Key
April 1992. Management', RFC 4107, June 2005.
[RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3', [RFC2026] S. Bradner, `The Internet Standards Process -- Revision 3',
RFC 2026, October 1996. RFC 2026, October 1996.
[RFC2104] H. Krawczyk, M. Bellare, R. Canetti, `HMAC: Keyed-Hashing
for Message Authentication', RFC2104, February 1997.
[RFC2119] S. Bradner, `Key words for use in RFCs to Indicate [RFC2119] S. Bradner, `Key words for use in RFCs to Indicate
Requirement Levels', RFC 2119, March 1997. Requirement Levels', RFC 2119, March 1997.
[RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for [RFC2330] V. Paxon, G. Almes, J. Mahdavi, M. Mathis, `Framework for
IP Performance Metrics' RFC 2330, May 1998. IP Performance Metrics' RFC 2330, May 1998.
[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, `Definition of [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, `Definition of
the Differentiated Services Field (DS Field) in the IPv4 and the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers', RFC 2474, December 1998. IPv6 Headers', RFC 2474, December 1998.
[RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay [RFC2679] G. Almes, S. Kalidindi, and M. Zekauskas, `A One-way Delay
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.
[RFC2898] B. Kaliski, `PKCS #5: Password-Based Cryptography
Specification, Version 2.0', RFC 2898, September 2000.
12. Informative References 12. Informative References
[APAN-OWAMP] Z. Shu and K. Kobayashi, HOTS: An OWAMP-Compliant [APAN-OWAMP] Z. Shu and K. Kobayashi, HOTS: An OWAMP-Compliant
Hardware Packet Timestamper, In Proceedings of PAM 2005, Hardware Packet Timestamper, In Proceedings of PAM 2005,
http://www.pam2005.org/PDF/34310360.pdf 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.
skipping to change at page 54, line 38 skipping to change at page 56, line 12
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 (2005). This document is subject Copyright (C) The Internet Society (2006). 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, Mark Allman, Jari Arkko, Hamid We would like to thank Guy Almes, Mark Allman, Jari Arkko, Hamid
Asgari, Steven Van den Berghe, Eric Boyd, Robert Cole, Joan Asgari, Steven Van den Berghe, Eric Boyd, Robert Cole, Joan
Cucchiara, Stephen Donnelly, Susan Evett, Sam Hartman, Kaynam Cucchiara, Stephen Donnelly, Susan Evett, Sam Hartman, Kaynam
Hedayat, Petri Helenius, Scott Hollenbeck, Russ Housley, Kitamura Hedayat, Petri Helenius, Scott Hollenbeck, Russ Housley, Kitamura
Yasuichi, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah, Yasuichi, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah,
Allison Mankin, Al Morton, Attila Pasztor, Randy Presuhn, Matthew Allison Mankin, Al Morton, Attila Pasztor, Randy Presuhn, Matthew
Roughan, Andy Scherrer, Henk Uijterwaal, and Sam Weiler for their Roughan, Andy Scherrer, Henk Uijterwaal, and Sam Weiler for their
comments, suggestions, reviews, helpful discussion and proof-reading. comments, suggestions, reviews, helpful discussion and proof-reading.
Expiration date: May 2006 Expiration date: August 2006
 End of changes. 57 change blocks. 
211 lines changed or deleted 236 lines changed or added

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