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

[Emil Ivov <[e-mail]>]

Hey Paul,

On 13.05.16 г. 22:21, Paul E. Jones wrote:
> Emil,
>
>>> 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.
>
> The group concluded that sequence numbers could be changed.  So, I think
> only the SSRC is an issue, right?

They both go hand in hand and yes, immutable SSRCs is the missing piece.

> Or are there other fields?  (The
> three fields that can change per current agreement is PT, X, and
> sequence number.)

Timestamps. That's part of the simulcast package.

> As an aside, I would still prefer we did not re-write RTP sequence
> numbers, but I appreciate the argument that it would be more appropriate
> for the receiver in terms of RFC 3550 intent.
>
>>>>>  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.
>
> Given that browsers today do not support what's being proposed, I don't
> see where you're going.

I said: doing away with SSRC rewriting will significantly complicate the 
life of SFUs

You said: it sounds to me that the very fact they are doing SSRC 
re-writing is the source of their complication.

I said: If you were to implement a WebRTC compatible SFU, you would 
understand exactly how SSRC rewriting is the (significantly) simpler option.

> Browsers will have to explicitly add support
> for PERC, and I think they'll be able to manage.

I wouldn't be so sure. We have no people here representing Chrome. We've 
had people from MS speak against it and the only pro-voice from a 
browser vendor has been Adam's.

>>> 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.
>
> But it's not doing PERC.

No it is not. I would really like it to but what you are asking us to do 
in order to support PERC is to throw away our simulcast implementation 
and I am not going to do that.

If it ever came to that then I'd much rather do without PERC and rely on 
something more reasonable even if it meant depending on rich clients.

> It's not doing end-to-end encryption with HBH
> in the middle, using appropriate logic for switching based on active
> speaker, and simulcast in a manner that will allow the receiver to
> compose media flows into something useful.  There are still many things
> we need to realize PERC in practice.  Let's avoid designing around what
> we have and figure out what we need.  I'm personally unconvinced that
> SSRC rewriting buys us anything.

It buys us adoption. Whether that matters to you is a different subject.

>>>> 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!"
>
> People from Cisco, Ericsson, Mozilla, Vidyo, Huawei, etc. were on a call
> and we reached agreement following a discussion about it.  It was a
> public call, minutes reported, etc.  We then revised the documents
> accordingly, published them, and then reviewed them face-to-face with a
> much larger audience.  Nobody presented a technical argument during that
> time for why this will not work, and the adopted approach is definitely
> in the spirit of RFC 3550.

This is going in circles ... Look, if that's what this is about then I 
am happy to take the blame for not taking that point far enough.

Now that this is out of the way, could we please revisit the decisions? 
Chairs? ADs? All?

It wouldn't be a big deal. It wouldn't hurt anyone, and it would make 
this entire problem go away.

>> Did you see them take part of the discussion? Did you take any steps
>> to go and check with them?
>
> I think your frustration with me is like "shooting the messenger."  If
> you'll listen to that recording I referenced in my last message, I
> suspect you will not even hear me speak up on the issue.  No decision
> was done in a vacuum; I'm just responding to the fact that you're
> digging up bones at this point.

As a co-author in two of the three WG documents you are more than just a 
messenger. Didn't mean to shoot anyone though. I am grateful you have 
engaged in the discussions!

>> "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.
>
> Again, don't shoot the messenger here, but the decision was reached 5
> months ago, with all of the material put put online for discussion, a
> F2F meeting held, etc.  So, to some extent I think it is reasonable to
> counter-argue with why you're re-opening points that were considered
> closed.  A good technical argument for why the current agreement is
> flawed would be helpful, but you are not making such an argument.

That's ... quite a confusing statement. People from Microsoft, Kurento, 
Janus, as well as myself have all explained how our implementations rely 
on SSRC rewriting for things such as simulcast. How is that not a 
technical argument?

>>>> 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.
>
> With all due respect, it's been out on the list for 5 months, documents
> published showing how it will work, etc.  I told you I don't expect
> people will be at meetings (they cost money), but the particular meeting
> where this agreement was reached cost no money to attend, recording was
> posted, minutes posted, documents revised and published several months
> later with no strong opposition to the decision, then no opposition at
> the meeting in April, etc.

Again, happy to take the blame if that would make things better. Now 
that it is all out there and everyone is well aware of the tradeoffs, 
could we please reverse this decision? It would be a trivial change for 
PERC and it would make the difference between adopting or ignoring it 
for a bunch of implementers.

>> 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!
>
> You are suggesting that the decision of the WG is somehow technically
> flawed,

That's quite a misrepresentation and I would appreciate it if you didn't 
attribute to me statements I never made. I have never said anything 
about PERC being technically broken in its current state.

All this is about is the fact that it is going in a direction that 
compromises its adoption.

> but what you're really concerned about is that you have to do
> some work to support PERC.  Everyone has to do some work to support
> PERC.  It is two-pass encryption with a switching function in the
> middle, DTLS-SRTP from the endpoints (which is not common at all
> presently, but viewed as far more secure than Security Descriptions), etc.

Oh come on Paul. Really? Some work? Do you really believe that or are 
you just writing it to be spiteful?

I am happy to ask my team to do the work to implement PERC support. What 
I will not do is ask them to do that and then go and reimplement 
simulcast just because the people who created the protocols decided they 
didn't care about our problems.

>>> 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.
>
> This was not a secret meeting.

Please point me to the message where I said that it was.

> As I noted above, the meeting was called
> in public, recording posted in public, meeting minutes from two
> different people posted in public, time elapsed with no departure from
> that consensus, so in March we revised the documents per the agreement
> in December and an announcement was sent to the list.  We then had a
> meeting F2F and discussed the texts again and adopted them.  So, you
> were pinged. :)
>
>> Now ... can we please stop this arguing and just work around the issue
>> with s.num/ssrc rewriting?
>
> PERC will allow rewriting sequence numbers so that systems can strictly
> comply with RFC 3550 (and to help network monitoring functions that are
> looking for packet drops,  I guess).  But, I do not know what to tell
> you on SSRC.  I'm just one guy in the crowd here.

Well if the crowd doesn't care then I guess we wouldn't either. At this 
point I can only consider that this was the goal all along so ... good job!

Emil
-- 
https://jitsi.org