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

Hi, Roman,

On Wed, May 11, 2022 at 4:12 PM Roman Shpount <roman@telurix.com> 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 <
> spencerdawkins.ietf@gmail.com> 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
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>>
>