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

[Martin Thomson <[e-mail]>]

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]> wrote:
>> Hi, Roman, 
>> 
>> On Wed, May 11, 2022 at 4:12 PM Roman Shpount <[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]> wrote:
>>>> Dear AVTCORE, 
>>>> 
>>>> I've had an open PR in https://github.com/SpencerDawkins/sdp-rtp-quic/pull/9 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://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/5 (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://www.rfc-editor.org/rfc/rfc7667 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]
>>>> https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt