Re: [AVTCORE] Design choice comments on draft-jones-avtcore-private-media-framework-00 - more comments

["Roni Even" <[e-mail]>]

Hi,
I agree with Magnus and would like to further extend the discussion on the architecture and what is trusted and what not.

To me when looking at what is called switching conference server it seems that this is not a conference server but maybe just an some sort of RTP translator or maybe what we called a media server (RFC5576 section 6) and the MKF is sort of application layer since it does not take part in the RTP session.  The communication between the endpoint and the MKF using external signaling as shown in figure 6 makes the MKF even more appear like part of a conference application server. So to summarize I would think that you describe an decomposed conference bridge and we can look at the work done in mediactrl WG for the architecture. This does not mean that the media server (switching conference server in this framework) should not use a DTLS channel to the application server (MKF) to convey the DTLS negotiation.

Roni Even as individual


> -----Original Message-----
> From: avt [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: 19 February, 2015 5:03 PM
> To: IETF AVTCore WG; Paul E. Jones; [e-mail]; David Benham
> (dbenham)
> Subject: [AVTCORE] Design choice comments on draft-jones-avtcore-private-
> media-framework-00
> 
> Hi,
> (As individual)
> 
> I have just reviewed the draft and are supportive of work in this field.
> However, I have some really high level comments in regards to the design
> choices.
> 
> 1. Supported RTP topologies
> 
> I think you will need to discuss a bit more which RTP topologies that the
> framework should support. The current draft supports only basic transport
> translators (Relay) to my understanding, because of it preventing rewriting of
> RTP sequence number as well as the SSRC. Thus, all RTP streams sent to the
> server must be forwarded to all other participants.
> 
> I believe the intention of the document is to support at least Selective
> Forwarding Middlebox (SFM). However, to support such a topology and be able
> to suspend delivery of some media streams, then RTP sequence number
> rewriting becomes a requirement to keep the media streams compliant with
> current RTP specification.
> 
> Also people who have been building conferencing middleboxes also uses other
> topologies, for example the RTP mixer in also used to build switching mixers.
> Where an SSRC can represent a role rather than a original sender.
> 
> I think there is need to have some discussion of which RTP topologies this type
> of solution intends to support so that one can determine which RTP field
> behaviours that is to be expected and need to be dealt with.
> 
> I would appreciate your view of what you see as needed to be supported.
> 
> 2. Additional privacy concerns in RTP/RTCP.
> 
> The proposed framework protects the RTP payloads and their media content
> from the middle. However, the document fails to discuss if privacy protection is
> needed either for the RTP header extensions themselves or if any RTCP packets
> or their content is privacy sensitive.
> 
> The RTP header extensions that are defined in IETF, as well as the two 3GPP has
> registered appears to be privacy sensitive in any way. However, the big picture
> issue is that RTP header extensions do not require to be standardized. The
> registration requires only an Expert Review, and they are trivial to use for
> proprietary extension. So we have no idea what might be showing up here. I
> could easily believe that someone would for example include a geolocation
> attached to a video stream to capture where for example a airborne drone
> where when capturing the video.
> Suddenly you have data that is privacy sensitive and may require end to end
> protection.
> 
> In RTCP you already today have some parts that are privacy sensitive.
> For example all the SDES items with the exception of CNAME (if generated
> correctly) can contain privacy sensitive data. Also the APP RTCP packet type
> might contain data that needs to be protected end to end.
> 
> Thus I think you need to consider if there are need for additional protection
> mechanisms to realize the goals of this framework. To me it appears that this
> are reasonably straightforward SRTP extensions that could solve these issues if
> they are considered necessary to resolve.
> Even if the initial solution doesn't provide a fully specified solution, I think it is
> important to ensure that the framework do support a solution to specified at a
> later stage.
> 
> 3. What must be in the trusted zone?
> 
> Looking at the description it looks like the solution is missing one important
> part in the trusted zone. That is the list of identities or secret that enables an
> invited / allowed participant to participate in a particular conference. That
> functionality is key component of the security solution. How else is the KMF
> going to be able to determine which asserted identities that are allowed to get
> the EKT, thus being able to get access to the media.
> 
> I understand the need for having solution agility when it comes to identity
> solutions, however the functionality and the requirement on it I think needs to
> be described in this type of framework.
> 
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt