Re: [MSEC] QUIC multicast

Hi Behcet,

I’d encourage you to read sections 1 and 4 of the draft, which try to cover this in some detail.

The summary answer is that there’s always a unicast connection as an anchor, but the server can ask the client to additionally join multicast channels that carry QUIC packets that can be decoded by the client using information that was passed to the client over the unicast connection.

Those packets have a channel id instead of a connection id, as well as secrets that are generated and distributed differently than the unicast secrets (with the in-depth examination of the security consequences of this covered in our earlier draft-krose-multicast-security doc), but the handling is otherwise very similar to handling for QUIC multipath packets.

HTH.

-Jake

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tue,2022-06-28 at 8:53 AM
To: "Holland, Jake" <jholland@akamai.com>
Cc: "msec@ietf.org" <msec@ietf.org>
Subject: Re: [MSEC] QUIC multicast

On Mon, Jun 27, 2022 at 10:48 AM Holland, Jake <jholland=40akamai.com@dmarc.ietf.org<mailto:40akamai.com@dmarc.ietf.org>> wrote:
Hi msec,

One of the actionable pieces of feedback[1] from the secdispatch
presentation of draft-krose-multicast-security at IETF 112 was
that we needed a concrete protocol proposal in order to evaluate
the security considerations, so we went ahead and made a
concrete proposal for multicast QUIC:
https://datatracker.ietf.org/doc/draft-jholland-quic-multicast/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-jholland-quic-multicast/__;!!GjvTz_vk!WLI8K0REmBUeJXD8Ej_71_7ACc80QBBiN3l8uU2VEeWp44usc-fp8cEfrfiEemXLTEOJg5PyoY7i4lv2dGuCBA$>
https://github.com/GrumpyOldTroll/draft-jholland-quic-multicast<https://urldefense.com/v3/__https:/github.com/GrumpyOldTroll/draft-jholland-quic-multicast__;!!GjvTz_vk!WLI8K0REmBUeJXD8Ej_71_7ACc80QBBiN3l8uU2VEeWp44usc-fp8cEfrfiEemXLTEOJg5PyoY7i4lsEw-3FOg$>

We think this proposal meets the security goals given in
draft-krose-multicast-security (plus the one that Ekr raised that
we haven't added text for about web content needing to be associated
with a url), but if you can see any sense in which this draft falls
short or is unclear on how those security properties are achieved,
we'd love to get that feedback (and suggestions on fixing it if you
have any).

I haven't sent this to quic yet, but will do so before long
unless anyone in msec can point out a critical flaw.  I'm planning
to ask for a short slot in quic to present at 114.  My main question
will be about what wg members would want to see addressed before
we ask for adoption (not planning to ask for adoption this time yet),
plus soliciting general feedback.

Before sending to quic, will you please let me know how multicast will work with a connection oriented  transport protocol which Quic largely is?

Behcet
-Jake

PS: several members of the W3C Multicast Community Group have
been working on an implementation and we'll have a table at the
hackathon, so if you'd like to be involved with that, please let
me know.

[1] notes from the secdispatch feedback:
https://mailarchive.ietf.org/arch/msg/msec/FYx5GsAtAyI3pypPIlJ_s3vtiwc/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/msec/FYx5GsAtAyI3pypPIlJ_s3vtiwc/__;!!GjvTz_vk!WLI8K0REmBUeJXD8Ej_71_7ACc80QBBiN3l8uU2VEeWp44usc-fp8cEfrfiEemXLTEOJg5PyoY7i4lsbbSpK7w$>

_______________________________________________
MSEC mailing list
MSEC@ietf.org<mailto:MSEC@ietf.org>
https://www.ietf.org/mailman/listinfo/msec<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/msec__;!!GjvTz_vk!WLI8K0REmBUeJXD8Ej_71_7ACc80QBBiN3l8uU2VEeWp44usc-fp8cEfrfiEemXLTEOJg5PyoY7i4luYDboKgw$>