Subject: [AVTCORE] RTP Header Extension Encryption

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 Sep 2020 14:14:06 -0700

At IETF 108, Justin Uberti lead a side meeting relating to RTP header
extension encryption:
https://www.ietf.org/proceedings/108/slides/slides-108-avtcore-rtp-header-extension-encryption-full-01

As presented in the slides there are a number of potential options for
moving forward. It is quite likely that we will discuss this more at IETF
109, but I thought it would be useful to get mailing list discussion going
beforehand.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 Sep 2020 14:42:08 -0700

Speaking only for myself (Chair hat off), the lesson from the RFC 6904
implementation experience described in the slides is that complexity is the
enemy of implementation correctness and also interoperability.   So a goal
should be to simplify the new proposal as much as possible. This includes
the potential to negotiate encryption of all RTP header extensions "on" or
"off" rather than allowing individual RTP header extensions to be
negotiated as encrypted or not.

There was also some discussion of whether encryption could be negotiated
per m-line or just a blanket on/off for all m-lines.  IMHO, negotiating
encryption per m-line is more complex, particularly if we also choose to
extend the scope of encryption, so as to cover the ID field (e.g. encrypt
the entire RTP header extension block).  Extending the scope of encryption
means that the entire MID header extension (including the ID field) could
be encrypted.

Having encryption on for some m-lines and off for other m-lines seems like
it would open up a number of corner cases.  If some MIDs have RTP header
extensions encrypted and others do not, how does an RTP receiver know
whether a particular RTP packet it receives has RTP header extensions
encrypted or not?

To determine this, the receiver needs to determine the MID value, but for
some packets the MID header extension is encrypted, and for other RTP
packets it isn't. The implementer might have to do some error-prone and
potentially non-interoperable gymnastics, like using heuristics to guess
whether the RTP header extension block is unencrypted or encrypted, or
attempting to decrypt the RTP header extension block on all received RTP
packets, then checking for a MID header extension to confirm that yes, the
RTP header extension block should have been encrypted.

This complexity can be avoided if RTP header extension encryption is either
on or off for all MIDs. It is hard to come up with a use case in which
you'd only want some m-lines to have RTP header extension encryption on and
you'd want other m-lines to have RTP header extensions sent in the clear.
So the added complexity doesn't seem to have a corresponding benefit.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 10 Sep 2020 23:44:27 +0200

Fully agree.

On 10/09/2020 23:42, Bernard Aboba wrote:
> implementation experience described in the slides is that complexity 
> is the enemy of implementation correctness and also interoperability.  
>  So a goal should be to simplify the new proposal as much as possible. 
> This includes the potential to negotiate encryption of all RTP header 
> extensions "on" or "off" rather than allowing individual RTP header 
> extensions to be negotiated as encrypted or not.
>
> There was also some discussion of whether encryption could be 
> negotiated per m-line or just a blanket on/off for all m-lines.  IMHO, 
> negotiating encryption per m-line is more complex, particularly if we 
> also choose to extend the scope of encryption, so as to cover the ID 
> field (e.g. encrypt the entire RTP header extension block).  Extending 
> the scope of encryption means that the entire MID header extension 
> (including the ID field) could be encrypted.
>
> Having encryption on for some m-lines and off for other m-lines seems 
> like it would open up a number of corner cases.  If some MIDs have RTP 
> header extensions encrypted and others do not, how does an RTP 
> receiver know whether a particular RTP packet it receives has RTP 
> header extensions encrypted or not?
>
> To determine this, the receiver needs to determine the MID value, but 
> for some packets the MID header extension is encrypted, and for other 
> RTP packets it isn't. The implementer might have to do some 
> error-prone and potentially non-interoperable gymnastics, like using 
> heuristics to guess whether the RTP header extension block is 
> unencrypted or encrypted, or attempting to decrypt the RTP header 
> extension block on all received RTP packets, then checking for a MID 
> header extension to confirm that yes, the RTP header extension block 
> should have been encrypted.
>
> This complexity can be avoided if RTP header extension encryption is 
> either on or off for all MIDs. It is hard to come up with a use case 
> in which you'd only want some m-lines to have RTP header extension 
> encryption on and you'd want other m-lines to have RTP header 
> extensions sent in the clear. So the added complexity doesn't seem to 
> have a corresponding benefit.
>
> On Thu, Sep 10, 2020 at 2:14 PM Bernard Aboba <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     At IETF 108, Justin Uberti lead a side meeting relating to RTP
>     header extension encryption:
>     As presented in the slides there are a number of potential options
>     for moving forward. It is quite likely that we will discuss this
>     more at IETF 109, but I thought it would be useful to get mailing
>     list discussion going beforehand.
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 10 Sep 2020 14:56:27 -0700

Sergio --

Of the encryption coverage options presented in the slides, do you have a
preference?

On Thu, Sep 10, 2020 at 2:44 PM Sergio Garcia Murillo <
[email-masked]> wrote:

> either on or off for all MIDs. It is hard to come up with a use case in
> which you'd only want some m-lines to have RTP header extension encryption
> on and you'd want other m-lines to have RTP header extensions sent in the
> clear. So the added complexity doesn't seem to have a corresponding
> benefit.
>
> Audio/Video Transport Core [email-masked]://www.ietf.org/mailman/listinfo/avt
>
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 11 Sep 2020 00:00:40 +0200

C1 Encrypt Extensions + CSRCs would be my choice, it encrypts the most 
metadata while still being easy to implement.

On 10/09/2020 23:56, Bernard Aboba wrote:
> Sergio --
>
> Of the encryption coverage options presented in the slides, do you 
> have a preference?
>
> On Thu, Sep 10, 2020 at 2:44 PM Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Fully agree.
>
>>     Speaking only for myself (Chair hat off), the lesson from the RFC
>>     6904 implementation experience described in the slides is that
>>     complexity is the enemy of implementation correctness and also
>>     interoperability.   So a goal should be to simplify the new
>>     proposal as much as possible. This includes the potential to
>>     negotiate encryption of all RTP header extensions "on" or "off"
>>     rather than allowing individual RTP header extensions to be
>>     negotiated per m-line or just a blanket on/off for all m-lines. 
>>     IMHO, negotiating encryption per m-line is more complex,
>>     particularly if we also choose to extend the scope of encryption,
>>     so as to cover the ID field (e.g. encrypt the entire RTP header
>>     extension block). Extending the scope of encryption means that
>>     the entire MID header extension (including the ID field) could be
>>     encrypted.
>>
>>     Having encryption on for some m-lines and off for other m-lines
>>     seems like it would open up a number of corner cases.  If some
>>     MIDs have RTP header extensions encrypted and others do not, how
>>     does an RTP receiver know whether a particular RTP packet it
>>     receives has RTP header extensions encrypted or not?
>>
>>     To determine this, the receiver needs to determine the MID value,
>>     but for some packets the MID header extension is encrypted, and
>>     for other RTP packets it isn't. The implementer might have to do
>>     some error-prone and potentially non-interoperable gymnastics,
>>     like using heuristics to guess whether the RTP header extension
>>     block is unencrypted or encrypted, or attempting to decrypt the
>>     RTP header extension block on all received RTP packets, then
>>     checking for a MID header extension to confirm that yes, the RTP
>>     header extension block should have been encrypted.
>>
>>     This complexity can be avoided if RTP header extension encryption
>>     is either on or off for all MIDs. It is hard to come up with a
>>     use case in which you'd only want some m-lines to have RTP header
>>     extension encryption on and you'd want other m-lines to have RTP
>>     header extensions sent in the clear. So the added complexity
>>     doesn't seem to have a corresponding benefit.
>>
>>     On Thu, Sep 10, 2020 at 2:14 PM Bernard Aboba
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         At IETF 108, Justin Uberti lead a side meeting relating to
>>         RTP header extension encryption:
>>         As presented in the slides there are a number of potential
>>         options for moving forward. It is quite likely that we will
>>         discuss this more at IETF 109, but I thought it would be
>>         useful to get mailing list discussion going beforehand.
>>
>>
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Sep 2020 14:31:40 -0400

Bernard,

On 9/10/20 5:42 PM, Bernard Aboba wrote:

> extend the scope of encryption, so as to cover the ID field (e.g. 
> encrypt the entire RTP header extension block).  Extending the scope of 
> encryption means that the entire MID header extension (including the ID 
> field) could be encrypted.
> 
> header extensions encrypted and others do not, how does an RTP receiver 
> know whether a particular RTP packet it receives has RTP header 
> extensions encrypted or not?
> 
> RTP packets it isn't. The implementer might have to do some error-prone 
> and potentially non-interoperable gymnastics, like using heuristics to 
> guess whether the RTP header extension block is unencrypted or 
> encrypted, or attempting to decrypt the RTP header extension block on 
> all received RTP packets, then checking for a MID header extension to 
> confirm that yes, the RTP header extension block should have been 
> encrypted.
> 
> which you'd only want some m-lines to have RTP header extension 
> encryption on and you'd want other m-lines to have RTP header extensions 
> sent in the clear. So the added complexity doesn't seem to have a 
> corresponding benefit.

Can you please clarify the scope for which you want the encryption to be 
consistent? Above you variously mention all MIDs and all m-lines. I'm 
concerned with what "all" applies to.

I think I can agree if you are talking about "all within a bundle 
group". Anything broader has major problems.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Sep 2020 12:00:13 -0700

Paul said:

"Can you please clarify the scope for which you want the encryption to be
consistent? Above you variously mention all MIDs and all m-lines. I'm
concerned with what "all" applies to.

I think I can agree if you are talking about "all within a bundle
group". Anything broader has major problems."

[BA] Thanks for pointing this out.

