Subject: [Perc] Cullen random notes from design call Nov 30

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 30 Nov 2015 18:01:51 +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

---

From: Adam Roach <[email-masked]>
Date: Mon, 30 Nov 2015 12:04:58 -0600

And here's my raw minutes.

Chair: These are looking a lot like virtual interims, so we're going
   to be following that process. Not much availability through end of year,
   so probably next meeting in January.

Chair slides
------------

Chair: The goal today is to discuss the SRTP transform. We're going to
   stay within the bounds of SRTP transforms, since that's all our charter
   allows us to discuss. What we're doing is inventing an entity that has an
   intermediate level of privilege. Current SRTP has two extremes: you're
   either in the security context and can do everything, or you're out 
and all
   you can do is read (but not authenticate) the clear-text fields. We're
   defining something between those poles.  We're talking about taking 
some of
   the capabilities and granting them to the MDD.

Chair: SRTP bases a lot of protection on sequence numbers. So the MDD needs
   to leave it alone, or the recipient must be able to reconstitute and
   authenticate it.

Chair: Questions for today: (1) What does the recipient need to do in 
response
   to MDD-modified header fields? (2) What should the MDD be allowed to 
do with
   extension headers (especially as it pertains to encrypted and unencrypted
   fields).

Chair: For each field, we should consider -- if the MDD has modified a 
field,
   what does the recipient use? Original value? New value? Some synthesis of
   both? Or does it reject the packet?

Magnus' Slides
--------------

Magnus: This is a continuation of the discussion in Yokohama. We're not 
going
   to go over the framing slides.

Magnus: For version field, we expect that this can't be modified by the
   middlebox.

Richard: Yes, and there's a compatibility question here, too, since 
there will
   probably be other changes required for v2 to work with v3.

Magnus: Padding bit -- since the payload can't be changed, it makes no sense
   for the MDD being able to change the paddding.

Magnus: Extension indicator (X) -- The MDD can remove header extensions
   (removing the bit), and can add header extensions (adding the bit).

Cullen: Because MDD can add mixer-to-client audio levels, we need to be able
   to change this bit. But let's not assume we can remove headers.

Magnus: In a cascaded conference, you might have headers added by one MDD
   and removed by another. But the question about whether the original
   value is needed, it depends on whether the extensions are internally
   protected.

Jonathan: The X bit by itself isn't that interesting by itself; I think we
   evaluate this in the context of the extension headers themselves.

Richard: [roughly agreeing with the above sentiment]

Magnus: Okay, marker bit (M) -- we got stuck on this in the meeting. The
   semantics of this vary by payload type. And it leaks some information,
   although no more than SRTP does. The question would be what the MDD would
   do to change this. If the MDD switches a stream, it might want to tag
   the packet with a talkspurt indicator. My personal recommendation 
would be
   to leave these alone.

Cullen: There's M for video, and M for audio. Audio is the interesting one
   My understanding is that existing mixers set this bit explicitly so that
   recipients can reset jitter buffers and similar things.

Jonathan: That only makes sense because they're splicing them all into one
   SSRC. Since PERC will give them all different SSRCs, the M-bit isn't 
needed.

Cullen: Okay, if we say that behavior is scoped to the SSRC, then I agree
   that the MDD doesn't need to change the M bit.

Magnus: It sounds like we agree that it shouldn't change. We should verify
   on the mailing list; but the less the MDD can change, the easier our 
job is.
   Does anyone disagree with the statement that we can't change M bits?

Cullen: The only worry I have is that, if the MDD drops the bits with 
M-bits,
   then recipients will never see them.

Richard: Let's leave an asterisk next to this until we have the SRTCP
   conversation.

Magnus: Payload Type (PT) -- main challenge is that signaling is independent
   per-leg, and each leg can end up with a different PT referring to the 
same
   codec/configuration. So this needs to change. However, if the MDD is
   malicious, it might modify the PT value to intentionally feed bad data
   into a fragile decoder to crash it or overrun a buffer. Also, feeding
   video into an audio PCM codec can sound horrible.

Cullen: The MDD can always trash the conference.

Magnus: I think the biggest issue is that the malicious MDD in collusion 
with
   a malicious endpoint, it could send bad packets to kill remote endpoints.

