[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                          A. Ballardie

                                                       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.


   ''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

   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

   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

   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;
         while (!first hop rtr for src))
               insert response segment;
               if ((S, G) for src)
                     forward trace over (S, G) parent_intf;
                     if (RP)
                           encapsulate trace to src;
                           if (multicast_proto == bidirectional)
                                 while ((!RP) && (*, G))
                                       insert response segment;
                                       forward trace over (*, G) par-
                           insert response segment;
                           forward trace over (*, G) parent_intf;

   unicast/multicast trace response to response address

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 (*).


   Thanks to Bill Fenner (Xerox PARC) for providing useful comments and

   <to be completed>

Expires May 1998                                                [Page 6]

INTERNET-DRAFT               shared-mtrace                  October 1997


  [1] A traceroute facility for IP Multicast; W. Fenner and S. Casner;
  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]