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

["Paul E. Jones" <[e-mail]>]

Emil,

>Hey Paul
>
>On Wed, May 11, 2016 at 6:12 PM, Paul E. Jones <[e-mail]> 
>wrote:
>>  Emil,
>>
>>>  A) Because otherwise that scr*ws up authentication because we cannot
>>>  keep track of the overwrites across RTP and RTCP: obviously this is
>>>  not true as we could simply not use SSRCs for PERC-specific purposes
>>>  and define PERC specific IDs
>>
>>  I'm not following that one.  RTCP is HBH, so not an issue.  Why would 
>>we
>>  need a PERC-specific ID?
>
>My point is that if you need an immutable ID then you can define your
>own. As I already stated in this thread: that new ID can be a copy of
>the original SSRC or something new: whatever works.

We do not really need an identifier, except to address the one security 
issue raised here:
https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4

With the agreement reached (after a lot of discussion) back in December 
not to change the SSRC, this issue no longer exists.

>>  I assume this is as an alternative to the SSRC in
>>  the cryptographic context?  We would not need that given "double" 
>>defined a
>>  field that could record the original E2E SSRC value.  (Yes that is 
>>now
>>  removed, but see below.)
>>
>>>  B) You are not correct and I, who have never implemented an SFU in 
>>>my
>>>  life, am telling you that you can reimplement your SFU to not rely 
>>>on
>>>  SSRC rewriting and it will be a piece of cake. I hope I don't have 
>>>to
>>>  comment on B.
>>
>>  It is indeed a fact that you can write a switching function that does 
>>not
>>  require changing SSRCs.
>
>Yes you can do that. You can also travel from Paris to London via
>Sydney: few people are making that choice though. All SFUs I am aware
>of overwrite SSRCs even if the one that you wrote might have taken a
>different path.

I'm scratching my head on this. ISTM that remapping SSRC is the longer 
path from Paris to London. I appreciate that you might not have seen all 
of the products on the market; there certainly are some that do not 
rewrite SSRCs.  So, I am curious why you cannot build a system that just 
leaves the SSRCs alone.

>>>  As an IETF WG, PERC's behaviour on this topic has been very 
>>>confusing
>>>  to me and I am almost at the point where willful disruption is the
>>>  only possible explanation that I can find. If we do proceed to 
>>>ignore
>>>  implementers the same way we are going to find ourselves debating 
>>>the
>>>  same concerns in IETF last call where reason would have a better
>>>  chance of prevailing.
>>
>>  I think the issue is this: you've not attended the meetings.  We had
>>  accommodated the option to change nearly everything in the RTP header 
>>via
>>  the OHB in "double".  During a recent meeting, it was decided to 
>>limit the
>>  scope of what can be changed.  We made the original "double" proposal 
>>to
>>  allow for anything to be changed
>>  (https://tools.ietf.org/html/draft-jennings-perc-double-00) and 
>>participants
>>  in the meeting said to reduce the possible set down to PT and 
>>sequence
>>  number, so we produced
>>  https://tools.ietf.org/html/draft-jennings-perc-double-01 
>>accordingly.  This
>>  change was proposed in a conference call, if I recall, and then 
>>discussed
>>  face-to-face before the document moved forward to WG adoption.
>>
>>  I do not recall any person on a phone call or in the meeting room who
>>  opposed the changes.  It came as a pleasant surprise to the authors 
>>that
>>  everyone was agreeable to such a narrow set of fields that could be 
>>changed.
>
>I am stunned!
>
>Paul, we first had this very conversation five months ago:
>
>https://www.ietf.org/mail-archive/web/perc/current/msg00136.html

Yes, I recall the older conversation and, in fact, we had it in our 
draft to allow the SSRC to change.  However, the decision to not modify 
the SSRC followed email exchange and the decision has been in place 
since at least early December.

>Numerous implementors commented here. This should have been the end of 
>it.
>
>then a bit later I raised it again here:
>
>https://www.ietf.org/mail-archive/web/perc/current/msg00222.html
>
>Now this.

Yes, at the time it was an active topic of discussion.  The decision was 
made, minutes reported, documents updated, etc.  I think it is the rest 
of us who were participating in the meetings who should be stunned at 
this issue being raised again.


>So are you now saying: "well Emil the issue is that you are not
>present on all meetings so every time we try to sneak this back in,
>you are not there to stop us and that's your problem!"

No, I don't expect anyone to be at every meeting.  However, you do need 
to appreciate that the decision is now 5 months old the group has 
long-since considered this issue closed.


>>  Can we support changing SSRCs?  Yes, we can put it back in.  We will 
>>need to
>>  change the way we have the OHB encoded, but it's certainly possible.
>>
>>>  E2E encryption is too important of a subject for us to botch this 
>>>work.
>>
>>  I can only encourage you to participate in meetings when they're 
>>called and
>>  to comment on drafts as they're published.  Heck, even if you cannot 
>>make a
>>  face-to-face meeting, the -01 draft has been out there since March 21 
>>and
>>  nobody commented on that change until this week.
>
>It is one thing to encourage involvement when new decisions are being
>made. I support this and we are all doing our best.
>
>It is a completely different thing to require participation so that
>the same points can be made over and over and over again.

I think you're mis-characterizing the events.  The SSRC issue was an 
active topic of discussion back in November / December.  We had to 
settle how we were going to deal with every header field and Magnus led 
that dialog taking us through a couple of hours of discussion as we went 
through each and every header value.  That meeting was held on November 
30 and a recording for that meeting posted to the list:
https://cisco.webex.com/ciscosales/lsr.php?RCID=2684921e717d4b45aadb88d9a8774ce5

The SSRC dialog was at 1:01:43 and we talked about it for about 20 
minutes.  I think it might be worth your time to review that.  Maybe you 
have a valid point not raised by others in the meeting, but I really 
think it's unfortunate that you re-raise this issue after we revised the 
drafts and went through another IETF meeting where the group adopted 
text based on this decision.

Paul