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

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

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" <[e-mail]> wrote:

    
    To be clear, see notes below.
    
    Sent from my iPad
    
    > On 17 Aug 2019, at 09:29, Gorry Fairhurst <[e-mail]> 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
    > 
    >> On 16/08/2019, 17:46, Xiaoqing Zhu (xiaoqzhu) wrote:
    >> 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.
    
    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 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.
    
    Proving a brief summary and citing in the sec considerations seems good to me.
    
    >> * 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.
    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.
    
    >> Best,
    >> Xiaoqing
    >> 
    >> On 8/16/19, 9:54 AM, "Colin Perkins"<[e-mail]>  wrote:
    >> 
    >>    Hi,
    >> 
    >>> On 16 Aug 2019, at 13:59, Mirja Kuehlewind<[e-mail]>  wrote:
    >>> 
    >>> Hi Sean, hi Gorry,
    >>> 
    >>> Thanks for your review and feedback. Please see below.
    >>> 
    >>>> On 13. Aug 2019, at 09:56, Gorry Fairhurst<[e-mail]>  wrote:
    >>>> 
    >>>> 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.
    >>> 
    >>> 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.
    >>> 
    >>>>> 
    >>>>> 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?
    >>> 
    >>> 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”).
    >>> 
    >>>>> 
    >>>>> 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.
    >>> 
    >>> 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.
    >> 
    >>    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
    >> 
    >> 
    >> 
    >>>>> 
    >>>>> 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
    >>> 
    >>> 
    >>> 
    >>>> Gorry
    >> 
    >> 
    >> 
    >>    --      Colin Perkins
    >>    https://csperkins.org/
    >> 
    >> 
    >>