draft-ietf-ippm-owdp-13.txt   draft-ietf-ippm-owdp-14.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: June 2005 Anatoly Karp
Jeff W. Boote Jeff W. Boote
Matthew J. Zekauskas Matthew J. Zekauskas
Internet2 Internet2
December 2004 December 2004
A One-way Active Measurement Protocol (OWAMP) A One-way Active Measurement Protocol (OWAMP)
<draft-ietf-ippm-owdp-13.txt> <draft-ietf-ippm-owdp-14.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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) . . . . . . . . . . . . . 10 3.2. Integrity Zero Padding (IZP) . . . . . . . . . . . . . 11
3.3. Values of the Accept Field . . . . . . . . . . . . . . 11 3.3. Values of the Accept Field . . . . . . . . . . . . . . 11
3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 11 3.4. OWAMP-Control Commands . . . . . . . . . . . . . . . . 12
3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 12 3.5. Creating Test Sessions . . . . . . . . . . . . . . . . 12
3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 17 3.6. Send Schedules . . . . . . . . . . . . . . . . . . . . 17
3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 18 3.7. Starting Test Sessions . . . . . . . . . . . . . . . . 18
3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19 3.8. Stop-Sessions . . . . . . . . . . . . . . . . . . . . 19
3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 22 3.9. Fetch-Session . . . . . . . . . . . . . . . . . . . . 22
4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 27 4. OWAMP-Test . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 27 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . 27
4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 27 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . 27
4.1.2. Packet Format and Content . . . . . . . . . . . . 28 4.1.2. Packet Format and Content . . . . . . . . . . . . 28
4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 31 4.2. Receiver Behavior . . . . . . . . . . . . . . . . . . 31
skipping to change at page 3, line 28 skipping to change at page 3, line 28
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
OWAMP servers that would make measurement of one-way delay as OWAMP servers that would make measurement of one-way delay as
commonplace as measurement of round-trip time using an ICMP-based commonplace as measurement of round-trip time using an ICMP-based
tool like ping. tool like ping.
Additional design goals of OWAMP include being hard to detect and Additional design goals of OWAMP include: being hard to detect and
manipulate, security, logical separation of control and test manipulate, security, logical separation of control and test
functionality, and support for small test packets. (Being hard to functionality, and support for small test packets. (Being hard to
detect makes interference with measurements more difficult for detect makes interference with measurements more difficult for
intermediaries in the middle of the network.) intermediaries in the middle of the network.)
OWAMP test traffic is hard to detect because it is simply a stream of OWAMP test traffic is hard to detect because it is simply a stream of
UDP packets from and to negotiated port numbers, with potentially UDP packets from and to negotiated port numbers, with potentially
nothing static in the packets (size is negotiated, as well). OWAMP nothing static in the packets (size is negotiated, as well). OWAMP
also supports an encrypted mode that further obscures the traffic, at also supports an encrypted mode that further obscures the traffic, at
the same time making it impossible to alter timestamps undetectably. the same time making it impossible to alter timestamps undetectably.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
All multi-octet quantities defined in this document are represented All multi-octet quantities defined in this document are represented
as unsigned integers in network byte order unless specified as unsigned integers in network byte order unless specified
otherwise. otherwise.
3. OWAMP-Control 3. OWAMP-Control
Each type of OWAMP-Control message has a fixed length. The recipient Each type of OWAMP-Control message has a fixed length. The recipient
will know the full length of a message after examining the first 16 will know the full length of a message after examining the first 16
octets of it. No message is shorter than 16 octets. octets of it. No message is shorter than 16 octets.
If the full message is not received within 30 minutes after it is An implementation SHOULD expunge unused state to prevent denial-of-
expected, connection SHOULD be dropped. service attacks, or unbounded memory usage, on the server. For
example, if the full control message is not received within some
number of minutes after it is expected, the TCP connection associated
with the OWAMP-Control session SHOULD be dropped. In absence of
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. The server responds with a server greeting:
0 1 2 3 0 1 2 3
skipping to change at page 8, line 39 skipping to change at page 8, line 43
. 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. The first
29 bits of Mode MUST be zero. A server MUST ignore the values of the 29 bits of Mode MUST be zero. A server MUST ignore the values of the
first 29 bits. first 29 bits. If zero Mode bits are set by the client, the client
indicates that it will not continue with the session; in this case,
the client and the server SHOULD close the TCP connection associated
with the OWAMP-Control session.
In unauthenticated mode, Username, Token, and Client-IV are unused. In unauthenticated mode, Username, Token, and Client-IV are unused.
Otherwise, Username is a 16-octet indicator that tells the server Otherwise, Username is a 16-octet indicator that tells the server
which shared secret the client wishes to use to authenticate or which shared secret the client wishes to use to authenticate or
encrypt, while Token is the concatenation of a 16-octet challenge and encrypt, while Token is the concatenation of a 16-octet challenge and
a 16-octet Session-key, encrypted using the AES (Advanced Encryption a 16-octet Session-key, encrypted using the AES (Advanced Encryption
Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be Standard) [AES] in Cipher Block Chaining (CBC). Encryption MUST be
performed using an Initialization Vector (IV) of zero and a key value performed using an Initialization Vector (IV) of zero and a key value
that is the shared secret associated with Username. (Both the server that is the shared secret associated with Username. (Both the server
and the client use the same mappings from user names to secret keys. and the client use the same mappings from user names to secret keys.
The server, being prepared to conduct sessions with more than one The server, being prepared to conduct sessions with more than one
client, uses user names to choose the appropriate secret key; a client, uses user names 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 being the typical low-entropy that secret keys, rather than having the low entropy typical of
passwords, are suitable for use as AES keys.) The shared secret will passwords, are suitable for use as AES keys.)
typically be provided as a passphrase; in this case, the MD5 sum
[RFC1321] of the passphrase (without possible newline character(s) at The shared secret MUST be generated with sufficient entropy not to
the end of the passphrase) MUST be used as a key for encryption by reduce the security of the underlying cipher. Typical methods of its
the client and decryption by the server (the passphrase also MUST NOT generation might be from a random number generator [RFC1750] or from
contain newlines in the middle). the hash of a passphrase. If the shared secret is provided as a
passphrase (typical for the case of interactive tools) then the MD5
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. Client-IV merely needs to be the security of the underlying cipher [RFC1750]. Client-IV merely
unique (i.e., it MUST never be repeated for different sessions using needs to be unique (i.e., it MUST never be repeated for different
the same secret key; a simple way to achieve that without the use of sessions using the same secret key; a simple way to achieve that
cumbersome state is to generate the Client-IV strings using a without the use of cumbersome state is to generate the Client-IV
cryptographically secure pseudo-random number source: if this is strings using a cryptographically secure pseudo-random number source:
done, the first repetition is unlikely to occur before 2^64 sessions if this is done, the first repetition is unlikely to occur before
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 message:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| MBZ (15 octets) | | MBZ (15 octets) |
| | | |
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
skipping to change at page 10, line 16 skipping to change at page 10, line 42
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 the ``Values of full list of available Accept values is described in Section 3.3,
the Accept Field'' section. ``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 Uptime is a timestamp representing the time when the current
instantiation of the server started operating. (For example, in a instantiation of the server started operating. (For example, in a
multi-user general purpose operating system (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 Uptime SHOULD be set to a string of zeros. In authenticated and
encrypted modes, Uptime is encrypted as described in the next encrypted modes, Uptime is encrypted as described in the next
section, unless Accept is non-zero. (Authenticated and encrypted mode section, unless Accept is non-zero. (Authenticated and encrypted mode
cannot be entered unless the control connection can be initialized.) cannot be entered unless the control connection can be initialized.)
Timestamp format is described in ``Sender Behavior'' section below. Timestamp format is described in Section 4.1.2. The same
The same instantiation of the server SHOULD report the same exact instantiation of the server SHOULD report the same exact Uptime value
Uptime value to each client in each session. 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
skipping to change at page 15, line 7 skipping to change at page 15, line 7
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 IZP. It is used by
the sender to determine when to send test packets (see next section). 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 both server and client sent during this OWAMP-Test session (note that either the server or
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.
The Sender Address and Receiver Address fields contain, respectively, The Sender Address and Receiver Address fields contain, respectively,
the sender and receiver addresses of the end points of the Internet the sender and receiver addresses of the end points of the Internet
path over which an OWAMP test session is requested. path over which an OWAMP test session is requested.
skipping to change at page 16, line 33 skipping to change at page 16, line 33
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (12 octets) | | IZP (12 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this message, zero in the Accept field means that the server is In this message, zero in the Accept field means that the server is
willing to conduct the session. A 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 the ``Values of the Accept Field'' section. 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
response to the Request-Session message. response to the Request-Session message.
The meaning of Port in the response depends on the values of The meaning of Port in the response depends on the values of
Conf-Sender and Conf-Receiver in the query that solicited the Conf-Sender and Conf-Receiver in the query that solicited the
response. If both were set, the Port field is unused. If only response. If both were set, the Port field is unused. If only
Conf-Sender was set, Port is the port from which to expect OWAMP-Test Conf-Sender was set, Port is the port from which to expect OWAMP-Test
packets. If only Conf-Receiver was set, Port is the port to which packets. If only Conf-Receiver was set, Port is the port to which
skipping to change at page 19, line 22 skipping to change at page 19, line 22
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IZP (16 octets) | | IZP (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 the ``Values of the Accept Field'' Accept values is described in Section 3.3, ``Values of the Accept
section. The server MAY, and the client SHOULD, close the connection Field''. The server MAY, and the client SHOULD, close the connection
in the case of a rejection. in the case of a rejection.
The server SHOULD start all OWAMP-Test streams immediately after it The server SHOULD start all OWAMP-Test streams immediately after it
sends the response or immediately after their specified start times, sends the response or immediately after their specified start times,
whichever is later. If the client represents a Sender, the client whichever is later. If the client represents a Sender, the client
SHOULD start its OWAMP-Test streams immediately after it sees the SHOULD start its OWAMP-Test streams immediately after it sees the
Start-Ack response from the Server (if the Start-Sessions command was Start-Ack response from the Server (if the Start-Sessions command was
accepted) or immediately after their specified start times, whichever accepted) or immediately after their specified start times, whichever
is later. See more on OWAMP-Test sender behavior in a separate is later. See more on OWAMP-Test sender behavior in a separate
section below. section below.
skipping to change at page 21, line 11 skipping to change at page 21, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All these records comprise one logical message: the Stop-Sessions All these records comprise one logical message: the Stop-Sessions
command. command.
Above, the first octet (3) indicates that this is the Stop-Sessions Above, the first octet (3) indicates that this is the Stop-Sessions
command. command.
Non-zero Accept values indicate a failure of some sort. Zero values Non-zero Accept values indicate a failure of some sort. Zero values
indicate normal (but possibly premature) completion. The full list indicate normal (but possibly premature) completion. The full list
of available Accept values is described in the ``Values of the Accept of available Accept values is described in Section 3.3, ``Values of
Field'' section. the Accept Field''.
If Accept had a non-zero value (from either party), results of all If Accept had a non-zero value (from either party), results of all
OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be OWAMP-Test sessions spawned by this OWAMP-Control session SHOULD be
considered invalid, even if a Fetch-Session with SID from this considered invalid, even if a Fetch-Session with SID from this
session works for a different OWAMP-Control session. If Accept was session works for a different OWAMP-Control session. If Accept was
not transmitted at all (for whatever reason, including the TCP not transmitted at all (for whatever reason, including the TCP
connection used for OWAMP-Control breaking), the results of all connection used for OWAMP-Control breaking), the results of all
OWAMP-Test sessions spawned by this OWAMP-control session MAY be OWAMP-Test sessions spawned by this OWAMP-control session MAY be
considered invalid. considered invalid.
skipping to change at page 24, line 26 skipping to change at page 24, line 26
| | | |
| IZP (16 octets) | | IZP (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 IZP) if Accept is non-zero. The full list of available Accept values
is described in the ``Values of the Accept Field'' section. 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 33, line 41 skipping to change at page 33, line 41
almost verbatim quotation from [KNUTH], p.133. almost verbatim quotation from [KNUTH], p.133.
Algorithm S: Given a real positive number 'mu', produce an Algorithm S: Given a real positive number 'mu', produce an
exponential random variate with mean 'mu'. exponential random variate with mean 'mu'.
First, the constants First, the constants
Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11 Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!), 1 <= k <= 11
are computed in advance. The exact values which MUST be used by all are computed in advance. The exact values which MUST be used by all
implementations are given in the reference code (see Appendix A). implementations are given in the next section. This is necessary to
This is necessary to insure that exactly the same pseudo-random insure that exactly the same pseudo-random sequences are produced by
sequences are produced by all implementations. all implementations.
S1. [Get U and shift.] Generate a 32-bit uniform random binary S1. [Get U and shift.] Generate a 32-bit uniform random binary
fraction fraction
U = (.b0 b1 b2 ... b31) [note the binary point] U = (.b0 b1 b2 ... b31) [note the binary point]
Locate the first zero bit b_j, and shift off the leading (j+1) bits, Locate the first zero bit b_j, and shift off the leading (j+1) bits,
setting U <- (.b_{j+1} ... b31) setting U <- (.b_{j+1} ... b31)
Note: In the rare case that the zero has not been found, it is Note: In the rare case that the zero has not been found, it is
prescribed that the algorithm return (mu*32*ln2). prescribed that the algorithm return (mu*32*ln2).
skipping to change at page 34, line 38 skipping to change at page 34, line 38
u_int64_t u; u_int64_t u;
u |--> (double)u / (2**32) u |--> (double)u / (2**32)
The algorithm produces a sequence of such u_int64_t integers that, The algorithm produces a sequence of such u_int64_t integers that,
for any given value of SID, is guaranteed to be the same on any for any given value of SID, is guaranteed to be the same on any
implementation. implementation.
We specify that the u_int64_t representations of the first 11 values We specify that the u_int64_t representations of the first 11 values
of the Q array in the high-level algorithm be as follows: of the Q array in the high-level algorithm MUST be as follows:
#1 0xB17217F8, #1 0xB17217F8,
#2 0xEEF193F7, #2 0xEEF193F7,
#3 0xFD271862, #3 0xFD271862,
#4 0xFF9D6DD0, #4 0xFF9D6DD0,
#5 0xFFF4CFD0, #5 0xFFF4CFD0,
#6 0xFFFEE819, #6 0xFFFEE819,
#7 0xFFFFE7FF, #7 0xFFFFE7FF,
#8 0xFFFFFE2B, #8 0xFFFFFE2B,
#9 0xFFFFFFE0, #9 0xFFFFFFE0,
skipping to change at page 36, line 29 skipping to change at page 36, line 29
U4. [Do output] Output the i_th quartet of octets from s starting U4. [Do output] Output the i_th quartet of octets from s starting
from high-order octets, converted to native byte order and from high-order octets, converted to native byte order and
represented as OWPNum64 value (as in 3.b). represented as OWPNum64 value (as in 3.b).
U5. [Loop] Go to step U2. U5. [Loop] Go to step U2.
6. Security Considerations 6. Security Considerations
6.1. Introduction 6.1. Introduction
The goal of authenticated mode to let one passphrase-protect service The goal of authenticated mode to let one passphrase-protect the
provided by a particular OWAMP-Control server. One can imagine a service provided by a particular OWAMP-Control server. One can
variety of circumstances where this could be useful. Authenticated imagine a variety of circumstances where this could be useful.
mode is designed to prohibit theft of service. Authenticated mode is designed to prohibit theft of service.
An additional design objective of the authenticated mode was to make An additional design objective of the authenticated mode was to make
it impossible for an attacker who cannot read traffic between OWAMP- it impossible for an attacker who cannot read traffic between OWAMP-
Test sender and receiver to tamper with test results in a fashion Test sender and receiver to tamper with test results in a fashion
that affects the measurements, but not other traffic. that affects the measurements, but not other traffic.
The goal of encrypted mode is quite different: to make it hard for a The goal of encrypted mode is quite different: to make it hard for a
party in the middle of the network to make results look `better' than party in the middle of the network to make results look `better' than
they should be. This is especially true if one of client and server they should be. This is especially true if one of client and server
does not coincide with either sender or receiver. does not coincide with either sender or receiver.
skipping to change at page 38, line 27 skipping to change at page 38, line 27
otherwise). For authenticated sessions, the administrator who otherwise). For authenticated sessions, the administrator who
configures the service should be able to decide the exact policy, but configures the service should be able to decide the exact policy, but
useful policy mechanisms that MAY be implemented are the ability to useful policy mechanisms that MAY be implemented are the ability to
automatically reclaim memory when the data is retrieved and the automatically reclaim memory when the data is retrieved and the
ability to reclaim memory after a certain configurable (based on user ability to reclaim memory after a certain configurable (based on user
class) period of time passes after the OWAMP-Test session terminates. class) period of time passes after the OWAMP-Test session terminates.
6.6. Use of Cryptographic Primitives in OWAMP 6.6. Use of Cryptographic Primitives in OWAMP
At an early stage in designing the protocol, we considered using At an early stage in designing the protocol, we considered using
Transport Layer Security (TLS) and IPsec as cryptographic security Transport Layer Security (TLS) [RFC2246, RFC3546] and IPsec [RFC2401]
mechanisms for OWAMP. The disadvantages of those are as follows (not as cryptographic security mechanisms for OWAMP. The disadvantages of
an exhaustive list): those are as follows (not an exhaustive list):
Regarding TLS: Regarding TLS:
+ While TLS could be used to secure TCP-based OWAMP-Control, but + While TLS could be used to secure TCP-based OWAMP-Control, but
difficult to use to secure UDP-based OWAMP-Test: OWAMP-Test difficult to use to secure UDP-based OWAMP-Test: OWAMP-Test
packets, if lost, are not resent, so packets have to be packets, if lost, are not resent, so packets have to be
(optionally) encrypted and authenticated while retaining (optionally) encrypted and authenticated while retaining
individual usability. Stream-based TLS is not conducive of this. individual usability. Stream-based TLS is not conducive of this.
+ Dealing with streams, does not authenticate individual messages + Dealing with streams, does not authenticate individual messages
skipping to change at page 39, line 33 skipping to change at page 39, line 33
IPsec (for comparison purposes with encryption above layer 4, SSH IPsec (for comparison purposes with encryption above layer 4, SSH
use is at 2-4% and HTTPS use is at 0.2-0.6%). It is desirable to use is at 2-4% and HTTPS use is at 0.2-0.6%). It is desirable to
be able to deploy OWAMP on as large of a number of different be able to deploy OWAMP on as large of a number of different
platforms as possible. platforms as possible.
+ The deployment problems of a protocol dependent on IPsec would be + The deployment problems of a protocol dependent on IPsec would be
especially acute in the case of lightweight embedded devices. especially acute in the case of lightweight embedded devices.
Ethernet switches, DSL ``modems,'' and other such devices mostly Ethernet switches, DSL ``modems,'' and other such devices mostly
do not support IPsec. do not support IPsec.
+ The API for manipulation IPsec from an application is currently + The API for 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 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. 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).
skipping to change at page 42, line 17 skipping to change at page 42, line 17
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.
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. The rest of this appendix only serves for implementations (see sections 5.1 and 5.2). This appendix only
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).
** If a variate with some mean mu other than 1 is desired, the output ** If a variate with some mean mu other than 1 is desired, the output
** of this algorithm can be multiplied by mu according to the rules ** of this algorithm can be multiplied by mu according to the rules
** of arithmetic we described. ** of arithmetic we described.
** Assume that a 16-octet 'seed' has been initialized ** Assume that a 16-octet 'seed' has been initialized
** (as the shared secret in OWAMP, for example) ** (as the shared secret in OWAMP, for example)
skipping to change at page 49, line 24 skipping to change at page 49, line 24
[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',
January 1999.
[RFC2401] S. Kent, R. Atkinson, `Security Architecture for the
Internet Protocol', November 1998.
[RFC3546] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T.
Wright, `Transport Layer Security (TLS) Extensions', June 2003.
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
 End of changes. 

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