EKR: Wait, we're worried that the MDD can exploit this rather than an 
endpoint?

Magnus: [started an argument about browsers, then retracted it]. This 
isn't an
   MDD attack after all.

EKR: My analysis would start with: is there a good reason to change this 
field?

Jonathan: Well, you can't force PT types across all legs, so there needs 
to be
   some fixup here.

Mo: This attack is possible even with changing the PT number. This could be
   mounted just as easily by generating bad PTs in the SDP

Jonathan: Unless we have something like the KMF handing out PTs, there's
   no way to avoid modification.

EKR: As long as there's a good reason to rewrite, I'm okay with rewriting.

Richard: It sounds like there's a need to be able to change this. So I think
   we simply have some things here to document in security considerations

Magnus: The question is: do we try to mitigate this, or do we simply 
document
   it as a security issue? For example, by providing the PT to the 
endpoint, it
   might be able to detect a malicious change.

Ricahrd: But without a PT-to-codec mapping, it can only detect that it's a
   change rather than a malicous change.

Magnus: Any mitigation seems very tricky, and the attack seems weak.

Colin: Any endpoint can send garbage even without MDD participation.

Roni: The question I hear -- I hear that we're going to change this due to
   SDP negotiation. But SDP negotiation is out of scope, so I don't see how
   we can do anything.

Magnus: There has to be something that's doing the negotiation, and it's 
going
   to have a PT-to-codec mapping.

Roni: But that requires a relationship between the signaling system and the
   MDD.

