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

[Emil Ivov <[e-mail]>]

Hey Paul,

On 12.05.16 г. 21:27, Paul E. Jones wrote:
> 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.

Let's please get that reversed. We need SSRC and seq num rewriting to be 
possible so let's find a different solution to that *one* security issue 
that wouldn't make a bunch of implementers whine on this list every few 
months.

It is not a big deal for this WG's work. It has a huge impact on the 
adoption of that work though.

>>>  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.

You will understand as soon as you try to implement an SFU that works 
well with WebRTC today.

> I appreciate that you might not have seen all
> of the products on the market;

I am pretty sure I know about most of the WebRTC compatible ones.

> there certainly are some that do not
> rewrite SSRCs.

And they, whoever they are, would be just fine if we relaxed the 
requirements on immutable seq nums and SSRCs.

> So, I am curious why you cannot build a system that just
> leaves the SSRCs alone.

I have already built my system. So have Google and Vidyo and Janus and 
Microsoft and Kurento. We are *all* rewriting sequence numbers and SSRCs.

>>>>  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.

I cannot believe you are making that point. Did you at any point see any 
of the concerned implementers come back and say: "Oh right! That totally 
makes sense now! Forget about immutable seq nums and SSRCs, we can do 
with out them. Roll on!"

As a responsible document editor, *that* is what you should be looking 
for. Same for all actively participating WG members.

You know me, you know Lorenzo, you know Bernard I assume you also know 
people from the other companies/orgs implementing simulcast through SSRC 
and seq num rewrites.

Did you see them take part of the discussion? Did you take any steps to 
go and check with them?

"You weren't there to complain then, so get lost now" is a pretty bad 
argument and I certainly didn't expect it from someone with your 
experience.

>> 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.

I fail to see how that is in any way relevant. The concerns were stated 
before the decision was made. The people having made the concerns were 
absent when it was decided to not address them.

This doesn't mean they didn't care. If they didn't they wouldn't have 
stated them. This simply means that they trusted the WG to do the right 
thing.

It did not!

>>>  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.

I couldn't agree more. It is very unfortunate and so easily avoidable if 
only steps had been taken to ping the concerned parties.

Now ... can we please stop this arguing and just work around the issue 
with s.num/ssrc rewriting?

Please!

Emil


-- 
https://jitsi.org