Re: [AVTCORE] [EXTERNAL] Re: Registering AVP Profiles for RTP over QUIC

["Asveren, Tolga" <[e-mail]>]

Maybe a somewhat different perspective on this whole issue:

  *   "SAVP" stands for "Secure AVP Profile" and refers to use of SRTP
     *   So, arguably it should be signaled only if SRTP is to be used
  *   With QUIC -or with UDP/DTLS- there is no need for SRTP from hop-to-hop security perspective
  *   How to signal middleboxes that SRTP has to be used for their downstream media legs as well
     *   Does "SAVP" actually mean that?
     *   I would argue that technically not and the final outcome is left to the interpretation/configuration of the middlebox
  *   Is it useful and sometimes even needed- to signal that media stream needs to secured across the whole path?
     *   Probably and arguably this should be signaled in an explicit way in SDP



Thanks,

Tolga

-----Original Message-----
From: avt <[e-mail]> On Behalf Of Martin Thomson
Sent: Wednesday, May 11, 2022 9:19 PM
To: [e-mail]
Subject: [EXTERNAL] Re: [AVTCORE] Registering AVP Profiles for RTP over QUIC



Hi Roman,



I've always considered QUIC-SRTP to be a viable alternative to DTLS-SRTP.  The challenge there is that it is not specified as possible.



I think that people here are looking to pick up more of the advantages of QUIC though.  That is, even if that means losing some of the advantages of existing stuff as SCTP <-> QUIC is not a seamless transition and SRTP/QUIC has some interesting properties.



On Thu, May 12, 2022, at 11:15, Roman Shpount wrote:

> Hi Spencer,

>

> I was thinking not about using QUIC to transport RTP, just to

> negotiate the encryption keys and protocol. Once keys and protocol are

> negotiated, SRTP-over-UDP sends the packets. SRTP/SRTCP packets are

> demultiplexed from QUIC, and both protocols run side-by-side. This

> means none of the QUIC encryption, NACK, congestion control, etc., is

> used for media. It is an exact equivalent of DTLS-SRTP with QUIC being

> used instead of DTLS to negotiate keys.

>

> Even if this draft does not cover such a set-up, I think it is a

> viable network configuration. Whatever protocol name you will come up

> with, it should be possible to differentiate media over QUIC vs. key

> negotiation over QUIC.

> _____________

> Roman Shpount

>

>

> On Wed, May 11, 2022 at 6:41 PM Spencer Dawkins at IETF

> <[e-mail]<mailto:[e-mail]>> wrote:

>> Hi, Roman,

>>

>> On Wed, May 11, 2022 at 4:12 PM Roman Shpount <[e-mail]<mailto:[e-mail]>> wrote:

>>> What about using QUIC for encryption session setup and SRTP for sending media, similar to DTLS-SRTP? This can be the easiest option to implement.

>>

>> I'm not aware of a way to stop encryption in RFC 9000 QUIC, which is using RFC 9001 TLS for key exchange, etc, in favor of an application-level encryption mechanism. This has come up a number of times in conversations with 3GPP, who also wanted to avoid duplicate encryption (details don't matter, at this point), and the IETF has always said they wouldn't provide that.

>>

>> But maybe something has changed?

>>

>> Best,

>>

>> Spencer

>>

>>> Best,

>>> _____________

>>> Roman Shpount

>>>

>>>

>>> On Wed, May 11, 2022 at 4:47 PM Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>> wrote:

>>>> Dear AVTCORE,

>>>>

>>>> I've had an open PR in https://clicktime.symantec.com/3TSmRngAhdKrRbCSwZPQ3HA6H4?u=https%3A%2F%2Fgithub.com%2FSpencerDawkins%2Fsdp-rtp-quic%2Fpull%2F9 for a while,so I could get a sense of how AVT profiles are supposed to work, and I'd like to push on that now (with a virtual interim meeting coming up next week)..

>>>>

>>>> The high-level summary of discussion in https://clicktime.symantec.com/3R2yBz2ZCbhWMW3QYKvVfK26H4?u=https%3A%2F%2Fgithub.com%2FSpencerDawkins%2Fsdp-rtp-quic-issues%2Fissues%2F5 (note that this discussion is in a different repo, because reasons) has been roughly,"what's the difference between QUIC/RTP/AVPF and QUIC/RTP/SAVPF"?

>>>>

>>>> The arguments about not registering secure AVP profiles involve

>>>>  *  the computational overhead of double encryption for all

>>>> packets, plus

>>>>  * the payload overhead of 10 bytes per packet since you have 2 HMACs.

>>>> The arguments about registering secure AVP profiles seem to revolve

>>>> around

>>>>  * Minimizing the impact of added QUIC support in existing implementations that are using /RTP/SAVPF now.

>>>>  * QUIC encryption protects payloads between QUIC endpoints, but there are many multi-endpoint RTP topologies (https://clicktime.symantec.com/37MgqdQA3JHTWFiLP2243MF6H4?u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc7667 has about 50 pages of them), and when a middlebox receives  QUIC/RTP/AVPF, it's not obvious whether the middlebox should

>>>>    * forward the RTP payload using  RTP/AVPF (where the outgoing AVPF matches the incoming AVPF), or

>>>>    * forward the RTP payload using RTP/SAVPF, where the outgoing

>>>> SRTP encryption matches the incoming QUIC It seems to me that there are three choices:

>>>>  * Use only QUIC/RTP/AVPF, and and require middleboxes receiving

>>>> QUIC/RTP/AVPF traffic to always forward that traffic over RTP/SAVPF

>>>>  * Use only QUIC/RTP/AVPF, and and require senders to signal

>>>> middleboxes whether they should forward that traffic over RTP/AVPF

>>>> or RTP/SAVPF

>>>>  * Register both QUIC/RTP/AVPF and QUIC/RTP/SAVPF, and if you have

>>>> to do double encryption on the QUIC/RTP paths to get RTP/SAVPF on

>>>> the other side of a middlebox, too bad So, my questions are,

>>>>  * What am I missing here?

>>>>  * Are any of the choices I'm listing obviously the *BEST* choice?

>>>> Best,

>>>>

>>>> Spencer

>>>> _______________________________________________

>>>> Audio/Video Transport Core Maintenance [e-mail]<mailto:[e-mail]>

>>>> https://clicktime.symantec.com/3CNt68QCPT58CV457HLugmp6H4?u=https%3<https://clicktime.symantec.com/3CNt68QCPT58CV457HLugmp6H4?u=https%253>

>>>> A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Favt

> _______________________________________________

> Audio/Video Transport Core Maintenance [e-mail]<mailto:[e-mail]>

> https://clicktime.symantec.com/3CNt68QCPT58CV457HLugmp6H4?u=https%3A%2<https://clicktime.symantec.com/3CNt68QCPT58CV457HLugmp6H4?u=https%3A%252>

> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Favt



_______________________________________________

Audio/Video Transport Core Maintenance

[e-mail]<mailto:[e-mail]>

https://clicktime.symantec.com/3CNt68QCPT58CV457HLugmp6H4?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Favt

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.