Mixing unencrypted and encrypted RTP header extensions within a bundle
group is problematic because all of the RTP packets arrive on the same
port, and the receiver needs to know the MID (which could be encrypted) in
order to figure out which packets should have encrypted and unencrypted RTP
header extensions.  But if you have different bundle groups, then it is
possible for each group to have different settings (e.g. encrypted RTP
header extensions on one group and unencrypted RTP header extensions on
another bundle group) without that problem arising.  So this is an argument
only for consistency within each bundle group, not for requiring all bundle
groups to have the same setting.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Sep 2020 15:48:04 -0400

On 9/11/20 3:00 PM, Bernard Aboba wrote:
> port, and the receiver needs to know the MID (which could be encrypted) 
> in order to figure out which packets should have encrypted and 
> unencrypted RTP header extensions.  But if you have different bundle 
> groups, then it is possible for each group to have different settings 
> (e.g. encrypted RTP header extensions on one group and unencrypted RTP 
> header extensions on another bundle group) without that problem 
> arising.  So this is an argument only for consistency within each bundle 
> group, not for requiring all bundle groups to have the same setting.

I'm feeling we need a new term here. It has to cover a bundle group as 
well as a single media-description that isn't bundled. Is there a term 
for this within the RTP vocabulary?

	Thanks,
	Paul

> On Fri, Sep 11, 2020 at 11:31 AM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Bernard,
> 
>     negotiated
>     seems
>     receiver
>     but
>     error-prone
>     extensions

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Sep 2020 07:41:49 +0000

> for this within the RTP vocabulary?

The term in the RTP vocabulary that makes sense are to have header encryption
configuration be applied on the RTP session. 

A boundle group will be one RTP session as they share BUNDLE Transport
parameters.

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 15 Sep 2020 17:05:28 +0200

I think this scope is called "TRANSPORT" when talking about the bundle 
category of SDP extensions in general.

On 9/11/20 9:00 PM, Bernard Aboba wrote:
> port, and the receiver needs to know the MID (which could be 
> encrypted) in order to figure out which packets should have encrypted 
> and unencrypted RTP header extensions.  But if you have different 
> bundle groups, then it is possible for each group to have different 
> settings (e.g. encrypted RTP header extensions on one group and 
> unencrypted RTP header extensions on another bundle group) without 
> that problem arising.  So this is an argument only for consistency 
> within each bundle group, not for requiring all bundle groups to have 
> the same setting.
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 16 Sep 2020 12:33:34 +0200

> A boundle group will be one RTP session as they share BUNDLE Transport

I think this is wrong. An RTP session can cover multiple transports (and 
will, if you don't use BUNDLE).

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Sep 2020 14:28:13 +0000

> will, if you don't use BUNDLE).

In what context? Yes, the generalized definition of an RTP session is the set of
RTP + RTCP packets sent and received over a set of transport receivers and
transport destination as specified by some type of addressing. 

However, in a SDP using Offer/Answer if you have two or more media descriptions
that has different UDP ports and not use bundle then you will get multiple RTP
sessions. 

Section 9.1 in BUNDLE (
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/) is
explicit about that one BUNDLE group is one RTP session. If you fail to
establish this bundle group you will have multiple RTP sessions with indepdent
SSRC spaces. 

If you put things on the SDP session level then you could jointly configure all
of the created RTP sessions, but they will be multiple RTP sessions. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Mobile +46 73 0949079
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Sep 2020 08:26:40 +0000

Hi,

A Clarification to the RTP session definition.

> transport destination as specified by some type of addressing.
That share SSRC space. It is the SSRC space that is the core of the RTP session.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 17 Sep 2020 14:42:30 +0200

> That share SSRC space. It is the SSRC space that is the core of the RTP session.

Yep.

When using WebRTC, we are using BUNDLE, and the BUNDLE spec says that 
media sections can move into and out of bundles.

When they move, there's nothing anywhere that says they change SSRCs.

So my interpretation is that everything inside a WebRTC media 
description (unless it refuses bundling altogether) has to be part of 
the same RTP session.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Sep 2020 11:42:19 -0400

On 9/17/20 8:42 AM, Harald Alvestrand wrote:
>>> In what context? Yes, the generalized definition of an RTP session is 
>>> the set
>>> of

IIUC when they move in and out of bundles they are implicitly moving 
among different SSRC spaces, though they may still retain the same SSRC. 
(As long as there is no conflict with the space they are moving into.)

Maybe WebRTC needs to say more about this.

> description (unless it refuses bundling altogether) has to be part of 

What does a webrtc media description correspond to in sdp terminology? 
Is it a session description?

Because it is really problematic to make this restriction across a 
complete session description. (These can be composed from media 
descriptions that terminate on different servers.)

One question is how to represent this in sdp so that it is consistent 
across the intended scope. If the scope is a bundle group (or unbundled 
media description) then it might make sense to represent this as a 
separate attribute that has a mux category of IDENTICAL.

	Thanks,
	Paul