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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------