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

["Paul E. Jones" <[e-mail]>]

Magnus,

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

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.



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

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.


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

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

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