Subject: [Perc] Design Meeting Notes

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 13 Oct 2015 00:30:38 -0700

Hello All

    Many thanks for a fruitful and engaging design team discussion today.

   Also apologies for messing up the meeting time and thanks to the group
for being patient in that regard.

Below, I have included my raw notes with some corrections (based on the
recording).  Please also refer to Cullen's updated slide deck that captures
some of conclusions from meeting today

Here is the WebEx Link : *Play recording*
<https://go.webex.com/go/ldr.php?RCID=96be77d4e5673e8f5412368d95494e31> (1
hr 51 min)

*PERC Design Meeting 2 *

*Attendees*: Paul Jones, Magnus Westerlund,  Cullen Jennings, Roni Even, Mo
Zanaty, John Mattson, Jonathan Lennox, Ram Mohan, Richard Barnes, Suhas
Nandakumar

Cullen presented background slides as an attempt to get everyone on the
same page for the problem space

*General Discussions / Agreements*

  - Trust Model of E2E Conference is we don't trust the middle box.

  - Don't change the security properties of the SRTP unless it is required
for the
    RTP aspects the correspond to security context. [[ref: Security
weakness and lot of thinking went in the design of SRTP]]

  - There are conferences today where MDD doesn't really change the data
while forwarding and with SFU and MSM coming into the picture there might
be few MDDs that will change some aspects of RTP packet. The design should
consider both the scenarios.

  - For E2E there are certain RTP fields (sorry for this nomenclature) that
need to be integrity protected E2E (ex: SeqNo, SSRC/source identifier).
These needs to be placed at some place in the packet. The location for the
placement is not yet finalized.

  - HBH will be based on standard SRTP as the default solution. Future
proposals may be defined  to use non SRTP HBH but the WG needs to decide on
it. For now the discussion is tabled till  the WG tackles core PERC & SRTP
design issues.

*Specific Topics Discussions*

*  Source Identification in the PERC Conference*

   The fundamental point of discussion was to agree upon the definition of
inner source identifier. Options on the table were
      a) locally generated SSRC
      b) out of band assigned Endpoint Source identifier.

   - opening question was - "Does SSRC suffices or do we need a new space
(identifier) as the global scope?".

   Discussion points :

      --  Needed in the context of MDD remapping SSRC and needing to have
the source  identifier binding to the end-point. this enables the receiver
to get the full context of source stream to source end-point identity
mapping

      -- If the trust chain is based on the source identifier mapped to a
DTLS Context mapped to the fingerprint which is in turn identified to an
EndPoint Identity mechanism,then SSRC can serve the purpose of source
identification.

      -- Regardless of what the identifier we call it as, there is need for
some global source identifier space that needs to be maintained E2E

     -- If SSRC is used as source identifiers, we need to have either
global SSRC space or a way of assigning SSRCs to avoid collisions. This
will protect against SSRC rewriting by  the MDD and maintains global SSRC
space for Inner/E2E layer.

      -- Since SSRCs are handled within DTLS context that allows
overlapping, SSRC should be  good enough. DTLS context between the End
point and the KMF should ensure the uniqueness   properties for SSRC across
the conference.

  Conclusions:
      -- Use SSRC as end-point source identifiers as a global scope.
      -- Ensure that the DTLS layer handing over the EKT master key will
partition the SSRC space or maintains the SSRC uniqueness property across
the conference.
      -- How the SSRCs are derived from the above needs to be defined.
      -- The conference topology that perc supports must ensure that the
original SSRC be unique.
      -- two possible options for MDDs that might rewrite the original SSRC
         1. Don't let the MDD rewrite it
         2. Place it outside - say in EKT for example
         OR Copy the original SSRC into CSRC field in the cases of SFU/MSM
      -- In general for the MDD cascaded topologies the original SSRCs need
to be preserved.

*    E2E Authentication Scope Discussions*

     This discussion focussed on what fields in the RTP packets are E2E
authenticated.

      -- Payload : needs to e2e encrypted and authenticated

      -- Padding : payload specific. It is authenticated E2E either
implicitly/explicitly.

      -- Marker Bit : unclear and needs more discussion.

      -- Header Extensions : Requires more evaluation per RTP Header
extension.

      -- Timestamp : Needs to be E2E authenticated and the original values
needs to be  maintained e2E to avoid delay attacks. Does need more
discussion on  defining efficient replay protection and clock skew changes.

      -- Seq No : We need E2E sequence number and it needs to be e2e
authenticated.

      -- CRSC,CC : Not needed to be E2E authenticated.

      -- SSRC : The original SSRCS needs to be E2E authenticated and
preserved and globally unique

      -- V : Must be 2 .

      -- PT: Probably e2E authenticated. Needs more discussion. Having no
signaling information at the  receiver results in not having mapping
between RTP PT value and its mime type in the  signaling [ this is however
related to high level metadata authentication and exists  outside RTP
packet].
             We need to document this problem and write up.

*Next Steps :*

  Magnus to write a draft documenting today's discussions/requirements.

*Open/Other Pending Topics that needs more discussion:*

  - Marker bit & Timestamp values needs more discussions on E2E
authenticated or not.
  - Placement of E2E context data - In RTP header or after RTP Payload.
  - Identify E2E RTCP requirements and if it is needed for PERC
  - Analyze each RTP header extension to identify its scope for E2E
