[Rum] Media security

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 05 September 2019 20:31 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rum@ietfa.amsl.com
Delivered-To: rum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B817120868 for <rum@ietfa.amsl.com>; Thu, 5 Sep 2019 13:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 ubq-yz3IPzRB for <rum@ietfa.amsl.com>; Thu, 5 Sep 2019 13:31:28 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 8742C120271 for <rum@ietf.org>; Thu, 5 Sep 2019 13:31:28 -0700 (PDT)
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 x85KVORF013902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Sep 2019 16:31:25 -0400
To: Brian Rosen <br@brianrosen.net>, =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Cc: rum@ietf.org
References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <a3d82911-8d07-16a3-780b-0592e48e37bd@alum.mit.edu> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <fa8e7a65-d818-58eb-a432-f8a57ed6af95@nostrum.com> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <C4670F1F-4AEC-45BE-9898-06FF2E28A6A9@standardstrack.com> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <D7293188-DC0C-40A8-9514-308566342170@brianrosen.net>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu>
Date: Thu, 5 Sep 2019 16:31:24 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <D7293188-DC0C-40A8-9514-308566342170@brianrosen.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/s_x-5vTIaKZuTn-dznjHZSgcxRY>
Subject: [Rum] Media security
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2019 20:31:31 -0000

On 9/4/19 10:37 AM, Brian Rosen wrote:
> Yes, for sure T.140 (RFC4103).
> The providers have SBCs that anchor media, so they can handle security 
> on one side but not the other.  That’s not a great answer, but it’s an 
> answer.  Transcoding video is not reasonable.

The soon to be released updated version of the Provider Profile 
specifies opportunistic media security [RFC8643].

Also, while providers use SBCs, some of them can set up e2e media for 
point to point calls, where the media won't be anchored and security 
can't be twiddled.

I think this can be a problem if RUM requires the RUE to signal 
mandatory media security, which (I think) WebRTC requires.

	Thanks,
	Paul

