Re: Last Call: <draft-ietf-clue-rtp-mapping-10.txt> (Mapping RTP streams to CLUE Media Captures) to Proposed Standard

Magnus Westerlund <> Fri, 13 January 2017 12:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B16F5129B5C; Fri, 13 Jan 2017 04:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qpxvQOG3Hrnr; Fri, 13 Jan 2017 04:22:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 042C9129B5D; Fri, 13 Jan 2017 04:22:41 -0800 (PST)
X-AuditID: c1b4fb25-3f77f980000042ea-73-5878c68f1e9f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id BD.C2.17130.F86C8785; Fri, 13 Jan 2017 13:22:39 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.319.2; Fri, 13 Jan 2017 13:22:21 +0100
Subject: Re: Last Call: <draft-ietf-clue-rtp-mapping-10.txt> (Mapping RTP streams to CLUE Media Captures) to Proposed Standard
References: <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Fri, 13 Jan 2017 13:22:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM2K7tG7/sYoIg4nbrS2+TlrCZrH/1GVm i6cT/7FYPNs4n8VixYYDrA6sHn/ff2DyWLLkJ1MAUxSXTUpqTmZZapG+XQJXxoEFn5gKtihU 7Fin0sDYJ9XFyMEhIWAi0fZRu4uRi0NIYB2jxLxp81kgnOWMEidv/GUHcYQFGhglNn84zdTF yMkhIiAsceTRP3aQbiEBP4mOmcEgYWaBaomZc24yg9hsAhYSN380soHYvAL2Eo03jrCD2CwC qhIPN6xhBbFFBWIk3q5fzg5RIyhxcuYTFhCbU8BfYsLXg2wg45mBeh9sLYMYLy/RvHU22Hgh AW2JhqYO1gmMArOQdM9C6JiFpGMBI/MqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMBwPbjl t+oOxstvHA8xCnAwKvHwFnBVRAixJpYVV+YeYpTgYFYS4S0/CBTiTUmsrEotyo8vKs1JLT7E KM3BoiTOa7byfriQQHpiSWp2ampBahFMlomDU6qBMTrdzMz6spKX+QPBrmtpuulX0x/d7q3Y Ntkz5EpczZU1adsl2qonBZUeKrj23FNlQ1tALmP19Zxzf78emXy6snT/5Kd5R/L+rJLWmnb5 Y5XU6ep/E3xObjgwIedW11ZhS6YVp54KKYaZnXcNNfrBGc1s4MRjKMC8RdR8v4/mxgw79iMf i7XZlViKMxINtZiLihMByEwp5VMCAAA=
Archived-At: <>
Cc:,,, Paul Kyzivat <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Jan 2017 12:22:48 -0000


As one of IANA's expert reviewers for the two registries that this 
document attempts to register in, I want to provide some feedback on 
individual basis and directly.

The SDES item registration of the CaptureID is fine with the exception 
that it isn't clear on the security consideration for the CaptureID 
field as SDES item. I fail to find any limitations or even 
recommendations for how the value is created by the implementation. Nor 
does the security considerations discuss the potential risk that the 
capture ID is privacy sensitive, like "Adrian's Mic" rather than AC0 as 
in the example in the data model document. The data model document is 
fairly clear on the need for confidentiality and authorization for the 
whole data model document. However, this thinking has not been raised 
and clarified in this specific move of the information into the RTP 

So, I would recommend a discussion in general if the field should have 
anonymous labels, that do not contain privacy information. Then one 
needs to be clear on what requirements that puts on transporting this 
field in RTP. And that depends on how certain one can be that it is 
anonymous or that it may contain sensitive information and therefore 
should be confidentiality protected. In all cases this field needs 
integrity and source authentication. Which should be made explicit in 
the security consideration. The clue mapping require implementation of 
SRTP with DTLS-SRTP keying, however, it fails to be specific on which 
protection profiles that are to be supported, both for the SRTP as well 
as the crypto functions for the key handshakes in DTLS-SRTP. Thus, I 
can't be certain if the CaptureID will be confidentiality protected or 
not even in RTCP.

When it comes to the RTP Header Extension case, the RFC 7941 is very 
explicit about the requirement on doing this security consideration. And 
I note that with the above analysis of what requirements to put, one can 
ensure that the right requirements on the CLUE system to protect any RTP 
header extension with the CaptureID is done. I do note that if 
confidentiality protection is needed, this means additional 
implementation requirement. Such needs to be defined in this or 
referenced document if that is the case.

This should be fairly straight forward to fix, but needs to be done.



Den 2016-12-22 kl. 22:18, skrev The IESG:
> The IESG has received a request from the ControLling mUltiple streams for
> tElepresence WG (clue) to consider the following document:
> - 'Mapping RTP streams to CLUE Media Captures'
>   <draft-ietf-clue-rtp-mapping-10.txt> as Proposed Standard
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> mailing lists by 2017-01-12. Exceptionally, comments may be
> sent to instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> Abstract
>    This document describes how the Real Time transport Protocol (RTP) is
>    used in the context of the CLUE protocol.  It also describes the
>    mechanisms and recommended practice for mapping RTP media streams
>    defined in SDP to CLUE Media Captures.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.


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: