Telechat Review of draft-ietf-mboned-mtrace-v2-22
review-ietf-mboned-mtrace-v2-22-tsvart-telechat-trammell-2018-01-24-00

Request Review of draft-ietf-mboned-mtrace-v2
Requested rev. no specific revision (document currently at 26)
Type Telechat Review
Team Transport Area Review Team (tsvart)
Deadline 2018-01-25
Requested 2018-01-22
Requested by Mirja Kühlewind
Authors Hitoshi Asaeda, Kerry Meyer, Weesan Lee
Draft last updated 2018-01-24
Completed reviews Secdir Last Call review of -?? by Dan Harkins
Genart Last Call review of -21 by Meral Shirazipour (diff)
Secdir Last Call review of -21 by Derrell Piper (diff)
Genart Telechat review of -22 by Meral Shirazipour (diff)
Tsvart Telechat review of -22 by Brian Trammell (diff)
Comments
Maybe some measurement person (Brian Trammell?) could review this?
Assignment Reviewer Brian Trammell
State Completed
Review review-ietf-mboned-mtrace-v2-22-tsvart-telechat-trammell-2018-01-24
Reviewed rev. 22 (document currently at 26)
Review result Not Ready
Review completed: 2018-01-24

Review
review-ietf-mboned-mtrace-v2-22-tsvart-telechat-trammell-2018-01-24

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