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

"Roni Even" <ron.even.tlv@gmail.com> Sun, 15 January 2017 06:05 UTC

Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC691289C4; Sat, 14 Jan 2017 22:05:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 f0tkCCDLtLbN; Sat, 14 Jan 2017 22:05:28 -0800 (PST)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E447127076; Sat, 14 Jan 2017 22:05:28 -0800 (PST)
Received: by mail-wm0-x241.google.com with SMTP id c85so22111047wmi.1; Sat, 14 Jan 2017 22:05:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=xkrEAQ2uQGhuSN6upJYoqwzb4ZMUX/KWNLTwXmKib14=; b=CGZKcz+CQpowEA4d7RGgiBxYhCEHn+uUTEoIpVs4w3PreBWjXim+/4fxsME82W8xK4 gZm8XBptG9nDKojRBD6k5eTh1rszLwGmfbr9Q+ryB+/WDwYhmEP3Gd8V+BtjrNbBtXtS FBX+CxQEoCtrC+r11BaZL9z1lP/WKCGZFJWr/72Je5R9QJDncI+lWWi7J230KeHE35IL TE2ZpvesQEVYSJnb20Lp/UvMs9dtIkPMB5mAJ6rYh/vxT8lOsTF2PyT5Bf2q7DtxRs6d /VfsrdScWh6StJ8NUh6upjE2PxS+Es9x8fv3yHCCy2wixWrLpgDIJsKoz0d1ttm7LsgK vypg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=xkrEAQ2uQGhuSN6upJYoqwzb4ZMUX/KWNLTwXmKib14=; b=iij48BwFVuP2452/JL8KQvi1kPIDmzr9tbniJf2UbhquHPZneJyQcIeacCOY+Si79f Hy7rSEkLt4Js2DWGs9XAMNLwkcDhcXJgVCAkmoXQEkhylVqnYvWzYbVAm7iyTUFfr2Xw aFSKJwjPKfBRMSDff9S5F3VUBsvUTeQzJKtgECh1Hd3tvP1CKLzrDn5CK6Uw0/BzGCnj tnfoSQaL+MR4onumcX1JHWVlPJFG6sCG2IZ0Z6C7mtFHqNMaJG+1Wr9glSLTerYvbcy7 PyBB2Zdm6+GHz3+H8KN4VJuv8VwqFHHf8yHv5/N8J6YjEeIskRww8XMoKz0OmHvfVlOT uQHA==
X-Gm-Message-State: AIkVDXLOm4RURP/hs01fHae+oIY/haeea35/D2JBnLqovcbc1wU9LfC37It5evltMPjkGA==
X-Received: by 10.223.130.204 with SMTP id 70mr18382305wrc.128.1484460326869; Sat, 14 Jan 2017 22:05:26 -0800 (PST)
Received: from RoniPC ([2.53.141.242]) by smtp.gmail.com with ESMTPSA id s20sm18224936wmb.9.2017.01.14.22.05.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 14 Jan 2017 22:05:24 -0800 (PST)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>, <ietf@ietf.org>
References: <148244150608.26135.13003140554574277685.idtracker@ietfa.amsl.com> <e62d8fea-692f-2463-3fce-e9bfbc87293c@ericsson.com>
In-Reply-To: <e62d8fea-692f-2463-3fce-e9bfbc87293c@ericsson.com>
Subject: RE: [clue] Last Call: <draft-ietf-clue-rtp-mapping-10.txt> (Mapping RTP streams to CLUE Media Captures) to Proposed Standard
Date: Sun, 15 Jan 2017 08:05:22 +0200
Message-ID: <001901d26ef5$5c91af20$15b50d60$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIponXJa9st+OXyo8A7i9lppNYssAHLDuQ3oHxKP1A=
Content-Language: he
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/hp4yvTU8KH7JBkH-6-FG6f2kbVw>
Cc: clue@ietf.org, clue-chairs@ietf.org, draft-ietf-clue-rtp-mapping@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jan 2017 06:05:30 -0000

Hi Magnus,
CaptureID here is just conveying the value defined in the CLUE data model
and CLUE protocol defines the security consideration for conveying the
adertized and configured values.
So any security on creating is done in the protocol document

As for the header extension, I will add some text
Roni

> -----Original Message-----
> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Magnus Westerlund
> Sent: Friday, January 13, 2017 2:22 PM
> To: ietf@ietf.org
> Cc: draft-ietf-clue-rtp-mapping@ietf.org; clue-chairs@ietf.org;
clue@ietf.org
> Subject: Re: [clue] Last Call: <draft-ietf-clue-rtp-mapping-10.txt>
(Mapping RTP
> streams to CLUE Media Captures) to Proposed Standard
> 
> Hi,
> 
> 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 protocol.
> 
> 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.
> 
> Cheers
> 
> Magnus
> 
> 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
> > ietf@ietf.org mailing lists by 2017-01-12. Exceptionally, comments may
> > be sent to iesg@ietf.org 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
> > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/
> >
> > IESG discussion can be tracked via
> > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ballot/
> >
> >
> > 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue