Subject: [Perc] Proposal for RTX and double

From: Cullen Jennings <[email-masked]>
Date: Mon, 10 Apr 2017 07:35:15 -0600

I've looked at a bunch of options for how we could approach this. Originally I planned to write them all up but the one that Nils (and others) was talking about seems like a clear best one to me so let me describe that then perhaps list some of the others ...

The goal of this is to keep the basic flow of information in your average endpoint as close to possible as it is today  and not need to substantial change any existing specification when using double vs when using other STLS-SRTP transforms. The goals is also not to just  solve the problems of RTX and FEC used today, but also be compatible with more complex FEC schemes that might be done in the future which have far more state that can become corrupted by un authenticated packets. 

The basic approach is pretty simple. We add to the OBH block a flag that indicates if that double algorithm does normal crypto where the half the key is used for the inner encrypt, then 2nd half key used for outer, or, if the flag is set, it only does the outer part. This allows a packet that is meant for the Media Distributor, and does not contain a payload that has non encrypted user media, to effectively be marked for single, not double encryption. RTX, FEC, and RTCP packets would be marked this way. It keeps all the flow of processing the same as existing systems that are not using double. The reason the flag needs to be in the OBH is the system receiving the packets needs to know this information to be able to decrypt. 

I don't think that using RTX for creating wasted bandwidth via padding is a great idea but none the less, this would support that use of RTX. It also allows the Media Distributor, to look at the RTX payload to find the OSN (original Sequence Number) so that the Media Distributor, can do repair. A RTX sender would cache the packets it is sending (which are normal double encrypted) and when it got a request for a retransmission, it would take the cached packet to form the RTX packet to send. This is exactly how RTX works if the endpoint is not doing double so it is nice that it is the same. 

Below I will list a few options that I considered but view as significantly worse than the above proposal. 

1.  Send RTX/FEC non authenticated, do the repair, and if the repair packet validated, then consider it OK 

2. Send RTX/FEC on separate steam that did not not negotiate double 

3. When using RTX and double, create a new RTP header extension that provides the Media Distributor with the OSN in the header extension. The RTX packet would still have the OSN in it. 

4. Leave RTX out of the first version of PERC and solve it as an extension to PERC later 

5. Some sequence o extracting an inserting packets half way through the double transform. Among other problems with requires the endpoints to significantly change their flow when using double and problem involves updating many specs to have special text around double handling. 

6. Simply use RTX in end to end way and not have the  Media Distributor participate in RTX.

7. Do a new version of RTX that puts the OSN as a header extension instead of as a payload extension.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 10 Apr 2017 16:04:15 +0200

Hi Cullen,

One thing I don't agree with is that currently RTX sender does not store 
sent packets after applying the DTLS/SRTP transform, they store it in 
clear. When a retransmission is requested, it retrieves the raw packet, 
creates the RTX packet by appending the OSN and appending the raw media 
and applies the DTLS/SRTP crypto to it.

In order to keep the same scheme in double, the RTX sender must keep the 
rtp packets after the inner crypto is applied but before the outer 
crypto is done. That way, when a retransmission is requested, it will 
create a rtp packet with the OSN and append the media of the "inner 
crypted" packet, and perform the outher crypto.

Also, not sure why we need to add a flag to the OHB header when RTX and 
FEC packets are already defined by payload type, except if we want to 
allow RTX/FEC both HBH and E2E. For RTCP it is not possible at all.

Best regards
Sergio

On 10/04/2017 15:35, Cullen Jennings wrote:
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 10 Apr 2017 08:25:23 -0600

Obviously if implementations cache and encrypted version or non encrypted and then recreate is an implementation detail. Can you walk me through how you think RTX works in a direct call from A to B wth normal SRTP with no double and no PERC and no conference bridge? If we can get to the point where it is clear we both understand that, then it might be easier to have this discussion. 

As a side note, I think it would be good to have an implementors email list where we can help folks implementing this understand the existing RFC specifications without doing it on the same list where we try and develop new ones. 

> On Apr 10, 2017, at 8:04 AM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> Hi Cullen,
> 
> One thing I don't agree with is that currently RTX sender does not store sent packets after applying the DTLS/SRTP transform, they store it in clear. When a retransmission is requested, it retrieves the raw packet, creates the RTX packet by appending the OSN and appending the raw media and applies the DTLS/SRTP crypto to it.
> 
> In order to keep the same scheme in double, the RTX sender must keep the rtp packets after the inner crypto is applied but before the outer crypto is done. That way, when a retransmission is requested, it will create a rtp packet with the OSN and append the media of the "inner crypted" packet, and perform the outher crypto.
> 
> Also, not sure why we need to add a flag to the OHB header when RTX and FEC packets are already defined by payload type, except if we want to allow RTX/FEC both HBH and E2E. For RTCP it is not possible at all.
> 
> Best regards
> Sergio
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 10 Apr 2017 16:47:26 +0200

Hi Cullen,

I was in disagreement with your implementation details, so if we leave 
them out (or just keep it as informative discussion or on a different 
list), I am fine.

If I understood the core of your proposal correctly, I think we are in 
agreement that FEC/RTX (how about RED?) and RTCP are HBH and only outer 
encrypted. I still have doubts about the usage of the OHB and the need 
of this flags as all the sender/receiver and MD already are able to 
differentiate FEC/RTC/RED/RTCP from media payloads and I don't see other 
scenarios in which we would want to use that flag in a more generic way.

Best regards
Sergio

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Apr 2017 17:25:46 -0500

On 4/10/17 09:47, Sergio Garcia Murillo wrote:
> agreement that FEC/RTX (how about RED?) and RTCP are HBH and only 
> outer encrypted. I still have doubts about the usage of the OHB and 
> the need of this flags as all the sender/receiver and MD already are 
> able to differentiate FEC/RTC/RED/RTCP from media payloads and I don't 
> see other scenarios in which we would want to use that flag in a more 
> generic way. 

(a) Using the SDP-negotiated PT value to determine what kind of SRTP 
encryption and decryption to apply is really strange, from a layering 
perspective. It requires the code that receives packets to have a 
mapping of PT values to codecs, and I would not expect any libraries 
that do that kind of thing to already have a notion of PT-to-codec 
mapping already. Thinking through what it would take to add this, the 
additional plumbing to get the socket handling code or the SRTP code to 
understand PTs is pretty convoluted.

(b) The use of a client-supplied bit in the OHB reduces questions like 
"should we double encrypt DTMF" to a policy question rather than a 
protocol question -- and this includes not just DTMF, but any kind of 
FEC/RTX/RED-type stuff that may be developed in the future.

/a

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Tue, 11 Apr 2017 10:03:22 +0200

On 11/04/2017 0:25, Adam Roach wrote:
>> If I understood the core of your proposal correctly, I think we are 
>> in agreement that FEC/RTX (how about RED?) and RTCP are HBH and only 
>> able to differentiate FEC/RTC/RED/RTCP from media payloads and I 
>> don't see other scenarios in which we would want to use that flag in 
>> a more generic way. 
>
>
> additional plumbing to get the socket handling code or the SRTP code 
> to understand PTs is pretty convoluted.
>

You are assuming that we enable both E2E and HBH for RTX, with IMHO is a 
bad idea (more on that later). If only HBH RTX is supported you don't 
even need to change a single line of code, as the inner crypto will be 
done after the RTX processing takes place, for both media and rtx packets.

> FEC/RTX/RED-type stuff that may be developed in the future. 

Let's imagine that we support both HBH and E2E RTX modes, there are new 
several question raised. First, are those H2B or E2E RTX modes 
negotiated? Does NACK packet carries a new flag to indicate if it wants 
it to be HBH or E2E? An SFU requires it to be HBH, so leaving it to a 
sender only decision, it may make RTX unusable at all for conferencing.  
Also, if we leave it to a sender only decision, it will only send HBH 
RTX as it is the only sensible decision nowadays.

