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

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

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?  Or are there other fields?  (The 
three fields that can change per current agreement is PT, X, and 
sequence number.)

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.  Browsers will have to explicitly add support 
for PERC, and I think they'll be able to manage.

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


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

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

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

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


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


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

Paul