Subject: [MBONED] WGLC on draft-ietf-mboned-mtrace-v2-06.txt

From: Leonard Giuliano <[email-masked]>
Date: Wed, 3 Feb 2010 12:09:09 -0800

We would like to start the Working Group Last Call on "Mtrace Version 2: 
Traceroute Facility for IP Multicast" to close at February 17, 2010 at 
Midnight, UTC. The latest version of the draft can be found at:

http://www.ietf.org/id/draft-ietf-mboned-mtrace-v2-06.txt

Hitoshi's email below describes the changes made from the previous 
version.  Please review the document carefully, and send your feedback to 
the list.  Please also indicate whether or not you believe that this 
document is ready to go to the IESG.

Thanks,
Lenny, Marshall and Greg

****
Date: Sat, 23 Jan 2010 18:41:29 +0900 (JST)
From: Hitoshi Asaeda <[email-masked]>
To: [email-masked]
Subject: [MBONED] Fw:  I-D Action:draft-ietf-mboned-mtrace-v2-06.txt

Hello folks,

I submitted the revised draft of mtrace2.
The change is related to GTSM used for packet verification as follows;

old:
It is highly RECOMMENDED for the router to use GTSM [16] to determine
whether the host or router is adjacent or not.

new:
GTSM [16] SHOULD be used by the router to determine whether the host
or router is adjacent or not.

This small change is based on the comments in the last MBONED meeting
at Hiroshima.

I believe this revision is ready for WGLC.
WG chairs, could you please start WGLC for this revised draft?

Thank you,
--
Hitoshi Asaeda

---

From: Liu Hui <[email-masked]>
Date: Tue, 09 Feb 2010 12:18:54 +0800

Hi Authors, Hi WG,

I have some comments on this draft. 

Firstly, I notice it does not use "Response Address" field, which is used by
its previous versions. It requires the Mtrace Response to be sent to the
"Destination Address".  Because the Destination is the receiver of a
multicast path (from the definition in 5.4), this draft requires all Mtrace
response packets are sent to the multicast receiver specified by this
destination address.

This may be too restrictive, because Mtrace should be a tool for both end
users and operators.  In operator multicast network, operators could use
mtrace to construct multicast tree topology.  And if fault occurs
influencing the normal multicast forwarding, Mtrace could also be used by
the operator to trace the fault path for maintenance purpose.  Because it is
inconvenient for the operator to receive the Mtrace response on host
identified by the "destination address", I suggest preserving the "Response
Address" field to support this application scenario.   Personally, mtrace is
even more useful a tool for the operator than for the end users, because the
operator usually does not want the numerous receivers to have knowledge of
the multicast tree information, from the security consideration on the
network maintenance.

Secondly, mtrace was designed in a mode that the response packet is only
sent once as the trace terminates.  Even this mode has the advantage that
least packet can be generated in normal condition, it has the disadvantage
that path determination time is not small, in the case when linear search is
required, as described in section 10.2.

Actually Mtrace tool could incorporate the unicast trace mode in a more
efficient manner than the mentioned linear search.  It could send Responses
at each traced hop rather than only at the final traced hop.  In this
manner, the non-responding node could be easily isolated by a single trace,
rather than the multiple linear traces.  Both the packet number and the
tracing time could be decreased. So I suggest augmenting an operation mode
of mtrace to enable per-hop response.

Best Regards,
Liu Hui 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Leonard Giuliano
> Sent: Thursday, February 04, 2010 4:09 AM
> To: [email-masked]
> Subject: [MBONED] WGLC on draft-ietf-mboned-mtrace-v2-06.txt
> 
> 
> Traceroute Facility for IP Multicast" to close at February 
> 17, 2010 at Midnight, UTC. The latest version of the draft 
> can be found at:
> 
> Hitoshi's email below describes the changes made from the 
> previous version.  Please review the document carefully, and 
> send your feedback to the list.  Please also indicate whether 
> or not you believe that this document is ready to go to the IESG.
> 
> 
> Thanks,
> Lenny, Marshall and Greg
> 
> 
> ****
> It is highly RECOMMENDED for the router to use GTSM [16] to 
> determine whether the host or router is adjacent or not.
> 
> new:
> GTSM [16] SHOULD be used by the router to determine whether 
> the host or router is adjacent or not.
> 
> This small change is based on the comments in the last MBONED 
> meeting at Hiroshima.
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 12 Feb 2010 15:43:25 +0900 (JST)

Hi Liu,

> response packets are sent to the multicast receiver specified by this

Removing the Response Address field was the concensus of the WG.
It aims to reduce the security concern, since the Response Address
field allows to forward mtrace2 response messages to any node
specified in the Response Address field.

