draft-ietf-ippm-owdp-reqs-05.txt		draft-ietf-ippm-owdp-reqs-06.txt
	Network Working Group Stanislav Shalunov		Network Working Group Stanislav Shalunov
	Internet Draft Benjamin Teitelbaum		Internet Draft Benjamin Teitelbaum
	Expiration Date: August 2003 Internet2		Expiration Date: December 2003 Internet2
	February 2003		June 2003
	A One-way Active Measurement Protocol Requirements		A One-way Active Measurement Protocol Requirements
	<draft-ietf-ippm-owdp-reqs-05.txt>		<draft-ietf-ippm-owdp-reqs-06.txt>
	1. Status of this Memo		1. Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 7, line 7		skipping to change at page 7, line 7
	measurement nodes requires O(N^2) total resources, such as storage		measurement nodes requires O(N^2) total resources, such as storage
	space and link capacity), OWAMP itself should not exaggerate the		space and link capacity), OWAMP itself should not exaggerate the
	problem or make it impossible (where it is in principle possible) to		problem or make it impossible (where it is in principle possible) to
	design other architectures that are free of scalability deficiencies.		design other architectures that are free of scalability deficiencies.
	It is the protocol user's responsibility to decide how to use the		It is the protocol user's responsibility to decide how to use the
	protocol and which measurements to conduct.		protocol and which measurements to conduct.
	6. Security Considerations		6. Security Considerations
	6.1. Modes of Operation		6.1. Authentication
	Since the protocol(s) will be used in widely varying circumstances
	using widely varying equipment, it is necessary be able to support
	varying degrees of security modes of operation. The parameters to be
	considered include: confidentiality, data origin authentication,
	integrity and replay protection.
	It should be possible to operate in a completely "open" mode, where		It should be possible to authenticate peers to each other using a
	no cryptographic security mechanisms are used. We call this		user ID and a shared secret. It should be infeasible for any
	"unauthenticated mode". In this mode, care must be taken to avoid		external party without knowledge of the shared secret to obtain any
	denial-of-service attacks.		information about it by observing, initiating, or modifying protocol
			transactions.
	It should also be possible to operate in a mode where all security		It should also be infeasible for such party to use any information
	mechanisms are enabled and security objectives are realized to the		obtained by observing, modifying or initiating protocol transactions
	fullest extent possible. We call this "encrypted mode".		to impersonate (other) valid users.
	Since timestamp encryption takes a certain amount of time, which may		6.2. Authorization
	be hard to predict on some devices (with a time-sharing OS), a mode
	should be provided that is similar to encrypted mode, but in which
	timestamps are not encrypted. In this mode, all security properties
	of the encrypted mode that can be retained without timestamp
	encryption should be present. We call this "authenticated mode".
	To make implementation more manageable, the number of other options		Authorization shall normally be performed on the basis of the
	and modes should be kept to the absolute practical minimum. Where		authenticated identity (such as username) and the specification shall
	choosing a single mechanism for achieving anything related to		require all implementations to support such a mode of authorization.
	security is possible, such choice should be made at specification		Different identities (or classes of identities) can have different
	phase and be put into the standard.		testing priviliges. The use of authorization for arriving at
			specific policy decisions (such as whether to allow a specific test
			with a specific source and destination and with a given test send
			schedule -- which would determine the average network capacity
			utilization -- at a given time) is up to the users.
	6.2. Being Hard to Interfere with by Applying Special Treatment to		6.3. Being Hard to Interfere with by Applying Special Treatment to
	Measurement Packets		Measurement Packets
	The design of the protocol should make it possible to run sessions		The design of the protocol should make it possible to run sessions
	that would make it very difficult for any intermediate party to make		that would make it very difficult for any intermediate party to make
	results appear better than they would be if no interference was		results appear better than they would be if no interference was
	attempted.		attempted.
	This is different from cryptographic assurance of data integrity,		This is different from cryptographic assurance of data integrity,
	because one can manipulate the results without changing any data in		because one can manipulate the results without changing any data in
	the packets. For example, if OWAMP-Test packets are easy to identify		the packets. For example, if OWAMP-Test packets are easy to identify
	(e.g., they all come to a well-known port number), an intermediate		(e.g., they all come to a well-known port number), an intermediate
	party might place OWAMP-Test traffic into a priority queue at a		party might place OWAMP-Test traffic into a priority queue at a
	congested link thus ensuring that the results of the measurement		congested link thus ensuring that the results of the measurement
	appear better than what would be experienced by other traffic. It		appear better than what would be experienced by other traffic. It
	should not be easy for intermediate parties to identify OWAMP-Test		should not be easy for intermediate parties to identify OWAMP-Test
	packets (just as it should not be easy for restaurants to identify		packets (just as it should not be easy for restaurants to identify
	restaurant critics).		restaurant critics).
	6.3. Secrecy/Confidentiality		6.4. Secrecy/Confidentiality
	It should be possible to make it infeasible for any outside party		It should be possible to make it infeasible for any outside party
	without knowledge of the shared secret being used to learn what		without knowledge of the shared secret being used to learn what
	information is exchanged using OWAMP-Control by inspecting an OWAMP-		information is exchanged using OWAMP-Control by inspecting an OWAMP-
	Control stream or actively modifying it.		Control stream or actively modifying it.
	(It is recognized that some information will inevitably leak from the		(It is recognized that some information will inevitably leak from the
	mere fact of communication and from the presence and timing of		mere fact of communication and from the presence and timing of
	concurrent and subsequent OWAMP-Test traffic.)		concurrent and subsequent OWAMP-Test traffic.)
	6.4. Authentication
	It should be possible to authenticate peers to each other using a
	user ID and a shared secret. It should be infeasible for any
	external party without knowledge of the shared secret to obtain any
	information about it by observing, initiating, or modifying protocol
	transactions.
	It should also be infeasible for such party to use any information
	obtained by observing, modifying or initiating protocol transactions
	to impersonate (other) valid users.
	6.5. Integrity		6.5. Integrity
	So that it is possible to detect any interference during a		So that it is possible to detect any interference during a
	conversation (other than the detention of some messages), facility		conversation (other than the detention of some messages), facility
	must be provided to authenticate each message of the OWAMP-Control		must be provided to authenticate each message of the OWAMP-Control
	protocol, its attribution to a given session, and its exact placement		protocol, its attribution to a given session, and its exact placement
	in the sequence of control protocol exchanges.		in the sequence of control protocol exchanges.
	It must also be possible to authenticate each message of the test		It must also be possible to authenticate each message of the test
	protocol and its attribution to a specific session, so that		protocol and its attribution to a specific session, so that
	skipping to change at page 9, line 29		skipping to change at page 9, line 9
	on its way to the recipient. There's no way such delay can be		on its way to the recipient. There's no way such delay can be
	reliably distinguished from naturally occuring delay by the		reliably distinguished from naturally occuring delay by the
	recipient.		recipient.
	OWAMP-Test should measure the network as it was. Note, however, that		OWAMP-Test should measure the network as it was. Note, however, that
	this does not prevent the data from being sanitized at a later stage		this does not prevent the data from being sanitized at a later stage
	of processing, analysis, or consumption. Some sanity checks (those		of processing, analysis, or consumption. Some sanity checks (those
	that are deemed reliable and erring on the side of inclusion) should		that are deemed reliable and erring on the side of inclusion) should
	be performed by OWAMP-Test recipient immediately.		be performed by OWAMP-Test recipient immediately.
			6.7. Modes of Operation
			Since the protocol(s) will be used in widely varying circumstances
			using widely varying equipment, it is necessary be able to support
			varying degrees of security modes of operation. The parameters to be
			considered include: confidentiality, data origin authentication,
			integrity and replay protection.
			It should also be possible to operate in a mode where all security
			mechanisms are enabled and security objectives are realized to the
			fullest extent possible. We call this "encrypted mode".
			Since timestamp encryption takes a certain amount of time, which may
			be hard to predict on some devices (with a time-sharing OS), a mode
			should be provided that is similar to encrypted mode, but in which
			timestamps are not encrypted. In this mode, all security properties
			of the encrypted mode that can be retained without timestamp
			encryption should be present. We call this "authenticated mode".
			It should be possible to operate in a completely "open" mode, where
			no cryptographic security mechanisms are used. We call this
			"unauthenticated mode". In this mode, mandatory-to-use mechanisms
			must be specified that prevent the use of the protocol for network
			capacity starvation denial-of-service attacks (e.g., only sending
			test data back to the client that requested them to be sent with the
			request delivered over a TCP connection).
			To make implementation more manageable, the number of other options
			and modes should be kept to the absolute practical minimum. Where
			choosing a single mechanism for achieving anything related to
			security is possible, such choice should be made at specification
			phase and be put into the standard.
	7. IANA Considerations		7. IANA Considerations
	Relevant IANA considerations will be placed into the protocol		Relevant IANA considerations will be placed into the protocol
	specification document itself, and not into the requirements		specification document itself, and not into the requirements
	document.		document.
	8. Normative References		8. Normative References
	[RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for		[RFC2330] V. Paxson, G. Almes, J. Mahdavi, M. Mathis, "Framework for
	IP Performance Metrics", RFC 2330, May 1998.		IP Performance Metrics", RFC 2330, May 1998.
	skipping to change at page 10, line 26		skipping to change at page 10, line 41
	http://www.ripe.net/test-traffic/		http://www.ripe.net/test-traffic/
	[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/		[SURVEYOR] Surveyor Home Page, http://www.advanced.org/surveyor/
	10. Authors' Addresses		10. Authors' Addresses
	Stanislav Shalunov <shalunov@internet2.edu>		Stanislav Shalunov <shalunov@internet2.edu>
	Benjamin Teitelbaum <ben@internet2.edu>		Benjamin Teitelbaum <ben@internet2.edu>
	Expiration date: August 2003		Expiration date: December 2003
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/