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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sat, 17 August 2019 08:29 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97D6120108; Sat, 17 Aug 2019 01:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgZQJBdENK5n; Sat, 17 Aug 2019 01:29:31 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 36092120105; Sat, 17 Aug 2019 01:29:30 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id CEB551B0028A; Sat, 17 Aug 2019 09:29:18 +0100 (BST)
Message-ID: <5D57BADD.8080508@erg.abdn.ac.uk>
Date: Sat, 17 Aug 2019 09:29:17 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com>
CC: Colin Perkins <csp@csperkins.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, Sean Turner <sean@sn3rd.com>, "secdir@ietf.org" <secdir@ietf.org>, "rmcat@ietf.org" <rmcat@ietf.org>, "draft-ietf-rmcat-nada.all@ietf.org" <draft-ietf-rmcat-nada.all@ietf.org>, IETF <ietf@ietf.org>
References: <156565849881.20488.4580765481520503258@ietfa.amsl.com> <5D526D4A.5010304@erg.abdn.ac.uk> <8EB353C0-FC34-4514-8283-0D1654EE48DD@kuehlewind.net> <2EB42977-16EF-46AA-B1E8-EA4C420FA51A@csperkins.org> <865425B9-FF34-45F6-89C4-2C2D79741382@cisco.com>
In-Reply-To: <865425B9-FF34-45F6-89C4-2C2D79741382@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/rsK0UQ3kBskFh6gmiTVQWBA301g>
Subject: Re: [secdir] [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Aug 2019 08:29:34 -0000

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.
> * 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"<csp@csperkins.org>;  wrote:
>
>      Hi,
>
>      >  On 16 Aug 2019, at 13:59, Mirja Kuehlewind<ietf@kuehlewind.net>;  wrote:
>      >
>      >  Hi Sean, hi Gorry,
>      >
>      >  Thanks for your review and feedback. Please see below.
>      >
>      >>  On 13. Aug 2019, at 09:56, Gorry Fairhurst<gorry@erg.abdn.ac.uk>;  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/
>
>
>
>
>
>