Subject: [MBONED] mtrace2 modification

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 17 Feb 2009 19:01:53 +0900 (JST)

Hi all,

I'd like to ask if you agree the following mtrace2 modification.

===

The discussion point is; "Response Address field is eliminated from
mtrace2 query header".

Here I'd tell you the whole story.

In the current spec, multicast routers will accept mtrace2 query
message directly sent from any node.
This spec is explained in the section 10.1 as follows:
  "if the mtrace2 client
   wants to restart mtrace2 Query from the intermediate router that
   responded with NO_SPACE in Forwarding Code of Standard Response Block
   as specified in Section 6.13, the Query could be unicasted to that
   router."
However, I think it is better to accept mtrace2 query message invoked
by a node ONLY in the same LAN, NOT a foreign node, due to a security
reason.

The current mtrace2 inherits Query header format from the original
mtrace (mtrace1, hereafter).
Mtrace1 allows to make a response to a specified address in the
Response Address field. This address could be either of unicast or
multicast, and the unicast address could be different from an mtrace1
querier's address (which is specified in another "Destination Address"
in the same query header).

The current mtrace2 spec inherits the thought and defines the query
header, being very similar to the one of mtrace1, as follows;

      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
                                                     +-+-+-+-+-+-+-+-+
                                                     |    # hops     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                      Multicast Address                        |
     |                                                               |
     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
     |                                                               |
     |                        Source Address                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                      Destination Address                      |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                       Response Address                        |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Query ID            |        Client Port #        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

However, since the latest version of mtrace2 eliminates the function
of multicast response, "Response address" specified in mtrace2 query
header must be a unicast address. And since the mtrace2 querier
address is specified in the Destination address field, "Response
address" is only useful to specify a node that is different from the
mtrace2 querier.

It is useful since there may be the case that some administrator wants
to capture mtrace2 response requested by a different node in order to
trace a multicast path from the node located in the different network
to a sender. However, this function may include some security concern,
because any node can directly forward mtrace2 request to any router,
and the router that receivers mtrace2 query request forwards the
mtrace2 message and the first hop router sends back to the node
specified in the "Response Address" field, whereas the router does not
know if the Response Address is the correct node.

Well, since the unicast traceroute program always feedbacks the
traceroute querier and does not allow to feedback to a node that is
not the traceroute querier, eliminating the "Response Address" field
would be reasonable from this point, too.

If we eliminate the "Response address" field, we must decide the way
to forward the mtrace2 message that was stopped by NO_SPACE.
In fact, it is possible for a multicast router (that encounter
NO_SPACE) to 1) send back the mtrace2 response with contained data and
NO_SPACE flag, and 2) continue mtrace2 query by sending an mtrace2
request containing the mtrace2 query with no change except for the
#hops field and its response block. The #hops field must be decreased
according to the number of standard response blocks in th mtrace2
request received by the router.
Then the original mtrace2 querier can receive multiple mtrace response
messages and integrate (construct) them as a single response.

===

Please give us your opinion.
If there is no strong objection, we'll modify the current spec and
submit the new version before the submission D/L.

Regards,
--
Hitoshi Asaeda