Subject: [Perc] RTCP: Do major surgery or do nothing?

From: Richard Barnes <[email-masked]>
Date: Wed, 27 Jan 2016 16:55:30 -0500

Hey all,

I'll be the first to admit that I barely know how to spell SRTCP, but I
wanted to throw out an idea that occurred to me as I was preparing for
tomorrow's interim:

tl;dr: Doing anything meaningful with SRTCP is hard.  Let's punt for now.

In preparation for the discussion of SRTCP in the virtual interim, I took a
look at the SRTCP packet format in RFC 3711 [1].  One thing that
immediately jumps out at you is that the encryption system doesn't align
with how the packet is structured (!)  RTCP packets are compound, carrying
multiple individual units inside one packet.  But SRTP encryption is *not*
compound; all of the units in one packet are protected within the same
envelope, and only the first unit's header is visible.

On the one hand, this means that if we want to enable an MDD to operate on
individual units (without just giving the keys, in which case we don't do
anything), we're going to have to do some major surgery.  Even if we just
want to expose unit boundaries, we would have to have the length field in
each unit be encrypted under a different (HBH) key from the overall (E2E)
key.  If we want to let the intermediary change anything within the packet,
we'll have to re-arrange the whole integrity calculation.

On the other hand, if the MDD can't operate on individual units, then it
can't really do anything useful.  Only the following fields are carried
outside the encrypted portion of the packet:

