Subject: [Tsv-art] TSV Area Review of draft-ietf-mboned-mtrace-v2

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 24 Jan 2018 10:47:51 +0100

Greetings,

I've reviewed this document as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@… if you reply to or forward this review.

Summary:

The document is not ready for publication as a Standards Track RFC in its current state.

The protocol appears to make appropriate use of UDP; i.e., it poses no concerns about congestion safety when implemented and used as designed with non-malicious clients.

However, I'm concerned about the potential for abuse of mtrace2. Specifically, replies are larger than queries, so the protocol can be used for amplification, and the protocol will send replies to a client address which is sent in cleartext without integrity protection, so the potential for redirection via spoofing exists.

The first, I think, could be addressed by requiring the initial query to be a near-maximum-size UDP packet, or at least larger than the reply packets.

The security concept in sections 9.1 and 9.2 seems to assume that client filtering at a network border is sufficient; however, this does not appear to address the case of inside an administrative domain spoofing its address. Section 9.5 acknowledges the potential of the protocol for amplification, but should provide concrete advice for rate limiting.

One question: this may be a moot question (I did not review mtrace v1), but it appears that mtrace2 is designed to share a port with mtrace1, and I don't see any version field in the messages. How is version transition handled by this protocol? Is it possible to run a mixed network with both mtrace versions and have the right thing (probably downgrade) happen, or is the assumption that mtrace version migration is a flag day? A related editorial suggestion: a list of changes from mtrace v1 to mtrace v2 in an appendix would be useful.

Cheers,

Brian

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 25 Jan 2018 13:54:22 +0900

Hi Brian,

Thanks for your review and comments.

> 2018/01/24 18:47, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Greetings,
> 

I may misunderstand this comment, but..
Do you think creating the initial query to be a near-maximum-size UDP packet (maybe by padding with zero?) addresses the security concern?
A malicious user would cause more disruption by sending big query packets than by sending small ones. Since only one mtrace query can be sent per UDP packet, there is no “amplification” exposure in which a packet could contain a large number of queries, yielding a much higher volume of response data for a given packet. The ratio of response data per mtrace query is unchanged by sending big query packets and using extra bandwidth for the queries is undesirable.

> The security concept in sections 9.1 and 9.2 seems to assume that client filtering at a network border is sufficient; however, this does not appear to address the case of inside an administrative domain spoofing its address.

There are two different types of filtering being mixed up in this comment: (1) Filtering by administrative boundary (which only makes sense at a border). (2) Filtering to allow only acceptable source addresses (which can be applied on any router and can be used to filter out unwanted sources within an administrative domain). We think that we can satisfy your concern by clarifying this point (with editorial update).
We’ll provide some text for (2) in the revision.

> Section 9.5 acknowledges the potential of the protocol for amplification, but should provide concrete advice for rate limiting.

We think it is difficult to provide concrete advice for rate limiting, because it hardly depends on the environments and situations/conditions. The WG also agreed that the rate limit is left to the router's implementation.
If you believe we should specify some advice for concrete value for rate limiting, could you kindly give some example?

> One question: this may be a moot question (I did not review mtrace v1), but it appears that mtrace2 is designed to share a port with mtrace1, and I don't see any version field in the messages. How…

There is no mtrace v1 specification. Some vendors and UNIX OSes implemented mtrace (aka mtrace “v1”) without the standard specification. It was mentioned in section 10 (Acknowledgements) as follows;

   This specification started largely as a transcription of Van
   Jacobson's slides from the 30th IETF, and the implementation in
   mrouted 3.3 by Ajit Thyagarajan.  Van's original slides credit Steve
   Casner, Steve Deering, Dino Farinacci and Deb Agrawal.  The original
   multicast traceroute client, mtrace (version 1), has been implemented
   by Ajit Thyagarajan, Steve Casner and Bill Fenner.

The problem is that since no standard specification, there is no interoperability with the different mtrace v1 implementations. Mtrace v1 is not only obsolete but also no specification; hence it is difficult or meaningless to clearly show the diffs between mtrace v1 and v2, IMO.