> Address" field to support this application scenario.  

You believe such functionality is convenient for operational purpose.
I also like the idea to retrieve routing state by a foreign node (i.e.
a non-adjacent host of the last-hop router).
However, such functionality gives the possibility of the use of a DoS
tool. There is a trade-off between convenience and security.

> Personally, mtrace is

I think your assumption is that an operator will control mtrace2 query
and response from the operational (foreign) site.
However, mtrace2 does not allow a query request from a foreign node.
Whether the Response Address is preserved or not, mtrace2 query must
be invoked by an adjacent host. If there is no operator attached to
the last-hop link, an end user attached to the LAN needs to invoke
mtrace2 query instead of the operator. It is not an additional high
cost that the end user additionally forwards or tells the output of
the mtrace2 response triggered by him to his operator after he got the
output, I think.

> of mtrace to enable per-hop response.

Then do you propose to allow for a foreign node to send mtrace2 query?
It was also the concensus of the WG. The reason is also due to the
security concern, as well as the above consideration.

WG members, do you have any objection?

Regards,
--
Hitoshi Asaeda

---

From: liuhui 47967 <[email-masked]>
Date: Tue, 16 Feb 2010 02:16:59 +0800

Hi Hitoshi,

> > response packets are sent to the multicast receiver specified by 
> this> destination address.
> 

I understand this security concern.  But, will using of a destination address be more secure than using of response address? A destination address is also an *any* node for the non-lasthop router.

> tool. There is a trade-off between convenience and security.

Even the trace is started by a host on the last hop link, there is also the possibility of DOS attack. 

And for the provider, a management mode outside the multicast path might be more trustful than an arbitrary end host. There should be no conflict between convenience and security in this aspect.

> the mtrace2 response triggered by him to his operator after he got the

Most mtrace tool implemented in the today's router OS and management software support response address and support query from a foreign node. How this Mtrace2 interoperate with them? What's the relationship between the original mtrace and this new version? Will this new version replace ver1 and revise current implementations? 

May before this strict restriction - "must be invoked by an adjacent host"- is finally made, some investigations should be taken among the providers. For example, do they want to restrict
the tool to be started only on the last-hop link or also from a management node on their network? Do they like the end user to trace their multicast network? Where will the actual security threat come from, from the end user or from their network side? Is this security issue so severe that we have to shrink this tool to this limited usage?

> > least packet can be generated in normal condition, it has the 
> disadvantage> that path determination time is not small, in the 
> case when linear search is
> > at each traced hop rather than only at the final traced hop.  In 
> this> manner, the non-responding node could be easily isolated by 
> a single trace,

This second issue discussed is an optimization of mtrace tool. It's different from both ver1 and ver2. It intends to augment mtrace with a per-hop response mode (whether response address and foreign query are adopted or not) to speed fault isolation process.

Best Regards,
Liu Hui

---

From: liuhui 47967 <[email-masked]>
Date: Tue, 16 Feb 2010 02:17:08 +0800

Hi Hitoshi,

> specified in the Response Address field.

I understand this security concern.  But, will using of a destination address be more safe than a response address? An destination address is also an *any* node from the aspect of the non-lasthop router.

> tool. There is a trade-off between convenience and security.

Even the trace is started by an host on the last hop link, there is also the possibility of DOS attack. 

And for the provider, a management mode outside the multicast path should usually be much more trustful than an arbitrary end host. There should be no conflict between convenience and security in this aspect. 

> the mtrace2 response triggered by him to his operator after he got the

Most mtrace tool impelemented in the today's router OS and managment software support response address and support query from a foreign node. How this Mtrace2 interoperate with them ? What's the relationship betweem the original mtrace and this new version? Will this new version replace ver1 and revise current implementations? 

I suggest before this strict restriction - "must be invoked by an adjacent host"- be finally made, some investigatioms should be taken among the providers. For example, do they want to restrict
the tool to be started only on the last-hop link or also from a management node in their network? Do they like the end user to trace their multicast network? Where will the actual security threat come from, from the end user or from their network side? Is this security issue so severe that we have to shrink this tool to this limited usage? 

> security concern, as well as the above consideration.

This second issue discussed is an optimization of mtrace tool. It's different from both ver1 and ver2. It augment mtrace with a per-hop response mode (whether response address and foreign query are adopted or not) to speed fault isolation process.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 16 Feb 2010 12:44:18 +0900 (JST)

> I understand this security concern.  But, will using of a
> destination address be more secure than using of response address?

Yes, because no third-party address allowed.

