[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MBONED] mtrace-v2-04 draft submission

Hello folks,

I updated the mtrace2 draft.
http://tools.ietf.org/html/draft-ietf-mboned-mtrace-v2-04

The changes are mainly to fix bugs I already mentioned in the attached
mail and got the concensus to be updated in the last IETF meeting.

The other changes are the clarifications based on the Ron's comments
at the last meeting.
The points are, 1) consideration for "the neighbor nodes", and 2)
consideration for rate limiting for bursty query/request.
For the former one, I updated the sect.9.2.1 as follows;

9.2.1.  Packet Verification

   If the mtrace2 Request does not come from an adjacent host or router,
   it MUST be silently ignored.  If the mtrace2 Request is not addressed
   to this router, or if the Request is addressed to a multicast group
   which is not a link-scoped group (i.e. 224/24 for IPv4, FFx2::/16 [3]
   for IPv6), it MUST be silently ignored.  The router's neighbor
   information, e.g.  ARP database or PIM neighbor list, should be used
   to determine whether the host or router is adjacent or not.

For the latter one, I added the sect.4.3 as follows;

14.3.  Limiting Query/Request Rates
 
   Routers should limit mtrace2 queries and requests by ignoring the
   received messages.  Routers MAY randomly ignore the received messages
   to minimize the processing overhead, i.e., to keep fairness in
   processing queries.

Comments are welcome.
Regards,
--
Hitoshi Asaeda
--- Begin Message --- 
(The example figures I sent was very confusing, so I modified the
figure. Please discard the previous mail and look at this one, sorry.)

Dear all,

I'm very sorry that I found several bugs in the current mtrace2 spec.

Section 9.3 of the current draft (-03) says that upon NO_SPACE error
a new mtrace2 request will be continued by the router that encountered
NO_SPACE error. And regarding the new mtrace2 query header, the draft
says "The # hops field must be decreased according to the number of
standard response blocks in the mtrace2 request received by the
router." However, this is contradict to the spec saying "The header is
only filled in by the originator of the mtrace2 Query; intermediate
routers MUST NOT modify any of the fields." in section 5.

In addition, while the current draft does not distinguish the
following two cases, "a router cannot insert any response block in the
mtrace2 request due to MTU issue" and "a router is a NAT or firewall
whose outgoing interface is non-routable from outside or that needs to
hide information inside network", for NO_SPACE error. However, the
router's behavior must be different between these two cases.

In the former case (Case-1, hereafter), when the router (B in the
following figure) recognizes NO_SPACE problem, it sends response back
with NO_SPACE code in the standard response block of the
"previous-hop" router and continues mtrace2 request "with the same
mtrace2 query header". Since routers toward S need to know the limited
hop count without changing mtrace2 query header, the router (B)
inserts "augmented response block" to specify "how many routers (hops)
were passed".

Q: mtrace2 querier, A-D: router, S: data source,
X: previous-hop router addr or appropriate multicast addr
[ ]: IP header, ( ): mtrace2 header and data

Case-1 (B encounteres NO_SPACE):
 Q --> A --> B --> C --> D --> S
  ---> query [src:Q,dst:X](src:S,dst:Q,hop:n)
        ---> request [src:A,dst:X](src:S,dst:Q,hop:n,std-blk:A)
  <---------- response [src:B,dst:Q](src:S,dst:Q,std-blk:A,NO_SPACE)
              ----> request [src:B,dst:X]
                            (src:S,dst:Q,hop:n,std-blk:B,aug-blk)
                    ----> request [src:C,dst:X]
                                  (src:S,dst:Q,hop:n,std-blk:B,aug-blk,
                                   std-blk:C)
  <---------------------- response [src:D,dst:Q]
                                   (src:S,dst:Q,std-blk:B,aug-blk,
                                    std-blk:C,std-blk:D)

In the latter case (Case-2, hereafter), when the router (B in the
following figure) is a NAT/gateway, it hides the information between Q
and B. The router (B) sends back the response with REACHED_GW and then
creates a new mtrace2 request with "new mtrace2 query header". The new
query header includes "# hops" that is the original # hops minus the
number of standard response blocks returned to Q. The router (B) takes
a role as a proxy and sends back the response from the first-hop router
to the original querier Q.

Case-2 (B proxies mtrace2 query):
 Q --> A --> B --> C --> D --> S
  ---> query [src:Q,dst:X](src:S,dst:Q,hop:n)
        ---> request [src:A,dst:X](src:S,dst:Q,hop:n,std-blk:A)
  <---------- response [src:B,dst:Q]
                       (src:S,dst:Q,std-blk:A,std-blk:B,REACHED_GW)
              ----> query [src:B,dst:X](src:S,dst:B,hop:n-2)
                    ----> request [src:C,dst:X]
                                  (src:S,dst:B,hop:n-2,std-blk:C)
              <---------- response [src:D,dst:B]
                                   (src:S,dst:B,hop:n-2,std-blk:C,
                                    std-blk:D)
  <---------- response [src:B,dst:Q](src:S,dst:Q,std-blk:C,std-blk:D)

So far, I updated the current draft and you can fetch the pre-release
-04 version from;
http://www.sfc.wide.ad.jp/~asaeda/paper/draft-ietf-mboned-mtrace-v2-04-pre2.txt

The corresponding explanations of Case-1 and Case-2 are described in
section 9.3 of above draft.
And the new augmented response block used for Case-1 is mentined in
section 8.
For Case-2, I explicitly mentioned the scenario in section 9.5
"Proxying Mtrace2 Queries".

Thanks for your attention.
See you soon in San Francisco,
--
Hitoshi Asaeda
_______________________________________________
MBONED mailing list
MBONED at ietf.org
https://www.ietf.org/mailman/listinfo/mboned

--- End Message ---