Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 24 February 2017 08:14 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F00129545 for <clue@ietfa.amsl.com>; Fri, 24 Feb 2017 00:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 7-G3nqINXIl3 for <clue@ietfa.amsl.com>; Fri, 24 Feb 2017 00:14:33 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 53290129489 for <clue@ietf.org>; Fri, 24 Feb 2017 00:14:33 -0800 (PST)
X-AuditID: c1b4fb3a-b9bff700000021e0-b9-58afeb67dbf6
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 42.C8.08672.76BEFA85; Fri, 24 Feb 2017 09:14:31 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.319.2; Fri, 24 Feb 2017 09:14:30 +0100
To: Roni Even <roni.even@huawei.com>, "clue@ietf.org" <clue@ietf.org>
References: <148697819872.24905.9378282459902101772.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <8d7ca9a1-b4de-8c3f-833e-c7119c1b7614@ericsson.com>
Date: Fri, 24 Feb 2017 09:14:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD77374B@DGGEMM506-MBX.china.huawei.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2K7um766/URBt8uqVvsP3WZ2eLTsfMs DkweLUfesnosWfKTKYApissmJTUnsyy1SN8ugSvjRuMupoIVyhWtJyewNzCuk+li5OSQEDCR OLS0ma2LkYtDSGAdo0RPYz8rhLOcUWLCmSOsIFXCAm4SJ56eYgGxRQRcJY4s2McOUTSdUWLy 3x6wIjYBC4mbPxrZQGxeAXuJps4DYHEWAVWJ39tWgDWLCsRI7O2/zwRRIyhxcuYTsDinQIjE pHUT2UFsZqA5i98chLLlJZq3zmYGsYUEtCUamjpYJzDyz0LSPgtJyywkLQsYmVcxihanFhfn phsZ6aUWZSYXF+fn6eWllmxiBIbgwS2/rXYwHnzueIhRgINRiYf3w491EUKsiWXFlbmHGCU4 mJVEeLufrY8Q4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64kEB6YklqdmpqQWoRTJaJg1Oq gTE7wXT5R0+l4sP6V/5v2SzsEL44TulK9MkIOS5D5ZtHzxYuzNprUHuAl1Mmq/Rkbu/seaf8 m6eaTpxwMzMr+dzzHytn/WMxj2M9Yex749PFlR3Gx3idftamSc1OqTs7Zd2X5zHp6gKJxu8j VI9cE9QNsoh4Mvl8wiLZcPVVP7cJKz6XZZ9aFKLEUpyRaKjFXFScCADt53F6PQIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/gATk0cIddoWUS5UO6gNVu5ocR0U>
Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Feb 2017 08:14:35 -0000

Hi,

To be clear, yesterday's posting with remaining issues are applicable on 
this version.

That is actually a shortcoming of RTCWeb Security architecture and there 
exists an tracked issue for it:

https://github.com/rtcweb-wg/security-arch/issues/34

So, yes, I would really like to see the communication security section 
mandate encrypted RTCP. This due to the information included in RTCP 
about the application. The protection profile mandated does imply equal 
strength RTCP protection, but if one uses other profiles it might not be 
as clear cut. So a wording on protecting RTCP at same or similar 
protection strength to RTP I think is motivated.

What I also think is missing in the new text is discussion of RTP header 
extension encryption, i.e. RFC 6904. I thought the conclusion on the 
capture ID is that there is no strong generation requirements to ensure 
they don't contain privacy sensitive information. And it definitely 
reveals what is happening in the application context to third parties. 
Thus, I think encrypting the RTP header extensions would be good 
practice in clue situations.

I also reacted to the use of "untraceable" in this sentence:

CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as
    specified in [RFC7022], resulting in untraceable CNAME values.

The point of them is that they are not long term persistent and thus 
can't be used for long term tracking of the user. Writing "untraceable" 
I would interpret as indicating a stronger user protection then what is 
actually provided.

Cheers

Magnus

Den 2017-02-13 kl. 10:59, skrev Roni Even:
> Hi,
> This new version is submitted to address Magnus and Ben comments.
> There is a new section Communication security that specifies normative security for CLUE media.
> The security consideration is just considerations and added text about the CaptureID
> There are also some editorial and nits changes
> Roni
>
>
> -----Original Message-----
> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: יום ב 13 פברואר 2017 11:30
> To: i-d-announce@ietf.org
> Cc: clue@ietf.org
> Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-13.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF.
>
>         Title           : Mapping RTP streams to CLUE Media Captures
>         Authors         : Roni Even
>                           Jonathan Lennox
> 	Filename        : draft-ietf-clue-rtp-mapping-13.txt
> 	Pages           : 14
> 	Date            : 2017-02-13
>
> Abstract:
>    This document describes how the Real Time transport Protocol (RTP) is
>    used in the context of the CLUE protocol (ControLling mUltiple
>    streams for tElepresence).  It also describes the mechanisms and
>    recommended practice for mapping RTP media streams defined in Session
>    Description Protocol (SDP) to CLUE Media Captures and defines a new
>    RTP header extension (CaptureId).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-13
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>
-

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------