[Perc] Cullen random notes from design call Nov 30

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Mon, 30 November 2015 18:01 UTC

From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: "perc@ietf.org" <perc@ietf.org>
Thread-Topic: Cullen random notes from design call Nov 30
Thread-Index: AQHRK5kwVkhNxrwJZU6z3K1i1JYMnA==
Date: Mon, 30 Nov 2015 18:01:51 +0000
Message-ID: <779F5752-BE63-4A6F-B432-BE2D748A9C68@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.249.165]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E7CB7557D77B94468E837A8BC773E11C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/perc/i07wXCShYfkRy9Xaw2GMe9XcUIM>
Subject: [Perc] Cullen random notes from design call Nov 30
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Nov 2015 18:01:54 -0000

			
My random notes from todays design call

V 
MDD can not change 

P 
MMD can not change

X
yes - MDD can add header such as mixer to client audio level 

M
MMD can not change it. The M bit for audio is tired to the SSRC so the jitter buffer is logically per SSRC so when and endpoint sees a SSRC change, it can do the right thing with jitter buffers. 

PT 
An MDD changing the PT could cause bad noise by playing video into PCM. 

If a endpoint has a buffer overflow in codec, it can be exploited by someone just calling the device so not really so worried about a MDD being able to exploit this. The endpoint needs to fix this regardless of PERC. 

Agree that MDD needs to change PT 

Leave open the option of also having original PT value as well so that we can validate the change. 


SEQ NUM
- MDD can change 
- original seq number needs to be preserved

and discussion around attacks also lead to some discussion that end to end RTCP was desirable in RTCP case


Timestamp 
- MDD MAY need to change it (depended on SSRC change decision) 
- need original value 
- after SSRC decision came back to and decided MDD can not modify Time stamp 


SSRC 
- splicing attack not possible if group key not given to different endpoints with same SSRC. Magnus and I agree on pushing this up to next layer and then we can discuss the various ways this could be done. 

- adam point out if change SSRC ever 20 ms packet sill like average of 71 weeks to have a collision

- mo  point out it is just not 32 bits here but bunch more 

- no one on call arguing for changing SSRC

very complicated to have secure RTCP if you allow this to change 

Decision on call is MDD can not change SSRC 


CSRC 
- MDD can not modify it (make no sense in perc context)
- it may have been set by some endpoint 

CC
- same as CSRC (MDD can not change)


Header Extensions

TTO
- looks like RMCAT will not use this so may be irrelevant 
- not agrement on what is needed

SMPTE 
- no one does this today and fairly unlikely 

Sync Metadata (RFC 6051)
- having the MDD remove this would break end to end SR in RTCP 
- did not see need for MDD to change or remove 

Client to Mixer audio level 
- MDD does not need to change or remove 

Mixer to client
- MDD does not modify 
- irrelevant in perc environment

CVO 
- MDD does not change 

ROI
- MDD does not change

[Perc] Cullen random notes from design call Nov 30 Cullen Jennings (fluffy)
Re: [Perc] Cullen random notes from design call N… Adam Roach
Re: [Perc] Cullen random notes from design call N… Suhas Nandakumar
Re: [Perc] Cullen random notes from design call N… Emil Ivov