Encryption & authentication
  - HBH encryption design - SRTP vs Non-SRTP pros and cons

Please let us know if there are any omissions and mistakes.

Thanks
Suhas

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 13 Oct 2015 08:47:36 +0000

Suhas,

Questions:
"How the SSRCs are derived from the above needs to be defined."

If the SSRC is delivered over a secure connection like DTLS, do we 
really need to define how they are derived?  If the KMF is allocating 
them, then it is not sufficient for our work to simply state that the 
KMF must assign unique SSRCs for each RTP session?

In the conclusions relating to SSRC, wasn't it concluded that at least 
in one topology the SSRC will be changed by an MDD, so therefore must be 
preserved?  If so, then I would suggest we say that as a conclusion; the 
text now leaves that open for discussion, I think.

Let me express that I appreciate Magnus taking the action to write up a 
draft on the RTP fields that need or don't need to be E2E protected.  I 
think this is important to discuss further to get right.  I that, 
because I know I'm going to sound contrary, but my intentions are good 
:-)  We really need to think carefully about what we attempt to 
preserve.  Every bit will increase the packet size and I question the 
security benefit given that the unique packet identifiers will be 
present E2E, which should allow an endpoint to determine if media is 
replayed, etc. I get the impression that most of the fields, if changed, 
do nothing but disrupt service and do not reveal information about the 
content (i.e., media content confidentiality is not compromised); I 
think media content confidentiality is the prime objective.  So to keep 
the system as simple as possible without sacrificing security, I'd like 
to make sure we think twice about the disposition of every field.

Paul

------ Original Message ------
From: "Suhas Nandakumar" <[email-masked]>
To: [email-masked]
Sent: 10/13/2015 3:30:38 AM
Subject: [Perc] Design Meeting Notes

>    Also apologies for messing up the meeting time and thanks to the 
>group for being patient in that regard.
>
>
>recording).  Please also refer to Cullen's updated slide deck that 
>captures some of conclusions from meeting today
>
>Here is the WebEx Link : Play recording (1 hr 51 min)
>
>
>PERC Design Meeting 2
>
>Attendees: Paul Jones, Magnus Westerlund,  Cullen Jennings, Roni Even, 
>Mo Zanaty, John Mattson, Jonathan Lennox, Ram Mohan, Richard Barnes, 
>Suhas Nandakumar
>
>General Discussions / Agreements
>
>   - Don't change the security properties of the SRTP unless it is 
>required for the
>   - There are conferences today where MDD doesn't really change the 
>data while forwarding and with SFU and MSM coming into the picture 
>there might be few MDDs that will change some aspects of RTP packet. 
>The design should consider both the scenarios.
>
>   - For E2E there are certain RTP fields (sorry for this nomenclature) 
>that need to be integrity protected E2E (ex: SeqNo, SSRC/source 
>identifier). These needs to be placed at some place in the packet. The 
>location for the placement is not yet finalized.
>
>proposals may be defined  to use non SRTP HBH but the WG needs to 
>decide on it. For now the discussion is tabled till  the WG tackles 
>core PERC & SRTP design issues.
>
>
>Specific Topics Discussions
>
>   Source Identification in the PERC Conference
>
>    The fundamental point of discussion was to agree upon the definition 
>of inner source identifier. Options on the table were
>    - opening question was - "Does SSRC suffices or do we need a new 
>space (identifier) as the global scope?".
>
>    Discussion points :
>
>       --  Needed in the context of MDD remapping SSRC and needing to 
>have the source  identifier binding to the end-point. this enables the 
>receiver to get the full context of source stream to source end-point 
>identity mapping
>
>       -- If the trust chain is based on the source identifier mapped to 
>a DTLS Context mapped to the fingerprint which is in turn identified to 
>an EndPoint Identity mechanism,then SSRC can serve the purpose of 
>source identification.
>
>       -- Regardless of what the identifier we call it as, there is need 
>for some global source identifier space that needs to be maintained E2E
>
>will protect against SSRC rewriting by  the MDD and maintains global 
>SSRC space for Inner/E2E layer.
>
>point and the KMF should ensure the uniqueness   properties for SSRC 
>across the conference.
>
>
>
>   Conclusions:
>       -- Ensure that the DTLS layer handing over the EKT master key 
>will partition the SSRC space or maintains the SSRC uniqueness property 
>across the conference.
>       -- The conference topology that perc supports must ensure that 
>the original SSRC be unique.
>       -- In general for the MDD cascaded topologies the original SSRCs 
>need to be preserved.
>
>
>
>
>     E2E Authentication Scope Discussions
>
>       -- Timestamp : Needs to be E2E authenticated and the original 
>values needs to be  maintained e2E to avoid delay attacks. Does need 
>more discussion on  defining efficient replay protection and clock skew 
>changes.
>
>       -- PT: Probably e2E authenticated. Needs more discussion. Having 
>no signaling information at the  receiver results in not having mapping 
>between RTP PT value and its mime type in the  signaling [ this is 
>however related to high level metadata authentication and exists  
>outside RTP packet].
>Next Steps :
>Open/Other Pending Topics that needs more discussion:
>