> Brian
> 
>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström 
>> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>>
>>
>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen:
>>> I think our consensus is MTI:
>>> Audio: G.711 and Opus
>>> Video: H.264
>>
>>  Real-time text: T.140        (I think you said it is mandatory for 
>> clients, and optional for services.)
>>
>>
>> All these need then transport and security details specified to assure 
>> interop with RUM.
>>
>> How can you hope for backward compatibility with legacy devices when 
>> it is said in RUM that the security requirements must be met?
>>
>> Regards
>>
>> Gunnar
>>
>>>
>>> We need to get into the details of H.264 to maintain compatibility 
>>> with the WebRTC specs and as much backwards compatibility as possible.
>>>
>>> Anyone object?
>>>
>>>
>>>
>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat <pkyzivat@alum.mit.edu 
>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>
>>>> On 9/2/19 4:39 AM, James Hamlin wrote:
>>>>> Just to add: the VRS industry supports a variety of endpoints, many 
>>>>> of which are hardware based and not built by VRS providers 
>>>>> themselves. H.264 and G..711 therefore need to be in the MTI list.
>>>>> I believe the FCC order related to compensation by compliant 
>>>>> providers not that every call had to come from a compliant endpoint.
>>>> Sorry if I got that wrong. I wrote that from memory and perhaps my 
>>>> memory is faulty.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>>> Best Regards
>>>>> James
>>>>> ________________________________________
>>>>> From: Rum <rum-bounces@ietf.org <mailto:rum-bounces@ietf.org>> on 
>>>>> behalf of Paul Kyzivat <pkyzivat@alum..mit.edu <http://mit.edu>>
>>>>> Sent: 28 August 2019 16:48
>>>>> To: rum@ietf.org <mailto:rum@ietf.org>
>>>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01
>>>>> On 8/28/19 11:25 AM, Eric Burger wrote:
>>>>>> I guess the question is whether we want today’s devices to have a 
>>>>>> chance of being RUM compatible. I don’t think anyone will be 
>>>>>> surprised if a five-year-old device is history. Is it realistic 
>>>>>> for current devices to get VP8 upgrade? [Would be nice for some 
>>>>>> manufacturers or others building such devices to pipe in here.]
>>>>> Lets be clear about what we mean by "RUM compatible".
>>>>> When Henning and I were working on this with the providers in 2014 and
>>>>> 2015 there was an expectation that the providers would be required to
>>>>> support the defined RUE devices, but they would also be permitted to
>>>>> support their existing proprietary devices. The RUE devices could have
>>>>> requirements that their existing devices don't meet. But calls between
>>>>> the two were expected to work.
>>>>> There was great consternation when subsequently the FCC issued a
>>>>> proposed order that said only VRS calls involving RUE-compatible 
>>>>> devices
>>>>> would be compensated. (But that was in 2015. I presume it has not 
>>>>> happened.)
>>>>> If there is an intent to exclude non-RUM-compliant devices from use in
>>>>> VRS calls then there needs to be a migration plan to get from here 
>>>>> to there.
>>>>>         Thanks,
>>>>>         Paul
>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen <br@brianrosen.net 
>>>>>>> <mailto:br@brianrosen.net>> wrote:
>>>>>>>
>>>>>>> If we require OPUS and G.711 as MTI and we require both H.264 and 
>>>>>>> VP8 as MTI, then we get backwards compatibility without 
>>>>>>> transcoding and forwards compatibility with WebRTC.  Isn’t that 
>>>>>>> what we want?
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat 
>>>>>>>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>>>>>
>>>>>>>> Inline...
>>>>>>>>
>>>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote:
>>>>>>>>> I certainly have thoughts. The executive summary is that I 
>>>>>>>>> personally believe RUM should specify Opus as the one audio 
>>>>>>>>> codec MTI, and match RFC 7742's "Non-Browser" requirements for 
>>>>>>>>> the video codec MTI. Rationale below.
>>>>>>>>>  From an interop perspective, the important thing is that any 
>>>>>>>>> given profile has (at least) one MTI video codec and (at least) 
>>>>>>>>> one MTI audio codec.. I know there is a strong desire -- one 
>>>>>>>>> that I share -- that these endpoints can talk to/be implemented 
>>>>>>>>> in web browsers without the need for media transcoding.
>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the 
>>>>>>>>> former because it works without transcoding to landline PSTN 
>>>>>>>>> destinations, and the latter because it sounds much, much 
>>>>>>>>> better. RUM could make the same decision; or it could decide to 
>>>>>>>>> move away from a codec that is as old as I am and opt to 
>>>>>>>>> designate Opus as the only MTI. Given that RUM inherently needs 
>>>>>>>>> to deploy into audio/video environments, backwards 
>>>>>>>>> compatibility with the PSTN seems to be unnecessary baggage.
>>>>>>>> Please keep in mind where we are coming from. The RUM will be a 
>>>>>>>> new interface to the *existing* VRS infrastructure. That 
>>>>>>>> infrastructure currently has proprietary devices that serve the 
>>>>>>>> RUE function, deployed to VRS users and to Communications 
>>>>>>>> Assistants (CAs, Interpreters). These have G.711 MTI, and also 
>>>>>>>> *recommend* G.722.2.
>>>>>>>>
>>>>>>>> Making OPUS the only MTI audio codec would be problematic.
>>>>>>>>
>>>>>>>>> For video: While specifying either VP8 or H.264 would be 
>>>>>>>>> sufficient for system interop, and for interop with compliant 
>>>>>>>>> WebRTC endpoints, I'd really prefer not to re-live the WebRTC 
>>>>>>>>> video codec wars. Concretely, what I would propose is that RUM 
>>>>>>>>> indicate that the video codec requirements are defined to be 
>>>>>>>>> identical to those defined for "WebRTC Non-Browsers" in Section 
>>>>>>>>> 5 of RFC 7742. It should be made clear that RUM endpoints *are* 
>>>>>>>>> *not* WebRTC Non-Browsers per se; merely that they comply with 
>>>>>>>>> the same video codec requirements as WebRTC Non-Browsers.
>>>>>>>> Continuing my comment above, existing devices have H.264 
>>>>>>>> Constrained Baseline Profile, Level 1.3, packetization mode 1 as 
>>>>>>>> the MTI codec. Odds are many of these devices aren't capable of VP8.
>>>>>>>>
>>>>>>>> We can't realistically require a wholesale swap out of existing 
>>>>>>>> devices before the RUE defined by RUM can work. We can *discuss* 
>>>>>>>> whether forcing the providers to transcode is a practical way 
>>>>>>>> forward. I'm dubious.
>>>>>>>>
>>>>>>>>     Thanks,
>>>>>>>>     Paul
>>>>>>>>
>>>>>>>>> /a
>>>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote:
>>>>>>>>>> Well, we certainly want interoperability, and I think we can 
>>>>>>>>>> only get that with MTI codecs.
>>>>>>>>>>
>>>>>>>>>> I think we really are talking about a WebRTC-compatible 
>>>>>>>>>> endpoint, but we want interoperability with a WebRTC browser 
>>>>>>>>>> endpoint.
>>>>>>>>>>
>>>>>>>>>> Not sure how to say this.  Maybe Adam can help.
>>>>>>>>>>
>>>>>>>>>> Brian
>>>>>>>>>>
>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat 
>>>>>>>>>>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> draft-rosen-rue-01 changes the video codec requirements. It 
>>>>>>>>>>> now simply references webrtc RFC7742.
>>>>>>>>>>>
>>>>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC 
>>>>>>>>>>> browser", "WebRTC non-browser", and "WebRTC-compatible 
>>>>>>>>>>> endpoint". AFAIK it assumes that each end is one of these.
>>>>>>>>>>>
>>>>>>>>>>> Is the expectation here that both the RUE and the provider 
>>>>>>>>>>> comply with one of these? In particular, that the provider 
>>>>>>>>>>> may simply be a "WebRTC-compatible endpoint? Notably:
>>>>>>>>>>>
>>>>>>>>>>>    "WebRTC-compatible endpoints" are free to implement any 
>>>>>>>>>>> video codecs
>>>>>>>>>>>    they see fit.  This follows logically from the definition 
>>>>>>>>>>> of "WebRTC-
>>>>>>>>>>>    compatible endpoint".  It is, of course, advisable to 
>>>>>>>>>>> implement at
>>>>>>>>>>>    least one of the video codecs that is mandated for WebRTC 
>>>>>>>>>>> browsers,
>>>>>>>>>>>    and implementors are encouraged to do so.
>>>>>>>>>>>
>>>>>>>>>>> Similarly, the audio requirements have been changed to 
>>>>>>>>>>> reference webrtc RFC7874. That one doesn't have the 
>>>>>>>>>>> distinction between "WebRTC browser", "WebRTC non-browser", 
>>>>>>>>>>> and "WebRTC-compatible endpoint". It applies the same 
>>>>>>>>>>> requirements to all. In particular, it requires OPUS support. 
>>>>>>>>>>> I don't know why it doesn't make the same endpoint 
>>>>>>>>>>> distinctions as for video.
>>>>>>>>>>>
>>>>>>>>>>> I think simply referencing these documents isn't sufficient. 
>>>>>>>>>>> Seems like we need a more nuanced specification of what is 
>>>>>>>>>>> required, though we may still reference these docs with 
>>>>>>>>>>> qualifications.
>>>>>>>>>>>
>>>>>>>>>>>     Thanks,
>>>>>>>>>>>     Paul
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> --
>>>>>>> Rum mailing list
>>>>>>> Rum@ietf.org <mailto:Rum@ietf.org>
>>>>>>> https://www.ietf.org/mailman/listinfo/rum
>>>>>>
>>>>> --
>>>>> Rum mailing list
>>>>> Rum@ietf.org <mailto:Rum@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/rum
>>>> --
>>>> Rum mailing list
>>>> Rum@ietf.org <mailto:Rum@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/rum
>>
>> --
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
>> +46 708 204 288
>