Subject: [AVTCORE] Update to draft-dawkins-avtcore-sdp-rtp-quic for double encryption

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 26 Feb 2022 11:18:53 -0600

Dear AVTCORE,

I've started working on the open issues identified in the repo for this
draft, and the first issue is "Does double encryption matter for (say)
SAVPF?". <https://github.com/SpencerDawkins/sdp-rtp-quic/issues/1>

Although this draft hasn't been adopted by the working group, I thought it
best to let people know what I was planning to do for this issue.

The short answer is "double encryption has costs and no benefits, so don't
do double encryption". The long answer is in this PR
<https://github.com/SpencerDawkins/sdp-rtp-quic/pull/9.> (because there are
always details).

For anyone who doesn't speak GitHub PRs, a diff for this update from my -00
submission is here
<https://www.ietf.org/rfcdiff?url1=https://SpencerDawkins.github.io/sdp-rtp-quic/draft-dawkins-avtcore-sdp-rtp-quic.txt&url2=https://SpencerDawkins.github.io/sdp-rtp-quic/AVT-profiles/draft-dawkins-avtcore-sdp-rtp-quic.txt>
.

If you have thoughts, please feel free to reply, either here or on GitHub,
but if you think I'm headed into the weeds at a high rate of speed, please
reply here and let me know.

Best,

Spencer

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 26 Feb 2022 11:33:43 -0800

It makes sense to clarify the meaning of QUIC/RTP/AVPF (encryption at the
QUIC layer).

Not sure I'd prohibit QUIC/RTP/SAVPF (double encryption) although I'm not
clear what the use case would be.

On Sat, Feb 26, 2022 at 9:19 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> <https://github.com/SpencerDawkins/sdp-rtp-quic/pull/9.> (because there
> are always details).
>
> For anyone who doesn't speak GitHub PRs, a diff for this update from my
> -00 submission is here
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 26 Feb 2022 21:22:56 -0600

Hi, Bernard,

