Subject: [Last-Call] Tsvart last call review of draft-ietf-avtcore-cc-feedback-message-08

From: Michael Scharf via Datatracker <[email-masked]>
Date: Wed, 09 Sep 2020 01:22:31 -0700

Reviewer: Michael Scharf
Review result: Ready with Issues

This document has been reviewed 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 and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

Major issues
-------------

None

Minor issues
-------------

1/ Section 5:

   All RTP congestion control algorithms MUST specify how they
   respond to the loss of feedback packets.

This is a process-related requirement not relevant for interoperability of
implementations. In addition, the requirement is not very specific (What would
have to be specified?). I am not sure if such a requirement in capital letters
is really needed here. This should be handled consistently in all IETF
documents.

2/ Section 11:

The Security Considerations do not discuss off-path attacks, and it is not
clear why this case is missing. Can an off-path attacker trick the sender into
sending at either an excessively high or excessively low rate?

Nits
----

1/ Abstract:

The protocol extension enables fine-grained feedback on per-packet reception
quality. The rationale is provided in Section 1 and (more comprehensively) in
Section 8. Yet, I wonder if this objective could also be made a bit more
explicit in the abstract, e.g., along the lines of the "fine-grained feedback"
wording in the first paragraph of Section 8.

2/ Section 7:

Typo in "a=ecn-capaable-rtp:"

---

From: Colin Perkins <[email-masked]>
Date: Thu, 17 Sep 2020 23:39:08 +0100

Hi Michael,

> On 9 Sep 2020, at 09:22, Michael Scharf via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Michael Scharf

Happy to change this to “need to specify”, but I also think “MUST” is appropriate. RTCP congestion control feedback packets can carry information about a larger number of data packets than is typical for, e.g., TCP ACKs, so it might be considered more critical that response to loss of feedback is defined.

> sending at either an excessively high or excessively low rate?

An off-path attacker can’t modify RTCP congestion control feedback, but they could potentially spoof such packets. The fix is the same: use Secure RTP to authenticate. Will clarify.

> wording in the first paragraph of Section 8.

Sure, seems reasonable.

> 2/ Section 7:
> 
> Typo in "a=ecn-capaable-rtp:”

Will fix.

-- 
Colin Perkins
https://csperkins.org/