QUIC interaction with ICE

[SpencerDawkins]

We need QUIC-ICE in order to support peer-to-peer operation, but some functionalities overlap between ICE and QUIC. For example,

• QUIC validates addresses, and ICE nominates candidate pairs
• QUIC Ping frames and ICE Keepalives And, of course, ICE prioritizes candidate pairs, which QUIC might have opinions about for connection migration.

That's probably an incomplete list. But we need to figure this out.

[aboba]

QUIC over ICE shipped in a Chromium Origin Trial in 2019, and these issues were addressed as follows:

• QUIC connection migration was not enabled, since this was handled by ICE, just as SCTP migration is not supported in WebRTC data channel.

• ICE keepalives were implemented, since the socket can be shared (e.g. QUIC, SRTP/SRTCP, DTLS, ZRTP can be multiplexed) and so you can't assume that the keepalives are solely handled by QUIC.

• For similar reasons, you need both ICE connectivity checks and QUIC address validation.

[SpencerDawkins]

@SpencerDawkins and @mengelbart suspect that the ICE negotiations may belong in another document that this document will reference, saying "you need an open validate QUIC connection, and if you can't find the other endpoint without ICE, you need to go look at ICE-for-QUIC and come back here when you do have an open valid QUIC connection".

[SpencerDawkins]

@SpencerDawkins thinks this is probably the RoQ version of https://github.com/moq-wg/moq-requirements/issues/103, and should probably have the same proposed path forward at this time, which is, for reference,

I think the Right Thing To DO is for us to participate in, and gate this issue on, discussion of draft-seemann-quic-nat-traversal-00 and draft-thatcher-p2p-quic-00 in the QUIC working group. @LPardue, is that WRONG?

I'll leave this tagged "Deferred for now" for now.

We don't have "Deferred for now" in THIS repo, but we do have "Not Yet", so it's probably correctly tagged for now.

[SpencerDawkins]

@SpencerDawkins is taking the action to see what, if anything, the QUIC working group can/will do to add ICE support to the base QUIC protocol, noting that my understanding from @aboba is that this is critical for WebRTC use of RoQ.

[aboba]

A complete replacement of ICE by QUIC is probably a long-term project. But there are a few immediate questions:

a. The overlap between ICE candidate pair selection and QUIC interface selection. Only one of these is probably needed. b. The use of QUIC ping for consent freshness versus RFC 7675.

Other things (possibly handled in an SDP doc) c. The authentication mechanism. Self-signed certs with hash verification in signaling? d. It is possible to multiplex more than one RoQ connection on the same socket?

[SpencerDawkins]

(This was actually part of a comment in the wrong issue - sorry! fixed now)

I'm thinking we can defer this issue for now and see how P2P QUIC and/or Using QUIC to traverse NATs progress. Thoughts?

[SpencerDawkins]

So, I've re-read the current doc on ICE, and the only place ICE is mentioned is here.

Given that the document doesn't describe interactions with, or implications of, using RoQ with ICE, my suggestion for this version of the specification is that we delete the second paragraph in Section 12.1, and consider mentioning this in the Future Work section proposed in #161 - that issue already says we should mention ICE in the new section.