> It makes sense to clarify the meaning of QUIC/RTP/AVPF (encryption at the

Thanks!

> clear what the use case would be.

Yeah, me too.

This is a humble individual draft, so I know I'm not prohibiting anyone
from doing anything, but my goal in this draft is to only include things
that I have some confidence will be used, rather than adding all the
combinations and permutations I can think of.

If anyone puts forward a plausible use case for needing double encryption,
I'd add QUIC/RTP/SAVPF back in. It's just that, so far, I haven't heard
from anyone who desperately needs to do double encryption, explaining why.

If anyone is waiting to suggest that, this is a great time, and AVTCORE is
a great venue for a conversation about it.

Best,

Spencer

>> Although this draft hasn't been adopted by the working group, I thought
>> it best to let people know what I was planning to do for this issue.
>>
>> The short answer is "double encryption has costs and no benefits, so
>> don't do double encryption". The long answer is in this PR
>> If you have thoughts, please feel free to reply, either here or on
>> GitHub, but if you think I'm headed into the weeds at a high rate of speed,
>> please reply here and let me know.
>>
>> Best,
>>
>> Spencer

---

From: Roman Shpount <[email-masked]>
Date: Sat, 26 Feb 2022 23:49:47 -0500

Spencer,

One other thing I wanted to bring for p2p scenarios and QUIC. With
offer/answer, it is possible to have multiple independent communications
sessions over the same address/port pairs. It is not a problem with RTP,
where these sessions can be distinguished based on SDES. They turned out to
be the problem with DTLS, so we had to work around that in rfc8842.

Is it possible to demultiplex multiple QUIC sessions over the same
address/port pairs?

If it is, you need to figure out a mechanism to signal the way to
distinguish these sessions in SDP. Otherwise, you will need to copy the
language from rfc8842 to require one of the sides to change the transport
address or port when new QUIC sessions are established.

Best Regards,
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 26 Feb 2022 21:18:13 -0800

On Feb 26, 2022, at 20:50, Roman Shpount <[email-masked]> wrote:
> 
> 
> Spencer,
> 
> One other thing I wanted to bring for p2p scenarios and QUIC. With offer/answer, it is possible to have multiple independent communications sessions over the same address/port pairs. It is not a problem with RTP, where these sessions can be distinguished based on SDES. They turned out to be the problem with DTLS, so we had to work around that in rfc8842.
> 
> Is it possible to demultiplex multiple QUIC sessions over the same address/port pairs?

[BA] This should be possible. The means will differ depending on whether we are talking about P2P QUIC (where you could use Connection-Id) or something higher up the stack. Multiplexing as defined in rfc7983bis wasn’t implemented in the P2P (g)QUIC Origin trial since the QUIC implementation was pre-standard and lacked the capability. So only one connection was allowed. At the time the focus was on P2P data not media, but in the absence of priority support, it seemed desirable to allow distinct data and media connections that might be constructed to use different cc algorithms.

> 
> If it is, you need to figure out a mechanism to signal the way to distinguish these sessions in SDP. Otherwise, you will need to copy the language from rfc8842 to require one of the sides to change the transport address or port when new QUIC sessions are established.

---

From: Ross Finlayson <[email-masked]>
Date: Sun, 27 Feb 2022 18:19:43 +1300

> On Feb 27, 2022, at 4:22 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> If anyone puts forward a plausible use case for needing double encryption, I'd add QUIC/RTP/SAVPF back in. It's just that, so far, I haven't heard from anyone who desperately needs to do double encryption, explaining why. 

I’m not sure if this is really needed, but I can imagine it possibly being useful if - for some reason - you want to relay an existing SRTP (over UDP) session over QUIC.  I.e., if you want to relay SRTP (and SRTCP) packets, without decrypting them first.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Roman Shpount <[email-masked]>
Date: Sun, 27 Feb 2022 00:36:56 -0500

On Sun, Feb 27, 2022 at 12:18 AM Bernard Aboba <[email-masked]>
wrote:

> [BA] This should be possible. The means will differ depending on whether
> we are talking about P2P QUIC (where you could use Connection-Id) or
> something higher up the stack. Multiplexing as defined in rfc7983bis wasn’t
> implemented in the P2P (g)QUIC Origin trial since the QUIC implementation
> was pre-standard and lacked the capability. So only one connection was
> allowed. At the time the focus was on P2P data not media, but in the
> absence of priority support, it seemed desirable to allow distinct data and
> media connections that might be constructed to use different cc algorithms.
>
>
This is very interesting and can be one more reason to use QUICK instead of
DTLS. The problem would be to map a pair of tls-id to a Connection-Id.
_____________
Roman Shpount

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 27 Feb 2022 15:38:59 -0600

Hi, Ross,

On Sat, Feb 26, 2022 at 11:20 PM Ross Finlayson <[email-masked]>
wrote:

> > If anyone puts forward a plausible use case for needing double
> encryption, I'd add QUIC/RTP/SAVPF back in. It's just that, so far, I
> haven't heard from anyone who desperately needs to do double encryption,
> explaining why.
>
> I’m not sure if this is really needed, but I can imagine it possibly being
> useful if - for some reason - you want to relay an existing SRTP (over UDP)
> session over QUIC.  I.e., if you want to relay SRTP (and SRTCP) packets,
> without decrypting them first.
>

That's actually what I was thinking in my -00 draft, but I'm now thinking
that "SRTP over QUIC" seems to confuse almost everyone, and that (for
example) if you want to relay an RTP-encapsulated in-QUIC session that will
be forwarded to an RTP endpoint that isn't RTP-encapsulated
in-QUIC-capable, you could just tell the RTP middlebox out-of-band to
"forward this connection using SRTP", and that would be more obvious than
leaving middleboxes to guess what to do.

Another possibility would be to *require *RTP middleboxes to forward
RTP-encapsulated in-QUIC sessions using SRTP to any RTP endpoint that isn't
RTP-encapsulated in-QUIC-capable so the middlebox doesn't have to guess,
and an RTP sender knows what will happen on the other side of a (trusted)
middlebox.

But I'm not sure whether there is one answer that will work for every
flavor of "RTP middlebox" described in RFC 7667 - there are a lot of them -
and I'd like to have someone demanding to do this, before we go through all
those possibilities in this document.

Thoughts from anyone are welcome, of course.

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 27 Feb 2022 21:53:46 -0600

I should add one more point.

On Sat, Feb 26, 2022 at 11:37 PM Roman Shpount <[email-masked]> wrote:

> This is very interesting and can be one more reason to use QUICK instead
> of DTLS. The problem would be to map a pair of tls-id to a Connection-Id.
>

(After agreeing with Bernard's points)

Within the "Media Over QUIC" conspiracy, we have some folks that are
assuming they would use datagrams ("because datagrams"), and other folks
assuming they would use streams ("because multiplexing"). One of the things
that I'm finding in conversations on that side of the fence is that the
choice isn't obvious (even though it's obvious to everyone, it's not the
same obvious answer).

The QUIC working group started out thinking that they obviously needed some
way to multiplex datagrams, but then discovered that there were a lot of
(potentially conflicting) reasons to want to multiplex datagrams, so they
punted that to the application, in
https://www.ietf.org/archive/id/draft-ietf-quic-datagram-10.html#name-multiplexing-datagrams
.

I wrote about this in more detail, in
https://spencerdawkins.github.io/sdp-rtp-quic-questions/draft-dawkins-sdp-rtp-quic-questions.html#name-quic-datagram-multiplexing
.

(I *really *need to update my sdp-rtp-quic*-questions* draft - I wasn't
expecting that, but I'm happy to do it)

Best,

Spencer

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Feb 2022 20:14:56 -0800

In P2P there is the potential need to multiplex/demultiplex:
1. RTP/RTCP over QUIC datagrams,
2. Data over QUIC datagrams, (unreliable/unordered)
3. Data over a QUIC reliable stream (reliable/ordered),
4. Message per stream (reliable/unordered)

Cases 3/4 could be either data or media (e.g. case 3 could be GoP per
stream, 4 could be encoded frame per stream).

On Sun, Feb 27, 2022, 7:54 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> The QUIC working group started out thinking that they obviously needed
> some way to multiplex datagrams, but then discovered that there were a lot
> of (potentially conflicting) reasons to want to multiplex datagrams, so
> they punted that to the application, in

---

From: Roman Shpount <[email-masked]>
Date: Sun, 27 Feb 2022 23:36:14 -0500

I want to be clear about what I am asking: I am asking about multiplexing
multiple QUIC connections as a whole over the same transport (address/port
pairs).

In P2P, it is possible for one party to etsablish a new connection over the
same address/port pairs when the previous connection is still used to send
data. Most commonly, this happens due to races between signaling and media.
_____________
Roman Shpount

On Sun, Feb 27, 2022 at 11:15 PM Bernard Aboba <[email-masked]>
wrote:

>>>> [BA] This should be possible. The means will differ depending on
>>>> whether we are talking about P2P QUIC (where you could use Connection-Id)
>>>> or something higher up the stack. Multiplexing as defined in rfc7983bis
>>>> wasn’t implemented in the P2P (g)QUIC Origin trial since the QUIC
>>>> implementation was pre-standard and lacked the capability. So only one
>>>> connection was allowed. At the time the focus was on P2P data not media,
>>>> but in the absence of priority support, it seemed desirable to allow
>>>> distinct data and media connections that might be constructed to use
>>>> different cc algorithms.
>>>>
>>>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 28 Feb 2022 09:43:16 -0600

Hi, Roman,

> multiple QUIC connections as a whole over the same transport (address/port

Keeping in mind what Bernard said - "multiplex" is an overloaded term in
the QUIC community ...  but for your question.

>
> In P2P, it is possible for one party to etsablish a new connection over
> the same address/port pairs when the previous connection is still used to
> send data. Most commonly, this happens due to races between signaling and
> media.
>

Are you asking about

   - multiplexing QUIC connections within a single five-tuple, or
   - multiplexing RTP sessions over QUIC streams, or
   - multiplexing RTP sessions over QUIC datagrams?

If it's really the first one on my list, that should work, based in
https://www.rfc-editor.org/rfc/rfc9000.html#name-connections - sorry for
pointing to the whole section, but the description of this isn't in one
place, that I can find.

Does that help?

Best,

Spencer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 28 Feb 2022 17:29:47 -0500

Hi Spencer,

Yes, I was asking about multiplexing QUIC connections within a single
five-tuple. Thank you for the reference to connection IDs.

Do you think it makes sense to expose QUIC connection IDs in SDP, such as
tls-id or something similar?

Best,
_____________
Roman Shpount

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 01 Mar 2022 10:16:32 +1100

On Tue, Mar 1, 2022, at 09:29, Roman Shpount wrote:
> Do you think it makes sense to expose QUIC connection IDs in SDP, such 
> as tls-id or something similar? 

No.  Let the endpoints manage connection IDs.  Both QUIC and TLS have mechanisms that endpoints can use to avoid unnecessary collisions.  Tying that into session negotiation would constrain those mechanisms.

Yes, this is not particularly conducive to intermediation of the form that does not participate in the end-to-end session properly.  That's a feature.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 28 Feb 2022 18:25:18 -0500

On Mon, Feb 28, 2022 at 6:17 PM Martin Thomson <[email-masked]> wrote:

> No.  Let the endpoints manage connection IDs.  Both QUIC and TLS have
> mechanisms that endpoints can use to avoid unnecessary collisions.  Tying
> that into session negotiation would constrain those mechanisms.
>
> Yes, this is not particularly conducive to intermediation of the form that
> does not participate in the end-to-end session properly.  That's a feature.
>

In the P2P case, how should the connection be mapped to the certificate?
Should we use fingerprints, similar to DTLS? Should all possible
fingerprints be checked if multiple connections are used over the same
5-tuple?
_____________
Roman Shpount

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 01 Mar 2022 10:32:00 +1100

On Tue, Mar 1, 2022, at 10:25, Roman Shpount wrote:
> In the P2P case, how should the connection be mapped to the 
> certificate? Should we use fingerprints, similar to DTLS? Should all 
> possible fingerprints be checked if multiple connections are used over 
> the same 5-tuple?

Good question.  It's possible that you could use SDP to set the initial connection ID for that purpose, but that comes with a pretty major downside in that you then also need to hook into address validation more deeply because you are then interfering with the functioning of that mechanism in QUIC (TLS doesn't address validation, so that isn't affected).

What I would instead suggest is one of three things:

1. Use one certificate.  If this is a single endpoint that is sharing a UDP port, then the need for multiple certificates is hard to comprehend.

2. Make one connection at a time.  This is probably only useful if you are sharing ports and creating multiple sessions.

3. Use the external_session_id TLS extension defined in Section 4.3 of RFC 8844.  Not only does that protect you from the attacks in that document, it can act as a unique key for mapping the connection to your SDP.

The last of these is probably what you really want, but it's new code and not widely implemented (to my knowledge).

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Feb 2022 20:51:20 -0500

> No.  Let the endpoints manage connection IDs.  Both QUIC and TLS have mechanisms that endpoints can use to avoid unnecessary collisions.  Tying that into session negotiation would constrain those m…

Isn't this a lot like SCTP? We already worked out all the SDP for 
connections there.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Feb 2022 20:51:42 -0500

Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 28 Feb 2022 18:08:58 -0800

"Isn't this a lot like SCTP?"

[BA] QUIC's built-in TLS exchange is similar to DTLS in that both will
utilize self-signed certificates with exchange of fingerprints.  Also, both
QUIC and DTLS will run over ICE.

There are also differences:

1. I believe that the intent is to use QUIC datagrams and streams for data
and media exchange rather than the RTCDataChannel abstraction that runs on
top of SCTP.
2. SCTP is tunneled over UDP, whereas QUIC runs directly over UDP.  This
means that SCTP has extra headers and multiplexing points (e.g. SCTP
ports).

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 01 Mar 2022 13:53:30 +1100

Has anyone seriously considered using QUIC-SRTP?  You could use the QUIC session for data and other such things, but some or all of the media could run alongside.  I'm not following the RTP over QUIC work very closely, but it seems like an interim solution - which would be much more like SCTP and its use with bundle - might be a low effort option.

On Tue, Mar 1, 2022, at 13:08, Bernard Aboba wrote:
> utilize self-signed certificates with exchange of fingerprints.  Also, 
> both QUIC and DTLS will run over ICE.
>
> 1. I believe that the intent is to use QUIC datagrams and streams for 
> data and media exchange rather than the RTCDataChannel abstraction that 
> runs on top of SCTP.  
> 2. SCTP is tunneled over UDP, whereas QUIC runs directly over UDP.  
> This means that SCTP has extra headers and multiplexing points (e.g. 
> SCTP  ports). 
>
>
>
> On Mon, Feb 28, 2022 at 5:51 PM Paul Kyzivat <[email-masked]> wrote:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 28 Feb 2022 21:30:59 -0600

Hi, Martin,

On Mon, Feb 28, 2022 at 8:54 PM Martin Thomson <[email-masked]> wrote:

> Has anyone seriously considered using QUIC-SRTP?  You could use the QUIC
> session for data and other such things, but some or all of the media could
> run alongside.  I'm not following the RTP over QUIC work very closely, but
> it seems like an interim solution - which would be much more like SCTP and
> its use with bundle - might be a low effort option.
>

I'm not sure what you're describing. Would this be something like

Media
---------
SRTP
---------
QUIC
----------
UDP

or something else?

Best,

Spencer

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 01 Mar 2022 14:43:48 +1100

Not quite.

QUIC is good for the data path:

Data > QUIC > UDP

But for media you would have:

Media > SRTP > UDP

That looks independent.  But the keys for SRTP would be derived from the adjacent QUIC connection, rather than a DTLS association.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 28 Feb 2022 22:24:30 -0800

> Has anyone seriously considered using QUIC-SRTP?  You could use the QUIC session for data and other such things, but some or all of the media could run alongside.  I'm not following the RTP over QU…

[BA] The discussion on RTP/QUIC is relatively young at this point. So it’s a good time to ask “why?” questions.

Are there use cases where QUIC-SRTP might be preferred to say, RTP integrated with QUIC (what the TUM team has been investigating)? If so, why?

It doesn’t seem like QUIC with NewReno or BBRv1/2 is well suited to RTC applications or even low latency streaming, but perhaps another cc algorithm (GCC or SCreAM) might fix that. 

Is QUIC-SRTP just for the scenario where that doesn’t pan out, and it’s desirable to avoid a dependency on both QUIC and DTLS-SRTP?