Re: [Perc] Request for decision review

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

Miguel,

The current design of PERC is one where there is an E2E encryption step 
using regular SRTP.  An intermediary does not have the E2E keys and, 
therefore, cannot change anything about the packet.  Then, that packet 
is encrypted HBH using a different key that the next hop device will 
have.  Assuming the next hop device is an MDD (nor "Media Distributor"), 
that device could have the liberty of changing the sequence numbers and, 
in fact, it will be obliged to do so if it does not always forward all 
of the streams (since not forwarding some streams will mean the 
cryptographic context gets out of sync).

So in the typical case, the MDD will change the sequence number and 
might insert a new header extension to carry the original value.  It 
might also change the payload type value.

How, as the endpoint receives a packet, it will decrypt the HBH packet 
and reconstruct the E2E packet using the OHB field.  But what is there?  
Well, it's the original packet as created by the sending endpoint.  Even 
if we change the SSRC or sequence number, the original values are there 
and preserved.  So, other than out of necessity (sequence number changed 
to keep crypto context in sync and PT changed to ensure the right PT 
value is received as expected), I'm still not convinced that changing 
the SSRC really buys us anything.  Sure, we could change it.  We 
actually has space in the OHB originally to allow that.  But for what 
purpose?  Changing or not changing an SSRC value should not have any 
affect whatsoever on the QoE.   (I'm not saying the SSRC has no 
importance, but I question the need to rewrite them.)

I'm not sure how the other identifiers you mention might help improve 
QoE.  Maybe expand on that little?

One important point to consider in all of this is that WebRTC browsers 
MUST be PERC-aware, else they cannot participate in conferences.  If 
they're not PERC-aware, then there would have to be a middlebox that 
"downgrades" for those older browsers and it can rewrite whatever it 
wants, since it would be in possession of keys and would strip off one 
layer of encryption to produce a legacy SRTP flow (or no SRTP at all).

Paul

------ Original Message ------
From: "Miguel París Díaz" <[e-mail]>
To: "Emil Ivov" <[e-mail]>
Cc: "Eric Rescorla" <[e-mail]>; "Paul E. Jones" 
<[e-mail]>; "Adam Roach" <[e-mail]>; 
"[e-mail]" <[e-mail]>; "Cullen Jennings" <[e-mail]>
Sent: 7/20/2016 6:56:59 AM
Subject: Re: [Perc] Request for decision review

