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(_at_)ietf(_dot_)org mailing lists by 2017-01-12. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)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(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------