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

From: Sean Turner via Datatracker <[email-masked]>
Date: Mon, 12 Aug 2019 18:08:18 -0700

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 13 Aug 2019 08:56:58 +0100

See  below:

> in the context of a specific transport protocol and its authentication
I also think that text (or similar) would also be valuable in the 
security considerations section.

Gorry

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 16 Aug 2019 14:59:37 +0200

Hi Sean, hi Gorry,

Thanks for your review and feedback. Please see below.

> On 13. Aug 2019, at 09:56, Gorry Fairhurst <[email-masked]> wrote:
> 
> See  below:
> 

I think this is actually based on text that we used for scream (now RFC8298) which is another congestion control developed in rmcat. I think we refined that text also based on a SEC (or GEN?) review comment at that time and people were at the end satisfied with it. However, your proposed change above could surely be integrated and I leave it to the authors if they want to refine the text further. 

>> more than its fair share of network bandwidth?

This is a very general point for all congestion control schemes, and for rmcat it is also discussed in draft-ietf-rmcat-cc-requirements (which is sitting in the RFC editor queue for a while as part of the 238 cluster…). I personally don’t see too much value in discussing this here once again (given the generic nature of the problem and very unclear definition of “fair”).

>> in the context of a specific transport protocol and its authentication

Hm, also not sure here because, while this congestion control scheme is developed for RTP/RTCP, it's defined in a more generic way and there are actually no real dependencies on a specific protocol.

>> 
>> Cheers,
>> 
>> spt
> I also think that text (or similar) would also be valuable in the security considerations section.
> 

Gorry: Can you further explain what part this comment related to?

Thanks!
Mirja

---

From: Colin Perkins <[email-masked]>
Date: Fri, 16 Aug 2019 15:54:07 +0100

Hi,

> On 16 Aug 2019, at 13:59, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Hi Sean, hi Gorry,
> 

For both this and the GenART review, it should maybe point to draft-ietf-avtcore-cc-feedback-message-04 as an example mechanism to carry congestion feedback. The security considerations in that draft highlight some of these issues, and point to the RTP security mechanisms needed to secure the feedback.

Colin

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

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Fri, 16 Aug 2019 16:46:13 +0000

Hi, 

Thanks to Sean and Gorry for your review comments.  And thanks to Mirja and Colin for chiming in with your inputs and suggestions. 

Below are my planned actions for revising the draft, so that they can address the original set of comments and questions from Sean (while taking into account inputs from Gorry/Mirja/Colin)

* Suggestions for revised text in the Security Considerations:  will be happy to revise accordingly. Will also split up the text into two paragraphs corresponding to the two points. 
* Question 1 on concerns related to greedy receivers:  as a general fairness concern (for most congestion control schemes) this is discussed in greater detail in the cc-requirements draft.  The draft current only cites the cc-requirements draft in the intro. We can add some more text to highlight several salient requirements (e.g., stability, fairness) as example. 
* Question 2 on RTP/RTCP security considerations:  per Colin's suggestion, will add a reference and point to the cc-feedback-message draft for further discussions on security mechanisms. 

Gorry -- I understood your comments as referring to the text suggestions by Sean.  Please let us know if that's not the case or if the above planned changes miss out any points you'd like to highlight.

Best,
Xiaoqing 

On 8/16/19, 9:54 AM, "Colin Perkins" <[email-masked]> wrote:

    Hi,

    
    Colin

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 17 Aug 2019 09:29:17 +0100

Yes. I'm happy with this approach in response to my feedback. 
Specifically, providing extra text in the security requirements to 
highlight each of these (generic) CC topics - if needed, with pointers 
to other documents where these are discussed more.

Gorry

On 16/08/2019, 17:46, Xiaoqing Zhu (xiaoqzhu) wrote:
> On 8/16/19, 9:54 AM, "Colin Perkins"<[email-masked]>  wrote:
>
>      Hi,
>
>      >  On 16 Aug 2019, at 13:59, Mirja Kuehlewind<[email-masked]>  wrote:
>      >
>      >  Hi Sean, hi Gorry,
>      >
>      >>  On 13. Aug 2019, at 09:56, Gorry Fairhurst<[email-masked]>  wrote:
>      >>
>      >>  See  below:
>      >>

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 17 Aug 2019 12:29:08 +0100

To be clear, see notes below.

Sent from my iPad

> On 17 Aug 2019, at 09:29, Gorry Fairhurst <[email-masked]> wrote:
> 
> 
> Yes. I'm happy with this approach in response to my feedback. Specifically, providing extra text in the security requirements to highlight each of these (generic) CC topics - if needed, with pointers to other documents where these are discussed more.
> 
> Gorry
> 

I liked the idea of noting the CC implications in the Security Considerations, we have done so before, and a brief additional text  with refs to another RFC should suffice.

>> * Question 1 on concerns related to greedy receivers:  as a general fairness concern (for most congestion control schemes) this is discussed in greater detail in the cc-requirements draft.  The dr…

Proving a brief summary and citing in the sec considerations seems good to me.

>> Gorry -- I understood your comments as referring to the text suggestions by Sean.  Please let us know if that's not the case or if the above planned changes miss out any points you'd like to highl…
Yes and some mention of possible attack on receiver-supplied info, although again my preference would be identify issue and provide  a ref to another RFC, rather than detailed discussion. This is not a new issue.

>>    --      Colin Perkins

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Sun, 25 Aug 2019 04:30:08 +0000

Just wanted to update that the draft has been updated to version -12, where we incorporated the Secdir review comments as discussed in this thread. 

Thanks again to Gorry/Sean/Mirja/Colin for your input & suggestions. 

Best,
Xiaoqing

On 8/17/19, 6:30 AM, "Gorry Fairhurst" <[email-masked]> wrote:

    Sent from my iPad