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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Feb 2015 16:02:40 +0100

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  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 19 Feb 2015 16:04:09 +0000

Magnus,

>I would appreciate your view of what you see as needed to be supported.

I agree that we will need to elaborate a bit more on that, but it's not 
clear to me if any of the existing topologies that are defined match 
exactly.  The desire to prevent changes to the RTP headers means that 
something else is needed in order to properly forward media (e.g., a 
header extension) and account for packet loss, handle congestion issues, 
etc.

We've been more focused on what we want to accomplish than trying to fit 
the solution into a specific topology.  I think we can get there, but we 
need more discussion as a group.

>solution to specified at a later stage.

The intention was the RTP header extensions and RTCP could optionally be 
encrypted using the SRTP keys exchanged as they are today.  This would 
be done hop-by-hop.  This does not provide for end-to-end privacy, of 
course.  That fits with the goals we've stated in the requirements 
document.  We're not trying to hide the fact that two people 
communicated, for example, but we do not want to disclose what is being 
communicated.

If there is truly a need to encrypt end-to-end such that middle boxes 
cannot gain access to some RTP header extensions or some RTCP data 
fields, I would assert we need to define a way to allow some header 
extensions and some RTCP header fields to be visible hop-by-hop.  We do 
want to enable middleboxes to be able to collect and use RTCP 
statistics, for example.  We also want to allow them to have access to 
any header extension that help facilitate packet forwarding and 
processing.

>I think needs to be described in this type of framework.

This framework is only focused on the media aspects.  The approach we're 
taking here is that there is some kind of exchange that happens between 
the endpoint and the KMF or some other trusted entity that exists in the 
signaling plane.  It is through this signaling that a determination is 
made as to what endpoint can have access to the keys for a particular 
conference.  We expect that fingerprint for the endpoint certificate 
would be exchanged with the KMF and vice versa.

When the DTLS connection is made to the switching conference server, 
that would be tunneled (via a protocol we've defined but not published) 
from the switching conference server to the KMF.  Effectively, the 
endpoint and KMF establish a DTLS connection.  The KMF would recognize 
the user as belonging to a particular conference and provide the SRTP 
keys (using DTLS-SRTP procedures) and the EKT key (via the EKT 
procedures).  One thing I would like to add to the EKT draft is some 
piece of data that indicates what the conference identifier is.  I would 
like the endpoint to convey that information as part of the EKT 
exchange, but no such field exists today.  I would also like the 
conference server to convey the conference identifier for comparison.

So, the framework is clearly not complete even on the media side.  There 
are some editor's notes and perhaps additional items (like the field for 
the conference identifier).  However, I would prefer to keep the 
signaling that happens before this point separate.  The reason is that I 
can imagine that a number of different mechanisms might exists.  For a 
WebRTC client, for example, the signaling might be entirely proprietary. 
  For SIP devices, we then also have to worry with securing the signaling 
exchanges  That's important, but I think that can be done in parallel 
and independently of this media-focused draft.

Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Feb 2015 10:07:11 +0100

Hi,

Please see inline.

> header extension) and account for packet loss, handle congestion issues,

Lets discuss this more, but I like to state my personal position here. I
much rather see the security solution take the current RTP into account,
rather than forcing us to redefine RTP and make changes to how existing
and working mechanisms function. In this case I am especially concerned
your disregard to ensure that the RTP sequence numbers will be sent
without sender side gaps in the sequence. This as it impacts the
existing packet loss detection and reporting mechanisms.

> need more discussion as a group.

I think that is fine, but you appear to have jumped to conclusions and
suggested technical solutions that consider the security goals but not
the RTP implications. Thus, I would suggest that you focus on making
clear the high level security requirements and then factor in the
existing RTP and its impact on possible solutions.

> any header extension that help facilitate packet forwarding and processing.

I fully agree that there MUST be possibility to have both RTP header
extensions as well as many type of RTCP packets to be only protected hop
by hop. The core of my comment is rather that the solution appear to
need to take into account the likely need for end-to-end protection of
other RTP/RTCP fields and actively discuss in its security
considerations the privacy risk from some existing RTP/RTCP protocol
elements, specifically the RTCP SDES items.

> would be exchanged with the KMF and vice versa.

I think that is not sufficient as it can not ensure the security goals
of providing confidentiality. Without explicitly discussing the fact
that there is a set of trusted participants and the need for a mechanism
to verify that a endpoint is representing that such a participant the
solution is flawed.

I fully understand that there is need to enable multiple technical
solutions for verifying that identity, however if the intention is to
provide a framework for solving this issue, the requirement on parts
that are outside of this WGs main expertise, namely RTP must still be
discussed.

> conference server to convey the conference identifier for comparison.

I do wonder about this part of the solution. Why the structure you have
selected? Another potential solution is clearly to run two different
DTLS-SRTP handshakes, one directly between endpoint and KMT, the other
between the endpoint and server. Once more I think you jumped into
solution without motivating why you think the proposed solution is the
appropriate.

> and independently of this media-focused draft.

Fully agree about the need for different signalling mechanism. However,
to me it appears there need to be one or a small set of solution or at
least hooks for how the KMT can verify the endpoint's right to be in
particular session.

I hope that you can take this discussion into account and improve your
framework document to clearer on what you see as the minimal necessary
functions in a solution. And when having established that can go into a
discussion of proposed solutions to realize that.

Cheers

Magnus Westerlund

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 20 Feb 2015 12:49:48 -0800

> existing packet loss detection and reporting mechanisms.

[BA] I agree with Magnus here.   Re-defining RTP is a last resort, and every possible effort should be made to avoid it. 
 
AFAIK, SSRC re-writing is very common in SFUs today, even in simulcast-only implementations.  
Sequence number rewriting is a requirement in all SFUs that support SRST transport for SVC (e.g. VP8, VP9, H.264/SVC, H.265 and H.265/SVC). 
 
In general, it seems possible to avoid these issues by taking the approach advocated in draft-cheng-srtp-cloud:  providing additional fields within the encrypted payload, rather than assuming that the SFU passes the SSRC and sequence number fields unmodified.  
 
The disadvantage of this approach is a potential decrease in the maximum payload size, but presumably the encoder can take this into account.