Then, I assume that if "encrypted flag" is used on an RTX packet it just 
means that the inner crypto is used or not, but the RTX payload is still 
the same. That means that a double encrypted RTX packet will carry inner 
crypto payload from the original packet (if not we will be requiring 
developers to implement too different double encryption mechanisms and 
not just a "flag").

In that case, we need to carry the original OHB for the inner crypto 
original packet, and a second OHB for the RTX inner crytpo packet. The 
receiver will be then able two support two different header extensions 
for same id and I assume remove the latest OHB but keep the first OHB 
when reconstructing the original packet.

Really, not sure if pushing this kind of complexity to developers is a 
good idea, especially as I have yet to see an use case in which E2E RTX 
makes sense.

Best regard
Sergio

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 11 Apr 2017 14:00:29 -0400

Per the minutes, there's supposed to be a focused call on how to handle
repair streams.  Is that scheduled yet?

Stephen

On Tue, Apr 11, 2017 at 4:03 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

>>> encrypted. I still have doubts about the usage of the OHB and the need of
>>> this flags as all the sender/receiver and MD already are able to
>> perspective. It requires the code that receives packets to have a mapping
>> of PT values to codecs, and I would not expect any libraries that do that
>> kind of thing to already have a notion of PT-to-codec mapping already.
>> Thinking through what it would take to add this, the additional plumbing to
>> get the socket handling code or the SRTP code to understand PTs is pretty
>> convoluted.
>>
>>
> bad idea (more on that later). If only HBH RTX is supported you don't even
> need to change a single line of code, as the inner crypto will be done
> after the RTX processing takes place, for both media and rtx packets.
>
>> "should we double encrypt DTMF" to a policy question rather than a protocol
>> question -- and this includes not just DTMF, but any kind of
> several question raised. First, are those H2B or E2E RTX modes negotiated?
> Does NACK packet carries a new flag to indicate if it wants it to be HBH or
> E2E? An SFU requires it to be HBH, so leaving it to a sender only decision,
> it may make RTX unusable at all for conferencing.  Also, if we leave it to
> a sender only decision, it will only send HBH RTX as it is the only
> sensible decision nowadays.
>
> developers to implement too different double encryption mechanisms and not
> just a "flag").
>
> receiver will be then able two support two different header extensions for
> same id and I assume remove the latest OHB but keep the first OHB when
> reconstructing the original packet.
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 11 Apr 2017 14:01:13 -0400

No.  Suhas and I are gathering dates to propose.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 11 Apr 2017 14:03:00 -0500

Before I respond I just wanted to check something:

Was this sent on April 1st and it then got stuck in an outbox
somewhere where it remained for 10 days?

-- 
https://jitsi.org

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 11 Apr 2017 14:57:58 -0600

I look forward to construct discussion on what parts of this don't work and expect them to be well informed by existing RFC and conversation in the WG. 

> On Apr 11, 2017, at 1:03 PM, Emil Ivov <[email-masked]> wrote:
>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 11 Apr 2017 17:09:21 -0500

To begin with, I assume none of that was said with an AD hat on?

> understand PTs is pretty convoluted.

There seems to be this conflict of perceptions here, where some people 
try to look at double as a single atomic transform.

Without considering the validity of such a perception I would like to 
point out that there is nothing in our charter that binds us to such a 
model.

If you look at this from the perspective of double being two independent 
transforms, then none of the crypto processing is impacted by payload. 
You simply have payload dictating whether something (e.g. the RTX 
module) would process packets in between the two transforms, but the 
transforms themselves are always the same.

Emil

> protocol question-- and this includes not just DTMF, but any kind of

> .

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Tue, 11 Apr 2017 17:11:22 -0500

Oh ok ... so this was a serious proposal. Inline then:

On 4/10/17 8:35 AM, Cullen Jennings wrote:
>
> I've looked at a bunch of options for how we could approach this.
> Originally I planned to write them all up but the one that Nils (and
> others) was talking about seems like a clear best one to me so let me
> describe that then perhaps list some of the others ...
>
> The goal of this is to keep the basic flow of information in your
> average endpoint as close to possible as it is today  and not need to
> substantial change any existing specification when using double vs
> when using other STLS-SRTP transforms.

This is NOT one of the objectives in our charter:

https://datatracker.ietf.org/doc/charter-ietf-perc/

One reason it isn't is because the *internals* of implementation 
optimizations are a concern to *implementers* ... not to the IETF.

Another reason it isn't is because the internals of your implementation 
are very different from mine.

> The goals is also not to just
> solve the problems of RTX and FEC used today, but also be compatible
> with more complex FEC schemes that might be done in the future which
> have far more state that can become corrupted by un authenticated
> packets.
>
> The basic approach is pretty simple. We add to the OBH block a flag
> that indicates if that double algorithm does normal crypto where the
> half the key is used for the inner encrypt, then 2nd half key used
> for outer, or, if the flag is set, it only does the outer part.

I still can't believe you suggested this with a straight face. You 
seriously want this working group to add an on-the-wire flag in a 
standards track IETF RFC, that on-the-wire entities will NOT need ... 
only so that you can pass a param to your implementation ...

I am speechless! :)

> This
> allows a packet that is meant for the Media Distributor, and does not
> contain a payload that has non encrypted user media, to effectively
> be marked for single, not double encryption. RTX, FEC, and RTCP
> packets would be marked this way. It keeps all the flow of processing
> the same as existing systems that are not using double. The reason
> the flag needs to be in the OBH is the system receiving the packets
> needs to know this information to be able to decrypt.
>
> I don't think that using RTX for creating wasted bandwidth via
> padding is a great idea but none the less, this would support that
> use of RTX. It also allows the Media Distributor, to look at the RTX
> payload to find the OSN (original Sequence Number) so that the Media
> Distributor, can do repair. A RTX sender would cache the packets it
> is sending (which are normal double encrypted) and when it got a
> request for a retransmission, it would take the cached packet to form
> the RTX packet to send. This is exactly how RTX works if the endpoint
> is not doing double so it is nice that it is the same.

No. This is not at all how it works if the endpoint is doing double. 
Every 4588 implementation that I am aware of caches packets before the 
hop by hop encryption.

The one PERC implementation that I know of also does this.

> Below I will list a few options that I considered but view as
> significantly worse than the above proposal.
>
> 3. When using RTX and double, create a new RTP header extension that
> provides the Media Distributor with the OSN in the header extension.
> The RTX packet would still have the OSN in it.
>
> 5. Some sequence o extracting an inserting packets half way through
> the double transform. Among other problems with requires the
> endpoints to significantly change their flow when using double and
> problem involves updating many specs to have special text around
> double handling.

This is quite a misrepresentation.

As it happens, this is the most reasonable approach to the problem.

"the endpoints" in this world do not have some common issue with it. 
Yours might, and I sympathize if that is the problem but I don't want 
you muddying my on-the-wire traffic because of that anyway.

Emil

> _______________________________________________ Perc mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/perc
>

-- 
https://jitsi.org

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 12 Apr 2017 00:19:52 +0200

> The one PERC implementation that I know of also does this. 

I am also not aware of a single SFU that uses E2E RTX/FEC, nor a single 
use case in which it make sense. So I would be deeply against defining a 
complex mechanism for something that is not used/usable at all.

Best regards
Sergio

---

From: Boris Grozev <[email-masked]>
Date: Tue, 11 Apr 2017 17:33:17 -0500

Hello Cullen,

On 10/04/2017 08:35, Cullen Jennings wrote:
> when using other STLS-SRTP transforms. The goals is also not to just
> for outer, or, if the flag is set, it only does the outer part. This
> the same as existing systems that are not using double.