> A destination address is also an *any* node for the non-lasthop
> router.

Yes, but the last hop router guarantees the mtrace2 querier is
his adjacent host by GTSM. It is possible to trace the querier.

> also the possibility of DOS attack. 

The security level is different. Allowing query and/or reply from/to
third-party nodes gives higher impact for security.

> And for the provider, a management mode outside the multicast path
> might be more trustful than an arbitrary end host. There should be
> no conflict between convenience and security in this aspect.

Who knows the third-party nodes are legitimate management nodes?

> Most mtrace tool implemented in the today's router OS and management
> software support response address and support query from a foreign
> node. How this Mtrace2 interoperate with them? What's the
> relationship between the original mtrace and this new version? Will
> this new version replace ver1 and revise current implementations? 

No interoperability with old mtrace. This is WG concensus.
The protocols used by mtrace and mtrace2 are also different.

> May before this strict restriction - "must be invoked by an adjacent
> host"- is finally made, some investigations should be taken among
> the providers. For example, do they want to restrict the tool to be
> started only on the last-hop link or also from a management node on
> their network? Do they like the end user to trace their multicast
> network? Where will the actual security threat come from, from the
> end user or from their network side? Is this security issue so
> severe that we have to shrink this tool to this limited usage?

Then, why your router does not implement mtrace2 client?
If your provider's router implements mtrace2 client, the router starts
mtrace2 query toward your target source and obtains its correspondign
mtrace2 response. You or your administrator who can access that router
can see mtrace2 response.
If you do want to trace by some management host or server, you can set
up something like a proxy or looking grass in your site.

> This second issue discussed is an optimization of mtrace tool. It's
> different from both ver1 and ver2. It intends to augment mtrace
> with a per-hop response mode (whether response address and foreign
> query are adopted or not) to speed fault isolation process.

The old mtrace and mtrace2 are similar but different.

Regards,
--
Hitoshi Asaeda

---

From: liuhui 47967 <[email-masked]>
Date: Tue, 16 Feb 2010 13:56:39 +0800

> >> You believe such functionality is convenient for operational 
> purpose.>> I also like the idea to retrieve routing state by a 
> foreign node (i.e.

I suppose providers have their own security measures when managing their networks. For example, the equipment management system needs to accept alarm messages from its network equipments, to query timely the operational status of the equipments. The equipments and management system are often geologically isolated. This is similar to the relationship between the Querier and the last hop router. 

The last hop router should start a trace when queried by a management node, but should not start a trace when queried by an end user, in a practically operational network. 

There is one special case that a management system is just on the network of the last hop.  But when the tree scale is large, to access each branch on each remote leaf node is not flexible for operating the network. 

The traditional Mtrace has already provided a good solution for all the above issues, Security could be enhance only when Query and Response messages travel through untrusted network. Why change it in this way just because of security consideration.

You mentioned that this is a consensus of the working group. But I'm sorry I failed to get this consensus information on the mailing list. Would you please introduce some providers' representatives (who have multicast network deployed) to express their standpoints on this matter?

Best Regards,
Liu Hui

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 16 Feb 2010 16:38:41 +0900 (JST)

> I suppose providers have their own security measures when managing
> their networks. For example, the equipment management system
> needs to accept alarm messages from its network equipments, to
> query timely the operational status of the equipments. The
> equipments and management system are often geologically
> isolated. This is similar to the relationship between the Querier
> and the last hop router. 

As I said, implementing mtrace2 client (query) program in a router
address your request.

> The last hop router should start a trace when queried by a
> management node, but should not start a trace when queried by an end
> user, in a practically operational network. 

Ditto.

> The traditional Mtrace has already provided a good solution for all
> the above issues, Security could be enhance only when Query and
> Response messages travel through untrusted network. Why change it in
> this way just because of security consideration.

If you like old mtrace, you can continue to use it.
I'd recommend to use mtrace2 to eliminate security concern, though.

> You mentioned that this is a consensus of the working group. But I'm
> sorry I failed to get this consensus information on the mailing
> list. Would you please introduce some providers' representatives
> (who have multicast network deployed) to express their standpoints
> on this matter?

This modification was done from -02 (issued on November 3, 2008) to
-03 (issued on March 9, 2009). It's not very new.

If some of WG members, especially providers, have opinion, please give
some comments.

We had already discussed this security concern and decided to
eliminate the function of requesting query from foreign nodes and
forwarding response to foreign nodes.
One of the big issues of multicast deployment is security.
I personally do want to eliminate security concern from the current
unfortunate condition of multicast deployment.

Regards,
--
Hitoshi Asaeda