Subject: Re: [Perc] PERC Draft Agenda - IETF99

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 7 Jul 2017 16:20:45 -0700

Here is the correct link : https://datatracker.ietf.org/doc/agenda-99-perc/

On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar <[email-masked]>
wrote:

> Hello All
>
> Here is the draft agenda for the PERC WG meeting to be held on Tuesday
> (July 18th)
>
> https://datatracker.ietf.org/doc/agenda-99-perc/
> <https://datatracker.ietf.org/doc/agenda-99-ice/>
>
> https://datatracker.ietf.org/doc/agenda-99-perc/

>
> Please let the chairs know if you have any comments/questions. We will be
> publishing the final agenda by Monday EOD
>
>
> Cheers
> perc chairs
>
>

---

From: Emil Ivov <[email-masked]>
Date: Fri, 07 Jul 2017 23:23:30 +0000

Any chance we can add some time for RTX?

Also I still don't think we have consensus on SSRC rewriting.

Emil

On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar <[email-masked]> wrote:

>
> Here is the correct link :
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>
-- 
sent from my mobile

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 7 Jul 2017 16:38:32 -0700

> On Jul 7, 2017, at 16:23, Emil Ivov <[email-masked]> wrote:
> 

If you mean RTX in the context of double then I would expect that to be part of the initial double discussion.
Or do you want to talk about your draft which modifies the OHB for RTX?

Cheers
  Nils

> On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Here is the correct link : https://datatracker.ietf.org/doc/agenda-99-perc/ <https://datatracker.ietf.org/doc/agenda-99-perc/>
> 
> On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar <[email-masked] <mailto:[email-masked]>> wrote:
> Hello All
> 
> Here is the draft agenda for the PERC WG meeting to be held on Tuesday (July 18th)
> 
> https://datatracker.ietf.org/doc/agenda-99-perc/ <https://datatracker.ietf.org/doc/agenda-99-ice/>
> 
> https://datatracker.ietf.org/doc/agenda-99-perc/ <https://datatracker.ietf.org/doc/agenda-99-perc/>
> 
> Please let the chairs know if you have any comments/questions. We will be publishing the final agenda by Monday EOD
> 
> 
> Cheers
> perc chairs
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/perc <https://www.ietf.org/mailman/listinfo/perc>
> --
> sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Sat, 08 Jul 2017 03:44:34 +0000

The latter.

During the interim it was mentioned that the modification wasnt clear.

I have yet to update the draft but unless people are now all comfortable
with the notion, which would make me very happy, I think it might be useful
to go over this again.

(And we still have to reach consensus on the ssrc issue)

Emil

On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier <[email-masked]> wrote:

>>> Please let the chairs know if you have any comments/questions. We will
>>> be publishing the final agenda by Monday EOD
>>>
>>>
>>> Cheers
>>> perc chairs
>>>
>>>
sent from my mobile

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 9 Jul 2017 21:35:48 -0700

Hello Emil and Percians

  From what i gather the sentiments at the IETF 98 was RTX for probing
bandwidth  (as implemented by chrome) was something that Chrome should fix
it. Were you able to reach out to Chrome team on the same ?

Also the latest double spec seems to indicate RTX in PERC is scoped only
for HBH and not E2E. IIRC your draft had similar recommendations.

please correct me If i am wrong in capturing the thoughts ?

Thanks
Suhas

---

From: Emil Ivov <[email-masked]>
Date: Thu, 13 Jul 2017 02:12:33 +0000

Hey Suhas,

I haven't had as much time as I would have liked for PERC so please excuse
me if I am making a glaring omission but I don't believe there has been any
resolution to the RTX issues discussed on the last virtual interim.

Specifically exactly how RTX will coexist with PERC (and no, this doesn't
really have anything to do with probing).

The latest double draft doesn't seem to say anything specific on the
subject unless if, again, I am actually missing something.

If I have indeed slept through how this WG reached consensus then I am very
happy to not have to prepare anything and please accept my appology.

If however there is still doubt on how RTX wedging should would I'll follow
up on my promise to update our RTX document.

Cheers,
Emil

sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Thu, 13 Jul 2017 02:17:08 +0000