The RTX format shares the RTP header extensions with the retransmitted 
packet. If we modify a flag in the OHB block of a packet after it has 
passed through SRTP, we need a way to restore the original value before 
decrypting the packet.

> The reason

Can you please elaborate this point? I don't understand why a receiving 
system needs this information.

> the RTX packet to send.

I am confused. After taking a double encrypted packet from the cache and 
applying RTX, would the RTX sender perform the outer SRTP transform again?

If not, then this is option "1" from below.

If yes, then the packet is effectively encrypted three times. A receiver 
would have to decrypt once, de-RTX, decrypt a second time (and if it is 
an endpoint then the second decryption will include the E2E decryption). 
If an RTX sender creates an RTX packet with payload which does not come 
from its cache (e.g. an MD forwarding a packet received in RTX), it 
would have to perform the HBH encryption twice. This is clearly over 
complicated, and requires changes to both endpoints and MDs.

> This is exactly how RTX works if the endpoint

This is not how current webrtc implementations work. Packets are cached 
before the SRTP transformation, and RTX is applied before SRTP.

> instead of as a payload extension.

What is missing from this list is the option proposed earlier of 
performing RTX (or FEC or anything defined in the future which needs to 
be handed HBH) after the E2E encryption, but before the HBH encryption. 
This requires no changes to MDs, and similar to your proposal requires a 
mechanism for senders to only perform the outer encryption.

Implementors can choose to use an RTP header extension to signal to 
their library that E2E encryption is to not be performed for a specific 
packet, but I don't see a need for this to go over the wire.

Regards,
Boris

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 11 Apr 2017 19:29:40 -0600

Reading this whole email, I think there is probably come confusion about a bunch of things which would likely best be cleared up with some slides and WG conference calls rather than email. But let me try and answer one of your questions inline 

> On Apr 11, 2017, at 4:33 PM, Boris Grozev <[email-masked]> wrote:
> 
> Hello Cullen,
> 
... snip ... 
> Can you please elaborate this point? I don't understand why a receiving system needs this information.

Take the DTMF example where it is a policy decision on sender if the MD was going to be able to decrypt the DTMF of not. The sender encrypts it one way or the other then send it to the MD and then the MD sends it to the receiver. The receiver needs some way to know how the sender encrypted it so that the receiver can correctly decode it. The receiver would do the outer decrypt, then look at the flag to decide if the inner decrypt should also be done. 

Does that make sense ?

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 12 Apr 2017 10:10:27 +0200

> Take the DTMF example where it is a policy decision on sender if the MD was going to be able to decrypt the DTMF of not. The sender encrypts it one way or the other then send it to the MD and then…
I should have never brought up the DTMF topic.. :)

I think that the discussion is around the recover streams (RTX, ulpfec, 
RED and Flex Fec), which IMHO doesn't make sense at all to be E2E 
encrypted. If we keep them HBH nothing needs to be changed to the 
current specs/implementetions. So I would expect a very well supported 
argument in favor of E2E recover streams that justifies the need for any 
new mechanisms.

Regarding the flag for media streams, I don't have a strong opinion yet, 
but I think it is better to keep both discussions separated.

Best regards
Sergio

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 12 Apr 2017 09:28:47 +0000

On Wed, Apr 12, 2017 at 1:10 AM Sergio Garcia Murillo <
[email-masked]> wrote:

> > Take the DTMF example where it is a policy decision on sender if the MD
> was going to be able to decrypt the DTMF of not. The sender encrypts it one
> way or the other then send it to the MD and then the MD sends it to the
> receiver. The receiver needs some way to know how the sender encrypted it
> so that the receiver can correctly decode it. The receiver would do the
> outer decrypt, then look at the flag to decide if the inner decrypt should
> also be done.

If I am not reading wrong, it looks like the original mail from Cullen
meant these to be Scoped just to the media distributor and not e2e ..

> but I think it is better to keep both discussions separated.

Regards
Suhas
(As individual )

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 12 Apr 2017 11:32:46 +0200

