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

"Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com> Sun, 25 August 2019 04:30 UTC

Return-Path: <xiaoqzhu@cisco.com>
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 E88901200EF; Sat, 24 Aug 2019 21:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=T5tro9eM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lgBirywa
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 QEkqocxzOvV0; Sat, 24 Aug 2019 21:30:36 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565AD1200D8; Sat, 24 Aug 2019 21:30:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10154; q=dns/txt; s=iport; t=1566707436; x=1567917036; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N4NwseiFJxSRuYLYS/xrMyn4o4h6FDV3xgufTiz4pqQ=; b=T5tro9eMDM8MPjGGZsedvmIrbun0DY83IOgdjeDY8C+rNnXVSvikAhJ3 0bq3PgXJcBwlmIhc15IsrswMND5rEO2lVnocLEJbt/DIvrKxv09p8DAIo AQ98Y8qyZhArFMDiSaLmPe3sBIgiLlx7x1UUMfaNH/YVPyHh91hao49Ih 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AZSotxBN3fmdv1gjRCyol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjrLfftdj46AexJVURu+DewNk0GUMs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYBwCYDmJd/49dJa1aCg4OAQEBBAE?= =?us-ascii?q?BBwQBAYFngUVQA21WIAQLKoQhg0cDimyCNyWXaIFCgRADVAkBAQEMAQEbEgI?= =?us-ascii?q?BAYQ/AheCUCM4EwIKAQEEAQEBAgEGBG2FLQyFSgEBAQECARIREQwBASkOAQ8?= =?us-ascii?q?CAQgYAgIRCA0CAgIwFRACBA4FIoMAAYFqAw4PAZ5zAoE4iGFzgTKCewEBBYR?= =?us-ascii?q?+GIIWAwaBDCiEe4IEgiqCSRiBQD+BEScME4JMPoN/GisXKIJMMoImjmsym2p?= =?us-ascii?q?nCQKCHoZqjVkUB4IyhzCKTmKDPY8ehjWQOwIEAgQFAg4BAQWBZyGBWHAVZQG?= =?us-ascii?q?CQYJCDBeDT4UUhQQ7coEpjhcBAQ?=
X-IronPort-AV: E=Sophos;i="5.64,428,1559520000"; d="scan'208";a="620695168"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Aug 2019 04:30:13 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x7P4UDQ4031438 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 25 Aug 2019 04:30:13 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 24 Aug 2019 23:30:12 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 25 Aug 2019 00:30:11 -0400
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 25 Aug 2019 00:30:11 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DTqBzE1Rln80KcYB28Tc2mBa0VuIH2LjTT/SM+3yro0eVMppP8thZV3Buk6tUtpiC6bAuY6DbRgUp3VEGs9l7WZfWdezf8IyRR6RVKEhP3DhL2y7suZTQI4baGQAS7AZM1WjsqjyT1IQLC47d41TpgUFoLcMFfVGU0s8wKd/q84v1RSe0VYp8WBCp66rTKVwl3ISwaf9Wq0q7iP+WJgD29kVAs4//4TWFFB/TcLEbk9jAs+IidRA1D4PpKJtE5X90OYa8WH8WgU9TopXjq59R40Jp2f71SguEWjXd17B8iC+ZvVw13coGbOrN+UNGONs8Hndr9j2/mlNEHUUxTASeg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N4NwseiFJxSRuYLYS/xrMyn4o4h6FDV3xgufTiz4pqQ=; b=FA9OlsiZRvIk9lU3zstyQyeES+wajbYXSH+dabepYFRvoXCO91stg8hUd2A7s+rTNQ8mXRH/qCwLeTzplmHCXLo/41iVgdZP4TO4WXVHMfVYu57qHIbCbuxruVMyCcTcv2qDK8Gv2t1iKTrK2yPTjZCMjrMJ//srdtANYfv1YP/wNBi9k/8beb4/120+A9A2w+6MjOP1HGaj6r4iyf2k2XujZfxxC3+OUYhV2EUSlw4DwRiuOMm+EPXGL2NYsIutP8JrYIoYRWDtE01ffQwoQbnc/lNKCxOUxJblWkAw/QzLh5dpIyQkPq5twz+eAP1ufiOkudP6X10zgNBZLUjIGg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N4NwseiFJxSRuYLYS/xrMyn4o4h6FDV3xgufTiz4pqQ=; b=lgBirywarWUqCve9M7NXMqdNSvM0L8akUu6BK9jXedNigjVvwyby25YlQlo4Yi0PI1guveX3+5m6d7UWDhpwG6ew6YjSyMrKsLXyUmaaLmSIj1GXhZYZqZ2LtQhOHCgVt6wA/a8j1BbRKrO3MgV2zhjfEd6hUKcc8xABFmBAgAY=
Received: from CY4PR11MB1559.namprd11.prod.outlook.com (10.172.72.140) by CY4PR11MB1382.namprd11.prod.outlook.com (10.173.16.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Sun, 25 Aug 2019 04:30:09 +0000
Received: from CY4PR11MB1559.namprd11.prod.outlook.com ([fe80::53:33f3:ea63:7f72]) by CY4PR11MB1559.namprd11.prod.outlook.com ([fe80::53:33f3:ea63:7f72%3]) with mapi id 15.20.2199.020; Sun, 25 Aug 2019 04:30:09 +0000
From: "Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
CC: "draft-ietf-rmcat-nada.all@ietf.org" <draft-ietf-rmcat-nada.all@ietf.org>, IETF <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "rmcat@ietf.org" <rmcat@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, Colin Perkins <csp@csperkins.org>, Sean Turner <sean@sn3rd.com>
Thread-Topic: [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11
Thread-Index: AQHVUXOlEGdHcdwXkkGy8eFbeJEvyKb4tnUAgAULjoCAAB/9gP//y4AAgAFbUICAADJAAIALycMA
Date: Sun, 25 Aug 2019 04:30:08 +0000
Message-ID: <E699E5A5-C365-445D-9872-8AF81514A9BD@cisco.com>
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> <5D57BADD.8080508@erg.abdn.ac.uk> <E6CE6322-6F13-4188-90BD-03C6EB7F87D9@erg.abdn.ac.uk>
In-Reply-To: <E6CE6322-6F13-4188-90BD-03C6EB7F87D9@erg.abdn.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=xiaoqzhu@cisco.com;
x-originating-ip: [2001:420:c0cc:1007::f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 41d80ab7-64f3-4737-c84b-08d72914e9da
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR11MB1382;
x-ms-traffictypediagnostic: CY4PR11MB1382:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <CY4PR11MB13826CD280622CEC63955694C9A60@CY4PR11MB1382.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 01401330D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(39860400002)(136003)(366004)(189003)(199004)(31014005)(186003)(966005)(256004)(14444005)(14454004)(478600001)(476003)(71200400001)(71190400001)(76176011)(25786009)(6246003)(11346002)(486006)(6436002)(46003)(102836004)(446003)(53936002)(99286004)(6506007)(53546011)(5660300002)(4326008)(6306002)(6512007)(296002)(316002)(58126008)(33656002)(54906003)(2906002)(6116002)(81166006)(8676002)(81156014)(2616005)(8936002)(6486002)(7736002)(305945005)(229853002)(76116006)(91956017)(86362001)(66446008)(6916009)(36756003)(64756008)(66556008)(66946007)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1382; H:CY4PR11MB1559.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: +xDiLi4Sa7OigHXlxSpKMRJ8LNJUgrI+ywPNIcVtvHN2shv4TD0Nw0+lDusSno3UYSODnH9xEbKzyqBASrWJho9CZe3YKNv2uewHOjnqkGYXle/mWB9gn3kOLpmzn1tsZ7jsjdaRZyPo1WWvaoe16INJRqmSEkvg5WiE1EN+Us6of8JeCVu+j2eAZNUjR/QKH/toGl/56UsYE5Gg2x95nqSLLre+lsW1nlGaxFl2qG3baAExQuKMHlfqO03p5fV5lWgeSQ7c9f62HwSlDUq2ZCnxO7IY+8UQNs2bIlmEf2/NFyLiq1t7btsTZtHIdbcDsLxwuNH06sSg0y6IStbn5O6FdWHotjDeGmarLLQAMwS3dqrUEbQ0RZJZXgleo5KKn9MU4MMeLE5NKbQdiu4gN2mwYh9TGog8UM/4mHzFl48=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <FEAB3C5A6DC72049820E5A294D2A3BC3@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 41d80ab7-64f3-4737-c84b-08d72914e9da
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2019 04:30:09.3749 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Grw02r8NJqQc+rMiGREOwzrSdUIKnEvWiJuBPfIuMyDh3DkERI38sIlFax+d6zFDW35p8VxvR3fEJ8DWZ17IOg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1382
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/5ZQKqdCAsoMFjO1KKkYLmsGyruI>
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: Sun, 25 Aug 2019 04:30:39 -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" <gorry@erg.abdn.ac.uk>; wrote:

    
    To be clear, see notes below.
    
    Sent from my iPad
    
    > On 17 Aug 2019, at 09:29, Gorry Fairhurst <gorry@erg.abdn.ac.uk>; 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"<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/
    >> 
    >> 
    >>