Re: [AVTCORE] RTP Header Extension Encryption

Harald Alvestrand <harald@alvestrand.no> Wed, 16 September 2020 10:33 UTC

Return-Path: <harald@alvestrand.no>
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 F3ED63A0FA3 for <avt@ietfa.amsl.com>; Wed, 16 Sep 2020 03:33:44 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 KDt-ULJoWFqX for <avt@ietfa.amsl.com>; Wed, 16 Sep 2020 03:33:43 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552813A0FA1 for <avt@ietf.org>; Wed, 16 Sep 2020 03:33:36 -0700 (PDT)
Received: from [192.168.3.157] (unknown [188.113.93.42]) by mork.alvestrand.no (Postfix) with ESMTPSA id 38E1F7C5D7B for <avt@ietf.org>; Wed, 16 Sep 2020 12:33:35 +0200 (CEST)
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>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <db1eb25e-a9ca-7005-a547-bd0ac9d67b4b@alvestrand.no>
Date: Wed, 16 Sep 2020 12:33:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <a94e06f512bea37100179f6601df363ef9ad207e.camel@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/H2P65FOqSkzOLgt7dXH-HCyZi9I>
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: Wed, 16 Sep 2020 10:33:45 -0000

On 9/14/20 9:41 AM, Magnus Westerlund wrote:
> On Fri, 2020-09-11 at 15:48 -0400, Paul Kyzivat wrote:
>> On 9/11/20 3:00 PM, Bernard Aboba wrote:
>>> Paul said:
>>>
>>> "Can you please clarify the scope for which you want the encryption to be
>>> consistent? Above you variously mention all MIDs and all m-lines. I'm
>>> concerned with what "all" applies to.
>>>
>>> I think I can agree if you are talking about "all within a bundle
>>> group". Anything broader has major problems."
>>>
>>> [BA] Thanks for pointing this out.
>>>
>>> Mixing unencrypted and encrypted RTP header extensions within a bundle
>>> group is problematic because all of the RTP packets arrive on the same
>>> port, and the receiver needs to know the MID (which could be encrypted)
>>> in order to figure out which packets should have encrypted and
>>> unencrypted RTP header extensions.  But if you have different bundle
>>> groups, then it is possible for each group to have different settings
>>> (e.g. encrypted RTP header extensions on one group and unencrypted RTP
>>> header extensions on another bundle group) without that problem
>>> arising.  So this is an argument only for consistency within each bundle
>>> group, not for requiring all bundle groups to have the same setting.
>> I'm feeling we need a new term here. It has to cover a bundle group as
>> well as a single media-description that isn't bundled. Is there a term
>> for this within the RTP vocabulary?
>>
>>
> 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).


>
>
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt