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/