draft-ietf-mboned-mtrace-v2-23.txt		draft-ietf-mboned-mtrace-v2-24.txt
	MBONED Working Group H. Asaeda		MBONED Working Group H. Asaeda
	Internet-Draft NICT		Internet-Draft NICT
	Intended status: Standards Track K. Meyer		Intended status: Standards Track K. Meyer
	Expires: October 4, 2018		Expires: December 21, 2018
	W. Lee, Ed.		W. Lee, Ed.
	April 2, 2018		June 19, 2018
	Mtrace Version 2: Traceroute Facility for IP Multicast		Mtrace Version 2: Traceroute Facility for IP Multicast
	draft-ietf-mboned-mtrace-v2-23		draft-ietf-mboned-mtrace-v2-24
	Abstract		Abstract
	This document describes the IP multicast traceroute facility, named		This document describes the IP multicast traceroute facility, named
	Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2		Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2
	requires special implementations on the part of routers. This		requires special implementations on the part of routers. This
	specification describes the required functionality in multicast		specification describes the required functionality in multicast
	routers, as well as how an Mtrace2 client invokes a query and		routers, as well as how an Mtrace2 client invokes a query and
	receives a reply.		receives a reply.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on October 4, 2018.		This Internet-Draft will expire on December 21, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 34 ¶		skipping to change at page 3, line 34 ¶
	6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 31		6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 31
	6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 32		6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 32
	7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 32		7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 32
	7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 32		7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 32
	7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 32		7.2. TTL or Hop Limit Problems . . . . . . . . . . . . . . . . 32
	7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 32		7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 32
	7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 33		7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 33
	7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 33		7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 33
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 33		8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 33
	8.2. "Mtrace2 TLV Types" registry . . . . . . . . . . . . . . 34		8.2. "Mtrace2 TLV Types" Registry . . . . . . . . . . . . . . 34
	8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 34		8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 34
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 34		9. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 34		9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 34
	9.2. Filtering of Clients and Peers . . . . . . . . . . . . . 34		9.2. Filtering of Clients and Peers . . . . . . . . . . . . . 34
	9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 34		9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 35
	9.4. Characteristics of Multicast Channel . . . . . . . . . . 35		9.4. Characteristics of Multicast Channel . . . . . . . . . . 35
	9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 35		9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 35
	9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 35		9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 35
	9.7. Specific Security Concerns . . . . . . . . . . . . . . . 35		9.7. Specific Security Concerns . . . . . . . . . . . . . . . 36
	9.7.1. Request and Response Bombardment . . . . . . . . . . 35		9.7.1. Request and Response Bombardment . . . . . . . . . . 36
	9.7.2. Amplification Attack . . . . . . . . . . . . . . . . 35		9.7.2. Amplification Attack . . . . . . . . . . . . . . . . 36
	9.7.3. Leaking of Confidential Topology Details . . . . . . 35		9.7.3. Leaking of Confidential Topology Details . . . . . . 36
	9.7.4. Delivery of False Information . . . . . . . . . . . . 36		9.7.4. Delivery of False Information (Forged Reply Messages) 36
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
	11.1. Normative References . . . . . . . . . . . . . . . . . . 36		11.1. Normative References . . . . . . . . . . . . . . . . . . 37
	11.2. Informative References . . . . . . . . . . . . . . . . . 37		11.2. Informative References . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	Given a multicast distribution tree, tracing hop-by-hop downstream		Given a multicast distribution tree, tracing hop-by-hop downstream
	from a multicast source to a given multicast receiver is difficult		from a multicast source to a given multicast receiver is difficult
	because there is no efficient and deterministic way to determine the		because there is no efficient and deterministic way to determine the
	branch of the multicast routing tree on which that receiver lies. On		branch of the multicast routing tree on which that receiver lies. On
	the other hand, walking up the tree from a receiver to a source is		the other hand, walking up the tree from a receiver to a source is
	easy, as most existing multicast routing protocols know the upstream		easy, as most existing multicast routing protocols know the upstream
	router for each source. Tracing from a receiver to a source can		router for each source. Tracing from a receiver to a source can
	skipping to change at page 28, line 31 ¶		skipping to change at page 28, line 31 ¶
	An Mtrace2 client could send an initial Query messages with a large #		An Mtrace2 client could send an initial Query messages with a large #
	Hops, in order to try to trace the full path. If this attempt fails,		Hops, in order to try to trace the full path. If this attempt fails,
	one strategy is to perform a linear search (as the traditional		one strategy is to perform a linear search (as the traditional
	unicast traceroute program does); set the # Hops field to 1 and try		unicast traceroute program does); set the # Hops field to 1 and try
	to get a Reply, then 2, and so on. If no Reply is received at a		to get a Reply, then 2, and so on. If no Reply is received at a
	certain hop, this hop is identified as the probable cause of		certain hop, this hop is identified as the probable cause of
	forwarding failures on the path. Nevertheless, the sender may		forwarding failures on the path. Nevertheless, the sender may
	attempt to continue tracing past the non-responding hop by further		attempt to continue tracing past the non-responding hop by further
	increasing the hop count in the hopes that further hops may respond.		increasing the hop count in the hopes that further hops may respond.
	Each of these attempts should be initiated only after the previous		Each of these attempts MUST NOT be initiated before the previous
	attempt has terminated either because of successful reception of a		attempt has terminated either because of successful reception of a
	Reply or because the [Mtrace Reply Timeout] timeout has occurred.		Reply or because the [Mtrace Reply Timeout] timeout has occurred.
	See also Section 5.6 on receiving the results of a trace.		See also Section 5.6 on receiving the results of a trace.
	5.3. Collecting Statistics		5.3. Collecting Statistics
	After a client has determined that it has traced the whole path or as		After a client has determined that it has traced the whole path or as
	much as it can expect to (see Section 5.8), it might collect		much as it can expect to (see Section 5.8), it might collect
	statistics by waiting a short time and performing a second trace. If		statistics by waiting a short time and performing a second trace. If
	skipping to change at page 34, line 5 ¶		skipping to change at page 34, line 5 ¶
	8.1. "Mtrace2 Forwarding Codes" Registry		8.1. "Mtrace2 Forwarding Codes" Registry
	This is an integer in the range 0-255. Assignment of a Forwarding		This is an integer in the range 0-255. Assignment of a Forwarding
	Code requires specification of a value and a name for the Forwarding		Code requires specification of a value and a name for the Forwarding
	Code. Initial values for the forwarding codes are given in the table		Code. Initial values for the forwarding codes are given in the table
	at the end of Section 3.2.4. Additional values (specific to IPv6)		at the end of Section 3.2.4. Additional values (specific to IPv6)
	may also be specified at the end of Section 3.2.5. Any additions to		may also be specified at the end of Section 3.2.5. Any additions to
	this registry are required to fully describe the conditions under		this registry are required to fully describe the conditions under
	which the new Forwarding Code is used.		which the new Forwarding Code is used.
	8.2. "Mtrace2 TLV Types" registry		8.2. "Mtrace2 TLV Types" Registry
	Assignment of a TLV Type requires specification of an integer value		Assignment of a TLV Type requires specification of an integer value
	"Code" in the range 0-255 and a name ("Type"). Initial values for		"Code" in the range 0-255 and a name ("Type"). Initial values for
	the TLV Types are given in the table at the beginning of Section 3.2.		the TLV Types are given in the table at the beginning of Section 3.2.
	8.3. UDP Destination Port		8.3. UDP Destination Port
	IANA has assigned UDP user port 33435 (mtrace) for use by this		IANA has assigned UDP user port 33435 (mtrace) for use by this
	protocol as the Mtrace2 UDP destination port.		protocol as the Mtrace2 UDP destination port.
	skipping to change at page 34, line 33 ¶		skipping to change at page 34, line 33 ¶
	An Mtrace2 header includes three addresses, source address, multicast		An Mtrace2 header includes three addresses, source address, multicast
	address, and Mtrace2 client address. These addresses MUST be		address, and Mtrace2 client address. These addresses MUST be
	congruent with the definition defined in Section 3.2.1 and forwarding		congruent with the definition defined in Section 3.2.1 and forwarding
	Mtrace2 messages having invalid addresses MUST be prohibited. For		Mtrace2 messages having invalid addresses MUST be prohibited. For
	instance, if Mtrace2 Client Address specified in an Mtrace2 header is		instance, if Mtrace2 Client Address specified in an Mtrace2 header is
	a multicast address, then a router that receives the Mtrace2 message		a multicast address, then a router that receives the Mtrace2 message
	MUST silently discard it.		MUST silently discard it.
	9.2. Filtering of Clients and Peers		9.2. Filtering of Clients and Peers
	A router MUST support a mechanism to filter out Queries from clients		A router MUST support an access control list (ACL) mechanism to
	and Requests from peer router addresses that are unauthorized or that		filter out Queries from clients and Requests from peer router
	are beyond a specified administrative boundary. This filtering		addresses that are unauthorized or that are beyond a specified
	could, for example, be specified via a list of allowed/disallowed		administrative boundary. This filtering could, for example, be
	client and peer addresses or subnets for the Mtrace2 protocol port.		specified via a list of allowed/disallowed client and peer addresses
	If a Query or Request is received from an unauthorized address or one		or subnets for the Mtrace2 protocol port. If a Query or Request is
	beyond the specified administrative boundary, the Query/Request MUST		received from an unauthorized address or one beyond the specified
	NOT be processed. The router MAY, however, perform rate limited		administrative boundary, the Query/Request MUST NOT be processed.
	logging of such events.		The router MAY, however, perform rate limited logging of such events.
			The required use of ACLs on the participating routers minimizes the
			possible methods for introduction of spoofed Query/Request packets
			that would otherwise enable DoS amplification attacks targeting an
			authorized "query" host. The ACLs provide this protection by
			allowing Query messages from an authorized host address to be
			received only by the router(s) connected to that host, and only on
			the interface to which that host is attached. For protection against
			spoofed Request messages, the ACLs allow requests only from a
			directly connected peer and allow these messages to be received only
			on the interface to which that peer is attached.
			Note that the following vulnerabilities cannot be covered by the ACL
			methods described here. These methods can, nevertheless, prevent
			attacks launched from outside the boundaries of a given network as
			well as from any hosts within the network that are not on the same
			LAN as an intended authorized query client.
			o A server/router "B" other than the server/router "A" that actually
			"owns" a given IP address could, if it is connected to the same
			LAN, send an Mtrace2 Query or Request with the source address set
			to the address for server/router "A". This is not a significant
			threat, however, if only trusted servers and routers are connected
			to that LAN.
			o A malicious application running on a trusted server or router
			could send packets that might cause an amplification problem. It
			is beyond the scope of this document to protect against a DoS
			attack launched from the same host that is the target of the
			attack or from another "on path" host, but this is not a likely
			threat scenario. In addition, routers on the path MAY rate-limit
			the packets as specified in Section 9.5 and Section 9.6.
	9.3. Topology Discovery		9.3. Topology Discovery
	Mtrace2 can be used to discover any actively-used topology. If your		Mtrace2 can be used to discover any actively-used topology. If your
	network topology is a secret, Mtrace2 may be restricted at the border		network topology is a secret, Mtrace2 may be restricted at the border
	of your domain, using the ADMIN_PROHIB forwarding code.		of your domain, using the ADMIN_PROHIB forwarding code.
	9.4. Characteristics of Multicast Channel		9.4. Characteristics of Multicast Channel
	Mtrace2 can be used to discover what sources are sending to what		Mtrace2 can be used to discover what sources are sending to what
	skipping to change at page 36, line 7 ¶		skipping to change at page 36, line 34 ¶
	Section 9.2.		Section 9.2.
	9.7.3. Leaking of Confidential Topology Details		9.7.3. Leaking of Confidential Topology Details
	Mtrace2 Queries are a potential mechanism for obtaining confidential		Mtrace2 Queries are a potential mechanism for obtaining confidential
	topology information for a targeted network. Section 9.2 and		topology information for a targeted network. Section 9.2 and
	Section 9.4 describe required and optional methods for ensuring that		Section 9.4 describe required and optional methods for ensuring that
	information delivered with Mtrace2 messages is not disseminated to		information delivered with Mtrace2 messages is not disseminated to
	unauthorized hosts.		unauthorized hosts.
	9.7.4. Delivery of False Information		9.7.4. Delivery of False Information (Forged Reply Messages)
	Forged Reply messages could potentially provide a host with invalid		Forged Reply messages could potentially provide a host with invalid
	or incorrect topology information. This threat is mitigated by the		or incorrect topology information. They could also provide invalid
			or incorrect information regarding multicast traffic statistics,
			multicast stream propagation delay between hops, multicast and
			unicast protocols in use between hops and other information used for
			analyzing multicast traffic patterns and for troubleshooting
			multicast traffic problems. This threat is mitigated by the
	following factors:		following factors:
	o The required filtering of permissible source addresses specified		o The required filtering of permissible source addresses specified
	in Section 9.2 eliminates the origination of forged Replies from		in Section 9.2 eliminates the origination of forged Replies from
	addresses that have not been authorized to send Mtrace2 messages		addresses that have not been authorized to send Mtrace2 messages
	to routers on a given network.		to routers on a given network. This mechanism can block forged
			Reply messages sent from any "off path" source.
	o To forge a Reply, the sender would need to somehow know the		o To forge a Reply, the sender would need to somehow know (or guess)
	associated two byte query ID for an extant Query and the		the associated two byte Query ID for an extant Query and the
	dynamically allocated source port number.		dynamically allocated source port number. Because "off path"
			sources can be blocked by ACLs, the scope of this threat is
			limited to "on path" attackers.
			o The use of encryption between the source of a Query and the
			endpoint of the trace would provide a method to protect the values
			of the Query ID and the dynamically allocated client (source) port
			(see Section 3.2.1). These are the values needed to create a
			forged Reply message that would pass validity checks at the
			querying client. This type of cryptographic protection is not
			practical, however, because the primary reason for executing an
			Mtrace2 is that the destination endpoint (and path to that
			endpoint) are not known by the querying client. While it is not
			practical to provide cryptographic protection between a client and
			the Mtrace2 endpoints (destinations), it may be possible to
			prevent forged responses from "off path" nodes attached to any
			Mtrace2 transit LAN by devising a scheme to encrypt the critical
			portions of an Mtrace2 message between each valid sender/receiver
			pair at each hop to be used for multicast/mtrace transit. This
			type of node/application authentication and authorization is,
			however, out of the scope of this document.
	10. Acknowledgements		10. Acknowledgements
	This specification started largely as a transcription of Van		This specification started largely as a transcription of Van
	Jacobson's slides from the 30th IETF, and the implementation in		Jacobson's slides from the 30th IETF, and the implementation in
	mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve		mrouted 3.3 by Ajit Thyagarajan. Van's original slides credit Steve
	Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original		Casner, Steve Deering, Dino Farinacci and Deb Agrawal. The original
	multicast traceroute client, mtrace (version 1), has been implemented		multicast traceroute client, mtrace (version 1), has been implemented
	by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the		by Ajit Thyagarajan, Steve Casner and Bill Fenner. The idea of the
	"S" bit to allow statistics for a source subnet is due to Tom		"S" bit to allow statistics for a source subnet is due to Tom
End of changes. 14 change blocks.
	33 lines changed or deleted		91 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/