[Discussion about signaling being in scope for PERC, with the general idea
being that it is, but we aren't talking about it now]

Magnus: So the question really is whether you need the original PT value
   at the receiver. We seem to be converging on 'no'

Cullen: That depends on what kind of verification you do at the recipient.
   I would like to keep open the option to verify the original PT at the
   recipient.

Magnus: MUST be able to modify it, recipient MAY need to have the original
   value.

Roni: There's a question about whether the MDD includes signaling to let
   everyone know about the original PT-to-codec mappings.

Magnus: Sequence number. We need this for decoding correct order. The MDD
   will ned to be able to rewrite the number, or we lose loss detection and
   have inconsistent RTCP reporting. But this ability to change opens up two
   attacks.

Magnus: Replay attack. In this attack, the MDD saves an old packet and
   reinjects it into the stream later. So we need to have some replay
   prevention. Access to the original SSRC and sequence number is probably
   needed for this prevention. We also need to be able to handle sequence
   number wrapping and rekeying events.

Richard: Isn't this a base SRTP issue? Can't it arise in the non-PERC case?

Magnus: Yes, but in that context, you can rely on the ROC and Sequence 
Numbers.
   You're not going to have the same on/off issue as you do with MDDs. 
With PERC,
   the MDD can turn off packets for more than 64k packets.

Richard: Can't a network node do that anyway?

EKR: Yeah, but people will hang up. This is very illuminating, since it
   highlights an issue that we haven't had before. It seems like we 
might need
   some kind of key rollover counter to prevent this. You should be able 
to do
   some kind of rollover time projection based on speed of packets being 
sent.

Cullen: I think this is a red herring. These rollovers have a very long time
   between them. And if you lose one of these rollovers, you're going to 
fail
   safe.

EKR: Sure, but you still have some means of the attacker to be able to move
   things within a range if you've had multiple rollovers lost.

Paul J: I'll note that the rollover counter is part of the EKT tag. If 
we pull
   it out so that it's not encrypted, then it provides a solution to this
   problem.

Richard: That sounds like it might work. So this might not be an issue for
   sequence number as much as something additional we need to add.

Magnus: The bigger issue is the delay attack, where the MDD, during a 
period of
   not forwarding packets from a source, decides to play old media that 
it had
   received during that period of not sending.

Colin: Doesn't the timestamp stop this?

Magnus: Only if you know how it behaves.

Cullen: You have to be able to handle this with normal SRTP.

Magnus: The timestamp changes with payload types. Say, switching from 8k 
uLaw
   to 48k Opus, would change the clock speed.

Cullen: You'd need to resignal

Magnus: Not if you agreed to receie both

Jonathan: We could enforce that different PTs need different SSRCs. No
   backwards compatibility concerns with PERC.

Cullen: I think that looking at the timestamps is the solution

Magnus: But you can have skew

Cullen: If you skew is so bad that you get outside that window, then things
   will break. That doesn't happen today.

Jonathan: If someone is muted for 2 hours, and you delay for 2:10, that's an
   issue.

Magnus: I've seen clock skew up to 10% on, say, old soundcards.

Cullen: We're seeing 100 ppm on the outside. We're not building for ancient
   soundcards.

Jonathan: The MDD could maybe do a total delay number in.

Cullen: I think the tolerance isn't in the RFCs because it's implementation
   dependent. We don't need to solve that.

Richard: What are you saying the solution is?

Cullen: Look at the timestamps and make sure they're in a reasonable time
   window. Jonathan is right that we need to think about whether we want 
this to
   work with a router that's introducing 10 seconds of delay.

Magnus: Unless you have RTCP reporting that reports this end-to-end, then
   the MDD can change this.

Cullen: Really, phones go on hold point-to-point for 30 minutes or 
longer all
   the time.

Magnus: The difference is that you aren't sending any media at all, 
while with
   PERC, the MDD can drop packets. It's also in the middle and can 
manipulate
   that information.

Cullen: I still think you need to look at the timestamps and make sure 
they're
   in a reasonable window

**********
Chair: Sounds like we're in agreement that the MDD needs to be able to 
change
   the sequence #, but that we need to carry the original end-to-end.
**********

Magnus: Yes, that's exactly what we propose (see slide).

Magnus: Timestamp: if you have an MDD that switches streams, it needs to
   generate its own timeline. The recommendation is: we need the original
   value. That seems consistent with the discussion we had around 
sequence #.
   Any disagreeent?

[none raised]

Jonathan: The question I would have is: if you know both timestamps, what
   do you do when they're inconsistent? You have to make sure what the 
receiver
   has to do to the original timestamps to compare them. Also, if we say 
that
   you don't rewrite SSRC, then I think we can say that you don't change
   timestamp.

Cullen: It's not clear that you need to rewrite these, but if you do, we
   definitely need the original.

Jonathan: So, it's conditional based on whether SSRC rewriting happens.

Jonathan: If it's being rewritten, we need to define how you detect that
   an attack is underway, so that the recipient can reject it.

Cullen: So, is SSRC the next slide?

Magnus: Yep.

Suhas: Clarification -- if the receiving endpoint gets a timestamp in a 
certain
   format, can it conclude that it's been changed in the middle of the 
network?

[I didn't really follow the question or the answer very well]

Magnus: SSRC. For a media switching mixer, the MSM has its own SSRCs,
   and can use the CSRC to indicate the original SSRC.

Magnus: Splicing attack. If you can, through SSRC collisions, get two
   sending parties to use the same SSRC, then it can cause sender 1's stream
   to look like sender 2. Could authenticate original source; could use some
   other means to ensure SSRC uniqueness; could prevent media protection 
rekeying
   until source ID is verified.

Richard: This lines up with an MDD requirement not to be able to switch
   authenticated identities.

Cullen: I think this is confusing because we're not looking at the whole 
system.
   the KMF is going to have to be able to detect SSRC collisions. We're 
going to
   have to let the KMF enforce unique identities, and there's no reason 
the SSRC
   can't be that identity.

Mo: You need to consider SSRC in conjuncion with ROC, timestamp, 
sequence. This
   is going to be a collision in 112 bits. You need to have a rule that 
talks
   about how to detect these kinds of attacks.

Magnus: If we can ensure unique source IDs, then this is a lot easier to
   analyse. Some of these fields might look big, but it might not be hard to
   force them to certain values.

Adam: Won't it take O(20ms * 2^31) to mount this attack? Or about 71 weeks?

Richard: No, you're missing the case where the MDD changes SSRCs.

Richard: I'm inclined to say that we can't change the SSRC, and then
   have SSRC assigned by the KMF.

Magnus: I'm good with requiring that SSRC doesn't change, and push 
uniqueness
   up to a higher layer

Roni: The entity can just start putting in the middle S2 rather than S1.

Magnus: Yes, but it would be correctly attributed in that case.

Mo: We shouldn't conflate this issue with whether SSRC is mutable. The 
attack
   should be discussed separately, since this issue can arise with 
changed or
   unchanged SSRCs.

Magnus: We propose that the higher layer takes care of this.

Cullen: I argue we just don't let it change.

Mo: The opposing traffic on the list seemed to be motivated by simplicity.

Richard: We can put that as a stake in the ground, and possibly come back
   and change it later.

Roni: We need to clarify what topologies the MDD supports.

Magnus: We only allow non-SSRC changing MDD.

Adam: We need to be a lot clearer about why we're proposing to keep it the
   same when we bring this to the list.

Jonathan: We might want to consider cases where one stream inbound is two
   streams outbound (e.g., participant stream, loudest speaker stream)

Magnus: More SDES items?

Cullen: Overloading SSRC to mean Role is insane.

Colin: I agree. There should be a label.

Jonathan: So we need the ability to tag multiple roles in a packet.

Mo: I don't think this actually solves the problem. It just saves a few
   bytes of overhead. The only people who argued against this were Bernard
   and Emil, and the only argument was that they didn't want existing
   implementations to have to change a bunch of stuff. I don't think 
they realise
   how much work will be needed anyway, and this won't be any more.

Magnus: It comes down to a complexity issue.

**********
We're going to assume immutability for SSRC for the rest of this call.
**********

Magnus: Since we can't have mixing MDDs in PERC, the idea of contribution
   doesn't make sense.

Jonathan: Well, if you have non-PERC mixers gatewaying into PERC, this can
   happen.

Cullen: Yes, we need to handle transitional periods.

Mo: I'm aware of endpoints that have CSRC populated in their original 
packets.

Magnus: Okay, it makes some points, then.

Colin: So I don't see why we should forbid their presence.

Magnus: Okay, if we have CSRCs meaning "contributing source," then using
   it to store old SSRCs becomes ambiguious.

Mo: If we want to store the original SSRC off somewhere, CSRC doesn't make
   sense. We can store them where we store other modifications

Colin: If we stick to the agreement that SSRC can't change, then this isn't
   an issue. If we don't, then we have bigger problems to solve.

Magnus: So what we seem to have here is that the MDD cannot change CSRC.

Mo: Right.

**********
Richard: So, this is e2e authenticated, the MDD must not modify?

Magnus: Yes.
**********

Magnus: CSRC count (CC) -- if we can't change CSRC, then we can't change 
this.
   No need to analyze it.

Richard: To sum up. Based on notes, three or four fields can change: PT, 
seq,
   ts, and maybe X.

Jonathan: I thought we said that SSRC can't change means TS can't change.

**********
   Changeable fields are: PT, Sequence, and maybe X.
**********

Magnus: Header extensions

Cullen: So, I think we should start by asking whether there's anything 
the MDD
   can delete, and whether there's anything it can add or change.

Jonathan: You need to be careful about tag remapping by the MDD.

Magnus: Transmission time offsets (RFC5450). Need to be able to update 
these.

Mo: Don't think RMCAT is going to be using this.

[some discussion that I missed]

Cullen: I don't buy that the middlebox needs to change this.

Magnus: Take it on list.

Magnus: SMPTE timestamps -- these are bound to the source media, so it 
should
   be end-to-end, and therefore end-to-end authenticated. Confidentiality is
   recommended.

Jonathan: Sure, if we have confidentitiality defined. This isn't 
sufficent to
   motivate a mechanism if we don't already have one.

Magnus: Sync Metadata (RFC6051).

Cullen: What would be the argument for removing it?

Jonathan: If MDD can change timestamp, it needs to rewrite/remove these.

Mo: This isn't realted to timetamp remapping. It's a question of whether
   timestamp SRs need to be end-to-end. This is basically a fast SR.

Jonathan: Part of one, yes.

Mo: So whatever we decide for SRs applies to this.

Magnus: Client-to-mixer audio level (RFC6464). Can leak content information.

Cullen: I don't see any need to have the MDD remove it. I can see how it
   doesn't hurt.

Magnus: Mixer-to-client audio level (RFC6465). Not likely in PERC. Must be
   combined with CSRC to make sense. So, end-to-end only. MDD doesn't need
   to look at it. Should make it confidential as an option.

Cullen: MDD does not need to generate, modify, etc. Whether these should be
   encrypted ... it's not different in PERC than it is in end-to-end SRTP.

Cullen: we're coming to the conclusion that I think we don't need to change
   any of these.

Jonathan: How about MDD?

Cullen: Ah, good point.

Magnus: Okay, for CVO -- it leaks information, so this needs to be e2e
   confidential. MDD can't change it.

Mo: Can it strip it? Because you might have different endpoints that
   don't support it. It should be able to strip it.

Jonathan: there's a good general question about how you handle 
extensions that
   endpoints don't negotiate. Not unique to CVO.

Cullen: Clearly, MDD doesn't modify CVO. Protecting its privacy? Seems a bit
   hard to argue for if you're not protecting client-to-mixer audio level.

Jonathan: Yeah, encrypting sounds good, but not high enough barrier to 
justify
   defining a new mechanism.

Magnus: For ROI (TS 26.114 v 13.1.0), should be private.

Cullen: Maybe, but isn't different in PERC than end-to-end.

Richard: So, we need a table that talks about what can be 
added/removed/changed.
   We want a general mechanism for doing these things, and then can talk 
about
   when it's valid to apply them.

[chair ends call]

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 30 Nov 2015 10:11:49 -0800

Here is the WebEx recording from our Design Meeting #3

*PERC Design Meeting #3-20151130 1606-1*Monday, November 30, 20158:06
am  |  Pacific Standard Time (San Francisco, GMT-08:00) *Play recording*
<https://cisco.webex.com/ciscosales/lsr.php?RCID=2684921e717d4b45aadb88d9a8774ce5>
(1
hr 54 min 0 sec) You can forward this message to others to allow them to
play back the recording. *Additional options*Edit recording
<https://cisco.webex.com/ciscosales/editrd.php?RCID=9343dcd489e349f6a2f32b8450512b49>Download
recording
<https://cisco.webex.com/ciscosales/viewrd.php?RCID=4bd4e40a1dff4a97a67be3d8ef422b03>Manage
recordings <https://cisco.webex.com/ciscosales/servicerds.php?SP=MC>

Cheers
Suhas

Cheers
Suhas

On Mon, Nov 30, 2015 at 10:04 AM, Adam Roach <[email-masked]> wrote:

>   either in the security context and can do everything, or you're out and
> all
>   defining something between those poles.  We're talking about taking some
> of
>   to MDD-modified header fields? (2) What should the MDD be allowed to do
> with
> Richard: Yes, and there's a compatibility question here, too, since there
> will
>   the packet with a talkspurt indicator. My personal recommendation would
> be
>   to leave these alone.
>
>   on the mailing list; but the less the MDD can change, the easier our job
> is.
>   You're not going to have the same on/off issue as you do with MDDs. With
> PERC,
>   highlights an issue that we haven't had before. It seems like we might
> need
>   some kind of key rollover counter to prevent this. You should be able to
> do
> Paul J: I'll note that the rollover counter is part of the EKT tag. If we
> pull
>   not forwarding packets from a source, decides to play old media that it
> had
> Cullen: Really, phones go on hold point-to-point for 30 minutes or longer
> all
>   the time.
>
> Magnus: The difference is that you aren't sending any media at all, while
> with
>   value. That seems consistent with the discussion we had around sequence
> #.
>   Any disagreeent?
>
> [none raised]
>
>   have to let the KMF enforce unique identities, and there's no reason the
> SSRC
>   can't be that identity.
>
> Mo: You need to consider SSRC in conjuncion with ROC, timestamp, sequence.
> This
>   should be discussed separately, since this issue can arise with changed
> or
>   unchanged SSRCs.
>
>   implementations to have to change a bunch of stuff. I don't think they
> realise
> Cullen: So, I think we should start by asking whether there's anything the
> MDD
> Jonathan: Sure, if we have confidentitiality defined. This isn't sufficent
> to
> Jonathan: there's a good general question about how you handle extensions
> that
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 30 Nov 2015 16:14:32 -0600

On Monday, 30 November 2015, Cullen Jennings (fluffy) <[email-masked]>
wrote:
>
>
> 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.
>

I must be very confused but I saw a bunch of implementors here stating that
banning SSRC rewriting would make PERC very impractical.

Did I miss a thread where all of them retracted and said "no, it's actually
fine so don't mind us" or does this working group not care about fostering
adoption?

Emil

--sent from my mobile

-- 
sent from my mobile