Subject: Re: [Perc] Minutes from Design Team call #3

From: Richard Barnes <[email-masked]>
Date: Mon, 4 Apr 2016 16:28:38 -0300

Magnus: Note the SSRC line below:

  Field       Can be modified?    Send original?
  ...
  SSRC            No                   ---

On Wed, Dec 2, 2015 at 8:36 PM, Richard Barnes <[email-masked]> wrote:

> Hey all,
>
> Please find below the chairs' notes from the design team call we had on
> Monday.
>
> --Richard
>
>
> PERC Design Team Call #3
>
> # Chairs introduction
>
> * Future calls will follow Virtual Interim process
> * This call is focused on figuring out what capabilities the MDD needs
> to modify header fields
>
>
> # Discussion of Header Fields
>
> Summary of conclusions on call:
>
>   Field       Can be modified?    Send original?
>   V               No                   ---
>   X               Yes            Maybe (see extn)
>   M               No                   ---
>   PT              Yes                  Yes
>   SEQ             Yes                  Yes
>   Timestamp       No                   ---
>   SSRC            No                   ---
>   CSRC/CC         No                   ---
>   Extension       Yes                  TBD
>
> ---
>
> V - MDD MUST NOT change
>
> P - MDD MUST NOT change
>
> X - MDD needs to be able to change
>     -- Original value may be necessary for E2E integrity-protected extns
>
> M - MDD MUST NOT change
>     -- M is used to signal to endpoints to reset jitter buffers
>     -- ... but it's tied to SSRC, so switching SSRC could be the signal
>     -- Might need to document how this relates to SSRC / source indication
>
> PT - MDD needs to be able to change
>    -- MDD can always trash the conference
>    -- needs changing to match PTs across individual sessions
>    -- Security considerations about malicious PT changes
>    -- No immediate need for the original value at the receiver
>    -- ... but we should keep the option open
>
> SEQ - MDD needs to be able to change
>
> -- For, e.g., consistent loss detection with stream on/off behavior
>
> -- Different from network attacker b/c long silences are normal
>
> -- Replay attacks might need extra mechanism
>
> -- e.g., authenticated ROC in EKT
>
> -- Delay attack might be better handled with timestamp / RTCP
>
> -- Original value needed at the endpoint
>
>
> Timestamp - MDD MUST NOT change
>
> -- MDD might want to change if MSM are used
>
> -- No MSM , no need to fudge the timespatmp
>
> -- When changed needs to preserve the original value
>
> -- No need to change if SSRC is immutable
>
>
> SSRC - MDD MUST NOT change
>
> -- Splicing attack - needs source to be verified ?
>
> -- Need higher level layer to ensure SSRCs are end to end
> authenticated somehow [[ or otherwise have the right properties ]]
>
> -- Might need to come back and make it mutable later
>
> -- Need to better express to the list why this design is simpler
> (Magnus/Adam)
>
> -- Might be making some topologies incompatible with this decision
>
> -- ... and we should be explicit about this
>
>
> CSRC - MDD MUST NOT change
>
> -- ... and by implication, CSRC Count (CC)
>
>
> Header Extensions
>
> -- ID values behave similar to PT (signaling based assignment)
>
> -- ... so MDD might need to align them
>
> -- Needs more discussion of how
>
> -- RFC5450
>
> -- MDD MUST NOT change
>
> -- Not used widely today and might not be in future (ref RMCAT )
>
> -- RFC6051
>
> -- MDD MUST NOT change, might need more discussions
>
> -- no timestamp rewriting implies no changing of this value
>
> -- Tied to E2E RTCP decision
>
> -- RFC6464
>
> -- removing or not removing might not matter
>
> -- b/w might force to remove but having it allows end-point to verify
> the authenticity of source reporting its audio level
>
> --  RFC6465
>
> -- MDD MUST NOT Modify
>
> --  Encrypted or not ( needs more discussion for all the audio
> levels). Use HBH as the baseline to drive these discussions.
>
> -- CVO
>
> -- MUST NOT MODIFY
>
> -- [[ Ran out of time here ]]
>
>
> Path Forward:
>
> -- Work through existing extensions to see what capabilities are needed
>
> -- Write protocol mechanism for capabilities, handling guidlines per header
>