Oh and I forgot to add: we still do not have consensus on rewriting SSRCs.
Would be good to have a plan about what we are doing there.

Emil

On Wed, 12 Jul 2017 at 21:12, Emil Ivov <[email-masked]> wrote:

> If I have indeed slept through how this WG reached consensus then I am
> very happy to not have to prepare anything and please accept my appology.
>
> If however there is still doubt on how RTX wedging should would I'll
> follow up on my promise to update our RTX document.
>
> Cheers,
> Emil
>
>>>>>> Please let the chairs know if you have any comments/questions. We
>>>>>> will be publishing the final agenda by Monday EOD
>>>>>>
>>>>>>
>>>>>> Cheers
>>>>>> perc chairs
>>>>>>
>>>>>>
-- 
sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Sat, 15 Jul 2017 17:11:28 -0500

Hey all,

As promised on the last interim, the RTX draft is now updated:

https://raw.githubusercontent.com/bgrozev/perc-rtx/master/draft-grozev-perc-double-rtx-01.txt

Apologies for the delay.

Hopefully we are going to have the time to discuss this in next week's 
meeting.

Cheers,
Emil

On 7/12/17 9:12 PM, Emil Ivov wrote:
> Hey Suhas,
> 
> I haven't had as much time as I would have liked for PERC so please 
> excuse me if I am making a glaring omission but I don't believe there 
> has been any resolution to the RTX issues discussed on the last virtual 
> interim.
> 
> Specifically exactly how RTX will coexist with PERC (and no, this 
> doesn't really have anything to do with probing).
> 
> On Sun, 9 Jul 2017 at 23:35, Suhas Nandakumar <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hello Emil and Percians
> 
>        From what i gather the sentiments at the IETF 98 was RTX for
>     probing bandwidth  (as implemented by chrome) was something that
>     Chrome should fix it. Were you able to reach out to Chrome team on
>     the same ?
> 
>     Also the latest double spec seems to indicate RTX in PERC is scoped
>     only for HBH and not E2E. IIRC your draft had similar recommendations.
> 
>     On Fri, Jul 7, 2017 at 8:44 PM, Emil Ivov <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         The latter.
> 
>         I have yet to update the draft but unless people are now all
>         comfortable with the notion, which would make me very happy, I
>         think it might be useful to go over this again.
> 
>         On Fri, 7 Jul 2017 at 18:38, Nils Ohlmeier
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>             On Jul 7, 2017, at 16:23, Emil Ivov <[email-masked]
>>             <mailto:[email-masked]>> wrote:
>>
>             If you mean RTX in the context of double then I would expect
>             that to be part of the initial double discussion.
>>             On Fri, 7 Jul 2017 at 18:20, Suhas Nandakumar
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>                 On Fri, Jul 7, 2017 at 4:19 PM, Suhas Nandakumar
>>                 <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                     Hello All
>>
>>                     Please let the chairs know if you have any
>>                     comments/questions. We will be publishing the
>>                     final agenda by Monday EOD
>>
>>
>>                     Cheers
>>                     perc chairs
>>
>>

-- 
https://jitsi.org

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 16 Jul 2017 06:42:44 -0700

Hello Emil

  Thanks for your draft.

We expected you to have the draft submitted* before the deadline* to the
IETF data tracker website to help everyone prepare for the meeting.

Regarding RTX,  I believe Cullen is addressing the alternate proposals in
his slide deck
- https://www.ietf.org/proceedings/99/slides/slides-99-perc-double-00.pdf.

We would encourage your participation and feedback on the same. Also can
you and Cullen discuss to see if the points are covered sufficiently.

Regarding SSRC rewriting, there has been a consensus to not rewrite the
SSRC by the MDD due to the security implications/attacks as discussed in
the earlier design meetings/virtual interims and IETF meetings (See
https://www.ietf.org/mail-archive/web/perc/current/msg00231.html)

Please refer to  https://www.ietf.org/proceedings/94/slides/slides-94-perc-5
.pdf for more information as the starting point on the various attacks.
Please submit a draft to the mailing list for discussions that addresses
the security concerns or invalidates them with an appropriate security
analysis

Cheers
Perc Chairs

On Sat, Jul 15, 2017 at 3:11 PM, Emil Ivov <[email-masked]> wrote:

>> excuse me if I am making a glaring omission but I don't believe there has
>> been any resolution to the RTX issues discussed on the last virtual interim.
>>
>>>             --             sent from my mobile
>>         --         sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Sun, 16 Jul 2017 09:08:43 -0500

Hey Suhas,

On Sun, Jul 16, 2017 at 8:42 AM, Suhas Nandakumar <[email-masked]> wrote:
> Hello Emil
>
>   Thanks for your draft.
>
> We expected you to have the draft submitted before the deadline to the IETF
> data tracker website to help everyone prepare for the meeting.

Indeed. I already apologised and I do again. Still, the gist of this
is a couple of pages so if people a 2 page document, so if the request
for this draft was indeed an honest attempt for understanding, the
explanation is available here:

> We would encourage your participation and feedback on the same. Also can you
> and Cullen discuss to see if the points are covered sufficiently.

I hope that gets covered adequately then.

> Regarding SSRC rewriting, there has been a consensus to not rewrite the SSRC
> by the MDD

This is factually wrong.

We had a discussion on this was on IETF 96 (Berlin) where I was asked
to describe how this works in a draft, which we did:

https://tools.ietf.org/html/draft-grozev-perc-ssrc-00

We then talked about it in Chicago. No decision was reached the topic
was left open.

> due to the security implications/attacks as discussed in the
> earlier design meetings/virtual interims and IETF meetings (See
> Please refer to
> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf for more
> information as the starting point on the various attacks. Please submit a
> draft to the mailing list for discussions that addresses the security
> concerns or invalidates them with an appropriate security analysis

All of this was discussed subsequently. While there is a lot of hand
waving about a possible SSRC splicing attack, to this date I am not
aware of an actual description of how this thing could work.

https://www.ietf.org/mail-archive/web/perc/current/msg00443.html

Especially in light of the draft above.

As long as the original SSRC is present and verifiable splicing is not possible.

Emil

-- 
https://jitsi.org

---

From: Nils Ohlmeier <[email-masked]>
Date: Sun, 16 Jul 2017 23:50:05 +0200

> On Jul 16, 2017, at 16:08, Emil Ivov <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-grozev-perc-ssrc-00 <https://tools.ietf.org/html/draft-grozev-perc-ssrc-00>
> 
>> https://www.ietf.org/mail-archive/web/perc/current/msg00231.html <https://www.ietf.org/mail-archive/web/perc/current/msg00231.html>)
>> 
>> Please refer to
>> https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf <https://www.ietf.org/proceedings/94/slides/slides-94-perc-5.pdf> for more

So here is the attack I’m concerned about:

We have an MD which is allowed to rewrite SSRC (even with including the original into the OHB).
Now an endpoint in a conference receives a RTP packet from that MD where the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint itself is using for sending.
The endpoint needs to change it's SSRC to avoid the collision. So the endpoint chooses another SSRC B for sending.
And the MD happens to choose another SSRC B as its re-written SSRC.
So endpoint changes the SSRC again to C.
Which then happens to be the same as the SSRC used by another endpoint in the conference.
Now the MD receives two incoming RTP streams with identical SSRCs from two different endpoints and can choose to recombine the RTP headers from client #1 with the payload from client #2.

I think this attack plus it’s possible mitigations need to be described in the draft draft-grozev-perc-ssrc-00.

Best regards
  Nils Ohlmeier

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 17 Jul 2017 00:01:19 +0200

On 16/07/2017 23:50, Nils Ohlmeier wrote:

> Now the MD receives two incoming RTP streams with identical SSRCs from 
> two different endpoints and can choose to recombine the RTP headers 
> from client #1 with the payload from client #2.
>
Shouldn't the SRTP authentication fail in that recombined packet?

Best regards
Sergio

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 16 Jul 2017 15:31:52 -0700

Nils said:

"So here is the attack I’m concerned about:"

[BA] What you are describing relates to the process for detecting and
resolving an SSRC conflict between RTP streams in the same RTP session
within PERC.  Whether the MDD modifies SSRCs or not, in PERC all conference
participants are effectively within the same RTP session, so that conflicts
can occur between participants  (not just between a participant and the MDD
as would normally be the case with a non-PERC SSRC-modifying MDD).

RFC 3550 and 3711 indicate that responsibility for collision resolution
lies with the endpoints, so a PERC endpoint needs to be prepared to handle
this, regardless of whether the MDD modifies SSRC.

>From RFC 3550 Section 8.2:

   Although the probability of SSRC identifier collision is low, all RTP
   implementations MUST be prepared to detect collisions and take the
   appropriate actions to resolve them.  If a source discovers at any
   time that another source is using the same SSRC identifier as its
   own, it MUST send an RTCP BYE packet for the old identifier and
   choose another random one.  (As explained below, this step is taken
   only once in case of a loop.)  If a receiver discovers that two other
   sources are colliding, it MAY keep the packets from one and discard
   the packets from the other when this can be detected by different
   source transport addresses or CNAMEs.  The two sources are expected
   to resolve the collision so that the situation doesn't last.

>From RFC 3711, Section 9.1:

   Thus, the SSRC MUST be unique between all the RTP streams within the
   same RTP session that share the same master key.  RTP itself provides
   an algorithm for detecting SSRC collisions within the same RTP
   session.  Thus, temporary collisions could lead to temporary two-time
   pad, in the unfortunate event that SSRCs collide at a point in time
   when the streams also have identical sequence numbers (occurring with
   probability roughly 2^(-48)).  Therefore, the key management SHOULD
   take care of avoiding such SSRC collisions by including the SSRCs to
   be used in the session as negotiation parameters, proactively
   assuring their uniqueness.  This is a strong requirements in
   scenarios where for example, there are multiple senders that can
   start to transmit simultaneously, before SSRC collision are detected
   at the RTP level.

On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <[email-masked]>
wrote:

> SSRC
> Now an endpoint in a conference receives a RTP packet from that MD where
> the re-written SSRC (outer SSRC) matches exactly the SSRC A the endpoint
> itself is using for sending.
> The endpoint needs to change it's SSRC to avoid the collision. So the
> endpoint chooses another SSRC B for sending.
> Now the MD receives two incoming RTP streams with identical SSRCs from two
> different endpoints and can choose to recombine the RTP headers from client
> #1 with the payload from client #2.
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 17 Jul 2017 00:42:09 +0200

> On Jul 17, 2017, at 00:31, Bernard Aboba <[email-masked]> wrote:
> 
> Nils said:
> 
> [BA] What you are describing relates to the process for detecting and resolving an SSRC conflict between RTP streams in the same RTP session within PERC.  Whether the MDD modifies SSRCs or not, in PERC all conference participants are effectively within the same RTP session, so that conflicts can occur between participants  (not just between a participant and the MDD as would normally be the case with a non-PERC SSRC-modifying MDD).
> 

Yes absolutely. That’s why the text further down includes statements like "So endpoint changes the SSRC again to C."

The important difference in my opinion is:
- If the MD is NOT allowed to re-write SSRCs only another endpoint can cause a SSRC collision. As endpoints are trusted in PERC the assumptions is that collisions will only happen in case of accidents but not intentionally.
- If the MD is allowed to re-write SSRCs it gives a malicious MD the possibility to cause SSRC collisions on purpose to create the situation where a splicing attack becomes possible.

Best
 Nils Ohlmeier

> RFC 3550 and 3711 indicate that responsibility for collision resolution lies with the endpoints, so a PERC endpoint needs to be prepared to handle this, regardless of whether the MDD modifies SSRC.
> 
> On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Jul 16, 2017, at 16:08, Emil Ivov <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Emil Ivov <[email-masked]>
Date: Sun, 16 Jul 2017 22:47:36 +0000

This is the first time I see someone take the pain to actually describe the
dreaded SSRC splicing on this list and for that I am very grateful. Thanks
Nils.

As an answer though:

At best (and after what would likely be A LOT of retries) this would allow
the SFU to let one participant to impersonate another.

We already established that this is a know property of PERC that doesn't
bother us:

I believe Bernard was making a similar point.

If for some reason we do absolutely want to solve this specific scenario
(but not other kinds of intra conference impersonation) then it would be
trivially easy to do so. We could:

A. Specify that collision detection should be performed on the e2e ssrc and
not on the hop by hop one or simply

B. Limit the number of allowed retries to, say, 3

And again, I don't see why we would do either given that easier kinds of
impersonationthat dont involve the MD would remain possible.

Would love to hear your thoughts.

Emil

-- 
sent from my mobile

---

From: Emil Ivov <[email-masked]>
Date: Sun, 16 Jul 2017 23:00:38 +0000

On Sun, 16 Jul 2017 at 17:42, Nils Ohlmeier <[email-masked]> wrote:

> can occur between participants  (not just between a participant and the
> MDD as would normally be the case with a non-PERC SSRC-modifying MDD).
>
>
> Yes absolutely. That’s why the text further down includes statements like
> "So endpoint changes the SSRC again to C."
>
> - If the MD is NOT allowed to re-write SSRCs only another endpoint can
> cause a SSRC collision. As endpoints are trusted in PERC the assumptions is
> that collisions will only happen in case of accidents but not intentionally.
>
- If the MD is allowed to re-write SSRCs it gives a malicious MD the
> possibility to cause SSRC collisions on purpose to create the situation
> where a splicing attack becomes possible.
>

The collision alone could only result in a DoS, which the MD can already
do, or impersonation from one endpoint to another, which is already
possible and accepted. I fail to see how this creates a new vector.

Emil

>> two different endpoints and can choose to recombine the RTP headers from
>> client #1 with the payload from client #2.
>>
sent from my mobile

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 16 Jul 2017 16:34:09 -0700

Nils said:

"The important difference in my opinion is:
- If the MD is NOT allowed to re-write SSRCs only another endpoint can
cause a SSRC collision"

[BA]  If the MD can handle hop-by-hop repair (e.g. RED, RTX and FEC) can't
it cause an SSRC collision? Also, can't an MD send RTCP packets (e.g.
feedback, SDES, etc.) that could cause a collision?

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 16 Jul 2017 16:38:14 -0700

Emil said:

"A. Specify that collision detection should be performed on the e2e ssrc
and not on the hop by hop one or simply"

[BA] Specifying how collision detection works in PERC is necessary,
regardless of what the MDD does.  I think it makes sense to detect
collisions based on the e2e SSRC, but there will be tricky aspects, such as
how to deal with packets that aren't e2e authenticated (e.g. RTCP).

On Sun, Jul 16, 2017 at 3:47 PM, Emil Ivov <[email-masked]> wrote:

> This is the first time I see someone take the pain to actually describe
> the dreaded SSRC splicing on this list and for that I am very grateful.
> Thanks Nils.
>
> As an answer though:
>
> A. Specify that collision detection should be performed on the e2e ssrc
> and not on the hop by hop one or simply
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 17 Jul 2017 01:08:33 -0700

> the draft draft-grozev-perc-ssrc-00.
IIRC correctly from the presentation that Jan Mattson gave on these
attacks, the cause for splicing attack happens  when the MDD hides the fact
that collision has happened and rewrites the SSRC.
So if MDD sees a collision from endpoint B to be using same SSRC as
endpoint A, it hides that fact and rewrites the SSRC. This causes the
endpoints not to be aware of SSRC collisions and can end up in a state
where multiple endpoints having the same SSRCs.  Now, at a right point it
time (combining with the delay attack and storing the packets for
appropriate time), the MDD can  splice the stream from A to B and send it
to whomever it wants.

The one approach to mitigate this was to allow a topology where the
rewriting was not allowed. If rewriting is allowed, then there needs to be
a clearly defined mitigation procedures on handling/disallowing the above
to happen

Cheers
Suhas (as individual)

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 17 Jul 2017 01:27:05 -0700

> a clearly defined mitigation procedures on handling/disallowing the above

again a possibility that the MDD "can induce and hides collisions" at the
same time is more challenging to protect against, if I am not wrong in
thinking it

---

From: Emil Ivov <[email-masked]>
Date: Mon, 17 Jul 2017 12:50:27 +0000

On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar <[email-masked]> wrote:

> endpoint A, it hides that fact and rewrites the SSRC.
>

Hides it? Could you please be a little bit more specific? Are you assuming
the the original SSRC does not reach the receivers?

Emil

This causes the endpoints not to be aware of SSRC collisions and can end up
> in a state where multiple endpoints having the same SSRCs.  Now, at a right
> point it time (combining with the delay attack and storing the packets for
sent from my mobile

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 17 Jul 2017 05:58:53 -0700

> the the original SSRC does not reach the receivers?

   That's what SSRC rewriting means I presume ?

>
> Emil
>
> This causes the endpoints not to be aware of SSRC collisions and can end
>> up in a state where multiple endpoints having the same SSRCs.  Now, at a
>> right point it time (combining with the delay attack and storing the
>> packets for appropriate time), the MDD can  splice the stream from A to B
>> and send it to whomever it wants.
>>

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 17 Jul 2017 14:59:51 +0200

> On Jul 17, 2017, at 14:50, Emil Ivov <[email-masked]> wrote:
> 
> 
> On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar <[email-masked] <mailto:[email-masked]>> wrote:
> IIRC correctly from the presentation that Jan Mattson gave on these attacks, the cause for splicing attack happens  when the MDD hides the fact that collision has happened and rewrites the SSRC.
> So if MDD sees a collision from endpoint B to be using same SSRC as endpoint A, it hides that fact and rewrites the SSRC.
> 
> Hides it? Could you please be a little bit more specific? Are you assuming the the original SSRC does not reach the receivers?

I think quite a bit of the discussion here circles around assumptions of what kind of verifications a receiving endpoint does.

For example if SSRC is permitted and done by the MDD does the receiver need to apply SSRC collision detection only onto the re-written, outer SSRC, only the original, inner SSRC, or on both SSRCs?

My guess is that would be the safest to do all verifications on original and re-written values. But that should be discussed in the draft.

Best
  Nils Ohlmeier (as individual)

---

From: Emil Ivov <[email-masked]>
Date: Mon, 17 Jul 2017 13:00:59 +0000

On Mon, 17 Jul 2017 at 07:58, Suhas Nandakumar <[email-masked]> wrote:

>>>> Now an endpoint in a conference receives a RTP packet from that MD
>>>> where the re-written SSRC (outer SSRC) matches exactly the SSRC A the
>>>> endpoint itself is using for sending.
>> Hides it? Could you please be a little bit more specific? Are you
>> assuming the the original SSRC does not reach the receivers?
>>
>

The one solution that was discussed in Berlin and then in Chicago includes
preservation of the original SSRC in the OHB:

Emil

sent from my mobile

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 17 Jul 2017 15:02:07 +0200

> On Jul 17, 2017, at 15:00, Emil Ivov <[email-masked]> wrote:
> 
> 
> On Mon, 17 Jul 2017 at 07:58, Suhas Nandakumar <[email-masked] <mailto:[email-masked]>> wrote:
> On Mon, Jul 17, 2017 at 5:50 AM, Emil Ivov <[email-masked] <mailto:[email-masked]>> wrote:
> 
> The one solution that was discussed in Berlin and then in Chicago includes preservation of the original SSRC in the OHB:
> 

But on which of these two SSRCs do you do collision detection?

  Nils

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Jul 2017 10:50:25 -0700

Nils said:

"But on which of these two SSRCs do you do collision detection?"

[BA]  Answering that question requires an understanding of the RTP topology
that is being created when the MDD modifies the SSRC.

PERC appears to require that all participant SSRCs need to be unique
(implying that they are all within the same RTP session in an "RTP
translator" topology).

This would seem to imply to me that the SSRC in the OHB should be used for
collision detection.

If the MDD forwards RTCP packets, rather than terminating and originating
them, then the collision detection algorithm will operate on the "original"
SSRCs in RTP packets (contained in the OHB) as well as "original" SSRCs in
RTCP packets (unmodified by the MDD).

It seems to me that things get tricky if a PERC MDD attempts to terminate
and originate RTCP packets.

In a non-PERC scenario where the MDD modifies the SSRC in RTP packets, the
MDD also typically terminates and originates RTCP packets, which causes
each participant to have a distinct RTP session with the MDD. This works
because the session scope in RTP and RTCP is consistent.

However in PERC, it seems to me that this consistency breaks down if the
MDD attempts to terminate and originate RTCP packets. For example, if a
participant detects a conflict based on the SSRC in the OHB and sends an
RTCP "BYE" packet, and the MDD consumes the "BYE" packet, how does it reach
the other participants?  Similarly, if a participant sends an RTCP SDES
packet that would notify other participants of a conflict in a future SSRC
contained in the OHB and the MDD consumes that packet, collision detection
would be delayed.

On Mon, Jul 17, 2017 at 6:02 AM, Nils Ohlmeier <[email-masked]>
wrote:

>>>>> I think this attack plus it’s possible mitigations need to be
>>>>> described in the draft draft-grozev-perc-ssrc-00.
>>>>>
>>>>>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 18 Jul 2017 02:07:46 +0000

RTP requires SSRC collisions to be detected wherever SSRCs are used, not just the SSRC field in the RTP header. For example, collisions must also be detected in the CSRC list.

PERC does not alter those basic rules of RTP. If all participants and the MD are in the same RTP session, SSRC collision must be detected everywhere SSRCs are used in that single RTP session. If the RTP session boundaries are narrower, the collision detection domain is correspondingly narrower, but collision must still be detected everywhere SSRCs are used within each RTP session. We can't limit PERC collision detection rules to a few select fields containing SSRCs. It must apply to all fields containing SSRCs within the same RTP session.

Mo

From: Perc <[email-masked]<mailto:[email-masked]>> on behalf of Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 17, 2017 at 1:50 PM
To: Nils Ohlmeier <[email-masked]<mailto:[email-masked]>>
Cc: Suhas Nandakumar <[email-masked]<mailto:[email-masked]>>, Emil Ivov <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Perc] Splicing attack with SSRC rewrite (was: Re: PERC Draft Agenda - IETF99)

Nils said:

[BA]  Answering that question requires an understanding of the RTP topology that is being created when the MDD modifies the SSRC.

PERC appears to require that all participant SSRCs need to be unique (implying that they are all within the same RTP session in an "RTP translator" topology).

This would seem to imply to me that the SSRC in the OHB should be used for collision detection.

If the MDD forwards RTCP packets, rather than terminating and originating them, then the collision detection algorithm will operate on the "original" SSRCs in RTP packets (contained in the OHB) as well as "original" SSRCs in RTCP packets (unmodified by the MDD).

It seems to me that things get tricky if a PERC MDD attempts to terminate and originate RTCP packets.

In a non-PERC scenario where the MDD modifies the SSRC in RTP packets, the MDD also typically terminates and originates RTCP packets, which causes each participant to have a distinct RTP session with the MDD. This works because the session scope in RTP and RTCP is consistent.

However in PERC, it seems to me that this consistency breaks down if the MDD attempts to terminate and originate RTCP packets. For example, if a participant detects a conflict based on the SSRC in the OHB and sends an RTCP "BYE" packet, and the MDD consumes the "BYE" packet, how does it reach the other participants?  Similarly, if a participant sends an RTCP SDES packet that would notify other participants of a conflict in a future SSRC contained in the OHB and the MDD consumes that packet, collision detection would be delayed.

On Mon, Jul 17, 2017 at 6:02 AM, Nils Ohlmeier <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 17, 2017, at 15:00, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, 17 Jul 2017 at 07:58, Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Jul 17, 2017 at 5:50 AM, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, 17 Jul 2017 at 03:08, Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> wrote:
On Sun, Jul 16, 2017 at 2:50 PM, Nils Ohlmeier <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 16, 2017, at 16:08, Emil Ivov <[email-masked]<mailto:[email-masked]>> wrote:

This is factually wrong.

Please refer to

So here is the attack I'm concerned about:

I think this attack plus it's possible mitigations need to be described in the draft draft-grozev-perc-ssrc-00.

  Nils

_______________________________________________
Perc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perc