Re: [AVTCORE] RTP Header Extension Encryption

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 17 September 2020 15:42 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348193A046D for <avt@ietfa.amsl.com>; Thu, 17 Sep 2020 08:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
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 XYaOC3fgq2Yr for <avt@ietfa.amsl.com>; Thu, 17 Sep 2020 08:42:24 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2045.outbound.protection.outlook.com [40.107.223.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB8A3A09F5 for <avt@ietf.org>; Thu, 17 Sep 2020 08:42:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NB4Xs2d3IhaH42m9lVmBU3D5GL4jg0Z6Dykfv8IkI/oIco2+3RTmJGQ0fhVsO8/oH5UpoIq4Tj3bYUDs7qTcIV4ZV4Zdqdvpxc65l6vD+7xafvdZnMKZ3oN4uI7ZPUzWBaVn9kLxo6CkYLrB2bPmzDLSDI+/pp1X+zaFlnW76UjuGejStVHbu518yO1Q1jskIhSnamS8WpJ/hM7YwRaOh+wNARyfkZWsT1DzSRgJgdoKAIckT1swkmZ3JRx2+V2fvTAbP2WGw1Z3OOX5j2hbXdk3vIhvUN52RfcYMuTu0hed71IoqDj/zpUkdiQEDK9IOuOJI/qANB0d/VX492WlHA==
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=50U5mJTIzVOmPGuVhazemNoLWdDC9RIQqTzoQORqFLA=; b=HVNEx+sLu+iPWd3LzGf1hPQOk2ChJVb/4A65T8jI0ZKYreOE49AB6ohX6Pcw6WbMgNg22R0vS7+rtsL00g/grKrr7A9yo0PfXYr6tZAL909he04HrfrRdbB4JZvz9imRxhedEr46I9sjCLe3nCLEMnmOtRO8jwGlEx0kESYXQ/vLW3f3rhciHyh4Dlwow9X0zp6O98DWAR7Q5BYB7vkl3z/PNUyjjz2P7Ln/LOKh62ZEMU28HDS6GYraust64MUwM/n/ikQl4fzoz6pCWXrpTaSfgyqW6dDX03r7eYcGRB2dXVQRJmuGl/K4JQsGAK4/x/oWFuV/69OAhCYB1eO6og==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=50U5mJTIzVOmPGuVhazemNoLWdDC9RIQqTzoQORqFLA=; b=DhEkwSankAlmJiLJ1YGoxO9kPk7l9WhjDUd4TtzAT1C9jGydzUF86XwdeS2Ezahw8cDko4ASSBvNusflpmt8VaAVHckYmLyBHokiq1GBMogaqA/3PLGjCOiOBUOQNLREWkRSN+icDqnKtZfSm5eCOCAiIvZjbwHw/cVFz1uFa3w=
Received: from DM5PR05CA0021.namprd05.prod.outlook.com (2603:10b6:3:d4::31) by MN2PR12MB2879.namprd12.prod.outlook.com (2603:10b6:208:a9::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Thu, 17 Sep 2020 15:42:22 +0000
Received: from CY1NAM02FT030.eop-nam02.prod.protection.outlook.com (2603:10b6:3:d4:cafe::51) by DM5PR05CA0021.outlook.office365.com (2603:10b6:3:d4::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.8 via Frontend Transport; Thu, 17 Sep 2020 15:42:22 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT030.mail.protection.outlook.com (10.152.75.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15 via Frontend Transport; Thu, 17 Sep 2020 15:42:21 +0000
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 08HFgJd3031109 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <avt@ietf.org>; Thu, 17 Sep 2020 11:42:20 -0400
To: avt@ietf.org
References: <CAOW+2dvo8z422LFeP5S652bq8RkF-SKhik=aXYXpTe9zqBX5yw@mail.gmail.com> <CAOW+2dt_A+A1AVnTUQyB4sTG5hMCv7Gf3-rrBB89LR-oacX=Rg@mail.gmail.com> <c390c256-3b4f-5c4d-0e2f-a784acec663c@alum.mit.edu> <CAOW+2dvAJSvAZmwNdYyGASj8Y5dptt8L6B9YrU3RMNrwP2ShGA@mail.gmail.com> <e94134bc-e411-1bdb-44cf-3cdf34f38044@alum.mit.edu> <a94e06f512bea37100179f6601df363ef9ad207e.camel@ericsson.com> <db1eb25e-a9ca-7005-a547-bd0ac9d67b4b@alvestrand.no> <f43686a846de09961d1c582f901655a93df384cc.camel@ericsson.com> <361477055a9b40788080613459f6675147bce9d6.camel@ericsson.com> <7ab7efea-d79b-7870-1feb-e499179ca7a8@alvestrand.no>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <97ea4546-4190-4c91-899d-3134cfabf76d@alum.mit.edu>
Date: Thu, 17 Sep 2020 11:42:19 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.2.2
MIME-Version: 1.0
In-Reply-To: <7ab7efea-d79b-7870-1feb-e499179ca7a8@alvestrand.no>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 9f2ecba0-34d4-42e6-c953-08d85b20446d
X-MS-TrafficTypeDiagnostic: MN2PR12MB2879:
X-Microsoft-Antispam-PRVS: <MN2PR12MB28795C6CAB0A3714CBA4979FF93E0@MN2PR12MB2879.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:8882;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: J5aUlr6lSaxIaTsjIYQgHbcg77KLNA6S9Fu2iAUTacr2HZp6DkWH8FyodqZuhyvOY9O9d8vDrLkDFrXua9Wmczvz6iz5KNLfXFNso+GLVe6omk1BZFo/cq/O8YBGG00RrE5Q9kjs2yqL5lK7/TElz7yvLYETBu1TuxwQNLuPDNDEtn780AYahVq3F03SmzKAyGlQjvFZi+XCT14gYREtHfvD4eNHA6YURBB//C7XtOAybDh9q+vFlKVOQhv5zxdr1iELb5mmXiGFUewwu6gzXuV/FfoKv1IveSAt19McU/zPAC1UnG2usIf52KOxCe/NpDNjFmBuyGzv4xwvrzDGCfulJccjvpxwrrMAZjBu1u13yVF4fRl+0F3bebKUTO4uditRDv0u+cjzbJjWBC4mcJ+NRH9sF7NoLmAZC/fLhyY=
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(39860400002)(136003)(396003)(346002)(376002)(46966005)(316002)(47076004)(70206006)(86362001)(70586007)(31696002)(5660300002)(26005)(53546011)(956004)(82740400003)(2906002)(186003)(2616005)(8676002)(356005)(6916009)(82310400003)(8936002)(786003)(478600001)(336012)(7596003)(36906005)(75432002)(31686004)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2020 15:42:21.6172 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9f2ecba0-34d4-42e6-c953-08d85b20446d
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT030.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB2879
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/BdVk63kTZtxYqPMAz1KyXROGoOI>
Subject: Re: [AVTCORE] RTP Header Extension Encryption
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2020 15:42:25 -0000

On 9/17/20 8:42 AM, Harald Alvestrand wrote:
> 
> On 9/17/20 10:26 AM, Magnus Westerlund wrote:
>> Hi,
>>
>> A Clarification to the RTP session definition.
>>
>>>>> The term in the RTP vocabulary that makes sense are to have header
>>>>> encryption
>>>>> configuration be applied on the RTP session.
>>>>>
>>>>> A boundle group will be one RTP session as they share BUNDLE Transport
>>>>> parameters.
>>>>
>>>> I think this is wrong. An RTP session can cover multiple transports 
>>>> (and
>>>> will, if you don't use BUNDLE).
>>> In what context? Yes, the generalized definition of an RTP session is 
>>> the set
>>> of
>>> RTP + RTCP packets sent and received over a set of transport 
>>> receivers and
>>> transport destination as specified by some type of addressing.
>> That share SSRC space. It is the SSRC space that is the core of the 
>> RTP session.
> 
> 
> Yep.
> 
> When using WebRTC, we are using BUNDLE, and the BUNDLE spec says that 
> media sections can move into and out of bundles.
> 
> When they move, there's nothing anywhere that says they change SSRCs.

IIUC when they move in and out of bundles they are implicitly moving 
among different SSRC spaces, though they may still retain the same SSRC. 
(As long as there is no conflict with the space they are moving into.)

Maybe WebRTC needs to say more about this.

> So my interpretation is that everything inside a WebRTC media 
> description (unless it refuses bundling altogether) has to be part of 
> the same RTP session.

What does a webrtc media description correspond to in sdp terminology? 
Is it a session description?

Because it is really problematic to make this restriction across a 
complete session description. (These can be composed from media 
descriptions that terminate on different servers.)

One question is how to represent this in sdp so that it is consistent 
across the intended scope. If the scope is a bundle group (or unbundled 
media description) then it might make sense to represent this as a 
separate attribute that has a mux category of IDENTICAL.

	Thanks,
	Paul