- V = Version = 2
- P = Padding flag
- RC = Reception report count (# of report blocks in this packet)
- PT = SR / RR
- length
- SSRC
- E = Encrypted flag
- SRTCP index
- SRTCP MKI
- authentication tag

Pretty much all of these are determined by the encrypted contents -- if you
change the RC value, for example, you're not going to be able to do
anything besides make the packet decode incorrectly.  The main thing that
doesn't have this property is the SSRC, and I thought we agreed in the RTP
discussion that SSRCs are immutable in RTP anyway.

That seems to leave us with two options:

1. Do nothing.  The MDD either has full access to SRTCP or no access at all.
2. Do major surgery

(Maybe there's a third option where the MDD can only change the SSRC.) Do
people have really important use cases that require the MDD to operate on
individual units?  Or can we make some progress without giving the MDD that
capability?

I for one would be glad to skip this and move on to discussing key
management.

--Richard

[1] https://tools.ietf.org/html/rfc3711#section-3.4

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 27 Jan 2016 22:47:24 +0000

Richard,

>In preparation for the discussion of SRTCP in the virtual interim, I 
>took a look at the SRTCP packet format in RFC 3711 [1].  One thing that 
>immediately jumps out at you is that the encryption system doesn't 
>align with how the packet is structured (!)  RTCP packets are compound, 
>carrying multiple individual units inside one packet.  But SRTP 
>encryption is *not* compound; all of the units in one packet are 
>protected within the same envelope, and only the first unit's header is 
>visible.

I guess I'm missing your point here.  Everything after a defined header 
in both RTP and RTCP are optionally encrypted as a unit.  I think your 
only point is that the different parts of the compound packet cannot be 
separately encrypted presently, and that's correct.

>On the one hand, this means that if we want to enable an MDD to operate 
>on individual units (without just giving the keys, in which case we 
>don't do anything), we're going to have to do some major surgery.  Even 
>if we just want to expose unit boundaries, we would have to have the 
>length field in each unit be encrypted under a different (HBH) key from 
>the overall (E2E) key.  If we want to let the intermediary change 
>anything within the packet, we'll have to re-arrange the whole 
>integrity calculation.

Yeah, this gets messy and is one reason why we recommended doing RTCP 
HBH only (both encryption and authentication) in our draft.  If we did 
want to have some component encrypted end-to-end, we would have to 
define a mechanism for encrypting that each part end-to-end such that it 
does not confuse HBH processing.  It is doable, but "major surgery" was 
the correct word you applied and counter to one of the objectives of 
minimizing any changes needed to RFC 3711.  We'd definitely need new 
procedures for encrypting single "parts" of the packet.  Perhaps it 
might be possible to take each part of the compound packet and encrypt 
it using the E2E key, inserting the entire encrypted "packet" into the 
RTCP packet using a new PT=QQQ (where QQQ means "end-to-end encrypted).  
(But, then the immediate next question is "what if we want to encrypt 
only part of an SDES packet?"  It's also not clear how we would cleanly 
tell any SRTP library to encrypt one part of another with the E2E key.  
That gets truly messy.)

Then along the lines of "double" we can encrypt the entire packet HBH 
using the HBH key.

>On the other hand, if the MDD can't operate on individual units, then 
>it can't really do anything useful.  Only the following fields are 
>carried outside the encrypted portion of the packet:
>
>- V = Version = 2
>- P = Padding flag
>Pretty much all of these are determined by the encrypted contents -- if 
>you change the RC value, for example, you're not going to be able to do 
>anything besides make the packet decode incorrectly.  The main thing 
>that doesn't have this property is the SSRC, and I thought we agreed in 
>the RTP discussion that SSRCs are immutable in RTP anyway.
>

My vote, but appreciating that there are privacy concerns with some 
information that COULD be placed in RTCP.  I think it might be worth 
while arguing why we should NOT put such data there.

>2. Do major surgery

I'm willing to work on it if we do want to go down this path, but we 
have to acknowledge this could drag us down a rat hole.  I'd suggest if 
we do this, we get HBH-only working first and come along with an E2E 
solution second.

>(Maybe there's a third option where the MDD can only change the SSRC.) 
>Do people have really important use cases that require the MDD to 
>operate on individual units?  Or can we make some progress without 
>giving the MDD that capability?

I think the use case was just that there might be confidential data 
placed in SDES items, for example.

Paul

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Jan 2016 15:16:21 -0800

Sometimes "Nothing" is the best choice.   As Wavy Gravy once said in the
"Nobody for President" campaign:

"Who keeps all their campaign promises?  Nobody!"

Access to RTCP RRs, SRs and feedback messages is fundamental to the
operation of an SFU, since this information is what enables the SFU to make
decisions on what packets to drop/forward.  AFAICT, all shipping SFUs make
use of this information, and going forward, it is likely that more RTCP
information (e.g. XR) will be utilized by SFUs in future, rather than less.

So I vote for option 1 (do nothing), on both practical and theoretical
grounds.

On Wed, Jan 27, 2016 at 1:55 PM, Richard Barnes <[email-masked]> wrote:

> In preparation for the discussion of SRTCP in the virtual interim, I took
> a look at the SRTCP packet format in RFC 3711 [1].  One thing that
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 28 Jan 2016 01:05:43 +0000

I agree. Someone needs to make a good case for E2E SRTCP before we start designing it.

Mo

On Jan 27, 2016, at 6:16 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:

Sometimes "Nothing" is the best choice.   As Wavy Gravy once said in the "Nobody for President" campaign:

Access to RTCP RRs, SRs and feedback messages is fundamental to the operation of an SFU, since this information is what enables the SFU to make decisions on what packets to drop/forward.  AFAICT, all shipping SFUs make use of this information, and going forward, it is likely that more RTCP information (e.g. XR) will be utilized by SFUs in future, rather than less.

So I vote for option 1 (do nothing), on both practical and theoretical grounds.

On Wed, Jan 27, 2016 at 1:55 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
Hey all,

I'll be the first to admit that I barely know how to spell SRTCP, but I wanted to throw out an idea that occurred to me as I was preparing for tomorrow's interim:

In preparation for the discussion of SRTCP in the virtual interim, I took a look at the SRTCP packet format in RFC 3711 [1].  One thing that immediately jumps out at you is that the encryption system doesn't align with how the packet is structured (!)  RTCP packets are compound, carrying multiple individual units inside one packet.  But SRTP encryption is *not* compound; all of the units in one packet are protected within the same envelope, and only the first unit's header is visible.

On the one hand, this means that if we want to enable an MDD to operate on individual units (without just giving the keys, in which case we don't do anything), we're going to have to do some major surgery.  Even if we just want to expose unit boundaries, we would have to have the length field in each unit be encrypted under a different (HBH) key from the overall (E2E) key.  If we want to let the intermediary change anything within the packet, we'll have to re-arrange the whole integrity calculation.

On the other hand, if the MDD can't operate on individual units, then it can't really do anything useful.  Only the following fields are carried outside the encrypted portion of the packet:

- V = Version = 2
- P = Padding flag

Pretty much all of these are determined by the encrypted contents -- if you change the RC value, for example, you're not going to be able to do anything besides make the packet decode incorrectly.  The main thing that doesn't have this property is the SSRC, and I thought we agreed in the RTP discussion that SSRCs are immutable in RTP anyway.

(Maybe there's a third option where the MDD can only change the SSRC.) Do people have really important use cases that require the MDD to operate on individual units?  Or can we make some progress without giving the MDD that capability?

I for one would be glad to skip this and move on to discussing key management.

--Richard

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

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

---

From: Christian Groves <[email-masked]>
Date: Thu, 28 Jan 2016 15:58:27 +1100

+1

Christian

On 28/01/2016 12:05 PM, Mo Zanaty (mzanaty) wrote:
> operation of an SFU, since this information is what enables the SFU to 
> make decisions on what packets to drop/forward.  AFAICT, all shipping 
> SFUs make use of this information, and going forward, it is likely 
> that more RTCP information (e.g. XR) will be utilized by SFUs in 
> future, rather than less.
>
>     I'll be the first to admit that I barely know how to spell SRTCP,
>     but I wanted to throw out an idea that occurred to me as I was
>     preparing for tomorrow's interim:
>
>     In preparation for the discussion of SRTCP in the virtual interim,
>     I took a look at the SRTCP packet format in RFC 3711 [1].  One
>     thing that immediately jumps out at you is that the encryption
>     system doesn't align with how the packet is structured (!)  RTCP
>     packets are compound, carrying multiple individual units inside
>     one packet.  But SRTP encryption is *not* compound; all of the
>     units in one packet are protected within the same envelope, and
>     only the first unit's header is visible.
>
>     On the one hand, this means that if we want to enable an MDD to
>     operate on individual units (without just giving the keys, in
>     which case we don't do anything), we're going to have to do some
>     major surgery.  Even if we just want to expose unit boundaries, we
>     would have to have the length field in each unit be encrypted
>     under a different (HBH) key from the overall (E2E) key. If we want
>     to let the intermediary change anything within the packet, we'll
>     have to re-arrange the whole integrity calculation.
>
>     On the other hand, if the MDD can't operate on individual units,
>     then it can't really do anything useful.  Only the following
>     fields are carried outside the encrypted portion of the packet:
>
>     - V = Version = 2
>     - P = Padding flag
>     Pretty much all of these are determined by the encrypted contents
>     -- if you change the RC value, for example, you're not going to be
>     able to do anything besides make the packet decode incorrectly. 
>     The main thing that doesn't have this property is the SSRC, and I
>     thought we agreed in the RTP discussion that SSRCs are immutable
>     in RTP anyway.
>
>     (Maybe there's a third option where the MDD can only change the
>     SSRC.) Do people have really important use cases that require the
>     MDD to operate on individual units?  Or can we make some progress
>     without giving the MDD that capability?
>
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>