On 12/04/2017 11:28, Suhas Nandakumar wrote:
>
> On Wed, Apr 12, 2017 at 1:10 AM Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > Take the DTMF example where it is a policy decision on sender if
>     the MD was going to be able to decrypt the DTMF of not. The sender
>     encrypts it one way or the other then send it to the MD and then
>     the MD sends it to the receiver. The receiver needs some way to
>     know how the sender encrypted it so that the receiver can
>     correctly decode it. The receiver would do the outer decrypt, then
>     look at the flag to decide if the inner decrypt should also be done.

No, the proposal allowed both modes, which means implementing it twice.

Best regards
Sergio

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 13 Apr 2017 13:54:28 -0600

> On Apr 12, 2017, at 2:10 AM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> I think that the discussion is around the recover streams (RTX, ulpfec, RED and Flex Fec), which IMHO doesn't make sense at all to be E2E encrypted. If we keep them HBH nothing needs to be changed to the current specs/implementetions. So I would expect a very well supported argument in favor of E2E recover streams that justifies the need for any new mechanisms.

I'm certainly not arguing for things like RTX to be done end to end. I think any repair algorithm is better HBH.

100% agree that with no changes to any of the existing drafts you can clearly do HBH repair using RTX in the mode where the RTX is on a separate RTP stream that does not use double. That works fine - I don't understand what concern Emil had with doing that but the main reason I proposed this was to try and find something that addressed Emil's problem. However, it seem that I have no clue what that problem is so I may stop trying until the actual problem is clearer. 

> 
> Regarding the flag for media streams, I don't have a strong opinion yet, but I think it is better to keep both discussions separated.

---

From: Emil Ivov <[email-masked]>
Date: Thu, 13 Apr 2017 15:11:44 -0500

On Thu, Apr 13, 2017 at 2:54 PM, Cullen Jennings <[email-masked]> wrote:
> 100% agree that with no changes to any of the existing drafts you can clearly do HBH repair using RTX in the mode where the RTX is on a separate RTP stream that does not use double.

Are you now suggesting that RTX should be *only* HBH protected? Or do
you mean triple protection?

> That works fine - I don't understand what concern Emil had with doing that but the main reason I proposed this was to try and find something that addressed Emil's problem. However, it seem that I have no clue what that problem is so I may stop trying until the actual problem is clearer.

I really have no problem. There is only one reasonable way to do RTX
with double, which consists in doing RTX and in between the two layers
of protection and I am perfectly fine with that.

You seem to have an issue with this, that I believe goes beyond
implementation specifics, and I think you can certainly solve it
somehow if you tried.

Emil

-- 
https://jitsi.org

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 14 Apr 2017 09:25:58 +0200

> implementation specifics, and I think you can certainly solve it

Seems that there has been a misunderstanding then.

Are we in agreement then that RTX/FEC (or any other reconstruction 
streams) will be done *ONLY HBH*?

Best regards
Sergio

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 14 Apr 2017 10:37:33 -0400

streams) will be done *ONLY HBH*?
In the case of FEC it is best if the stream is repaired HBH.  It is also
desirable to tailor the transmitted FEC to fit the loss characteristics of
the hop.

But I don't think that precludes pass-through of received FEC source
packets by the MD (decrypting the inbound HBH, and re-encrypting the
outbound HBH).  If there's a technical reason why that has to be precluded,
it'd be useful to understand it better.

For me it is important that the FEC and RTX packets be authenticated HBH
before being used for repair.  While in some specific cases, it might be
enough to authenticate the output of the reconstruction, it doesn't work
for all cases.  I believe that's also the motivation behind Emil's "one
reasonable way".  I'd like to know if there is agreement on the
authentication aspect.

Stephen

On Fri, Apr 14, 2017 at 3:25 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

>> That works fine - I don't understand what concern Emil had with doing
>>> that but the main reason I proposed this was to try and find something that
>>> addressed Emil's problem. However, it seem that I have no clue what that
>>> problem is so I may stop trying until the actual problem is clearer.
>>>