Regarding backward compatibility, as briefly mentioned in section 1 (as follows);

   Mtrace2 supports both IPv4 and IPv6.  Unlike the previous version of
   Mtrace, which implements its query and response as Internet Group
   Management Protocol (IGMP) messages [8], all Mtrace2 messages are
   UDP-based.

mtrace v1 was implemented on top of IGMP, while mtrace v2 is defined with UDP. There is no compatibility between them, and the WG agreed on ignoring this compatibility.

Also it may be worth noting that we can handle new (e.g., v3) mtrace versions by supporting new TLV types, with downward compatibility provided for the mtrace2 TLV types at this moment.

Best regards,
--
Hitoshi Asaeda

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 25 Jan 2018 16:06:54 +0100

hi Hitoshi,

Replies inline...

> On 25 Jan 2018, at 05:54, Hitoshi Asaeda <[email-masked]> wrote:
> 
> Hi Brian,
> 

Partially. There are two kinds of amplification: one spoofed packet causes many packets to be sent to the target, which is more pernicious; one spoofed packet causes a single larger spoofed packet to be sent to the target, which is less dangerous but still not great.

> A malicious user would cause more disruption by sending big query packets than by sending small ones.

The point is to reduce the ratio between Query and Reply size to ensure that there is no incentive to try to use mtrace2 reflection to increase the bandwidth available to an attacker.

> Since only one mtrace query can be sent per UDP packet, there is no “amplification” exposure in which a packet could contain a large number of queries, yielding a much higher volume of response data for a given packet. The ratio of response data per mtrace query is unchanged by sending big query packets and using extra bandwidth for the queries is undesirable.

I might misunderstand the protocol, but doesn't each Query cause at least one Request to be sent per hop? Although this then results in only one Reply, so I suppose the parallel per-packet amplification threat is minimal...

> We’ll provide some text for (2) in the revision.

Thanks!

> If you believe we should specify some advice for concrete value for rate limiting, could you kindly give some example?

I'm also not sure here, because I'm not familiar with the environments in which mtrace operates. In general, what is the data rate mtrace traffic on the path between routers, as a percentage of total available bandwidth? Perhaps expressing the recommended rate limits in these terms would be useful.

> mtrace v1 was implemented on top of IGMP, while mtrace v2 is defined with UDP. There is no compatibility between them, and the WG agreed on ignoring this compatibility.

Ah, right. I did see this, but it didn't register that that made versioning irrelevant, sorry. Thanks for explaining!

> Also it may be worth noting that we can handle new (e.g., v3) mtrace versions by supporting new TLV types, with downward compatibility provided for the mtrace2 TLV types at this moment.

Yep, this clearly works, and should probably be called out explicitly in the draft.

Thanks, cheers,

Brian

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 25 Jan 2018 23:51:49 +0100

Hitoshi, Brian, *:

Wrt. mtrace v1:

mtrace-v2 should probably include a reference of draft-ietf-idmr-traceroute-ipm-07
as the latest specification available for mtrace-v1.

Wrt. comparison. I would add a sentence saying that implementations
of mtrace-v1 in Unix and router operating systems where/are not necessarily fully
compliant with that specification or each other, therefore a detailled list of
changes vs. mtrace-v1 serves no good purpose because there is no clear most
relevant target of comparison.

E.g: It is at least my good memory that i ran into inconsitencies/incompatibilities between
that draft, Unix mtrace and Cisco IOS mtrace.

It would make sense to extract the existing paragraph mentioning the "previous version",
put it together with the paragraph explaining the history and above notes into some new section
at the end with "mtrace version 1" in its title so that one can easier find this mtrace-v1 stuff,
because right now its somewhat hidden.  But don't spend too many cycles on it.

Cheers
    torless

On Thu, Jan 25, 2018 at 01:54:22PM +0900, Hitoshi Asaeda wrote:
> There is no mtrace v1 specification. Some vendors and UNIX OSes implemented mtrace (aka mtrace ???v1???) without the standard specification. It was mentioned in section 10 (Acknowledgements) as follows;
> 
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 26 Jan 2018 00:05:42 +0100

Brian:

Is there any standards, lightweight UDP based three way handshake transport proto stub 
one could steal, e.g.: just nonce based initiator spoofing prevention. Its kinda silly having to reinvent
this over and over again.

Cheers
    Toerless

-- 
---
[email-masked]