draft-ietf-mboned-ssmping-04.txt		draft-ietf-mboned-ssmping-05.txt
	Network Working Group S. Venaas		Network Working Group S. Venaas
	Internet-Draft UNINETT		Internet-Draft UNINETT
	Intended status: Informational February 21, 2008		Intended status: Informational September 18, 2008
	Expires: August 24, 2008		Expires: March 22, 2009
	Multicast Ping Protocol		Multicast Ping Protocol
	draft-ietf-mboned-ssmping-04		draft-ietf-mboned-ssmping-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 24, 2008.		This Internet-Draft will expire on March 22, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The Multicast Ping Protocol specified in this document allows for		The Multicast Ping Protocol specified in this document allows for
	checking whether an endpoint can receive multicast, both Source-		checking whether an endpoint can receive multicast, both Source-
	Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also		Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also
	be used to obtain additional multicast related information like		be used to obtain additional multicast related information like
	multicast tree setup time etc. This protocol is based on an		multicast tree setup time etc. This protocol is based on an
	implementation of tools called ssmping and asmping.		implementation of tools called ssmping and asmping.
	skipping to change at page 2, line 23		skipping to change at page 2, line 17
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4		3. Protocol specification . . . . . . . . . . . . . . . . . . . . 4
	3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6		3.2. Defined Options . . . . . . . . . . . . . . . . . . . . . 6
	4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Message types and options . . . . . . . . . . . . . . . . . . 11		5. Message types and options . . . . . . . . . . . . . . . . . . 11
	6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12		6. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . . 12
	7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14		7. Server Behaviour . . . . . . . . . . . . . . . . . . . . . . . 14
	8. Recommendations for Implementers . . . . . . . . . . . . . . . 15		8. Recommendations for Implementers . . . . . . . . . . . . . . . 15
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 16		11. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 17		12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	12.2. Informative References . . . . . . . . . . . . . . . . . . 17		12.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 18		Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
	skipping to change at page 6, line 24		skipping to change at page 6, line 24
	Version, type 0		Version, type 0
	Length MUST be 1. This option MUST always be included in all		Length MUST be 1. This option MUST always be included in all
	messages, and the value MUST be set to 2 (in decimal). Note		messages, and the value MUST be set to 2 (in decimal). Note
	that there are older implementations of ssmping that only		that there are older implementations of ssmping that only
	partly follow this specification. They can be regarded as		partly follow this specification. They can be regarded as
	version 1 and do not use this option. If a server receives a		version 1 and do not use this option. If a server receives a
	message with a version other than 2 (or missing), the server		message with a version other than 2 (or missing), the server
	SHOULD (unless it supports the particular version) send a		SHOULD (unless it supports the particular version) send a
	Response message back with version set to 2. Client ID and		Response message back with version set to 2. Client ID and
	Sequence Number options should be echoed if present. It SHOULD		Sequence Number options SHOULD be echoed if present. It SHOULD
	not include any other options. A client receiving a response		not include any other options. A client receiving a response
	with a version other than 2, MUST (unless it supports the		with a version other than 2, MUST (unless it supports the
	particular version), stop sending requests to the server.		particular version), stop sending requests to the server.
	Client ID, type 1		Client ID, type 1
	Length MUST be non-zero. A client SHOULD always include this		Length MUST be non-zero. A client SHOULD always include this
	option in all messages (both Init and Request). The client may		option in all messages (both Init and Request). The client may
	use any value it likes to be able to detect whether a reply is		use any value it likes to be able to detect whether a reply is
	a reply to its Init/Request or not. A server should treat this		a reply to its Init/Request or not. A server should treat this
	as opaque data, and simply leave it unchanged in the reply		as opaque data, and MUST echo this option back in the reply if
	(both Server Response and Reply). The value might be a process		present (both Server Response and Reply). The value might be a
	ID, perhaps process ID combined with an IP address because it		process ID, perhaps process ID combined with an IP address
	may receive multicast responses to queries from other clients.		because it may receive multicast responses to queries from
	It is left to the client implementer how to make use of this		other clients. It is left to the client implementer how to
	option.		make use of this option.
	Sequence Number, type 2		Sequence Number, type 2
	Length MUST be 4. A client MUST always include this in Request		Length MUST be 4. A client MUST always include this in Request
	messages and MUST NOT include it in Init messages. A server		messages and MUST NOT include it in Init messages. A server
	replying to a Request message MUST copy it into the Reply (or		replying to a Request message MUST copy it into the Reply (or
	Server Response message on error). This contains a 32 bit		Server Response message on error). This contains a 32 bit
	sequence number. The values would typically start at 1 and		sequence number. The values would typically start at 1 and
	increase by one for each request in a sequence.		increase by one for each request in a sequence.
	skipping to change at page 7, line 16		skipping to change at page 7, line 16
	Length MUST be 8 bytes. A client SHOULD include this in		Length MUST be 8 bytes. A client SHOULD include this in
	Request messages and MUST NOT include it in Init messages. A		Request messages and MUST NOT include it in Init messages. A
	server replying to a Request message MUST copy it into the		server replying to a Request message MUST copy it into the
	Reply. The timestamp specifies the time when the Request		Reply. The timestamp specifies the time when the Request
	message is sent. The first 4 bytes specify the number of		message is sent. The first 4 bytes specify the number of
	seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4		seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4
	bytes specify the number of microseconds since the last second		bytes specify the number of microseconds since the last second
	since the Epoch.		since the Epoch.
	Multicast group, type 4		Multicast Group, type 4
	Length MUST be greater than 2. It MAY be used in Server		Length MUST be greater than 2. It MAY be used in Server
	Response messages to tell the client what group to use in		Response messages to tell the client what group to use in
	subsequent Request messages. It MUST be used in Request		subsequent Request messages. It MUST be used in Request
	messages to tell the server what group address to respond to		messages to tell the server what group address to respond to
	(this group would typically be previously obtained in a Server		(this group would typically be previously obtained in a Server
	Response message). It MUST be used in Reply messages (copied		Response message). It MUST be used in Reply messages (copied
	from the Request message). It MUST NOT be used in Init		from the Request message). It MUST NOT be used in Init
	messages. The format of the option value is as below.		messages. The format of the option value is as below.
	skipping to change at page 10, line 7		skipping to change at page 10, line 7
	'wildcard'. The group address need only contain enough octets		'wildcard'. The group address need only contain enough octets
	to cover the prefix length bits (i.e., the group address would		to cover the prefix length bits (i.e., the group address would
	have to be 3 octets long if the prefix length is 17-24, and		have to be 3 octets long if the prefix length is 17-24, and
	there need be no group address for the wildcard with prefix		there need be no group address for the wildcard with prefix
	length 0). Any bits past the prefix length MUST be ignored.		length 0). Any bits past the prefix length MUST be ignored.
	For IPv4, the option value length will be 4-7, while for IPv6,		For IPv4, the option value length will be 4-7, while for IPv6,
	it will be 4-19, and for the wildcard, it will be 3.		it will be 4-19, and for the wildcard, it will be 3.
	Session ID, type 11		Session ID, type 11
	Length MUST be non-zero. A server MAY include this in Server		Length MUST be non-zero. A server SHOULD include this in
	Response and Reply messages. If a client receives this option		Server Response and Reply messages. If a client receives this
	in a message, the client MUST echo the Session ID option in		option in a message, the client MUST echo the Session ID option
	subsequent Request messages, with the exact same value, until		in subsequent Request messages, with the exact same value,
	the next message is received from the server. If the next		until the next message is received from the server. If the
	message from the server has no Session ID or a new Session ID		next message from the server has no Session ID or a new Session
	value, the client should do the same, either not use the		ID value, the client should do the same, either not use the
	Session ID, or use the new value. The Session ID may help the		Session ID, or use the new value. The Session ID may help the
	server in keeping track of clients and possibly manage per		server in keeping track of clients and possibly manage per
	client state. It is left to the server implementer to decide		client state. The value of a new Session ID should be chosen
	whether it is useful and how to make use of it.		pseudo randomly so that it is hard to predict. This can be
			used to prevent spoofing of the source address of Request
			messages, see the Security Considerations for details.
	Server Timestamp, type 12		Server Timestamp, type 12
	Length MUST be 8 bytes. A server supporting this option,		Length MUST be 8 bytes. A server supporting this option,
	SHOULD include it in Reply messages, if requested by the		SHOULD include it in Reply messages, if requested by the
	client. The timestamp specifies the time when the Reply		client. The timestamp specifies the time when the Reply
	message is sent. The first 4 bytes specify the number of		message is sent. The first 4 bytes specify the number of
	seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4		seconds since the Epoch (0000 UTC Jan 1, 1970). The next 4
	bytes specify the number of microseconds since the last second		bytes specify the number of microseconds since the last second
	since the Epoch.		since the Epoch.
	skipping to change at page 13, line 9		skipping to change at page 13, line 14
	the unicast address of the server. It can then send an Init message		the unicast address of the server. It can then send an Init message
	with a prefix option containing the desired address family and zero		with a prefix option containing the desired address family and zero
	prefix length (wildcard entry). The server is then free to decide		prefix length (wildcard entry). The server is then free to decide
	which group, from the specified family, it should return. A client		which group, from the specified family, it should return. A client
	may also allow a user to specify group address(es) or prefix(es) (for		may also allow a user to specify group address(es) or prefix(es) (for
	IPv6, the user may only be required to specify a scope or an RP		IPv6, the user may only be required to specify a scope or an RP
	address, from which the client can construct the desired prefix,		address, from which the client can construct the desired prefix,
	possibly embedded-RP). From this the client can specify one or more		possibly embedded-RP). From this the client can specify one or more
	prefix options in an Init message to tell the server which address it		prefix options in an Init message to tell the server which address it
	would prefer. If the user specifies a group address, that can be		would prefer. If the user specifies a group address, that can be
	encoded as a prefix of maximal length (e.g. 32 for IPv4). The prefix		encoded as a prefix of maximal length (e.g., 32 for IPv4). The
	options are in prioritised order, i.e., the client should put the		prefix options are in prioritised order, i.e., the client should put
	most preferred prefix first.		the most preferred prefix first.
	If the client receives a Server Response message containing a group		If the client receives a Server Response message containing a group
	address it can start sending Request messages, see the next		address it can start sending Request messages, see the next
	paragraph. If there is no group address option, it would typically		paragraph. If there is no group address option, it would typically
	exit with an error message. The server may have included some prefix		exit with an error message. The server may have included some prefix
	options in the Server Response. The client may use this to provide		options in the Server Response. The client may use this to provide
	the user some feedback on what prefixes or scopes are available.		the user some feedback on what prefixes or scopes are available.
	Assuming the client got a group address in a Server Response, it can		Assuming the client got a group address in a Server Response, it can
	start pinging. Before it does that, it should let the user know		start pinging. Before it does that, it should let the user know
	skipping to change at page 14, line 16		skipping to change at page 14, line 21
	7. Server Behaviour		7. Server Behaviour
	We will consider how a typical server using the above protocol would		We will consider how a typical server using the above protocol would
	behave. First we consider how to respond to Init messages. If the		behave. First we consider how to respond to Init messages. If the
	Init message contains prefix options, the server should look at them		Init message contains prefix options, the server should look at them
	in order and see if it can assign a multicast address from the given		in order and see if it can assign a multicast address from the given
	prefix. The server would be configured, possibly have a default,		prefix. The server would be configured, possibly have a default,
	specifying which groups it can offer. It may have a large pool just		specifying which groups it can offer. It may have a large pool just
	picking a group at random, possibly choose a group based on hashing		picking a group at random, possibly choose a group based on hashing
	of the clients IP address or identifier, or just use a fixed group.		of the client's IP address or identifier, or just use a fixed group.
	It is left to the server to decide whether it should allow the same		A server could possibly decide whether to include site scoped group
	address to be used simultaneously by multiple clients. If the server		ranges based on the client's IP address. It is left to the server to
	finds a suitable group address, it returns this in a group option in		decide whether it should allow the same address to be used
	a Server Response message. The server may additionally include a		simultaneously by multiple clients. If the server finds a suitable
	Session ID. This may help the server if it is to keep some state,		group address, it returns this in a group option in a Server Response
	for instance for making sure the client uses the group it got		message. The server should additionally include a Session ID. This
	assigned. A good Session ID would be a random byte string that is		may help the server if it is to keep some state, for instance for
	hard to predict. If the server cannot find a suitable group address,		making sure the client uses the group it got assigned. A good
	or if there were no prefixes in the Init message, it may send a		Session ID would be a pseudo random byte string that is hard to
	Server Response message containing prefix options listing what		predict. If the server cannot find a suitable group address, or if
	prefixes may be available to the client. Finally, if the Init		there were no prefixes in the Init message, it may send a Server
	message requests the Server Information option, it should include		Response message containing prefix options listing what prefixes may
	that.		be available to the client. Finally, if the Init message requests
			the Server Information option, it should include that.
	When the server receives a Request message, it may first check that		When the server receives a Request message, it may first check that
	the group address and Session ID (if provided) are valid. If the		the group address and Session ID (if provided) are valid. If the
	server is satisfied, it will send a unicast Reply message back to the		server is satisfied, it will send a unicast Reply message back to the
	client, and also a multicast Reply message to the group address. The		client, and also a multicast Reply message to the group address. The
	Reply messages contain the exact options and in the same order, as in		Reply messages contain the exact options and in the same order, as in
	the Request, and after that the server adds a TTL option and		the Request, and after that the server adds a TTL option and
	additional options if needed. E.g., it may add a timestamp if		additional options if needed. E.g., it may add a timestamp if
	requested by the client. If the server is not happy with the Request		requested by the client. If the server is not happy with the Request
	(bad group address or Session ID, request is too large etc), it may		(bad group address or Session ID, request is too large etc), it may
	skipping to change at page 15, line 30		skipping to change at page 15, line 35
	freedom for implementers. In this section we present some		freedom for implementers. In this section we present some
	recommendations.		recommendations.
	Server administrators should be able to configure one or multiple		Server administrators should be able to configure one or multiple
	group prefixes in a server implementation. When deploying servers on		group prefixes in a server implementation. When deploying servers on
	the Internet and in other environments, the server administrator		the Internet and in other environments, the server administrator
	should be able to restrict the server to respond to only a few		should be able to restrict the server to respond to only a few
	multicast groups which should not be currently used by multicast		multicast groups which should not be currently used by multicast
	applications. A server implementation should also provide		applications. A server implementation should also provide
	flexibility for an administrator to apply various policies to provide		flexibility for an administrator to apply various policies to provide
	one or multiple group prefixes to specific clients. One such policy		one or multiple group prefixes to specific clients, e.g., site scoped
	could be to use the client IP address if it can be trusted.		addresses for clients that are inside the site. Clients could be
			identified by their IP address provided that clients are required to
			send Init messages, and they receive an unpredictable Session ID.
	Servers must perform rate limiting, to guard against this protocol		Servers must perform rate limiting, to guard against this protocol
	being used for DoS attacks. By default, clients should send at most		being used for DoS attacks. By default, clients should send at most
	one request per second, and servers should perform rate limiting if a		one request per second, and servers should perform rate limiting if a
	client sends more frequent requests. Server implementations should		client sends more frequent requests. Server implementations should
	provide administrative control of which client IP addresses to serve,		provide administrative control of which client IP addresses to serve,
	and may also allow certain clients to perform more rapid requests.		and may also allow certain clients to perform more rapid requests.
	Implementers of applications/tools using this protocol should		Implementers of applications/tools using this protocol should
	consider the UDP guidelines [6], in particular if clients are to		consider the UDP guidelines [6], in particular if clients are to
	send, or servers are to accept, requests at rates exceeding one per		send, or servers are to accept, requests at rates exceeding one per
	skipping to change at page 16, line 44		skipping to change at page 17, line 5
	There are some security issues to consider. One is that a host may		There are some security issues to consider. One is that a host may
	send a request with an IP source address of another host, and make an		send a request with an IP source address of another host, and make an
	arbitrary multicast ping server on the Internet send packets to this		arbitrary multicast ping server on the Internet send packets to this
	other host. This behaviour is fairly harmless. The worst case is if		other host. This behaviour is fairly harmless. The worst case is if
	the host receiving the unicast replies also happen to be joined to		the host receiving the unicast replies also happen to be joined to
	the multicast group used. In this case, there would be an		the multicast group used. In this case, there would be an
	amplification effect where the host receives twice as many replies as		amplification effect where the host receives twice as many replies as
	there are requests sent.		there are requests sent.
			In order to help prevent spoofing, a server SHOULD require the client
			to send an Init message, and return an unpredictable Session ID in
			the response. The ID should be associated with the IP address and
			have a limited lifetime. The server SHOULD then only respond to
			Request messages that have a valid Session ID associated with the
			source IP address of the Request.
	Server implementations should allow administrators to restrict which		Server implementations should allow administrators to restrict which
	groups a server responds to, and also perform rate limiting. This is		groups a server responds to, and also perform rate limiting. This is
	discussed in Section 8).		discussed in Section 8).
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	skipping to change at page 17, line 24		skipping to change at page 17, line 37
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	[4] "IANA, Address Family Numbers",		[4] "IANA, Address Family Numbers",
	<http://www.iana.org/assignments/address-family-numbers>.		<http://www.iana.org/assignments/address-family-numbers>.
	12.2. Informative References		12.2. Informative References
	[5] "ssmping implementation",		[5] "ssmping implementation",
	<http://www.venaas.no/multicast/ssmping/>.		<http://www.venaas.no/multicast/ssmping/>.
	[6] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for		[6] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
	Application Designers", draft-ietf-tsvwg-udp-guidelines-05 (work		Application Designers", draft-ietf-tsvwg-udp-guidelines-10 (work
	in progress), February 2008.		in progress), August 2008.
	Author's Address		Author's Address
	Stig Venaas		Stig Venaas
	UNINETT		UNINETT
	Trondheim NO-7465		Trondheim NO-7465
	Norway		Norway
	Email: venaas@uninett.no		Email: venaas@uninett.no
	skipping to change at page 18, line 44		skipping to change at line 813
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 15 change blocks.
	48 lines changed or deleted		56 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/