See below:
On 13/08/2019, 02:08, Sean Turner via Datatracker wrote:
Reviewer: Sean Turner
Review result: Has Nits
Hi! I'm no congestion control expert so nothing in the main body jumped out at
me. I did take a little time to review some security considerations for other
congestion control RFCs and just wanted to make sure the same kind of
information is getting addressed. I indicated the result of this review as
"has nits" because there is a pretty good chance I am just suggesting some
editorial tweaks.
The security considerations rightly points out that this mechanism is
susceptible to the same kind of attacks as TCP (e.g., hijack, replacement) and
what mitigations to use (i.e., integrity protection of the RTCP feedback
messages). But, what is missing is what happens if these attacks succeed: DoS
or in the worst case congestion collapse? So, maybe instead of:
As such, it is vulnerable to attacks where feedback
messages are hijacked, replaces, or intentionally injected with
misleading information, similar to those that can affect TCP.
Maybe:
As such, it is vulnerable to attacks where feedback
messages are hijacked, replaces, or intentionally injected with
misleading information resulting in denial of service, similar
to those that can affect TCP.
Also, unless I've completely misread this paragraph it seems like you are
talking about two things: 1) it's just like TCP, and 2) "The modification of
sending rate ...". So, maybe split the paragraph along those lines.
Further questions:
1. Are there any concerns related to a greedy receiver who wants to gobble up
more than its fair share of network bandwidth?
2. Seems like maybe you also need to refer to the RTP/RTCP security
considerations because it seems like security primarily needs to be considered
in the context of a specific transport protocol and its authentication
mechanisms.
Cheers,
spt
I also think that text (or similar) would also be valuable in the
security considerations section.
Gorry
