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

"Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com> Fri, 16 August 2019 16:46 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 46A831200F4; Fri, 16 Aug 2019 09:46:24 -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=Of+QzBiz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ESbLMYzS
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 8KgSydd2lB_1; Fri, 16 Aug 2019 09:46:21 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9614112080A; Fri, 16 Aug 2019 09:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7912; q=dns/txt; s=iport; t=1565973977; x=1567183577; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=viwF8u8G3IIDe1c97ffQEwoWPqzBLgp8Vq7usiVoJUM=; b=Of+QzBizV1cZS+rcJEjDj5DIjmPdEsb43GaccW9Cvu6jKtN2AXb71CaJ 5cKAIxb/Smu09fo3OfCCu4EJW5wf4lzAtZUAH0VsB8GksUUOzNZJ9GeFI xuDsaOFw2TukXTs2qhrUAmS09xihoZLCHkGJopuWydrC9h7M58AmqMQrx c=;
IronPort-PHdr: =?us-ascii?q?9a23=3AOyNS1ha1Gp0wTYuu+hs8UNT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8Kav6biU9BdZCSXdu/mqwNg5eH8OtL1A=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAAD53FZd/4MNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBRFADbVUgBAsqhB+DRwOKdoJbl2OBQoEQA1Q?= =?us-ascii?q?JAQEBDAEBGxICAQGEPwIXgwMjNwYOAgUBAQQBAQECAQYEbYUnDIVKAQEBAQI?= =?us-ascii?q?BEhERDAEBKQ4BDwIBCA4KAgIRFQICAjAVEAIEAQ0FIoMAAYFqAw4PAZ8ZAoE?= =?us-ascii?q?4iGBzgTKCegEBBYUGGIIUAwaBDCgBi2gXgUA/gREnH4JMPoN/XCiCTDKCJo5?= =?us-ascii?q?kMZtYZwkCgh2GZI1PG4IxhzCKRYQcjVeHYZAmAgQCBAUCDgEBBYFmIoFYcBV?= =?us-ascii?q?lAYJBgkIMF4NPhRSFP3KBKY15AQE?=
X-IronPort-AV: E=Sophos;i="5.64,393,1559520000"; d="scan'208";a="308640533"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Aug 2019 16:46:16 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x7GGkGUW004848 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Aug 2019 16:46:16 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 16 Aug 2019 11:46:15 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 16 Aug 2019 11:46:15 -0500
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 16 Aug 2019 11:46:14 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DEPdNytYhkVw1h5GrIiMhCTxzrVvU0+DauZtQmIf5A34WUyTgrzTx/6XV/RsmU+oy0gZ87reDwzqo4cdC/0lqNIQeVC95SmOE/iqojB2VV6TDJhBT0co4xzk54y7heeqwnLFFRY/Dt4rOTwIBViLqBgEXh/nM9FvrvjwKiUtAZyQv42/FNdLTXvrDhe+fH7ogeMNXBkUltfZWPfcGBqVggNeW+4OD3kaO8EFU2Q5ycMNlx/BSkE1S/4S7kmr9Spt1tu4yQMnR8HyNnQdjT58QNa5NlaTtIpcZ/zu3Pe4u/9+xTbOkT4TApVOLaR/tStNL+6TN3BGk4m5ufPrpKLG7w==
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=viwF8u8G3IIDe1c97ffQEwoWPqzBLgp8Vq7usiVoJUM=; b=TT+JXG9J0VLXER/RGNqry67hMkzYyH1g2Ez2Ytuij+AdgFh/t+cg1K751KM4Nzej2nbcxesJzXZLQP2ZNOQl5IqkuM2LIRGKCehCiHS9HQuEaf9sujPNH7mnABZ9kfb1UyEOw7mXXQhGtUkJklGH8oXZsEDAKH+nnNcR3n0GOaSF0/770PCT7ifU4GiOxulw4KQbhGmJt+2gwyHyUKeBRifZW0wi87ir+uDKgGNHC8u/jkQWncKU9T24e/NnwTMtAwM5P1ZMzmjL6ztjfQZNa4FUpXJBBWGP/ZODmWbjDnXPT8GGXyeZ8e+10XFAg3199RTOIWq0DCyKyJqSy+u7sw==
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=viwF8u8G3IIDe1c97ffQEwoWPqzBLgp8Vq7usiVoJUM=; b=ESbLMYzSTOAgY4jWPmqgT26ySxgMTMItJ8UD0JHSXPP48c7n9z6wCfRQiJnXuSvn2SMXPO6/ybh+1WQBN5Byoc8teJzmfHSlKywSZgN90CF6iAS1BrCOU1L6q40J7vPVIsucsgSayvub3zjCf2FrJaz8XGTpT3Hf2vGF0dtnK74=
Received: from CY4PR11MB1559.namprd11.prod.outlook.com (10.172.72.140) by CY4PR11MB1400.namprd11.prod.outlook.com (10.169.254.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.16; Fri, 16 Aug 2019 16:46:13 +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.2157.022; Fri, 16 Aug 2019 16:46:13 +0000
From: "Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com>
To: Colin Perkins <csp@csperkins.org>, Mirja Kuehlewind <ietf@kuehlewind.net>
CC: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, 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>
Thread-Topic: [rmcat] Secdir last call review of draft-ietf-rmcat-nada-11
Thread-Index: AQHVUXOlEGdHcdwXkkGy8eFbeJEvyKb4tnUAgAULjoCAAB/9gP//y4AA
Date: Fri, 16 Aug 2019 16:46:13 +0000
Message-ID: <865425B9-FF34-45F6-89C4-2C2D79741382@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>
In-Reply-To: <2EB42977-16EF-46AA-B1E8-EA4C420FA51A@csperkins.org>
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:1402:1250:5f1:23c7:f2d9:d83]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7cee6ce4-c5c5-4e78-7499-08d72269401f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR11MB1400;
x-ms-traffictypediagnostic: CY4PR11MB1400:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <CY4PR11MB140051424AD6C9234D4DEC49C9AF0@CY4PR11MB1400.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0131D22242
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(39860400002)(366004)(346002)(199004)(189003)(316002)(102836004)(53936002)(186003)(58126008)(478600001)(5660300002)(71200400001)(305945005)(66446008)(7736002)(71190400001)(66556008)(229853002)(486006)(33656002)(76116006)(91956017)(54906003)(66476007)(6512007)(6436002)(6306002)(6506007)(86362001)(64756008)(966005)(36756003)(6486002)(53546011)(476003)(81166006)(2616005)(4326008)(446003)(14454004)(6116002)(2906002)(8936002)(76176011)(66946007)(6246003)(46003)(110136005)(25786009)(11346002)(81156014)(8676002)(99286004)(256004)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1400; H:CY4PR11MB1559.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: 9G5eEOg1tyeJyJ3p62NE9je+1hREdICBozm40PmvNw7OZNuH5R4bYrCHWDHJVf4U6UL6mFFqyYqUd5VYTQbFdMkeFWmABqmjDYQsBS+DrZuuNeH8NA+TmXcUX4qA++ZEgdTV3lUW4pfaysRqsDw/VvdFCZaJagAUcSmyx2vJk3vLv0AlpCkFVXaFNGVizbO+Kpo+x1wo7YfTsPkrsGPvS8kWPSZXWz5GHjHHpqaPPEb9NMVx7q6ANEjY7zbHMKdij7XuFIG8smdUNEBCHd3VupJ/KBrlB6HRvZ5963FqdLSbK9CnRxKHtTDMhbE360xEr4grGGrJAlivjbzdspID5oBr1mJe7nSe6EhxBIDjRPKoJ/t7YFz9cw8SKoHWaAlw8X8GXpF/xd+EqIDNUFbHTe6QOV5GGDyMRJ4sbw3b6lY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <BCD8E7CD7027B545916B86BF321BFCEE@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7cee6ce4-c5c5-4e78-7499-08d72269401f
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2019 16:46:13.7858 (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: XibhuGt/kXeZJJsrRqksaxxNalG/8ozmHHzBXG1bEgCZNCIdKgUQSsaOjsCx6oemGuvu5Ik0ve1YwbtRLO9ztw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1400
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/yACjzacmPSgGgP2nAqSohGJDMc4>
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: Fri, 16 Aug 2019 16:46:25 -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" <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/