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

[Sean Turner via Datatracker <[e-mail]>]

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