Re: [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11

[Gorry Fairhurst <[e-mail]>]

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