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/