>Hello everybody,
>I understand the point of Emil because as implementer I am worried 
>about having hard restrictions which avoid or hinder the implementation 
>of features requested by the market, and this could make PERC unusable.
>
>So I think that firstly we should reach consensus about which features 
>or uses cases must be allowed to be implemented and then discuss the 
>low level details taking into account that we won't can add 
>restrictions which avoid these features.
>This may also apply to others WGs and not only to PERC. Even having 
>support for rid, mid, etc. could ease the design of PERC.
>
>Ones of the features affected with the current status are:
>   1 - Video quality switching (simulcast)
>   2 - Dominant Speaker switching
>
>These features must also offer an high QoE for the users. For that, the 
>experience tells me that it should be performed in the SFU side. In our 
>current implementation:
>   1 - Video quality switching (simulcast) is performed rewriting SSRCs, 
>seqnums and timestams
>   2 - Dominant Speaker switching is performed rewriting SSRCs, seqnums 
>andt timestams. Notice that it would be consider and attack [1] when it 
>is the best way (easy, efficient and
>with high QoE) we found to implement this feature.
>
>This is working in the WebRTC context using endpoints like Chrome or 
>Firefox. To implement them following current PERC status:
>Could (1) be implemented without SSRCs rewriting and using RID instead?
>I think so, but should be ensure that endpoints support that before 
>make SSRC immutable?
>Could (2) be implemented without SSRCs rewriting and using MID instead? 
>Could (2) be implemented even without adding a specific RTP stream 
>using idea [2]?
>I think so, but should be ensure that endpoints support that before 
>make SSRC immutable?
>
>These questions tell me that if endpoints does not support them, 
>features requested by the market and PERC will be incompatible :S.
>
>Best regards!!
>
>Refs
>[1] 
>https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4
>[2] https://www.ietf.org/mail-archive/web/mmusic/current/msg16611.html
>
>2016-05-26 1:12 GMT+02:00 Emil Ivov <[e-mail]>:
>>
>>
>>On Wednesday, 25 May 2016, Eric Rescorla <[e-mail]> wrote:
>>>
>>>
>>>On Wed, May 25, 2016 at 1:43 PM, Emil Ivov <[e-mail]> wrote:
>>>>
>>>>
>>>>On 25.05.16 г. 15:20, Paul E. Jones wrote:
>>>>>Emil,
>>>>>
>>>>>You are saying that endpoints would negotiate via signaling which 
>>>>>SSRC
>>>>>value(s) to use before actually joining the conference?
>>>>
>>>>It's awesome how you would always attribute to me the least 
>>>>appealing of all possible interpretations :).
>>>>
>>>>Whether or not we negotiate SSRCs should not be within PERC's scope. 
>>>>For the record this is how WebRTC works anyway (courtesy of some of 
>>>>the people on this list) but the matter is completely orthogonal to 
>>>>PERC.
>>>>
>>>>What I was suggesting is the possibility for PERC endpoints and MDD 
>>>>to negotiate whether or not they will be dealing with a single 
>>>>end-to-end SSRC space, or whether they will have separate HBH and 
>>>>E2E SSRC spaces.
>>>>
>>>>This way you get to only implement the single end-to-end option in 
>>>>your endpoints and to not support the other one.
>>>>
>>>>Does this make more sense?
>>>>
>>>>>That doesn't strike me as terribly appealing, honestly.  Between 
>>>>>that
>>>>>and the pain of dealing with conflicting SSRCs, I might favor the
>>>>>latter.  What I'd prefer most, though, is neither and just let 
>>>>>endpoints
>>>>>do their thing.
>>>>>
>>>>>I'd still like to hear confirmation that receiving browsers will
>>>>>definitely be doing the right thing w.r.t. receiving simulcast 
>>>>>streams.
>>>>>Adam seemed to suggest Firefox will be doing the right thing 
>>>>>(probably
>>>>>before PERC is done). What about popular browsers?
>>>>
>>>>I think at this point the answers that I've heard are for both 
>>>>browsers: we are not doing this now.
>>>
>>>As far as Firefox goes, we're not doing this now because PERC isn't 
>>>ready.
>>
>>So you are saying that simulcast itself is not a good enough reason to 
>>implement  receiver-side simulcast support ... but a minor 
>>optimization to PERC is ...
>>
>>Obviously I don't need to be explained the reasoning. I am glad you 
>>have this plan.
>>
>>I only wish we would have a clearer view of everyone's intended 
>>delivery dates since we are about to block PERC on them.
>>
>>
>>>We're looking at it soon and plan to try to implement it pretty much 
>>>as soon as it's baked enough to do.
>>>
>>>
>>>>it's not part of webrtc 1.0.
>>>
>>>Is it even something that could be in WebRTC 1.0? I.e., does it 
>>>require changes?
>>
>>How would you tell FF what group an RID corresponds to?
>>
>>Emil
>>>
>>>
>>>
>>>>we'd like to do it in the future.
>>>
>>>Yes.
>>>
>>>-Ekr
>>>
>>>
>>>
>>>>
>>>>What I'd like to avoid is PERC having a firm dependence on this last 
>>>>statement and for it to only be usable when it comes true.
>>>>
>>>>Emil
>>>>
>>>>>
>>>>>Paul
>>>>>
>>>>>------ Original Message ------
>>>>>From: "Emil Ivov" <[e-mail]>
>>>>>To: "Paul E. Jones" <[e-mail]>
>>>>>Cc: "Adam Roach" <[e-mail]>; "Cullen Jennings" 
>>>>><[e-mail]>;
>>>>>[e-mail]
>>>>>Sent: 5/25/2016 2:23:43 PM
>>>>>Subject: Re: [Perc] Request for decision review
>>>>>
>>>>>>Paul,
>>>>>>
>>>>>>I have answered your points below but we did gloss over the 
>>>>>>suggestion
>>>>>>I made and I consider it important:
>>>>>>
>>>>>>We can allow SSRC rewriting and make it negotiable by signalling. 
>>>>>>This
>>>>>>way SFUs can state they support rewriting/immutability/both and
>>>>>>endpoints can choose to use what's available or reject the session 
>>>>>>as
>>>>>>unsupported.
>>>>>>
>>>>>>I believe this should address the concerns that have been 
>>>>>>expressed so
>>>>>>far.
>>>>>>
>>>>>>Now for the rest of the points:
>>>>>>
>>>>>>On 25.05.16 г. 7:22, Paul E. Jones wrote:
>>>>>>>Emil,
>>>>>>>
>>>>>>>>>Since we are not enforcing a requirement that endpoints select 
>>>>>>>>>a
>>>>>>>>>distinct SSRC per media flow, there is a potential conflict in 
>>>>>>>>>the
>>>>>>>>>number space used E2E.
>>>>>>>>
>>>>>>>>As I have been insisting many times already: We have the option 
>>>>>>>>to
>>>>>>>>mandate that SFUs preserve the SSRC space. That's not hard to
>>>>>>>>implement. It's not a great option but it is a possibility.
>>>>>>>>
>>>>>>>>We can also say that whether or not SFUs do that rewrite is a 
>>>>>>>>feature
>>>>>>>>that has to be signalled so clients can choose whether to 
>>>>>>>>support it
>>>>>>>>or not. This should address your concern.
>>>>>>>
>>>>>>>The SFU has nothing to do with the E2E SSRC collision problem.  
>>>>>>>When an
>>>>>>>endpoints sends out an RTP packet and it goes though an SFU that 
>>>>>>>changes
>>>>>>>the SSRC, there is a HBH SSRC and an E2E SSRC.  I fully agree 
>>>>>>>that the
>>>>>>>SFU can ensure that the HBH SSRCs do not collide, but it cannot 
>>>>>>>control
>>>>>>>the fact that the E2E SSRCs collide.
>>>>>>
>>>>>>The SFU has everytihng to do with the E2E collision problem and 
>>>>>>it's
>>>>>>potential solutions. What you describe is one way to handle 
>>>>>>things.
>>>>>>Another one would be to just make SSRC conflicts obvious to 
>>>>>>senders so
>>>>>>that they would apply 3550 resolution. That's pretty easy to 
>>>>>>implement.
>>>>>>
>>>>>>>>>The 64 bit identifier is just a hack to work
>>>>>>>>>around that problem. If the problem didn't exist, we could use 
>>>>>>>>>SSRC
>>>>>>>>>values to look up the context as it was I intended in SRTP.
>>>>>>>>
>>>>>>>>E2E PERC is NOT SRTP. We may choose to make it look like it is 
>>>>>>>>and I
>>>>>>>>see why that is appealing but not doing it is by no means "a 
>>>>>>>>hack".
>>>>>>>
>>>>>>>Of course it's SRTP.  It just happens to be two passes of SRTP, 
>>>>>>>but it's
>>>>>>>nonetheless SRTP.
>>>>>>
>>>>>>Exactly! And two passes of SRTP happen to NOT be SRTP as in: no 
>>>>>>stock
>>>>>>SRTP endpoint would do anything meaningful with them. So what you 
>>>>>>are
>>>>>>looking is to just optimize implementations, which is relevant but 
>>>>>>not
>>>>>>the primary concern.
>>>>>>
>>>>>>>What PERC is adding are some additional steps between
>>>>>>>each pass for HBH authentication of packets at the sender (and 
>>>>>>>the
>>>>>>>reverse at the receiver).  The MDD doesn't have two steps: it 
>>>>>>>just does
>>>>>>>one normal SRTP decryption for the packet received and one SRTP
>>>>>>>encryption step sending the packet.  The only special requirement 
>>>>>>>PERC
>>>>>>>introduces is that if the MDD changes either the PT field or 
>>>>>>>sequence
>>>>>>>number, the original values have to be added to the packet inside 
>>>>>>>an RTP
>>>>>>>header extension called OHB (if not already present).
>>>>>>>
>>>>>>>
>>>>>>>>>The problem with using a 64 bit value is that any existing SRTP
>>>>>>>>>library
>>>>>>>>>would have to change to associate the context that way.
>>>>>>>>
>>>>>>>>So just to be clear ... we are lamenting about changing an int 
>>>>>>>>to a
>>>>>>>>long?
>>>>>>>
>>>>>>>No, lamenting that this would not align with what RFC 3711 says 
>>>>>>>to use
>>>>>>>to identify the context.
>>>>>>
>>>>>>Again, 3711 applies to HBH. We are trying to reuse as much of it 
>>>>>>for
>>>>>>E2E as possible and that's admirable but it's not a reason why we
>>>>>>should significantly disrupt existing implementations.
>>>>>>
>>>>>>>>>Further, if we
>>>>>>>>>wish to break up the PERC processing into two steps, that HBH 
>>>>>>>>>SSRC
>>>>>>>>>would
>>>>>>>>>have to be extracted and passed in by the application. While I
>>>>>>>>>think the
>>>>>>>>>intent with Double is for this to be an autonomous operation, 
>>>>>>>>>it might
>>>>>>>>>not be implemented that way for two reasons:
>>>>>>>>>1) If there is a desire to do HBH FEC, the process might be to 
>>>>>>>>>encrypt
>>>>>>>>>E2E -> FEC -> HBH. So the second call to the SRTP library would 
>>>>>>>>>need
>>>>>>>>>that HBH SSRC passed in when doing these steps in reverse to 
>>>>>>>>>introduce
>>>>>>>>>that 64-bit context ID.
>>>>>>>>
>>>>>>>>Em ... you'd have to explain this in a bit more detail because I 
>>>>>>>>fail
>>>>>>>>to see how FEC is any different than regular media. As you say 
>>>>>>>>it
>>>>>>>>yourself, it all just works out properly as long as you do your 
>>>>>>>>FEC
>>>>>>>>after E2E and before HBH as that way the SFU would be able to 
>>>>>>>>de- or
>>>>>>>>re-FEC.
>>>>>>>
>>>>>>>Historically, there were two options for FEC.  Either we do FEC 
>>>>>>>first
>>>>>>>and then SRTP, or SRTP first then FEC.  The order has to match at 
>>>>>>>both
>>>>>>>the sender and receiver.  Either way, it generally makes very 
>>>>>>>little
>>>>>>>difference.
>>>>>>>
>>>>>>>An MDD might want to be a good citizen and reconstruct lost 
>>>>>>>packets
>>>>>>>before sending a stream to a receiver.  In order to do that, the 
>>>>>>>sender
>>>>>>>will either need to do SRTP (both passes) then FEC or it could do 
>>>>>>>the
>>>>>>>first SRTP pass (the E2E encryption pass) then FEC then SRTP for 
>>>>>>>the
>>>>>>>HBH.  It really depends on what we want that FEC flow to look 
>>>>>>>like.  Do
>>>>>>>we want it to be FEC over a bunch of E2E+HBH encrypted packets or 
>>>>>>>just
>>>>>>>over the E2E packets.  (The latter would be parallel to the 
>>>>>>>current FEC
>>>>>>>order of "FEC then SRTP".
>>>>>>>
>>>>>>>So, thinking of how this might be implemented in an SRTP library, 
>>>>>>>if we
>>>>>>>allow the SRTP(E2E)+FEC+SRTP(HBH) option for FEC order, then when 
>>>>>>>the
>>>>>>>application encrypts the packet, it would pass the packet into 
>>>>>>>the SRTP
>>>>>>>libtary once to encrypt HBH.
>>>>>>
>>>>>>You mean E2E here.
>>>>>>
>>>>>>>  It then does whatever FEC processing it
>>>>>>>wants, then it calls into the SRTP library again to encrypt the 
>>>>>>>second
>>>>>>>pass (HBH pass).  It could be two entirely instances of the SRTP 
>>>>>>>library
>>>>>>>that handles each pass.  On the MDD, it decrypts the flow and 
>>>>>>>does
>>>>>>>whatevever FEC magic it wants to do.  There is only one SRTP 
>>>>>>>operation
>>>>>>>at the MDD, so no problem.  At the receiver, it decrypts the 
>>>>>>>packet
>>>>>>>received using HBH decryption. It then does whatever FEC 
>>>>>>>processing it
>>>>>>>needs to do.  Next, it would call into the SRTP library to 
>>>>>>>decrypt for
>>>>>>>E2E.  If the SSRCs never change, this works fine.  One could 
>>>>>>>implement
>>>>>>>this using two instances of an SRTP library today.  If a single 
>>>>>>>library
>>>>>>>is used, then the only requirement is to ensure the second call 
>>>>>>>into the
>>>>>>>library does not encounter issues with the replay database (since 
>>>>>>>it
>>>>>>>might otherwise think it's a replayed packet).  In either case, 
>>>>>>>the
>>>>>>>crypto context would be looked up as per RFC 3711 using SSRC.  
>>>>>>>If,
>>>>>>>however, the SSRC value is allowed to change, then the second 
>>>>>>>call into
>>>>>>>the SRTP library (same or different instance of the library) 
>>>>>>>would be a
>>>>>>>problem since Alice and Bob both used SSRC 1.  The collision is 
>>>>>>>going to
>>>>>>>prevent the library from working properly.
>>>>>>
>>>>>>I still fail to see how FEC changes any of this (for better or 
>>>>>>worse).
>>>>>>The problem you describe here is exactly the same with or without 
>>>>>>FEC
>>>>>>and it's what we are having the argument about.
>>>>>>
>>>>>>>If we take the approach of using a 64-bit identifier (in 
>>>>>>>contradiction
>>>>>>>to RFC 3711)
>>>>>>
>>>>>>:) ... It is NOT in contradiction with 3711 because layers of
>>>>>>encryptions are not part of 3711. We simply need to set the
>>>>>>expectations right for implementers.
>>>>>>
>>>>>>>  to identify the crypto context, then we would need to pass
>>>>>>>that identifier into the SRTP library when attempting to decrypt 
>>>>>>>the
>>>>>>>packet, because it could not simply discover it by looking at the 
>>>>>>>packet
>>>>>>>(which it could do normally since the SSRC value is right there 
>>>>>>>in the
>>>>>>>packet).  It would be necessary to make a call like
>>>>>>>srtp_unprotect(context, packet, stream_identifiier) (where
>>>>>>>stream_identifier is something that identifies the stream other 
>>>>>>>than the
>>>>>>>SSRC per 3711, like E2E_SSRC || HBH_SSRC).
>>>>>>>
>>>>>>>A beautiful thing about SRTP today
>>>>>>
>>>>>>You mean PERC here and not SRTP (even if PERC does simply apply a
>>>>>>second srtp unprotect it is still not stock 3711).
>>>>>>
>>>>>>>is the library can operate on streams
>>>>>>>without the application having to pass in such identifiers.  The 
>>>>>>>stream
>>>>>>>is self-identifying.  But, we lose that elegance when we modify 
>>>>>>>the SSRC
>>>>>>>in the MDD when we break the operation into two passes to handle 
>>>>>>>this
>>>>>>>FEC order.
>>>>>>
>>>>>>So we have an aesthetic concern because we have to change int-s to
>>>>>>long-s and that's why we are having a 100 mail thread. I am 
>>>>>>speechless.
>>>>>>
>>>>>>>>>2) It might be desirable to implement the PERC logic by just 
>>>>>>>>>having a
>>>>>>>>>two-step wrapper around the existing SRTP library to avoid 
>>>>>>>>>making
>>>>>>>>>changes to the core library. (I'd prefer built-in support for 
>>>>>>>>>Double,
>>>>>>>>>but I can appreciate how some might prefer to not change an 
>>>>>>>>>otherwise
>>>>>>>>>working library.)
>>>>>>>>
>>>>>>>>As I said, being able to reuse SRTP libraries with no change is 
>>>>>>>>a
>>>>>>>>great optimization if we get it but I really don't think the
>>>>>>>>alternative is anywhere near the complexity that would justify 
>>>>>>>>banning
>>>>>>>>SSRC re-writing.
>>>>>>>
>>>>>>>At least we agree that it would be a good goal to find an 
>>>>>>>approach that
>>>>>>>would eliminate or minimize changes to the SRTP logic. :)
>>>>>>>
>>>>>>>Now to the complexity part... that's in the thread you're having 
>>>>>>>with
>>>>>>>Cullen which, as I understand, is an expression of a concern that
>>>>>>>receiving endpoints are not going to properly handle multiple 
>>>>>>>simulcast
>>>>>>>streams coming toward them.
>>>>>>>
>>>>>>>Since I don't work for a browser vendor, I cannot speak to their 
>>>>>>>plans.
>>>>>>>I can only assume that proper handling of received simulcast 
>>>>>>>flows would
>>>>>>>be implemented per the current drafts.  And if that's the case, 
>>>>>>>then I
>>>>>>>don't think changing the SSRC would be needed.  If receiving 
>>>>>>>endpoints
>>>>>>>fail to do that, then you're right that this could be a problem.
>>>>>>
>>>>>>Let's be clear on this. There is absolutely nothing wrong or 
>>>>>>standard
>>>>>>breaking in the way browsers handle simulcast reception today. 
>>>>>>They
>>>>>>are simply not simulcast aware and the SFU hides it from them.
>>>>>>
>>>>>>There is no reason why that would be labelled a bad practice even 
>>>>>>when
>>>>>>RID does go through all of the IETF process.
>>>>>>
>>>>>>Also, the availability of this option (simulcast unaware 
>>>>>>receivers)
>>>>>>and its existence today make the motivation for RID support on the
>>>>>>receiving end pretty low. It does not give you anything extra in 
>>>>>>terms
>>>>>>of functionality. There are no substantial benefits from doing it 
>>>>>>(and
>>>>>>no it doesn't allow for significantly simpler SFUs ... those would
>>>>>>still have to keep 95% of their existing logic). We can decide to 
>>>>>>make
>>>>>>PERC dependent on it and hope that this would sway all browser 
>>>>>>vendors
>>>>>>... or we could also try to lower the burden on PERC adoption.
>>>>>>
>>>>>>Again, as stated in the beginning of this mail: it sounds like a
>>>>>>compromise may lie in the option for PERC to allow an SSRC 
>>>>>>rewriting
>>>>>>mode combined with the option for endpoints to not support it. In
>>>>>>other words we can have part of the PERC signalling indicate 
>>>>>>whether
>>>>>>the client and the server support these modes and whether they use
>>>>>>them. This is not beautiful (by any means) but it wouldn't prevent
>>>>>>either of us to do things their way.
>>>>>>
>>>>>>Emil
>>>>>>-- https://jitsi.org
>>>>>
>>>>>
>>>>
>>>>--
>>>>https://jitsi.org
>>>>
>>>>_______________________________________________
>>>>Perc mailing list
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/perc
>>>
>>
>>
>>--
>>sent from my mobile
>>
>>_______________________________________________
>>Perc mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/perc
>>
>
>
>
>--
>Miguel París Díaz
>------------------------------------------------------------------------
>Computer/Software engineer.
>Researcher and architect in http://www.kurento.org
>http://twitter.com/mparisdiaz
>------------------------------------------------------------------------