Internet DRAFT - draft-ballardie-shared-mtrace
draft-ballardie-shared-mtrace
INTERNET-DRAFT A. Ballardie
Consultant
October 1997.
''shared-mtrace'': A Multicast 'traceroute' facility for Shared Trees
Status of this Memo
This document is an Internet Draft. Internet Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work-
ing documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other In-
ternet Draft.
Abstract
''mtrace'' [1] is a very useful tool for diagnosing IP multicast rout-
ing problems, such as multicast routing loops and misconfigured mul-
ticast routers, associated with source-rooted RPF-based distribution
trees.
For ''mtrace'' to be useful in a shared tree environment (e.g. PIM [2],
CBT [3], GUM [4]) its behaviour must be modified. This draft speci-
fies that behaviour, which is sufficiently general to be applicable
to all shared tree types and operating modes. A new ''wildcard'' mode
of behaviour is also described, which allows a trace of a complete
shared tree. Authentication is recommended in this mode because of
its potential as a vehicle for denial of service attacks.
It is intended that this draft become a document of the Mbone Deploy-
ment (mboned) working group of the IETF. Therefore, comments are so-
licited and should be sent to mboned's mailing list <mboned@network-
services.uoregon.edu> and/or the author.
Expires May 1998 [Page 1]
INTERNET-DRAFT shared-mtrace October 1997
1. Introduction
"mtrace" [1] evolved some years ago from the need to have tools that
provide fault detection and diagnosis of multicast paths - "mtrace"
traces the path between a source and receiver via the specified group
distribution tree, which must be source-rooted.
Since then, multicast protocols that build shared multicast distribu-
tion trees have become more widely deployed, such as PIM and CBT. The
latest IDMR offering, GUM [4], is in its early stages of development,
and builds an inter-domain shared tree of domains. To accommodate the
newer shared tree trend, it is necessary to specify the behaviour of
"mtrace" when used with shared trees - we call this "shared-mtrace";
"shared-mtrace" does not alter the underlying means by which "mtrace"
gathers information from multicast routers on a path.
2. Overview
The design of "shared-mtrace" has been aimed at it being generally
applicable to all shared tree types, and their modes of operation.
This avoids requiring one such tool per shared tree {algorithm, mode}
pair. Besides the capability to trace a path between a particular
source and receiver over a shared tree, we have also included the
capability to trace the path between a shared tree's core/RP/root-
domain and all the leaves of the tree. This is called a wildcard
trace. This mode of operation may be useful for mapping (graphically,
or otherwise) a shared tree's current topology. It is recommended
that a wildcard trace request be subject to authentication at the the
core/RP/root-domain. Security is discussed further in the "Security
Considerations" section.
For a wildcard trace, "shared-mtrace" traces the path from the
group's core/RP/root-domain to each of the leaves of the tree. The
path between the source and the core/RP/root-domain, which may or may
not form a branch of the shared tree, must be traced separately.
For a receiver-specific trace, "shared-mtrace" traces the path from
the receiver to the core/RP/root-domain, or in some cases (e.g. some
instances of PIM), the path from the receiver all the way to the
specified trace source. The ability to trace from the receiver all
the way to the source IN ONE STEP depends on the presence of (S, G)
forwarding state in the routers along the path from the receiver. The
presence of (*, G) rather than (S, G) in the routers along the path
Expires May 1998 [Page 2]
INTERNET-DRAFT shared-mtrace October 1997
results in a trace only being able to progress as far as the
core/RP/root-domain.
In some cases (e.g. some instances of CBT), the path between the core
and specified source may form part of the distribution tree. There-
fore, the trace does not terminate at the core; the trace request is
encapsulated and sent to the specified source address, from where it
progresses in the direction source -> core, provided group forwarding
state exists. When this second trace phase is complete (or if no
group forwarding state exists) the the collection of completed trace
response segments can be returned to the designated trace response
address.
Since there are potentially two phases to "shared-mtrace", the cor-
rect interpretation of a trace response is more complicated than with
"mtrace". It is necessary for the receiver of a trace response to be
able to identify the group's core/RP/root-domain, and also be able to
identify whether the trace has progressed over a source tree (i.e.
via (S, G) state). This information allows the response to be
arranged/ordered correctly, and therefore interpreted correctly. For
example, for two different traces (wildcard or receiver-specific),
one may be completed in a single phase (e.g. PIM, where (S, G) state
exists between the receiver and source), whilst the other may be com-
pleted in two phases - the first between receiver and core, the sec-
ond between source and core (e.g. CBT, where source belongs to a sub-
net with at least one group member).
In order to be able to make this information available, we propose
the following:
+o a unique response code is used on the core/RP/root-domain's
response segment. All other response segments use the same
response code.
+o if the trace continues beyond the core/RP/root-domain (without
being encapsulated to the source), or the trace completes with-
out the inclusion of the core/RP/root-domain's response segment,
then the trace must have utilized (S, G) state. That is, the
utilization of source specific state is implicit.
3. "shared-trace" Algorithm
A "shared-mtrace" request is unicast from the network manager's
Expires May 1998 [Page 3]
INTERNET-DRAFT shared-mtrace October 1997
host/workstation to:
+o the core/RP/root-domain for wilcard traces
+o the specified receiver for receiver-specific traces
from where the trace begins.
The algorithm is as follows:
if (wildcard dst) /* wildcard trace */
while (out_intf_list != NULL)
insert response segment;
forward trace over each out_intf;
else
while (!first hop rtr for src))
insert response segment;
if ((S, G) for src)
forward trace over (S, G) parent_intf;
else
if (RP)
encapsulate trace to src;
if (multicast_proto == bidirectional)
while ((!RP) && (*, G))
insert response segment;
forward trace over (*, G) par-
ent_intf;
break;
else
insert response segment;
forward trace over (*, G) parent_intf;
unicast/multicast trace response to response address
end
4. Security Considerations
In wildcard mode, "shared-mtrace" could be used as a vehicle to mount
a denial of service attack. We therefore recommend that wildcard mode
be subject to the following constraints:
+o all wildcard traces begin at the group's core/RP/root-domain,
which must authenticate the source of the trace request, using a
Expires May 1998 [Page 4]
INTERNET-DRAFT shared-mtrace October 1997
proven, cryptographically strong, authentication technique such
as Keyed MD-5 [5]. This technique has been adopted by many other
Internet protocols, e.g. [ripv2, snmpv2]
+o the core/RP/root-domain may optionally maintain access control
lists (inclusion or exclusion lists) as an initial check point
(before authentication).
+o it may be useful to allow more fine-grained levels of access to
wildcard mode, for example, a source not included in an "include
list" (or named in an "exclusion list") are restricted to wild-
card traces whereby the trace source and response addresses must
be the same. This would cause the target of an attack to be the
attacker itself.
In general, we recommend that the header of all mtrace (shared-
mtrace) packets should contain the necessary authentication
fields. The additional fields indicated have been specified with
numerous other Internet protocols, and allow authentication
algorithm independence. The multicast traceroute header would
then be as follows:
Expires May 1998 [Page 5]
INTERNET-DRAFT shared-mtrace October 1997
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IGMP Type | # hops | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group Address |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| 0xFFFF | AuType=Keyed Message Digest | *
+-------------------------------+-------------------------------+ *
| (s-)mtrace Packet Length | Key ID | Auth Data Len | *
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ *
| Sequence Number (non-decreasing) | *
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| resp ttl | Query ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xFFFF | 0xXX | *
*
/ Authentication Data (var. length; 16 bytes with Keyed MD5) / *
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Proposed (shared-)mtrace Header for optional Authentication
The required additional fields for the purpose of authentication are
indicated by asterisks (*).
Acknowledgements
Thanks to Bill Fenner (Xerox PARC) for providing useful comments and
suggestions.
<to be completed>
Expires May 1998 [Page 6]
INTERNET-DRAFT shared-mtrace October 1997
References
[1] A traceroute facility for IP Multicast; W. Fenner and S. Casner;
ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-traceroute-
ipm-00.txt; Working Draft, March 1995.
[2] RFC 2117, Protocol Independent Multicast (PIM) Sparse Mode Speci-
fication; D. Estrin et al; ftp://ds.internic.net/rfc/rfc2117.txt.
August 1997.
[3] RFC 2189, Core Based Trees (CBT) Multicast Routing: Protocol Spec-
ification; A. Ballardie; ftp://ds.internic.net/rfc/rfc2189.txt.
September 1997.
[4] Grand Unified Multicast (GUM) Protocol Specification; D. Thaler,
D. Estrin, and D. Meyer, Editors; ftp://ds.internic.net/internet-
drafts/draft-ietf-idmr-gum-00.txt; Working Draft, July 1997.
[5] IP Authentication using Keyed MD-5; P. Metzger and W. Simpson; RFC
1828; ftp://ds.internic.net/rfc/rfc1828.txt.
Author Information:
Tony Ballardie,
Research Consultant.
e-mail: ABallardie@acm.org
Expires May 1998 [Page 7]
