How to identify QUIC transport sessions

[samhurst]

The draft currently doesn't specify how to identify a QUIC transport session that will carry the RTP-over-QUIC traffic. I think we could adopt the COMEDIA mechanisms specified for TCP and adapt them to QUIC. RFC4145 specifies how to do it with regular TCP and section 8 describes how to apply it to protocols that are not TCP. Then there's RFC8122 which adds things about TLS (which I haven't read in detail yet so I don't know if this is helpful, but I'm linking it here anyway just in case).

The only concern I have is that existing COMEDIA options all use the 5-tuple to uniquely identify a transport connection. However, a QUIC connection is not bound to a single 5-tuple, as it can perform connection migration. In future, this would also preclude the description of multipath QUIC sessions.

In the case where a new connection is established, this should be fine - but the concern here is about reuse of existing connections. Given that QUIC allows multiplexing of traffic, there's definitely a use-case where you could negotiate SDP media descriptions using something like SIP-over-QUIC using bidirectional streams, and then re-use the same transport connection with the callee/caller to run the RTP over unidirectional streams.

I don't have a good answer to the identification of extant QUIC transport associations at the moment, so this is more of an open question. We also can't use QUIC connection IDs as for one they can be generated and revoked at any time by the transport layer, and two I feel that putting connection IDs in an SDP media description is a security problem as it means an attacker could gain prior knowledge of some of the things which might be present in a QUIC transport packet, and use that to help attack the encryption context.

[SpencerDawkins]

@mengelbart, the last time you and I talked about flow IDs, we said they were scoped to a QUIC connection, is that right?

In order to address @samhurst's question, it looks to me like

• including QUIC connections in the SDP is not a good idea,
• but we need some kind of identifier that tells the answerer side of SDP that two different QUIC connections are related, unless we are punting both QUIC connection migration and QUIC multipath.

If Flow IDs are scoped to a "RoQ Session", which could span QUIC connections, we can include Flow IDs in the SDP and solve this problem, but "RoQ session" is an undefined term which is used exactly once in the RoQ specification. Do you have any thoughts about this, or should I just create an issue in https://github.com/mengelbart/rtp-over-quic-draft?

[mengelbart]

I don't think using flow IDs to identify QUIC connections is a good solution for this problem. It requires reading the payload of at least one RTP/RTCP packet but doesn't allow the endpoint to identify the QUIC connection based on the handshake packets.

This is a hard problem, and I am not sure how we can solve it. In addition to connections changing their 5-tuple, I think we could also have multiple connections with the same 5-tuple, which doesn't make it easier...

However, I wouldn't rule out connection IDs completely. Maybe we can't put explicit IDs in SDP directly, but maybe there's a way along the lines of what the QUIC LB draft is doing by encoding some information in the connection ID?

[samhurst]

It is a very hard problem indeed, as we're trying to do something that QUIC was expressly designed to avoid. I still think that adopting the COMEDIA approach to specify new/existing connections is required, and it's always an option to be more prescriptive than the QUIC spec allows - for example, it could be written that we can't reuse QUIC connections that are multiplexed on the same 5-tuple. The SDP answerer would be expected to change the connection attribute to "new" if this condition cannot be met, as specified in section 5.1 of RFC 4145.

I think it's also worth thinking about whether we want to consider the capabilities of extant QUIC connections to slim down the pool of potential reuse candidates. For example, if you've got three QUIC connections to choose from, you could look at the negotiated ALPNs for those connections and decide whether they would be compatible. For example, any h3 ones wouldn't be compatible, but any with roq would be. Equally, any other ALPNs that include scope for carrying RoQ frames (such as SIP-over-QUIC, which may be the same connection exchanging these SDP documents) could be considered.

I'm not sure the QUIC-LB approach would really work here, as it will make a lot of assumptions on how QUIC stacks work. The connection would need to support it right from the beginning, and if the connection is owned by something like a web browser I don't know what level of imposition we can realistically make on how they generate connection IDs. And indeed, it implies a much tighter bindings to the internals of a QUIC connection than realistically RoQ or SDP needs to have.

I have also tried looking for other attributes or features that already exist in QUIC that we could use, and I'm coming up a bit short. We could reuse the token which is exchanged by NEW_TOKEN frames, but this is used to validate connection paths so this would be information leakage that an attacker could exploit to make the QUIC stack do something odd, same as disclosing connection IDs. The only other option I've come up with is to invent a new transport parameter that just stores a random value which is otherwise never shared between endpoints as a way of identifying QUIC connections out-of-band, but again this requires more fiddling deeper in the QUIC stack.

[SpencerDawkins]

Upon reflection, I think much of this is related to consideration of BUNDLE in #3.